16 pre-attested answers to Shopify's data-protection form

We collect only what's needed to attribute conversions and bid for ads on the merchant's behalf: a first-party cookie ID (anonymous), event metadata (page view, add to cart, purchase), the order ID with its line items and total, and a SHA-256 hash of the customer email. The raw email is hashed at the bidder and never persisted in plaintext on the plugin side. We explicitly do not collect cleartext email, phone, payment data, postal address, government IDs, biometric data, or precise location.

Our public privacy policy enumerates every piece of personal data we process — its source, its purpose, and its retention window — for both merchant data (shop owner email, locale, access token) and storefront-customer data (cookie ID, events, hashed email). The Shopify App Store listing links to that policy, and the in-app Settings page surfaces it once the listing URL is published.

Each piece of data has exactly one documented purpose, enforced by both policy and code. The bidder API key is server-only and never reaches the browser. The pixel key is scoped to the event-ingestion endpoint. Our first-party cookie identifies a single visitor for that merchant's own attribution and is never combined across shops. Webhook payloads are stripped of email before being persisted in the retry queue. A single read boundary in our code is the only path that decrypts secrets, and every read is audit-logged — making purpose violations detectable.

We maintain a merchant-facing Data Processing Agreement template that covers the obligations of GDPR Article 28(3)(a-h): processing on the merchant's instructions, confidentiality, security, sub-processors, assistance with data-subject requests, breach notification, return-or-delete on termination, and audit rights. The template names the specific operational paths that satisfy each obligation.

Two layered consent gates ensure customer decisions are honored. Client-side: before any event is sent, the storefront pixel checks the analytics-consent value from Shopify's Customer Privacy API. If consent is denied or absent, the event is silently dropped — and the check fails closed on errors. Server-side: the event-ingestion endpoint authoritatively enforces the consent contract, so a non-pixel caller cannot bypass it. The pixel is the only path that legitimately reaches the endpoint with consent already verified.

This is the CCPA / CPRA Right to Opt Out of Sale — a separate consent dimension from analytics. Because ArgosAd is a programmatic-advertising DSP, forwarding events qualifies as "sale" under CPRA's cross-context-behavioral-advertising definition. The pixel checks the sale-of-data consent independently of the analytics consent — even if analytics is granted, if sale-of-data is denied, the event is dropped.

Our automated ad-targeting via cookie ID is technically automated processing, but it does not meet the GDPR Article 22 / CPRA § 7222 threshold of "legal effects or similarly significant effects" — that threshold targets things like loan approval, employment screening, or insurance pricing. Selecting which ads a customer might see does not qualify. Even so, the consent gates above function as a de facto opt-out: a customer who denies analytics or sale-of-data consent is excluded from all processing. Customers can additionally exercise their GDPR Article 21 (Right to Object) and Article 17 (Right to Erasure) rights, and CCPA / CPRA opt-outs, via the merchant — wired through Shopify's customer-data-request and customer-redact webhooks.

Each table has a documented retention window enforced by an automated pruner that runs weekly. Locked windows: completed retry-queue jobs 90 days, audit logs 365 days, install nonces 24 hours, Shopify sessions until uninstall + 30 days, shop configuration until uninstall + 30 days (or 48 hours after a shop-redact webhook, whichever fires first), and the storefront cookie 365 days browser-side. In-flight rows are never pruned — only completed rows past the cutoff.

Two layers of encryption. At rest (application layer): our most sensitive secrets — the bidder API key and the pixel key — are wrapped with AES-256-GCM. The 16-byte GCM authentication tag detects tampering, surfacing as an error rather than a silent decode. The encryption key lives in our hosting provider's secret manager; the app refuses to operate without it. At rest (disk layer): the deployment requires a managed Postgres provider with disk encryption enabled (Neon, Vercel Postgres, Supabase Pro, AWS RDS with storage encryption, or equivalent). Unmanaged Postgres deployments are forbidden by our deploy spec. In transit: TLS 1.3 is enforced everywhere — browser to plugin, plugin to Shopify Admin, plugin to bidder backend (additionally HMAC-signed), and plugin to Postgres. Known gap (transparent): the Shopify OAuth session token is not yet application-layer encrypted; it's stored by an upstream library and is mitigated today by disk encryption, access control, and audit logging. Application-layer encryption for that token is on our v1.1 roadmap.

Two ways. Application-layer (the secrets matter most): our highest-value secrets are encrypted at the row level — a leaked snapshot is useless without our encryption key. Disk-layer (the rest): managed Postgres providers store point-in-time-recovery snapshots and base backups encrypted at rest. We do not run our own backups; the managed provider's automated PITR is canonical.

Different database URLs per environment. Local development runs Postgres in Docker on a non-standard host port; production reads its database URL from the secret manager. Production data is never copied to development — dev is seeded with synthetic fixtures only. The production encryption key is generated fresh and lives only in the production secret manager; development uses a different key. The Shopify CLI naturally enforces that the development build only runs against a Shopify development store, never a production store.

Multi-layered. Provider: managed Postgres point-in-time recovery with retention of at least 7 days (we recommend 30+). Managed providers store backups in availability zones separate from the primary. Application: a circuit breaker prevents cascade failures into the bidder, and an idempotent retry queue preserves in-flight events through transient outages. Operational: RPO 5-minute / RTO 30-minute targets are documented, and quarterly test-restores on a PITR branch validate the recovery path. Key safety: our encryption key is held in the hosting provider's secret manager and backed up in the operator's password manager (encrypted, offline). Losing the key is treated as a top-tier incident.

Today, with a solo operator, our access posture is honestly stated: least privilege at N=1 means one person holds everything. Compensating controls are MFA on every in-scope account, a 365-day audit log of every secret read, and a quarterly access review. The role matrix is already documented for team growth: Engineer, Operator/SRE, Support, and CEO, with production secret-manager and production-database write access reserved to Operator/SRE only. Onboarding issues a least-privilege account on day zero with MFA enforced before access; offboarding revokes within 4 hours and rotates any shared credentials within 24.

Documented policy with annual self-attestation. Password managers required for all in-scope accounts (1Password, Bitwarden, Dashlane, KeePass, or equivalent) — no reuse, no memorized human-typed passwords. Generated passwords: at least 20 characters, at least 3 character classes. MFA required on every account in the inventory (GitHub, Shopify Partners, hosting provider, managed Postgres, secret manager, operator email, domain registrar, DNS provider, bidder admin). Preferred method: WebAuthn / FIDO2 hardware key. Fallback: TOTP. Forbidden: SMS-based 2FA (SIM-swap risk).

A dedicated audit-log table records every security-relevant access: reads of merchant access tokens, token mints during install, receipt of customer-data-request webhook payloads, and receipt of customer-redact webhook payloads. Each entry carries actor, shop, resource, action, outcome, request ID, and timestamp. Audit-log writes are fire-and-forget — they never break the operation they're auditing, but failures themselves surface to error logs. Retention: 365 days. What we deliberately do not log: every commerce webhook (too noisy to be useful) — bidder-side observability handles that.

A full incident-response runbook covers severity levels (Sev 1, 2, 3), detection sources, and a six-phase response: detect, contain, eradicate, recover, notify, and post-incident review. A confirmed Sev 1 starts the GDPR Article 33 72-hour clock immediately. Notification coverage includes GDPR Articles 33 (supervisory authority, 72h) and 34 (data subjects, without undue delay), CCPA § 1798.82 (California Attorney General + affected residents), Shopify Trust & Security (24h), and affected merchants (72h with an included template). Containment includes documented dual-secret overlap rotation for our inter-service HMAC secret. Emergency rotation of our application-layer database encryption key uses a manual procedure today; an automated dual-read rotation path is documented in our v1.1 roadmap.