CART DRAWER · DATA & PRIVACY APPENDIX
What Cart Drawer
reads, and why.
The company policies below apply to everything Retrics runs. This page is the part that is specific to this product — the data it touches, and who else sees it.
BUILDING
Cart DrawerBUILDING
RUNS ONboosters.retrics.ai
CUSTOMER GRAPHOutside the shared graph
DATA FLOW DECLAREDYes
THIS PAGE IS THE URL THIS PRODUCT’S APP LISTING SUBMITS
WHERE IT STANDS
The work is real. The door is not open yet.
THE DATA FLOW
Five questions, answered plainly.
WHAT IT READS
- A completed order from Shopify — its line items, the discounts applied, the subtotal and the currency, and nothing about the customer on it
- Which offer a shopper was shown on the storefront, and whether they took it
- On the Preorder listing only: a shopper's email address, and only when they type it into the sold-out form to ask to be told that variant is back. Nothing else about them — no name, no postal address, no phone, no IP address
WHAT IT STORES
- One row per offer moment: which offer, whether it was seen, touched or taken, and the browser-made session key
- The orders an offer earned: the order's id, the lines it applied to, and the money — never the customer
- One row per back-in-stock request: the encrypted address, which variant and offer it was for, and whether the alert has gone out
- The merchant's own offers and their settings
- Daily totals per offer
HOW IT IS PROTECTED
- Apart from the back-in-stock request below, no shopper name, email, address, phone or IP address is read or stored. The order webhook takes five fields and never opens the customer on the order
- A back-in-stock address is encrypted before it is stored, and the write is refused outright if encryption is unavailable — a request that cannot be stored safely is not stored, rather than kept in the clear
- The address is never held in a column that can be searched. Duplicates are recognised through a one-way keyed digest, so the plaintext is never queried
- The form answers every submission identically, whether the address was stored, already present or rejected, so nobody can use it to discover who is waiting on which product
- A request to erase a customer erases their back-in-stock requests outright — the row is deleted rather than blanked, because a record that this person wanted this variant is itself the thing being erased. A data request reports how many are held, never the address back
- The session key is a random string the shopper's own browser makes, and it is discarded when the tab closes
- In the verified production configuration, Shopify access and refresh tokens are encrypted with AES-256-GCM before storage under a key derived specifically for AOV Boosters
HOW LONG IT IS KEPT
- The per-offer event trail is deleted after 90 days
- The daily totals that outlive it are counts and money, with nothing per-shopper in them
- A back-in-stock address is erased at the moment the alert is sent — on a failed send as well as a successful one — and what remains is an addressless record that is deleted after 90 days
- A back-in-stock request that has not been answered yet is kept until it is, and is deliberately never aged out: someone who asked to be told expects to be told whenever the restock happens
- When a merchant uninstalls, the stored credentials are cleared; a shop redaction deletes every row belonging to that shop, including the shop itself
WHO ELSE SEES IT
- Resend delivers the one back-in-stock alert, so it receives the shopper's address and that message. It is the only third party any of this data reaches, and the only email this family sends — one message, triggered by the shopper's own request, with no marketing list to join
AND THE COMPANY POLICIES IT SITS UNDER
These apply to everything Retrics runs.
They are linked rather than repeated here. Twelve copies of the same policy is twelve things that drift apart.
Privacy →Subprocessors →Data processing addendum →Data rights →Data deletion →Security →Terms of service →
THIS APPENDIX IS MAINTAINED WITH THE PRODUCT · EDITING IT CHANGES NOTHING ELSE