What this holds about a person¶
7 tables, 17 columns about a person, 6 things held outside a column, 1 kind of data subject, 0 destinations. Some of it is kept indefinitely, and every one of those says why below.
What it holds¶
abandoned_carts_episode¶
Who a row is about: the shopper, by email on this table.
What makes a row go away: never — The row stands after an erasure and after the retention window, and nothing deletes it: the recovered-revenue figure is a sum over episodes and must not shrink retroactively, and a backfill reads the same rows to know who was already emailed. What is kept is a counter: one store, one language, one set of dates, one outcome. The address, the token, the coupon code and the error are emptied instead, and carry their own verdict.
| Column | What it is | Why it exists | What an erasure does |
|---|---|---|---|
store_id |
about |
Which storefront this person abandoned a checkout at, carried because the pass runs per store and the opt-out list is scoped by the same number. | retain |
email |
identifies |
The address the checkout was started with, exactly as core recorded it on the order, and the one the reminders go to. | blank |
opencart_customer_id |
refers |
The account the checkout belonged to, or 0 for a guest — what lets the landing link put the cart back into the right account. | retain |
language_code |
about |
Which language this person was written to in, a code rather than an id so a reused id cannot send a message in the wrong language. | retain |
token |
about |
The unguessable secret behind the link in the message, which puts the cart back and serves the unsubscribe. A bearer credential; NULL until the first send. | blank |
coupon_code |
about |
The single-use code a marketing sequence offered this person, when the merchant chose to offer one. | blank |
converted_order_id |
refers |
The order this person went on to place, which is what the recovered-revenue figure counts. Core's own row. | retain |
error |
about |
Why this episode could not be served, as the pass recorded it. A mail server's refusal can quote the address back, so it is shed with the address. | blank |
purged |
about |
The flag saying the personal part of this row is gone, which is what tells erased from never captured. | retain |
date_opened |
about |
When this person walked away from the checkout, which every delay is measured from. | retain |
date_last_send |
about |
When this person was last written to, which is what the per-address cooldown and the expiry are measured from. | retain |
date_clicked |
about |
When this person first followed the link, kept as a diagnostic and never as the basis of the recovered-revenue claim. | retain |
email is kept differently from the rest of the table: blanked — Emptied in place once the episode has been closed for longer than the merchant's window, and purged set.
How long: the module_abandoned_carts_retention_days setting — How long a closed episode keeps the shopper's address and lines, in days. Retention blanks them and never deletes the row, so what was sent and what came back is still counted. A year by default, which is the one retention period a data-protection regulator has accepted for exactly this data.
A store that has not changed it answers 365. You set it at Admin > Extensions > Extensions > Modules > Abandoned Cart Recovery.
token is kept differently from the rest of the table: blanked — Emptied in place once the episode has been closed for longer than the merchant's window, and purged set.
How long: the module_abandoned_carts_retention_days setting — How long a closed episode keeps the shopper's address and lines, in days. Retention blanks them and never deletes the row, so what was sent and what came back is still counted. A year by default, which is the one retention period a data-protection regulator has accepted for exactly this data.
A store that has not changed it answers 365. You set it at Admin > Extensions > Extensions > Modules > Abandoned Cart Recovery.
coupon_code is kept differently from the rest of the table: blanked — Emptied in place once the episode has been closed for longer than the merchant's window, and purged set.
How long: the module_abandoned_carts_retention_days setting — How long a closed episode keeps the shopper's address and lines, in days. Retention blanks them and never deletes the row, so what was sent and what came back is still counted. A year by default, which is the one retention period a data-protection regulator has accepted for exactly this data.
A store that has not changed it answers 365. You set it at Admin > Extensions > Extensions > Modules > Abandoned Cart Recovery.
error is kept differently from the rest of the table: blanked — Emptied in place once the episode has been closed for longer than the merchant's window, and purged set.
How long: the module_abandoned_carts_retention_days setting — How long a closed episode keeps the shopper's address and lines, in days. Retention blanks them and never deletes the row, so what was sent and what came back is still counted. A year by default, which is the one retention period a data-protection regulator has accepted for exactly this data.
A store that has not changed it answers 365. You set it at Admin > Extensions > Extensions > Modules > Abandoned Cart Recovery.
abandoned_carts_evidence¶
Who a row is about: the shopper, by order_id matched into order.order_id, which names them at email.
What makes a row go away: never — Nothing on an evidence row names anybody — it is a pair of numbers joining an episode to a checkout core itself keeps for ever — so what is kept is the store's own record that a checkout was absorbed, which stops the pass opening a second episode for it.
| Column | What it is | Why it exists | What an erasure does |
|---|---|---|---|
order_id |
refers |
A checkout this person started and did not finish, and the only route back to them. It is core's row, which core never purges. | retain |
abandoned_carts_send¶
Who a row is about: the shopper, by episode_id matched into abandoned_carts_episode.episode_id, which names them at email.
What makes a row go away: never — Each row is one attempted message, and the rolling daily send limit and the recovered-revenue funnel both count over them. The row is never deleted, and the transport error is emptied on an erasure and at the retention window with its episode's address, because it can quote the address; the rest is a count and a date.
| Column | What it is | Why it exists | What an erasure does |
|---|---|---|---|
error |
about |
Why one message to this person could not be sent, as the transport reported it — which can quote the address back. | blank |
date_sent |
about |
When this message was attempted, which is what the rolling daily send limit counts over. | retain |
error is kept differently from the rest of the table: blanked — Emptied with its episode's address once that episode has been closed for longer than the merchant's window. The row itself stays.
How long: the module_abandoned_carts_retention_days setting — How long a closed episode keeps the shopper's address and lines, in days. Retention blanks them and never deletes the row, so what was sent and what came back is still counted. A year by default, which is the one retention period a data-protection regulator has accepted for exactly this data.
A store that has not changed it answers 365. You set it at Admin > Extensions > Extensions > Modules > Abandoned Cart Recovery.
abandoned_carts_suppression¶
Who a row is about: the shopper, by email on this table.
What makes a row go away: never — Never purged and never dropped: an entry is a person's request not to be emailed, and a store that erased it would be free to start emailing them again. Removing an address is a merchant's deliberate act on the list itself, not a side effect of an erasure.
| Column | What it is | Why it exists | What an erasure does |
|---|---|---|---|
email |
identifies |
The address that asked not to be emailed. It is the whole of the entry, and erasing it would start the mail again, so it is kept. | retain |
source |
about |
How the request arrived — link where the person clicked the unsubscribe link, manual where a merchant honoured one that came in another way. |
retain |
What it holds that is not in a column¶
A file, a cookie and a key in the session are exactly where an erasure written as row deletion reaches nothing, and no schema can be diffed to find one. Each is listed here with what keys it to a person, why it is there, and what removes it.
A file on disk. kyvero.log in the store's own DIR_LOGS, the one diagnostic file every extension in this repository shares, capped at 1 MiB and trimmed oldest-first.
Nothing keys this to a person — every message is put through the diary's redaction rule before a byte is written, which is what makes the file survivable where OpenCart puts its own error log.
Why it is here: A merchant reporting a failure needs one place to look, and a support conversation without it is guesswork on both sides.
What an erasure does: retain.
A file on disk. Not a file at all: the standard error of abandoned_carts.php, the command-line entry point a merchant runs a pass from. Five one-line diagnostics — three saying the bootstrap could not find, read or recognise a store, one reporting an exception the bootstrap caught, and one reporting that the controller behind the command would not load. Where that stream goes is the operator's own crontab or terminal, and nothing here opens a file.
Nothing keys this to a person — each is a fixed sentence about a file path or a class name, or an exception's class and message. No address, no order number and no token is interpolated into any of them.
Why it is here: A pass run from a crontab has nowhere else to say that it could not start, and a cron job silent about that is one a merchant discovers is broken when a shopper was never reminded.
What an erasure does: retain.
A key in the store's session. Core's own success key, written by the reminder's link when it sends the shopper to the cart page: one or two sentences out of this extension's own storefront language file, naming the products that could not be put back.
It does not outlive the request that wrote it: this is session state, gone when the session is, without a clock having to run or a request having to reach it.
Nothing keys this to a person — sentences the store wrote, with product names from the catalogue and nothing of the shopper's in them.
Why it is here: The cart page is where core renders what just happened, beside the lines, and a redirect has nowhere but the session to carry the sentence.
What an erasure does: retain.
A key in the store's session. The session, under abandoned_carts_notice — one sentence out of this extension's own admin language file, carried across the redirect that follows a resend, a stop or a suppression added or lifted on the Episodes list, or a pass run by hand.
It does not outlive the request that wrote it: this is session state, gone when the session is, without a clock having to run or a request having to reach it.
Nothing keys this to a person — the key belongs to the member of staff whose admin session it is, and what it holds is a sentence the store wrote about an act they have just performed, with no address in it.
Why it is here: A POST that redirects has nowhere but the session to carry the sentence saying what happened, and the alternative is putting it in the query string of the page it lands on.
What an erasure does: retain.
A key in the store's session. The session, under abandoned_carts_notice_error — the boolean beside that sentence saying whether it reports a success or a failure, so that the screen knows which alert to paint it in.
It does not outlive the request that wrote it: this is session state, gone when the session is, without a clock having to run or a request having to reach it.
Nothing keys this to a person — a boolean, carried for one redirect.
Why it is here: The sentence and the kind of sentence travel together or the screen paints a failure green.
What an erasure does: retain.
A key in the store's session. The admin's own session, written when a merchant starts a backfill: whether it started, and one sentence out of this extension's admin language file with the number of shoppers and days in it.
It does not outlive the request that wrote it: this is session state, gone when the session is, without a clock having to run or a request having to reach it.
Nothing keys this to a person — a count and a sentence the store wrote, with no address in it.
Why it is here: Starting a backfill redirects back to the screen, and a redirect has nowhere but the session to carry what happened.
What an erasure does: retain.
What it deliberately does not hold¶
Abandoned Cart Recovery has nothing written down here. This section is where a column somebody decided against is recorded with the reason, and an empty one says only that nobody has recorded one — not that nothing was ever declined.
Where it goes¶
Nowhere. Nothing Abandoned Cart Recovery holds about a person leaves your store.
What the standard asks, and what this extension answers¶
Kept indefinitely, on purpose. Nothing below is removed by a clock. Each one says why, which is the part a merchant relying on it has to be able to state:
abandoned_carts_episode— The row stands after an erasure and after the retention window, and nothing deletes it: the recovered-revenue figure is a sum over episodes and must not shrink retroactively, and a backfill reads the same rows to know who was already emailed. What is kept is a counter: one store, one language, one set of dates, one outcome. The address, the token, the coupon code and the error are emptied instead, and carry their own verdict.abandoned_carts_evidence— Nothing on an evidence row names anybody — it is a pair of numbers joining an episode to a checkout core itself keeps for ever — so what is kept is the store's own record that a checkout was absorbed, which stops the pass opening a second episode for it.abandoned_carts_send— Each row is one attempted message, and the rolling daily send limit and the recovered-revenue funnel both count over them. The row is never deleted, and the transport error is emptied on an erasure and at the retention window with its episode's address, because it can quote the address; the rest is a count and a date.abandoned_carts_suppression— Never purged and never dropped: an entry is a person's request not to be emailed, and a store that erased it would be free to start emailing them again. Removing an address is a merchant's deliberate act on the list itself, not a side effect of an erasure.
What reaches them instead is the remove-everything screen, which is a request you act on rather than a clock that runs.
Each row below is keyed by the sub-paragraph of the General Data Protection Regulation
it comes from, so that you can read the source and disagree with us. What each state
means is on the data-protection boundary,
once, rather than reworded here. declared is not a pass: it says what the thing is,
not that the thing is fine.
| Article | What this extension supplies toward it | This extension |
|---|---|---|
5(1)(c) |
Every column this extension can put in a store is written down with the one sentence saying why it is there, and a column that is not fails the build — so what a store keeps is what somebody decided to keep rather than what accumulated. Beside it, in the same file and the extension's own voice, is what it deliberately does not keep, and why. | checked, 61 — every column this extension's schema can put in a store |
30(1)(c) |
What this extension holds about a person is published column by column — what the column is, whether it names somebody or points at them, and why it exists — so the record a merchant has to keep can be copied off a page rather than reconstructed out of the database. | declared |
7(1) |
Where anything this extension does rests on somebody having agreed to it, the declaration names the wording they agreed to and where the proof of it is recorded — and where nothing rests on consent it says so, because we did not need any is an answer and a blank is not. | declared |
7(3) |
A declared consent carries the path by which it is withdrawn, or the build fails — because withdrawing has to be no harder than giving, and a consent whose withdrawal path nobody wrote down is one a merchant discovers they cannot honour on the day somebody asks. | checked, 0 — every consent declared anywhere in it |
15(1) |
Every table holding anything about a person answers who that person is and how a request reaches them — a column on the table itself, the path through a table this extension does not own, or the plain statement that nothing on it keys a row to anybody — so that a request either has somewhere to arrive or is told outright that there is nowhere, rather than a screen having to guess which rows are whose. | checked, 4 — every table holding anything about a person |
16(1) |
A column holding a frozen copy of something the store holds elsewhere names the column it was copied from, so that correcting the original is an instruction a merchant can follow rather than a shrug about why the two disagree. | declared |
21(3) |
The row that records somebody saying stop names the subject it is keyed on and the verdict an erasure gives it, so that a live instruction to stop mailing survives the request that was meant to enforce it rather than being deleted by it. | declared |
25(2) |
A column that is only collected when a merchant turns something on names the setting that decides it, and the shipped value is read off the configuration declaration rather than restated here — so what a store collects out of the box is a fact on a page instead of something read out of a controller. | declared |
5(1)(e) |
Every table this extension can put in a store answers what makes a row holding a person go away — one of six verdicts, and a table that answers 'never' says why in the same breath or fails the build — so a store keeping something for ever is keeping it on purpose. | checked, 4 — every table an answer is owed for |
15(1)(d) |
The period each table is kept for is published beside what it holds, as the mechanism and — where there is one — the number or the setting it is read from, so that a merchant answering somebody who asks how long their data will be stored is copying an answer rather than composing one. | declared |
17(3) |
Everything an erasure deliberately keeps is published with the reason it was kept, and a kept column with no reason beside it fails the build — because the exemption a merchant relies on is one they have to be able to state, and the screen states it to them at the moment they press the button. | declared |
17(1) |
A merchant erases one named person from a screen, and what happens is what the declaration said would happen: the rows and the files an erasure takes are gone, what it keeps is still there, the person standing beside them is untouched, and pressing it a second time is safe. Asserted by running it on a real store — the only place in this standard where erasure behaviour is ever observed, and the only place a file is. | Asserted on a real store by make smoke, and deliberately not here — this page is generated by make check, which is green with no store at all, so a verdict rendered from it would rest on nothing. |
30(1)(f) |
The envisaged time limits for erasure are published per table rather than per extension, so the line a merchant copies into their own record says which data it is about instead of averaging seven answers into one. | declared |
15(1)(c) |
Every destination this extension's holdings leave it for is published by name, with which of those holdings reach it — so answering somebody who asks who their data was disclosed to is reading a page rather than reading the source. | declared |
20(2) |
This extension transmits nothing directly to another controller, and says so out loud rather than leaving it unmentioned: the destinations that exist are the published list, an export is a file the merchant receives and hands on themselves, and there is no path by which we send one controller's data to another on their behalf. | declared |
30(1)(d) |
Every destination is written down with who chose it, and a destination this extension chose itself that anything personal reaches fails the build — not by default, not behind a setting, not with a warning, because a store owner cannot consent on behalf of the people in the file. | checked, 0 — every destination anything leaves it for |
15(3) |
The screen that says what is held about one named person also hands that statement over: one button produces a file carrying every holding it just listed — what is held, why it is there and what removes it — so answering somebody who asked is sending what the screen showed rather than retyping it into an email. What the file does not carry is the values themselves, which stay in the store; 20(1) below says what that costs. Every extension ships that screen and that button byte for byte, so the file is the same file whichever extension a merchant happened to open. |
checked, 17 — every holding the file carries |
20(1) |
That file is JSON — structured, commonly used and machine-readable — rather than a screen printed to paper, so whoever asked for it can read it with something other than their eyes. What it carries is the inventory and not the contents: every holding this extension has about that person, folded out of the declaration without a table being opened, which is why two people's files differ in the address at the top and nowhere else. Portability is the right to receive the data itself, and this is not that — the values are in the merchant's own database, and what this supplies is a machine-readable statement of where each one is and what removes it. The row is declared for that reason and not machine: what the rule behind it decides is that every extension ships one export byte for byte, which says what the file is and not that the file is what this article asks for. |
declared |
30(1)(g) |
The technical and organisational measures are the security baseline's subject, published on its own page with its own rows and its own scanners, and this page links to it rather than restating any of it. What is asserted here is the seam between them: every file this extension writes is declared in both places and cross-checked both ways, so the two descriptions cannot drift apart. | declared |
KYV-D1 |
Everything this extension holds about a person can be removed on purpose, from a screen, without uninstalling it — and the screen shows what will go before it goes. Uninstalling keeps it all, because an OpenCart upgrade is an uninstall followed by an install and an extension that dropped its tables on the way out would destroy a store's data on every routine update. A holding every one of whose columns is kept for ever, with nothing anywhere able to remove any of it, fails the build. | checked, 5 — every holding the remove-everything screen reaches |
What is left over¶
No column Abandoned Cart Recovery holds is declared a frozen copy of anything the store keeps elsewhere, so this page names no second place a correction has to be made first. What each column is, and where its contents came from, is in its own row above.
Removing all of it is one button, on Abandoned Cart Recovery's own settings screen at Admin > Extensions > Extensions > Modules > Abandoned Cart Recovery. It prints what will go — every table, every file, every key, with a count beside each line and the reason beside the ones it keeps — and nothing goes until you press the second button. It cannot be undone: no soft delete, no recycle bin, no undo, because a recycle bin for personal data is personal data that is still there. Uninstalling does not do it, deliberately: an OpenCart upgrade is an uninstall followed by an install, so an extension that dropped its tables on the way out would destroy your data every time you updated it. Your settings, your configuration and whatever the extension remembers about itself are not touched.
What the law asks of you — you are the controller, and installing an extension is not a compliance process — is on the data-protection boundary, which is also where the words above are defined and where it says why there is no badge. What OpenCart's own erasure feature does underneath all of this, and the things about it worth knowing first, is on what core's own GDPR feature does.