Analytics - GDPR, CCPA, and similar
How cookie consent affects A/B test analytics and tracking on Shopify
Eraya helps Shopify merchants run A/B tests by tracking key user events like Add to Cart, Checkout, and Page Views. These events are collected client-side in the visitor's browser through the Eraya SDK and Shopify Web Pixels.
Orders and revenue, on the other hand, are reconciled server-side from Shopify — so they stay accurate even when client-side tracking is blocked. Understanding this split is the key to reading your results correctly.
What happens when a visitor declines cookies
Because of Shopify's privacy policies and global data-protection laws (GDPR, CCPA, and similar), if a visitor declines cookie consent in your store's privacy banner, Shopify automatically blocks tracking pixels. When that happens, these events cannot be collected:
Add to Cart events
Checkout events
Page View events
For any visitor who declines consent, none of the above will appear in your test's engagement metrics.
Important: This is a platform-level restriction enforced by Shopify — it is not something Eraya can override, and doing so would violate the visitor's privacy choice.
How to handle this in your A/B test analysis
If some visitors decline cookies, their client-side actions (Add to Cart, Checkout, Page View) won't be counted. Order count is unaffected, because Eraya reconciles orders directly from Shopify's server-side order data — which does not depend on cookie consent.
Each order still carries its test assignment. When a visitor is placed in a test, Eraya writes the assignment into the order's note attributes (for example _eraya_test_id, _eraya_variation, and _eraya_user_id). Shopify stores those attributes on the order regardless of the visitor's pixel-consent choice, so Eraya can attribute the order to the correct variation later.
What to focus on
If you're concerned about missing event data from privacy settings, base your decision on the metrics Shopify cannot restrict:
✅ Order count — reconciled from Shopify's server-side order data
✅ Revenue metrics — total revenue and AOV (average order value) per variation
✅ Conversion rate on orders — orders relative to assigned visitors
These are the numbers that decide a winner. Add to Cart and Checkout counts are useful directional signals for the funnel, but they are the metrics most affected by consent, so don't treat a gap there as the deciding factor.
Why the traffic split between variations can look uneven
You may notice the visitor split between variations isn't a clean 50/50 (or whatever ratio you configured). Cookie consent is a common reason, and in most cases it does not mean traffic is actually being allocated unevenly.
Here's why. The visitor and session counts shown per variation are client-side metrics — they come from the same pixel/SDK tracking that consent can block. So when a visitor declines consent, they may still be assigned to a variation and still see that variation's experience, but they won't be counted as a visitor in the reported numbers. If declined-consent visitors happen to land unevenly across variations, the reported split looks skewed even though the actual allocation is balanced.
Two things stay reliable regardless:
Assignment is still balanced. Eraya allocates visitors to variations based on their anonymous ID, independent of whether their events are tracked.
Orders are still attributed correctly. Every order carries its
_eraya_test_id/_eraya_variationnote attributes, so it's counted against the right variation even if that visitor was never tracked client-side.
What to do: judge fairness of the split by looking at orders and revenue per variation rather than raw visitor counts. If the order-level split is roughly in line with your configured ratio, the test is running correctly — a gap in the visitor counts alone is expected when consent is declined. A genuinely lopsided split usually points to a targeting/audience rule rather than a tracking issue; if you're unsure, reach out to Eraya support.
Why are order counts higher than checkout or Add to Cart events?
Some merchants are surprised to see more orders than checkout or Add to Cart events in the analytics table and assume it's a tracking bug. In almost all cases it isn't — it's the expected result of how client-side vs. server-side data is collected. Common causes:
1. Cookie / privacy settings
If your store shows a cookie banner, Eraya can only record client-side events for visitors who accept it. Visitors who decline still buy — and those orders are still attributed server-side — but their Add to Cart and Checkout events are blocked. Result: orders exceed the events that led to them.
2. Add to Cart skips straight to checkout
In some themes, the Add to Cart button takes the visitor directly to checkout (or straight to a payment sheet). No add-to-cart interaction fires, so the Web Pixel has nothing to record — but the order still lands.
3. Orders placed outside Shopify's native checkout
When an order is completed without going through Shopify's standard checkout page — for example via an express or alternative payment method — the checkout event isn't captured client-side, yet the order is.
Examples of flows that commonly bypass client-side checkout tracking:
COD / custom order forms
Releasit COD Form & Upsells and similar apps
Express checkout
Shop Pay, PayPal, Google Pay, Apple Pay
In each of these cases, order count remains correct because it comes from Shopify's server-side data — only the intermediate funnel events are missing.
Why Add to Cart events may not be tracked with certain third-party pixels installed
Some third-party pixel and marketing apps interfere with the browser storage the Eraya SDK relies on. Eraya keeps a small amount of attribution and assignment state in the browser's local storage (for example _eraya_attributions and _eraya_user_journey). When another app aggressively overwrites, locks, or clears local storage, it can disrupt Eraya's ability to record Add to Cart events reliably.
What this looks like: Add to Cart tracking becomes intermittent or drops out, while other events are generally unaffected.
What you can do:
If Add to Cart tracking is essential for a specific test, temporarily disable the conflicting app while the test runs.
Reach out to Eraya support with the app name — we investigate these conflicts and coordinate a fix where possible.
Note that even when a conflicting app affects client-side events, your order and revenue numbers are still accurate, because those are reconciled server-side.
Why do I see Eraya information in my orders?
If you've run an A/B test with Eraya, you may notice extra note attributes on some orders — keys prefixed with _eraya_, such as:
_eraya_test_idand_eraya_variation— which test and variation the visitor was assigned to_eraya_user_id— the anonymous visitor identifier used to keep assignment consistent_eraya_utm_historyand_eraya_clids— a compact record of the marketing source(s) and ad-click IDs for the visitTest-specific keys such as
_eraya_shipping_test_…,_eraya_theme_test_id,_eraya_url_test_…,_eraya_template_test_…
This is normal and expected.
What these notes are used for
They capture session-level details about the visit — the assigned variation and the marketing channel it came from — so Eraya can attribute each order to the right test group and channel in your reports. They do not affect the shopping experience or what the customer sees.
Why they're still added after a test ends
Visitors are assigned to test groups while a test is active. If someone visits during the test but places their order later — even after the test has ended — their original assignment is still recorded so the order is attributed correctly. This is what keeps late conversions from silently dropping out of your results.
Can I remove these notes?
We don't recommend it. These note attributes are how Eraya filters and attributes test results. Deleting or overwriting them can produce incomplete or inaccurate data for the affected orders.
Quick reference
Page Views
Client-side (SDK / Web Pixel)
Yes — blocked if consent declined
Add to Cart
Client-side (SDK / Web Pixel)
Yes — blocked if consent declined
Checkout
Client-side (SDK / Web Pixel)
Yes — blocked if consent declined
Order count
Server-side (Shopify order data)
No — always accurate
Revenue / AOV
Server-side (Shopify order data)
No — always accurate
Bottom line: decide your test winners on orders and revenue. Treat Add to Cart, Checkout, and Page View as directional funnel signals — they can undercount due to privacy settings, theme behavior, and third-party apps, but that never affects the accuracy of your orders or revenue.
Last updated