How Ordinary handles your visitor and customer data

Ordinary helps you measure where your sales come from. To do that we capture browsing and purchase activity on your Shopify storefront. This article explains what gets captured, how it flows into your reports, and the privacy posture we apply by default — including how we differ for visitors in jurisdictions with stricter consent regimes.

If you need the formal documents, see:

• Privacy Policy
• Data Processing Agreement (DPA)
• Sub-processor list

Who is the controller and who is the processor

You — the merchant — are the data controller. You decide what to collect, how to use it, what to put in your privacy policy, and how to handle visitor consent on your storefront.

Ordinary is your data processor. We process visitor and customer data on your behalf, under your instructions, to provide the analytics you signed up for. Our DPA is the formal document that describes this relationship.

What Ordinary captures

When a shopper visits your store, our pixel and Theme App Extension together capture:

On every page view:

• A pseudonymous browser identifier (no name, no email)
• The page URL, the referring page, the device type and browser
• The operating system family (iOS, Android, macOS, Windows, Linux, ChromeOS, or other), classified from the user-agent string — no separate geolocation lookup runs
• Whether the shopper is new or returning to the store. We tell which by leaving a small cookieless marker in the pixel’s own isolated storage on the shopper’s first visit. The marker is scoped to the pixel and not shared with the rest of the storefront; clearing browser data resets it
• UTM parameters and ad-platform click identifiers in the URL
• The shopper’s approximate location at city level — country, region, city, latitude, longitude. We derive this from the IP address at the network edge and do not store the raw IP address against the event record
• The event timestamp

At checkout:

• Email and phone number (raw, as the shopper types them — including on abandoned checkouts)
• Billing and shipping country, region, postal code, city
• Marketing-consent flags
• Cart and checkout line items (products, variants, SKUs, quantities, prices, discounts)
• Cart attributes (custom key-value pairs you’ve configured)
• The Shopify order ID and customer ID (only on a completed checkout)

After the order:

• Standard order, customer, and product data, synced from Shopify’s Admin API as you’d expect
• Your orders’ shipping location is synced from Shopify and used for location-based revenue and cohort analytics

At install (one-time, historical baseline):

• Aggregate session counts from Shopify’s analytics warehouse covering the months before you installed Ordinary. Counts are bucketed by day, landing page, and traffic source — useful for showing trends in your dashboards from day one. Aggregate-only: no individual shopper IDs, no IP addresses, no email or phone, no event-level rows. The data comes from Shopify directly via the same Admin API scope you already grant on install; we don’t ask the shopper for anything new

For the full per-event field list, see § 4.2 of the DPA.

About your Ordinary account

If you install Ordinary directly from the Shopify App Store, we create your Ordinary user account using the shop owner’s name and email that Shopify shares with us during the install handshake. We pass that information to our identity provider to mint your account. No password is collected from you at install — you can set one later from your account settings, or sign in via SSO. If an account already exists for the same email, we attach your Ordinary access to that existing account rather than creating a duplicate.

If you’d prefer to use a different email than the one Shopify holds for your shop owner, you can complete a manual sign-up at tryordinary.com first and then connect Shopify from inside the dashboard.

Acceptance records

Every time you accept our Terms of Service or Privacy Policy — at sign-up, when the documents change, or via in-app prompts — we keep a record of that acceptance so we can demonstrate consent if asked. Each record includes which document you accepted, the version of the document, the calendar timestamp, your browser’s User-Agent, and a label describing where the acceptance happened.

We store your IP address with this log only when you accept from a region we treat as permissive (outside the EU/EEA, UK, Switzerland, and Brazil). Operators who accept from strict-region jurisdictions have no IP stored alongside their acceptance record.

How visit data connects to orders

Ordinary uses a couple of overlapping signals so your attribution still works even when one of them is unavailable:

1. A browser-stable UUID. Ordinary generates a random, pseudonymous identifier for each browser on its first visit and associates it with that browser’s storefront activity. The same identifier is linked to the order eventually placed from that browser. Result: every event from that browser — and the eventual order — share the same UUID.

2. Shopify’s pixel client_id. A separate pseudonymous identifier set by Shopify itself, attached to the pixel events.

3. The checkout email (only after the buyer types it in). Used for one specific purpose: linking the SAME buyer’s activity across different devices.

The first two signals are pseudonymous — they identify a browser, not a person. The third is the only one that touches a personal identifier, and it’s only used to merge a buyer’s mobile and desktop sessions into one customer journey in your reports.

Region-aware approach to cross-device linking

For visitors in the European Economic Area, the United Kingdom, Switzerland, and Brazil, Ordinary does NOT link a visitor’s pre-checkout browsing to a personal identity by default. Visit-to-order attribution within the same browser still works — those visitors’ pseudonymous identifiers still tie their visits to their orders — but the post-checkout merge that combines a buyer’s mobile and desktop sessions into a unified customer record is suppressed. A buyer in these jurisdictions who switches between mobile and desktop will appear in your reports as two separate visitor sessions.

For visitors in the United States (including California), Canada, Australia, New Zealand, and the rest of the world, the cross-device email link is written by default. This is permitted by the relevant privacy regimes (CCPA / CPRA in California regulate the sale and sharing of personal information with third parties, not first-party linkage of pseudonymous identifiers within your own systems) provided your privacy policy discloses the practice.

Either way:

• Pseudonymous browser identifiers are used in all regions. They are not personal data on their own.
• All identity merges that link a visitor’s pre-checkout browsing to a personal identity are gated on the visitor’s region. This applies equally to email-based and customer-account-based merges.
• Approximate visitor location (city-level) is captured in all regions. It’s not personal data on its own at this grain.

What we store from connected ad platforms

When you connect Meta (Facebook + Instagram Ads) to Ordinary, we store additional details about your ad campaigns to power the analytics, creative-analysis, and AI-assisted copy and creative generation features:

• Campaign and ad-set configuration — names, objectives, budgets, audience targeting settings, optimisation goals, and the history of how those settings have changed over time.
• Creative content — the ad copy text (headlines, primary text, descriptions, link descriptions, calls-to-action) and the images and videos used in your ads.
• Performance broken down by placement and demographic — performance figures broken down by where the ad ran (Feed, Stories, Reels, Audience Network, etc.) and by demographic bucket (age and gender breakdowns Meta makes available).

This data is stored against your organisation only, used to deliver the Ordinary product to you, and never sold or shared with third parties. We do not store individual end-customer data from Meta — only aggregate ad-level metrics and the creative assets you yourself uploaded into Meta. Audience configuration data is stored at the targeting-criteria level (e.g. “ages 25-34 in the United States, interested in fitness”), not as the underlying personal records that fall under Meta’s audience match.

The same posture applies to other ad platforms when connected. For Google Ads specifically, Ordinary ingests campaign-, ad-group-, ad-, and keyword-level performance (spend, impressions, clicks, conversions, conversion value); performance broken down by device, network placement, geographic location, and demographic (age range, gender, parental status, household income range); ad asset content (headlines, descriptions, image and video creatives associated with campaigns); a daily configuration history (campaign and ad-group budget, status, bid strategy, and targeting); and ad account metadata. Orders that arrive at the merchant’s storefront with a Google click identifier in the URL are joined to ad data so the merchant can compare Google-reported conversions against orders their store actually recorded. At your request, Ordinary also creates draft, non-serving ad creative assets in your connected Google Ads account from creatives you generate in Ordinary, which you review and publish yourself in Google Ads. Ordinary does not edit campaigns, budgets, bids, or targeting, does not serve ads or spend your budget, and does not upload conversions or audiences. We also do not use your Google Ads data to train AI models, sell or share it with data brokers or information resellers, use it for credit-worthiness or lending decisions, build databases for resale, or serve advertising of any kind — including retargeting and personalised advertising. The data is rendered in your dashboard and that’s it. For Amazon, Ordinary ingests two kinds of read-only data from your own Amazon account. From the Amazon Selling Partner API: your selling-operations data — sales and traffic metrics (ordered sales, units, sessions, page views, conversion rate, Buy Box share), financial data (settlements, fees, refunds, and adjustments), inventory levels, and order records (product, quantity, and price only — no end-buyer names, email addresses, or shipping addresses). From the Amazon Ads API: Sponsored Products, Brands, and Display campaign performance. Same read-only posture — Ordinary reads your Amazon data and does not create, edit, or manage anything in your Amazon account. For Klaviyo, Ordinary ingests campaign and flow performance data (recipients, opens, clicks, unsubscribes, bounces, attributed revenue) and campaign / flow metadata; orders that arrive at the merchant’s storefront with a Klaviyo click identifier on the link are joined to the campaign data so the merchant can compare Klaviyo-reported revenue against orders their store actually recorded. Same read-only posture — Ordinary does not send campaigns, edit flows, modify lists, or upload subscribers to Klaviyo. For Google Search Console — not an ad platform, but a Google integration that sits alongside the others — Ordinary ingests organic-search performance per verified site you select (queries shown to users on Google Search, impression and click counts, click-through rates, and average ranking position, by query and landing page, by day). Search Console exposes no end-customer identifiers to site owners, so the data we read contains no individual-searcher records. Same read-only posture — Ordinary does not create properties, verify sites, modify configuration, submit sitemaps, or request indexing.

How long browsing data is kept

Ordinary retains visit-level browsing data for a minimum of 90 days. This is what supports cross-session attribution — the ability to credit a purchase to the marketing source that originally drove the visit, even when the buyer comes back days or weeks later. Aggregate analytics derived from this data may be retained longer for trend reporting (up to 2 years), but those aggregates do not themselves identify individual visitors. Full retention details are in our Privacy Policy § 4.

Blocked-browser shoppers (Brave, strict-mode Safari, iOS content blockers)

A small slice of shoppers use browsers that block analytics from running on their device, regardless of which analytics tool the merchant has installed. Two design decisions matter for these shoppers:

• For their completed orders: we reconstruct the conversion event server-side from Shopify’s order webhook (which is server-to-server and not affected by browser-side blocking) + Shopify’s customer-journey data. The merchant gets the order in their reports with accurate channel attribution. No browse-side data is fabricated; only what the order itself carries.
• For their pre-purchase browsing: a first-party beacon path recovers most of it for shoppers using moderate privacy browsers. For the residual diehard cohort whose browsers block even first-party analytics: we don’t see their browsing at all, by design — there’s no server-side equivalent for page-view-level data. Visitors who don’t end up buying are invisible to us in this cohort.

For questions about which third-party services we use to deliver Ordinary, see the sub-processor list in our Privacy Policy.

What your privacy policy should mention

Ordinary’s Privacy Policy covers Ordinary’s own practices as your processor. Your storefront should also cover what you, the merchant, do with this data — most importantly that you use a third-party analytics provider (Ordinary) to measure attribution across channels.

A short paragraph, adapted to your tone, that you can paste into your privacy policy:

We use Ordinary, an analytics service, to measure how visitors find and shop on our store. Ordinary captures pseudonymous browsing activity (page views, clicks, cart events), approximate location at city level, and — at checkout — the email and address you provide, in order to attribute purchases to their original marketing source. Ordinary does not sell or share this data with third parties for their own purposes. Ordinary is contractually our data processor; our agreement with them is the Ordinary Data Processing Agreement.

Adjust to match your existing policy’s voice. Your customers’ opt-out rights run through your standard channels (your privacy policy contact, Shopify’s customer privacy controls, our Data Deletion page).

Consent banners

Shopify offers a customer-privacy framework that lets visitors decline analytics. Where required by law (notably the EU and UK), you should have a consent banner installed on your store that gates Shopify’s analytics-consent flag. When a visitor declines, Shopify’s pixel (including Ordinary’s) will not fire — that’s how the framework works for every analytics app, not just Ordinary. We respect that gate.

The Theme App Extension portion of Ordinary (the part that writes the browser UUID) is not consent-gated by Shopify the same way the pixel is, but the Extension only writes pseudonymous identifiers and does not capture personal data. If you want to disable it for a specific deployment, you can toggle it off in your theme editor under App Embeds.

The same consent gate applies to the experiments dashboard — A/B tests don’t get any special treatment. Shoppers who decline cookies are invisible to your experiment results too, which means sample sizes for tests with strict-region traffic will be lower than your overall visitor count suggests. The experiments article covers this in more detail, including how to plan around it.

What happens when a customer asks to be deleted

Two ways to handle a deletion request:

1. Through Shopify — open the customer’s record in Shopify Admin and use Shopify’s standard “Erase customer” workflow. Shopify will fire the standard customers/redact webhook, and Ordinary will delete the corresponding records from your dataset.

2. Through Ordinary directly — point the customer (or yourself) at our Data Deletion page for the manual process.

Either way, deletion is normally completed within 30 days, in line with GDPR Article 12(3) and similar timelines elsewhere.

When we change our privacy posture

If we materially change how Ordinary handles your visitor or customer data — adding a new sub-processor, changing what we capture, changing the region-aware default above — we will:

• Update the Privacy Policy and DPA on the relevant date
• Email the contact on file for your organisation
• Give at least 30 days’ notice for new sub-processors per industry standard

The change history is recorded at the bottom of the DPA.