Privacy and field inventory

Every piece of personal data that leaves a Magento store through the Conviro integration, what Conviro keeps, for how long, and what is never sent or stored. Plan §22 and §20 item 17. Read against the code on feat/magento-10-10 (d3472ce2), 2026-09-24; updated 2026-09-25 for revenue attribution (514d99b0, 101ed33d, f9e583f6, c3374a58) and release gate R3 (ceaaac4d API, ee07b4fc widget, 8791cdc4 module). For Conviro's subprocessors, legal basis and data processing terms, see the Conviro DPA — this page does not list them.

Classes (plan §22): public catalog, merchant confidential, customer PII, order PII, credentials / secrets. The attribution ids are pseudonymous identifiers (random, not derived from the person).

Summary

Field inventory by event

Field lists with types are in the event reference; the personal fields:

order.placed no longer sends the billing first / last name and phone, the line items or the customer id (release gate R3): no Conviro consumer used them.

The envelope's store block (base URL, ids, code, locale, currency) and meta (versions) are merchant data, not personal data.

What is never sent

• Passwords, password hashes, payment card data, CVV, payment tokens.
• Customer addresses and phone numbers (billing or shipping). Since 1.4.0 no event carries a billing name or phone either.
• Date of birth, gender, tax/VAT numbers.
• Customer data of store views not selected in the setup wizard (a customer.deleted is sent regardless, so a deletion always reaches Conviro).
• Cart and payment data until you confirm those features.
• Anything from a disconnected store: the module queues nothing without an API key, and Disconnect empties every stored outbox payload. A deleted customer's undelivered payloads are dropped at the deletion.

What Conviro never stores from these events

Raw e-mail in commerce_orders / commerce_customers / commerce_checkouts / commerce_payment_failures; names, phones, addresses, line items or tracking numbers in any commerce table; the chat visitor id in any commerce table; event payloads in logs (the ingest does not log them; labels of Conviro's metrics never carry a workspace id, store URL, SKU, order number or e-mail).

E-mail hashing

apps/api/src/modules/magento/commerce-email-hash.ts: HMAC-SHA256 of the trimmed, lower-cased address, domain-separated (conviro:commerce-email:v1), under the server-side key COMMERCE_EMAIL_HASH_KEY (≥ 16 characters) or, when that is not set, a key derived (HMAC with a label) from the application secret. With no secret at all it refuses to hash rather than store an unkeyed value. Each row stores a 16-hex email_hash_key_id, so a key rotation shows up as a different key id. Purpose: recognise the same shopper across orders and checkouts without holding a readable address. The hash is one-way; it cannot be turned back into the address, but anyone holding the key and a candidate address can test it — the key never leaves Conviro's servers. A customer.deleted can only match rows hashed under the current key.

Retention

In Magento

Measured on the local stack (retention.sh): a 40-day log row deleted and a 10-day one kept; two orders jobs finished 100+ days ago deleted, a recent one, the newest (200-day-old) repair job and a 120-day-old running job kept.

At Conviro

All purges run daily in batches until done (a 4-minute budget per run, time indexes from migration 0228); a table left with rows past retention is logged and sent to Conviro's ops channel.

ai_action_requests.customer_ref holds the customer's e-mail masked (a***@example.com); details.customerEmailHash is the keyed HMAC of commerce-email-hash (it was a plain SHA-256 before the security review) and is never returned to a browser. The one-time code of a customer-confirmed action is stored only as a keyed hash, for 10 minutes of validity. The grounding record stores the facts shown to the AI (for order answers: order number, status, total, tracking values up to 120 characters) and is visible to your team only.

Deletion and export

• Product removed or disabled in Magento → its knowledge-base entry is deactivated at once (product.deleted, enabled: false).
• A customer deleted in Magento → customer.deleted (module 1.4.0, while the store view's customer data is shared). Magento first drops the customer's undelivered payloads; Conviro then, in one transaction: deletes the commerce_customers row; removes the e-mail hash from this store's commerce_orders, commerce_checkouts and commerce_payment_failures rows (a waiting payment-assist offer is withdrawn); anonymises the lead this store's registration created for that e-mail (name, e-mail, phone, company, job title, notes, city, country cleared — the row stays, marked anonymizedBecause: magento.customer.deleted); deletes that e-mail's cart-recovery rows; writes magento.customer.deleted to the audit log (counts and the customer id, never the e-mail). Conversations and contacts are not touched — they are Conviro's own records: delete a person's conversations and contact with Conviro's GDPR tools (Contacts › contact › GDPR erase, DELETE /contacts/:id/gdpr-erase; Settings › Privacy › visitor data deletion). Orders still exist in Magento with their e-mail; a later order history re-sync sends them again with that e-mail.
• A conversation deleted in Conviro (inbox delete or bulk delete, visitor data deletion, the workspace's session-retention purge) → its id is removed from every order's and checkout's attribution record; payment failures and attribution links drop their reference (ON DELETE SET NULL). The record still says the order was influenced by a conversation at the time.
• Disconnect → Conviro deletes the store credentials and stops reading the store; the module empties every queued payload. The store's order, customer, checkout, payment-failure and sync-job rows are deleted 30 days later unless the store reconnects; leads, contacts, conversations and audit logs are not deleted by Disconnect (Reconnect and disconnect).
• Delete store data now (Conviro dashboard › Integrations › Magento, store card; owners and admins; confirmed) → the same rows are deleted at once and the action is written to the audit log with the counts (magento.store_data.deleted). While the store is still connected, new events are stored again.
• A shopper's export request: handle it in Conviro per the DPA / Conviro support; the order and customer tables can be matched by the e-mail hash.
• Leaving Conviro: workspace deletion removes the workspace's rows through the tenant foreign keys; the exact process is Conviro's (see the DPA).

Storefront widget

When a shopper is logged in, the widget loader reads the customer's id, name, first name and e-mail in the browser — Magento's customer section (mage-cache-storage) has the names; the id and e-mail come from the module's customer-data section conviro-customer ({id, email}, empty for guests; stored by Magento in the same mage-cache-storage entry, dropped at logout) — and passes them to Conviro's widget as user: {id, name, firstName, email}. A guest's page view reads nothing (1.4.0; 1.3.x called /rest/V1/customers/me on every guest page view). Conviro stores the first name, the e-mail and (since 1.4.0) the customer id with the chat session (chat_sessions.metadata.userContext). Until 1.4.0 the template sent the id as userId, which neither the widget nor Conviro read; both still accept userId from an older module. Nothing personal is rendered into the cacheable page (verified by fpc-privacy.sh, WidgetPrivacyTest and widget-identity.sh). The store view code, name, locale and language are passed too. The module's template does not consult a consent manager for this — see Headless / PWA for consent options.

Signed customer identity and My orders (1.5.0, unreleased)

1.5.0 (unreleased), read 2026-09-27 on feat/magento-1.5.0-customer-hub (backend, module), feat/magento-1.5.0-p34-module (admin card) and feat/magento-1.5.0-p34-ui (widget, dashboard). Off unless switched on in the store and at Conviro (Signed customer identity and My orders).

What leaves Magento

What Magento keeps

What Conviro keeps

Order lists and details are never cached and never written to the order tables; the AI reply cache and the debug prompt log skip every turn that carried verified order data. Metrics labels are checked against closed lists — a label that looks like an id, an e-mail or an order number is refused.

Deletion

• A customer deleted in Magento → the module revokes all of that customer's live bindings, queues identity.bindings_revoked (customer_deleted) with their ids, and then deletes every binding row of that customer — live, revoked and expired — in the same deletion (Phase 5 P5-13, branch feat/magento-1.5.0-p5-module, unit-tested; before it the rows were purged within a day); another customer's rows are untouched. Conviro marks the principals revoked; customer.deleted then deletes the principal rows of that customer id in that integration (Phase 5 P5-05 368c9808 on feat/magento-1.5.0-customer-hub, not deployed — until the deploy they go with the conversation, or with the 7-day purge of P5-04). The sealed answers and handoff contexts carry no customer id: delete the conversation (Conviro's GDPR tools) to remove them.
• A conversation deleted in Conviro → its challenges, principals, handoff contexts and messages (sealed answers included) go with it.
• Disconnect → every identity key and principal of the store is revoked; the rows stay until the workspace is deleted or the purge above runs.

Guest verification codes (designed, not built)

Planned for 1.5.0 (switch guest_verification_enabled in the module, flag magento_guest_otp at Conviro): a ledger guest_order_verifications with hashes only — keyed hashes of the order number and e-mail, an IP hash with a daily salt, the code as an HMAC — attempts, resends and times, kept 30 days. The code is never stored in a transcript (the widget sends it apart from the message text; other channels store [verification code]). Not built at Conviro on 2026-09-27: nothing of this is stored today.

Revenue attribution (cookies & ids)

Plan P6.4 (owner decision 4: session and link models, reported separately, "influenced", never "caused").

On the storefront (the chat widget, 101ed33d, ee07b4fc). Two first-party cookies on the store's own domain, path=/, SameSite=Lax, Secure on https, written only when the host page asked for attribution (the module passes it — Sync Settings › Revenue attribution, default on, website scope) and there is a positive consent signal:

Consent (security review R3, 2026-09-25): the cookies need a positive signal — an explicit host decision; with Cookie Restriction Mode on, Magento's user_allowed_save_cookie holding {"<websiteId>":1} (set by the Luma and Hyvä notices); a recognised consent platform reporting consent (IAB TCF v2: purpose 1 plus a measurement purpose 7, 8 or 9, and the vendor's consent when the host names a vendor id; OneTrust: the performance group C0002; Cookiebot: statistics); or Google Consent Mode analytics_storage: granted. Every signal present can refuse, and so can the widget's own privacy policy. No signal, a platform still loading, or a consent platform the widget cannot read = nothing is written. Only the merchant setting Attribution cookies without a consent signal (conviro_aichat/sync/attribution_without_consent, website scope, default No, for regions where analytics cookies need no consent) lets the widget write them on a page that carries no consent signal and no consent platform at all. An explicit refusal removes both cookies on the next page view and suppresses even the click report below. Neither cookie holds an e-mail, a name or an IP.

URLs. Product cards Conviro shows (chat, flows, knowledge-base cards) of a Magento-connected workspace carry ?cvr_att=<22 random characters>. Landing with it, the widget reports the click to POST /v1/widget/attribution/click (public key + link id only; 30 per minute per IP; a reload within 10 minutes is not counted twice) — whether or not a cookie may be set, but never after an explicit refusal.

Orders, checkouts and failed payments (module, f9e583f6). Service/Attribution/AttributionCookies reads the two cookies only for a storefront request (frontend, REST, SOAP, GraphQL — never admin, cron or CLI), with Revenue attribution on and, under Cookie Restriction Mode, the shopper's consent cookie for that website, validates them and adds them as data.attribution {visitorId?, linkIds?} to order.placed, checkout.started and (release gate R3) payment.failed. Nothing else is read or stored in Magento.

At Conviro (514d99b0).

The visitor id itself is never stored in a commerce table; an order's e-mail is matched in memory only. Since the security review an e-mail match counts as influenced only through a verified identity — the e-mail of a lead or a contact of the workspace. An e-mail only the browser supplied (the host page's user.email, or one typed in the chat) is recorded as email_unverified and reported separately in the revenue card, never in the influenced totals. Historical orders (order.synced) are never attributed.

Also in 1.4.0 that affects privacy

• customer.updated sends only id, e-mail and group, and only while customer data is shared (event reference).
• checkout.started sends the e-mail only when the shopper already gave it (event reference).
• Payment assist records failed payments and may offer the shopper help once (Cart recovery and payment assist).
• The connect-minted API key can reach only the routes the module uses (magento:module), limited to the chosen chatbot — it cannot read your conversations (Security model).