Data Retention Policy — Store Integration

1. Retention schedule

The app’s database contains 44 tables. Every one of them carries a shop column, so every one is shop-scoped and every one appears below. Until 2026-07-30 this section said “twelve” and listed twelve; sixteen tables — including Review, which holds a buyer’s email address — had no retention row at all.

On 2026-08-17 four more rows were added — ChatConversation and ChatMessage for the new in-checkout chat, CustomerDataRequest for the rebuilt customers/data_request answer, and one for EmailDeliveryEvent, which had shipped on 2026-08-05 and was described in the privacy policy but had no retention row here at all. That omission was found by the automated check described in §5, which is exactly the failure the check exists to catch.

Nothing in this app is deleted on a schedule. The app’s hourly scheduled task dispatches recurring subscription billing and the delayed-job sweep, and nothing else. Almost every “retention period” below is therefore an event, not a clock. Read §2 for the three events.

One exception, added 2026-08-17: CustomerDataRequest has a real age bound of 30 days, and it is enforced — but by the traffic that creates such rows (every customers/data_request and every customers/redact prunes the shop’s expired ones), not by a scheduler. A shop that receives no further requests keeps an expired row until it does, or until shop/redact. The heatmap tables carry an expiry stamp that nothing reads unprompted; that is a different and weaker thing, and it is described in its own row below and in §4.

2. The three deletion triggers, precisely

1. app/uninstalled → deletes the shop’s Session rows and deactivates its billing schedule. Nothing else is removed. Deliberate: Shopify sends shop/redact 48 hours later, and a merchant who reinstalls in the meantime keeps their configuration.
2. customers/redact → reaches fourteen tables, in two different ways. That is not a maintained list: an automated check derives from the database schema which tables hold a buyer identifier and verifies each is reached, and reports fourteen holding one, fourteen reached as of 2026-08-17.

customers/data_request no longer runs this path. Until 2026-08-17 the handler served both topics without branching, so an access request destroyed the data instead of returning it. The topics are now answered separately: a data request reads, records a CustomerDataRequest row and deletes nothing. - deleted: matching SurveyResponse and EmailLog rows; the buyer’s ChatConversation rows and every ChatMessage inside them; any pending CustomerDataRequest for that person; Profile, FlowRun, CampaignRecipient and EmailDeliveryEvent matched by email; - identifier erased, row kept: RetentionSession.customerId, DisputeEvent.customerId/orderId/orderName, SplitEvent.orderId, FunnelEvent.referenceId, EmailEvent's email and order ID, and Review's email, order ID and author name. These rows are what save rates, dispute history, split-test results, open and click rates and the public review corpus are built from; deleting them would rewrite a merchant’s history as a side effect of one customer’s request. Erasure covers the personal data, not the fact that the event happened.

Until 2026-07-30 this section claimed SurveyResponse and EmailLog were “the only tables holding buyer-keyed data”. They were not — five more tables held a Shopify customer ID, order ID or email, and the app holds Shopify Admin API tokens, so those IDs resolve to a named person. The handler now covers them; the claim is deleted rather than reworded.

Still not reached, and this is the honest residue: ContractActivity and DunningTracker (keyed by contract only, which Shopify can link back to a buyer), dead-lettered JobQueue parameters (IDs live inside a JSON string, not a column), and the heatmap tables (nothing identifying to match, on the checkout surface as much as on the storefront). All are cleared by shop/redact.

1. shop/redact → deletes every shop-scoped row in all 44 tables. This is the complete erasure path, and it is the only one that reaches everything — with one stated exception: EmailDeliveryEvent rows with no shop are not shop-scoped and a shop-scoped delete cannot match them. A missing shop means the send they referred to was already gone, so no merchant’s data is left behind; those rows are removed by a customers/redact for the address.

All three handlers verify Shopify’s HMAC signature before touching data, so deletion cannot be triggered by an unauthenticated caller.

3. Backups

The app performs no application-level backups and keeps no separate copy of the database. Cloudflare’s own point-in-time recovery applies at the platform level; a restore would reintroduce deleted rows, so any restore must be followed by re-running the outstanding redactions. This is a manual step and is listed in the internal incident-response runbook.

4. Gaps in this policy

Stated so a reviewer does not have to discover them:

• Almost no age-based expiry, and nothing runs on a schedule to delete. CustomerDataRequest is the sole exception and it is traffic-swept rather than scheduled (§1). Survey responses, notification logs, reviews, split-test events and dispute records are all kept for the life of the install. A merchant who wants a 12- or 24-month ceiling has to delete the records. A scheduled pruning job is the obvious fix and is not built.
• The heatmap retention setting is not enforced by anything automatic. A merchant setting “30 days” in the admin gets an expiry stamp on each row and nothing that reads it. Only a manual operator purge, or shop/redact, actually removes those rows. This is the single largest gap between what the app’s UI implies and what it does; the fix is a scheduled purge, and it is not built. It applies equally to the checkout rows written by the web pixel extension since 2026-08-17.
• ContractActivity, DunningTracker and dead-lettered JobQueue rows outlive a customer redaction. None carries a customer ID, so a customer-scoped redaction cannot match them — but all three carry a contract ID (and a queued job may carry an order ID inside its parameters) that Shopify can resolve to the buyer. Defensible, but it is residual data, not an empty set.
• customers/redact matching is asymmetric. RetentionSession is matched only on customer ID (it has no order ID column); SplitEvent and FunnelEvent only on order ID (they have no customer ID). A payload carrying a customer ID but an empty orders_to_redact leaves that buyer’s split-test and funnel rows intact, and vice versa.
• Chat transcripts have no ceiling of any kind. No expiry, no purge job, and no delete control in the merchant inbox — closing a conversation only changes its status. A transcript is buyer-typed free text, so this is the module where “kept for the life of the install” costs the most. The same scheduled pruning job that would fix the heatmap gap would fix this one.
• A chat conversation is matched on customer ID or order ID, never on email, because it has no email column — the module never asks a buyer for an address. A buyer who opened a chat at checkout while signed out has neither identifier on the row (at checkout there is no order yet), so a customers/redact for that person cannot reach their transcript. Removed only by shop/redact or by hand.
• Review is matched by email and only by email. A reviewer who left no email, or whose Shopify account email differs from the one on the review, is not reached by customers/redact at all.
• Dead-lettered queued jobs are kept forever by design; they can carry order and contract IDs. They are removed only by shop/redact or by hand.
• Log retention is Cloudflare’s, not ours, and the app does not currently scrub the email addresses the Klaviyo bridge writes into those logs (privacy policy §8).

5. Review

This policy is reviewed whenever the database schema gains a new table. Any new shop-scoped table must be added to the shop/redact deletion job and to the table in §1, or the app silently stops being redact-complete.

Three automated checks exist, and all three read the schema directly rather than a maintained list:

• one verifies that every shop-scoped table is deleted by shop/redact — as of 2026-08-17 it reports 44 shop-scoped tables and 44 purged;
• one verifies that every table holding a buyer identifier is reached by customers/redact — as of 2026-08-17, fourteen holding one and fourteen reached;
• one guards this document: it fails if a shop-scoped table has no retention row here or no description in the privacy policy, and it fails if the table count stated in §1 stops matching the schema. That check exists because the stale “twelve” above survived sixteen new tables.

The same shop/redact completeness check also runs inside the app’s automated test suite, so an omission fails the tests whether or not anyone remembers to run the script.

None of them runs automatically on build or deploy, and this repository has no continuous integration. Somebody has to run them by hand. Wiring at least the first into the build is an open gap.

Last reviewed 2026-08-17 · KDD Brands LTD (company 16411950) · privacy@kddbrands.com