# Data Processing Agreement **Last updated:** 2026-06-09 **Version:** 1.7 > This is Ordinary's launch-version Data Processing Agreement. It reflects > GDPR Article 28 minimum requirements and industry-standard SaaS practice. > External legal counsel review is planned when revenue supports it. If > you're a merchant with a specific legal requirement not covered here, > contact [privacy@tryordinary.com](mailto:privacy@tryordinary.com) and > we'll address it inline. This Agreement governs Ordinary's processing of Personal Data on behalf of its merchant customers ("Controller") who use the Ordinary application ("Processor" or "Ordinary"). It is effective from the date the Controller accepts Ordinary's Terms of Service and remains in force for the duration of the Controller's use of the Ordinary Service. --- ## 1. Definitions - **Controller**: the Shopify merchant (organisation and/or individual) that uses Ordinary to analyse its store's data. - **Processor**: Ordinary (the service, operated by Rendr Inc). - **Personal Data**: any information relating to an identified or identifiable natural person, as defined by GDPR Art. 4(1), CCPA, and equivalent regulations. - **Data Subject**: the person to whom the Personal Data relates — typically a customer who purchased from the Controller's Shopify store. - **Sub-Processor**: a third party engaged by Ordinary to process Personal Data on behalf of the Controller. The canonical list is maintained at [/sub-processors](https://tryordinary.com/sub-processors) and in `docs/SUB_PROCESSORS.md` in this repository. - **Service**: the Ordinary application at app.tryordinary.com, including its pixel, APIs, reports, and integrations. --- ## 2. Roles and Scope ### 2.1 Controller / Processor relationship The Controller determines the purposes and means of processing Personal Data (what analytics to collect, which integrations to enable, whether to forward events to ad platforms). Ordinary acts as a Processor, processing Personal Data solely to provide the Service on the Controller's documented instructions. Where Ordinary forwards hashed customer identifiers to a third-party ad platform (Meta Conversions API) at the Controller's instruction, Ordinary acts as a Processor in this activity too. Meta is a separate Controller or joint Controller of the data it receives, per its own terms. Ordinary's role is limited to hashing and forwarding on the Controller's behalf. Ordinary's Google Ads integration reads Google's reporting APIs and, at the Controller's instruction, creates draft (non-serving) ad creative assets in the Controller's own Google Ads account; Ordinary does NOT forward customer identifiers or conversion data to Google, and does not manage campaigns, budgets, bids, audiences, or live ad serving. Ordinary's Klaviyo integration is also read-only ingest of Klaviyo's reporting APIs; Ordinary does NOT send campaigns, edit flows, modify lists, or upload subscribers to Klaviyo. ### 2.2 Documented instructions The Controller's instructions to the Processor are documented in: - This DPA - The Terms of Service at [/terms](https://tryordinary.com/terms) - The settings the Controller configures in the Ordinary dashboard (integrations enabled/disabled, ad accounts connected, pixel installed on the Controller's store) - Written communications between the Controller and Ordinary If the Controller issues instructions outside this scope, Ordinary will notify the Controller and may decline to execute them until they are formalised. --- ## 3. Nature, Purpose, and Duration of Processing ### 3.1 Nature and purpose Ordinary processes Personal Data to provide cross-channel attribution and customer-journey analytics to the Controller. Specifically: - Recording customer browsing behaviour on the Controller's storefront (via the Shopify Web Pixel installed by the Controller) - Syncing order data from the Controller's Shopify store (via OAuth) - Joining browsing events with orders to attribute revenue to marketing channels, pages, products - Optionally forwarding hashed customer identifiers and order values to Meta (via the Conversions API) to improve the Controller's campaign measurement. Ordinary's Google Ads integration reads reporting data and, at the Controller's instruction, creates draft ad creative assets in the Controller's own account — no customer identifiers or events are forwarded TO Google. ### 3.2 Duration Processing continues for the duration of the Controller's use of the Service. Data is retained per Section 8 ("Return or Deletion of Data") on termination. --- ## 4. Types of Personal Data and Categories of Data Subjects ### 4.1 Categories of Data Subjects - **End customers of the Controller's Shopify store** — people who visited or purchased from the Controller's storefront - **Authorised users of the Controller's Ordinary account** — typically the Controller's employees who log in to the Ordinary dashboard ### 4.2 Categories of Personal Data processed This section describes the **categories** of Personal Data Ordinary processes on the Controller's behalf. It is a category-level description, not a field-level inventory — the specific data points captured within each category evolve as the Service evolves. #### 4.2.1 Storefront activity (end customers of the Controller's storefront) Through the Shopify Web Pixel installed by the Controller, Ordinary captures storefront browsing and checkout interactions on the Controller's behalf — for example pages and products viewed, search and cart activity, and progress through the checkout. Until the buyer enters identifying details at checkout, this activity is associated only with a pseudonymous visitor identifier. The categories of Personal Data captured through this surface are: - **Browsing and interaction data** — the storefront pages and products a visitor engages with, their search and cart activity, the marketing parameters and ad-click identifiers present on the URLs they arrive through (used for marketing attribution), and a returning-visitor signal. - **Device and approximate-location data** — browser and device characteristics, and a coarse, city-level approximate location. The approximate location is derived from the network request at Ordinary's ingest endpoint; the raw IP address is used only to derive the approximate location and is not stored against the event. - **Contact details at checkout** — the email address and phone number a buyer enters at checkout, billing and shipping locality (e.g. country, region, postal code, city), and email/SMS marketing-consent flags. This data is retained even where a checkout is abandoned and never becomes an order. - **Cart and order commerce data** — cart and order values, line items, discounts, currency, and any merchant-configured cart attributes, together with the resulting order and customer identifiers once a purchase completes. A limited amount of attribution data (such as the marketing parameters a visitor first arrived through) may be held in the visitor's own browser storage to support attribution across sessions. Where the buyer declines analytics consent through Shopify's consent controls, this falls back to storage that is discarded when the browsing session ends. #### 4.2.2 Commerce data synced from Shopify Once an order is placed, and on subsequent updates, Ordinary syncs commerce data from the Controller's Shopify store via the Shopify Admin API. The categories of Personal Data this involves are: - **Order and commerce data** — orders, line items, totals, currency, timestamps, fulfilment and financial status, and refunds. - **Customer record data** — the customer's name, email, phone, addresses, and order history as held in the Controller's Shopify store. (Product-catalogue and shop-settings data are also synced but do not relate to an identifiable natural person.) The customer's email address and phone number reach Ordinary both through checkout (§ 4.2.1) and through this Admin-API sync. Raw email and phone are stored within the Controller's own data partition and are never sent to any third party in raw form. ##### Connected advertising and marketplace reporting data (read-only ingest) When the Controller connects a Meta, Amazon, or Google Ads account to Ordinary, Ordinary ingests **read-only** reporting data via the respective platform's API. For advertising accounts this is ad-performance data — performance metrics, ad creative content, targeting summaries, and configuration history for the Controller's own campaigns. For a connected Amazon Seller account, Ordinary additionally ingests the Controller's own Amazon selling-operations data — sales and traffic metrics, financial data (settlements, fees, refunds, and adjustments), inventory levels, and order records (product, quantity, and price only). In all cases this is the Controller's own marketing- and business-operations data from the Controller's own accounts; it does **not** include Personal Data of the Controller's end customers / shoppers — in particular, the Amazon order records Ordinary ingests do not include end-buyer names, email addresses, or shipping addresses. For Klaviyo this ingest is read-only in both directions: Ordinary reads reporting data and does not send campaigns, edit flows, modify lists, or upload subscribers. For Google Ads, Ordinary reads reporting data and, at the Controller's instruction, creates draft (non-serving) ad creative assets in the Controller's own account; it does not create, edit, or manage campaigns, audiences, budgets, or bids, does not serve or pause live ads, and does not upload conversions, customer-match audiences, or customer identifiers. Where a storefront order carries an ad-platform click identifier in its URL, Ordinary may match the order to the corresponding campaign so the Controller can compare platform-reported conversions against orders its storefront recorded. Per Google Ads API Terms § 7(B), to the extent any Google Ads data constitutes personal data under the GDPR, Ordinary processes it consistent with the Controller's obligations under the Google Ads Controller-Controller Data Protection Terms (https://privacy.google.com/businesses/controllerterms) and / or Google Ads Data Processing Terms (https://privacy.google.com/businesses/processorterms), as applicable to the Controller's Google Ads program account. #### 4.2.3 Hashed customer identifiers (only when forwarded to ad platforms) When the Controller has connected the Meta integration, Ordinary forwards **hashed** (irreversible, SHA-256) customer identifiers derived from contact and name details — together with order values — to the Meta Conversions API, on the Controller's instruction, to improve the Controller's campaign measurement. No identifier is forwarded in raw form. Ordinary does **not** forward customer identifiers to Google Ads, Amazon, or Klaviyo. None of these receive end-customer Personal Data from Ordinary — the Google Ads integration's only write is creating draft ad creative assets at the Controller's instruction (no customer data; see § 4.2.2), and Amazon and Klaviyo are read-only ingest only. The current Sub-Processor list is maintained at `/sub-processors`. #### 4.2.4 Authorised users of the Controller's Ordinary account For the Controller's own staff who log in to the Ordinary dashboard, Ordinary processes account and authentication data: - Email and name (from Ordinary's authentication provider) - Role assignments within the Controller's organisation - Standard authentication logging (including IP address and browser/device information for sign-in events) Where the Controller installs Ordinary from the Shopify App Store, Ordinary uses the shop owner's name and email supplied by Shopify during the OAuth handshake to create the initial authorised-user account. No password is collected at install. If an account already exists for that email, the new organisation membership is attached to it rather than creating a duplicate. #### 4.2.4a Acceptance records for Ordinary's Terms and Privacy Policy When an authorised user accepts the Ordinary Terms of Service or Privacy Policy, Ordinary records which document and version was accepted, when, and the browser information for the acceptance, so it can demonstrate consent if later asked by the Controller, a data subject, or a regulator. Consistent with Ordinary's region-aware posture (§ 4.2.5), the IP address of the acceptance is retained only for visitors outside the stricter-regulation regions. These records are retained for the lifetime of the authorised user's account plus a defensible audit window thereafter. #### 4.2.5 Attribution, identity linkage, and region-aware posture To provide attribution analytics, Ordinary associates a visitor's sessions with one another and with the orders they place, so the Controller can see which marketing channels and touchpoints led to a purchase. Within the same browser, this association relies on a pseudonymous identifier that is not derived from Personal Data and is treated as pseudonymous under GDPR Art. 4(1) until and unless it is linked to identifying data. **Region-aware posture.** For visitors in stricter-regulation regions — the European Economic Area, the United Kingdom, Switzerland, and Brazil — Ordinary applies a more conservative identity-linkage posture: it does not perform the cross-session, email-based linkage it may perform for visitors elsewhere, so a single buyer using multiple devices may appear to the Controller as multiple distinct visitors. Visit-to-order attribution within the same browser is preserved in all regions; only the broader cross-device, identity-based linkage is suppressed for stricter-region visitors. This posture is the default and is applied at the point the data is collected. For visitors elsewhere (including the US, Canada, Australia, New Zealand, and the rest of the world), Ordinary performs the broader identity linkage as part of the attribution feature, on the Controller's documented instruction and in reliance on the Controller's own privacy disclosures. This linkage takes place within the Controller's own first-party systems and does not constitute a "sale" or "share" of personal information under CCPA / CPRA. A Controller in a stricter-regulation region that wishes to enable the broader linkage for its own buyers may request this in writing, provided its privacy policy and consent practices cover the linkage; the default remains the more conservative posture. #### 4.2.6 Server-derived attribution for some orders For a small proportion of purchases — for example where a shopper's browser blocks analytics from running — Ordinary may not capture storefront activity directly. For those orders, Ordinary may derive a limited attribution view from the order data the Controller already shares with Ordinary and from Shopify's own customer-journey information for the order. These derived records introduce no new categories of Personal Data beyond the order data itself, do not reconstruct pre-purchase browsing, and follow the same region-aware posture described in § 4.2.5. Where genuine storefront data and a derived view both exist for an order, Ordinary's reports use the genuine data. #### 4.2.7 Historical analytics baseline (pre-install backfill) When a Controller installs Ordinary, Ordinary retrieves a one-time historical analytics baseline from Shopify covering the period before installation, so the Controller's dashboards have historical context. This baseline consists of **aggregate** traffic and source data only — it contains no individual-shopper identifiers and no end-customer Personal Data, and is included here only for completeness of the Shopify → Ordinary data flow. ### 4.3 What Ordinary does NOT process - Payment card details — Ordinary never receives these; payment processing for Ordinary's own subscription fees is handled by a third-party payment processor (see `/sub-processors`) - Customer passwords — authentication is delegated to Ordinary's authentication provider - Precise geolocation — Ordinary holds only the coarse, approximate geography described in § 4.2.1 - Health, biometric, or other special-category data (GDPR Art. 9) — not supported --- ## 5. Security Measures Ordinary implements appropriate technical and organisational measures to protect Personal Data against unauthorised or unlawful processing and against accidental loss, destruction, or damage. These measures are reviewed periodically as the Service evolves. ### 5.1 Technical measures - **Transport encryption** — TLS 1.2+ for all data in transit between Controller's storefront, Ordinary, and sub-processors - **Encryption at rest** — database disk encryption (Neon/AWS) + encrypted secret storage for OAuth tokens (AES-256) - **Access control** — staff access to production data requires authenticated login (Clerk) plus a privileged platform administrator role. All access is audit-logged - **Multi-tenant isolation** — every database record is scoped to the organisation it belongs to, and that scope is enforced consistently through a single centralised access-control check on API requests - **Hashed PII for ad-platform forwarding** — any contact or name details forwarded to Meta (the only platform Ordinary forwards to; see § 4.2.3) are irreversibly hashed server-side before they leave Ordinary - **Audit logging** — every privileged action (role change, data deletion, integration connection, etc.) is logged with actor + timestamp + before/after state - **Regular dependency updates** + automated security scans in CI - **Principle of least privilege** on all third-party OAuth scopes ### 5.2 Organisational measures - Staff with production access undergo reasonable background checks and sign confidentiality agreements - Data-access changes (granting or revoking privileged administrator access) are logged - Security findings identified by internal or external testing are tracked in an administrator-only security dashboard ### 5.3 Breach notification Ordinary will notify the Controller without undue delay, and in any event within **72 hours** of Ordinary becoming aware of a Personal Data breach affecting the Controller's data. Notification will include: - Nature of the breach, categories and approximate number of data subjects and records concerned - Contact point for further information - Likely consequences of the breach - Measures taken or proposed to address the breach Notification will be sent to the administrative contact on file for the Controller's account. Controllers are responsible for maintaining a valid administrative email in their Ordinary account settings. --- ## 6. Sub-Processors ### 6.1 General authorisation The Controller authorises Ordinary to engage Sub-Processors to process Personal Data, subject to the conditions in this section. The current list of Sub-Processors is maintained at [/sub-processors](https://tryordinary.com/sub-processors) and in `docs/SUB_PROCESSORS.md` in this repository. ### 6.2 Notification of new Sub-Processors Ordinary will update the Sub-Processor list at least **30 days** before engaging a new Sub-Processor for a new category of processing. Controllers may object to the new Sub-Processor in writing within that 30-day window. If the objection is reasonable and cannot be resolved, the Controller may terminate the Service without penalty as its sole remedy. ### 6.3 Ordinary's obligations Ordinary will impose on each Sub-Processor data-protection obligations no less protective than those in this DPA. Ordinary remains liable to the Controller for the performance of its Sub-Processors. --- ## 7. Data Subject Rights ### 7.1 How data-subject requests reach Ordinary End-customer data-subject requests (access, deletion, correction, portability) are managed primarily through the Controller's own Shopify admin, which issues the standard Shopify GDPR webhooks. Ordinary receives: - `customers/data_request` — Ordinary compiles the Personal Data it holds for that customer (their customer record, order history, and recorded storefront activity) and provides it to the Controller's administrators within 30 days - `customers/redact` — Ordinary anonymises the customer's Personal Data so the records no longer identify the individual, which also ends any future ad-platform forwarding for that customer - `shop/redact` — on Shopify uninstall, Ordinary anonymises the Controller's data organisation-wide Controllers can also contact Ordinary at [privacy@tryordinary.com](mailto:privacy@tryordinary.com) to initiate the same requests directly. ### 7.2 Response timeline Ordinary will respond to data-subject requests initiated by the Controller within **30 days**, consistent with GDPR Art. 12(3). For technical requests requiring a larger dataset (e.g. a full customer-journey export spanning years), the timeline may extend to 60 days with prior notice. ### 7.3 Controller's responsibility The Controller is responsible for: - Responding to the data subject directly - Validating the identity of data subjects before requests are forwarded to Ordinary - Maintaining its own privacy policy and consent practices Ordinary will not respond directly to end-customer data-subject requests for Controller data except in emergencies or as required by law, in which case Ordinary will notify the Controller before or concurrently with the response. --- ## 8. Return or Deletion of Data on Termination ### 8.1 On termination of the Service Within **90 days** of termination of the Controller's Service: - All Personal Data in Ordinary's production database is deleted; deleting the Controller's organisation account cascades to remove the associated records across Ordinary's data stores - Backups containing the Controller's data are overwritten per the standard backup-rotation cycle (Ordinary's primary database provider, Neon, retains Point-in-Time Recovery for 30 days) - Operational audit logs are retained for approximately 30 days. Billing and financial records are retained as required by tax and accounting law (typically up to 7 years), in minimised form. ### 8.2 Early export At any time before termination, the Controller can export its data via: - The built-in CSV export on each report page - The Shopify `customers/data_request` pathway for customer-scoped data - A formal export request to [support@tryordinary.com](mailto:support@tryordinary.com) for org-wide data bundles ### 8.3 Data that cannot be fully deleted Where hashed identifiers have been forwarded to Meta or other ad-platform Sub-Processors before the deletion request, Ordinary cannot delete the data from those platforms — the Controller must use the ad platform's own data-deletion flow, which Ordinary will assist with on request. (Google Ads is not in this list because Ordinary forwards no customer identifiers to Google in the first place — the integration reads reporting data and at most creates draft ad creative assets, which contain no customer Personal Data.) --- ## 9. Cross-Border Transfers Ordinary's primary infrastructure is hosted in the US (Vercel, Neon on AWS) with EU-region options available for specific components where required. For data transfers from the EEA / UK / Switzerland to the US, Ordinary relies on the EU-US Data Privacy Framework where the Sub-Processor is certified, and on Standard Contractual Clauses (2021 SCCs, module 2 or 3) otherwise. Controllers subject to EU/UK/Swiss data-protection law may request a signed copy of the SCCs via [privacy@tryordinary.com](mailto:privacy@tryordinary.com). --- ## 10. Audit Rights The Controller or a mutually agreed independent auditor may audit Ordinary's compliance with this DPA once per calendar year, at the Controller's expense and with at least 30 days' written notice. Ordinary may satisfy audit requests by providing: - Copies of recent third-party audit reports (SOC 2, ISO 27001, etc.), when obtained - Completed security questionnaires (SIG Lite, CAIQ) - This DPA, Sub-Processor list, and the security measures documented in Section 5 On-premises audits are available for Controllers with legitimate compelling reasons, subject to scheduling and reasonable confidentiality protections. --- ## 11. Liability Liability under this DPA is governed by the Limitation of Liability section of Ordinary's Terms of Service. The Controller and Ordinary each remain liable for their own compliance failures. Ordinary is not liable for data-subject requests unanswered because the Controller did not forward them from Shopify or otherwise communicate them. --- ## 12. Governing Law This DPA is governed by the same law as Ordinary's Terms of Service (Delaware, USA). For Controllers subject to EU/UK data-protection law, the GDPR and UK GDPR apply to the processing of Personal Data under this DPA, and the SCCs referenced in Section 9 apply to cross-border transfers. --- ## 13. Contact For any matter relating to this DPA: - General / privacy: [privacy@tryordinary.com](mailto:privacy@tryordinary.com) - Security / breach reports: [security@tryordinary.com](mailto:security@tryordinary.com) - DPA-specific questions / signed SCC requests: [privacy@tryordinary.com](mailto:privacy@tryordinary.com) Ordinary commits to responding within 5 business days.