> For the complete documentation index, see [llms.txt](https://eraya.gitbook.io/eraya-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eraya.gitbook.io/eraya-docs/eraya-analytics-specification/analytics-gdpr-ccpa-and-similar.md).

# 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_variation` note 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:

| Type                     | Examples                                     |
| ------------------------ | -------------------------------------------- |
| 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_id` and `_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_history` and `_eraya_clids` — a compact record of the marketing source(s) and ad-click IDs for the visit
* Test-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

| Metric            | Source                               | Affected by cookie consent?       |
| ----------------- | ------------------------------------ | --------------------------------- |
| 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.