Why Optimizely Data Doesn't Match Google Analytics (And How to Fix It)

Why Optimizely Data Doesn't Match Google Analytics (And How to Fix It)

"Your Optimizely results show 14,200 visitors in the experiment. GA4 shows 11,800. Which one is right?"

This question comes up in almost every post-experiment readout. And the answer — frustratingly — is: both, and neither, depending on what you're measuring.

Discrepancies between Optimizely and Google Analytics are normal. They are expected. A 10-20% difference in visitor counts between the two tools is not a problem to fix — it's a feature of how fundamentally different the tools are.

But there are discrepancy patterns that do signal real problems. This guide shows you how to tell the difference and what to do about each.

Why Discrepancies Are Normal and Expected

Optimizely and GA4 are measuring different things, at different times, with different identity models. They will never match exactly.

Here's what each tool is actually counting:

Optimizely counts: Unique visitors who were assigned to an experiment variation, identified by the optimizelyEndUserID cookie, for the lifetime of the experiment.

GA4 counts: Sessions (and users, which is a different thing again) identified by the GA4 client ID cookie, with events triggered when the GA4 script fires.

These are fundamentally different units of measurement. A single Optimizely visitor can generate multiple GA4 sessions. A single GA4 session can involve multiple page views across multiple Optimizely experiments. The counts will not match, and they're not supposed to.

The acceptable range for visitor count discrepancy between Optimizely and GA4 is roughly 10-25%. Anything within that range, in either direction, is within normal operating variance given the differences in identity model, timing, and bot filtering.

**Pro Tip:** Before any experiment launches, document your baseline discrepancy rate — compare Optimizely visitor counts against GA4 session counts for a week of non-experiment traffic on the same pages. That ratio is your expected discrepancy. If your experiment shows a significantly larger discrepancy, that's the signal worth investigating.

The 5 Root Causes of Discrepancies

1. Different User Identity Models

This is the biggest driver of count differences and cannot be eliminated — only understood.

Optimizely's visitor ID: The optimizelyEndUserID cookie, set at the visitor level with a 6-month expiration. Optimizely counts each unique cookie value once per experiment. If someone clears cookies and revisits, they become a new visitor to Optimizely and are re-bucketed.

GA4's identity: GA4 uses a combination of the ga client ID cookie, logged-in user IDs (if you've implemented user ID tracking), and Google Signals for cross-device stitching. A single person can have different GA4 client IDs across devices, browsers, and after clearing cookies.

The practical result: Optimizely usually shows fewer unique visitors than GA4 shows sessions, because GA4 sessions are a less strict unit. But Optimizely may show more unique visitors than GA4's "active users" count, because GA4 applies more aggressive deduplication across sessions.

2. Script Loading and Timing Differences

The Optimizely Web snippet is loaded synchronously at the top of the page head — it must execute before any page rendering to avoid flicker. GA4 (via GTM or direct integration) typically loads asynchronously and lower on the page.

This means for every page load, Optimizely fires before GA4 does. In some percentage of sessions — typically 3-8% — the user bounces, navigates away, or the page crashes before GA4 finishes loading. Optimizely recorded a visitor; GA4 did not.

This timing gap is the most consistent and predictable source of discrepancy. It runs in one direction: Optimizely overcounts relative to GA4.

How to reduce this: Move your GTM snippet as close to the Optimizely snippet as possible in the page head tag. If you're using a direct GA4 implementation rather than GTM, load the GA4 config tag at the same position.

3. Ad Blockers and Tracking Prevention

Ad blockers, browser privacy modes, and iOS Intelligent Tracking Prevention (ITP) affect the two tools differently.

Optimizely's tracking is typically loaded server-side or via a first-party CDN endpoint, making it harder to block. GA4's standard tracking endpoint (analytics.google.com) is on most major blocklists.

In markets with high technical sophistication — developer tools, security products, enterprise B2B — ad blocker penetration can be 25-40% of your traffic. These visitors appear in Optimizely but not in GA4. This is not a discrepancy to "fix" — it's a real difference in what each tool can see.

**Pro Tip:** Check your discrepancy magnitude against your audience profile. If you're running experiments on a developer-focused landing page vs. a consumer checkout flow, you'll see dramatically different discrepancy rates. Knowing your ad blocker rate explains a large portion of the gap.

4. Session and Conversion Window Differences

Optimizely counts a conversion as belonging to a visitor if it happens at any point during the experiment run — it's lifetime attribution within the experiment window. By default, there's no session timeout.

GA4 uses a session-based model with a 30-minute timeout. A visitor who converts 45 minutes after their initial page view may have that conversion attributed to a second session in GA4, while Optimizely attributes it to the same visitor.

This matters most for conversion metric comparisons, not just visitor counts. If you're comparing Optimizely's reported conversion rate against GA4's goal completion rate, the denominator and attribution window differences alone can produce 15-30% differences in conversion rate — even if both tools are working perfectly.

5. Bot Filtering and Traffic Quality Differences

Both tools filter bot traffic, but they use different methods and different blocklists.

GA4 uses Google's bot detection — which is aggressive and continuously updated. Optimizely filters known bots but allows legitimate automated traffic (certain monitoring tools, synthetic testing) that GA4 may flag differently.

If you're in a high-bot-traffic vertical (consumer finance, competitive e-commerce), bot filtering differences can account for 5-15% of visitor count discrepancy.

Auditing Each Cause Systematically

When a stakeholder questions your discrepancy, run through these checks in order:

Step 1: Calculate the discrepancy magnitude and direction Optimizely visitors ÷ GA4 sessions for the same date range and page(s). Is it within 10-25%? If yes, document as expected and move on. If Optimizely is > 30% above or below GA4, investigate.

Step 2: Check the timing gap Open a browser network tab on your test page. How many milliseconds between the Optimizely snippet firing and the GA4 tag firing? If it's > 500ms, you have a meaningful timing gap. Move GTM/GA4 earlier in the page.

Step 3: Check the experiment scope vs. GA4 view Is your GA4 report scoped to the same pages your experiment is running on? An experiment on your checkout page, compared against a GA4 view of all traffic, will show a massive discrepancy that's purely a scope mismatch.

Step 4: Check for bounce rate contribution Your page's bounce rate in GA4 is approximately the upper bound of your timing-related discrepancy. High bounce rate + high discrepancy = timing is the culprit.

Step 5: Check your ad blocker penetration Compare traffic volume on your experiment pages between GA4 and your server-side log data (if available). The gap between server logs and GA4 is your ad blocker rate. Apply that rate to explain the Optimizely-GA4 gap.

**Pro Tip:** Build a discrepancy check into your experiment QA checklist. Run the experiment for 48 hours in QA traffic, compare Optimizely vs. GA4 visitor counts, and document the baseline ratio. If production discrepancy exceeds your QA baseline by more than 5 percentage points, flag it for investigation before the experiment results are read.

Red Flags: When Discrepancies Signal a Real Problem

These patterns indicate something is wrong and need investigation:

Discrepancy > 35% in either direction. At this level, there's almost certainly a technical problem: the wrong GA4 property is being compared, the experiment is running on more pages than the GA4 filter covers, or there's an implementation bug.

Optimizely shows flat conversions while GA4 shows normal. Your Optimizely conversion event is broken. It may have been firing on the wrong event, or a recent code change broke the trigger.

Discrepancy changes direction mid-experiment. If Optimizely was 15% above GA4 for the first week and drops to 8% below in week two, something changed — a code deployment, a campaign change, or a bot burst.

GA4 shows zero experiment-related events. If you're using Optimizely's GA4 integration to send experiment bucketing events, and those events aren't appearing in GA4, your integration is broken. This means you cannot validate your test results in GA4 at all.

One tool shows a trend reversal the other doesn't. If Optimizely shows conversion rate going up and GA4 shows it going down for the same period, you have a measurement discrepancy that needs to be resolved before any result can be trusted.

Reconciling Data When Stakeholders Question It

The question is always: "Which number do I use?"

Here's the decision framework:

For experiment statistical validity: Use Optimizely. Full stop. Stats Engine is designed for Optimizely's data, not GA4's. The confidence intervals, significance calls, and improvement calculations are all based on Optimizely's visitor and conversion counts. Using GA4 data to recalculate significance is methodologically incorrect.

For revenue impact calculations: Use your backend/order management system data, not either analytics tool. Neither Optimizely nor GA4 is a system of record for transactions.

For understanding traffic sources and user behavior context: Use GA4. It's better at session-level behavior, funnel analysis, and attribution.

For stakeholder trust: Acknowledge the discrepancy proactively. "Optimizely shows 14,200 visitors; GA4 shows 11,800. The 17% difference is within the expected range for our site given our implementation — Optimizely loads before GA4 and captures visitors who bounce before GA4 fires." A confident explanation of an expected discrepancy is much more convincing than a defensive response.

Worked Example: Auditing a 31% Discrepancy

Situation: Experiment on product detail page. 2 weeks of runtime. Optimizely shows 22,400 visitors; GA4 shows 15,700 visitors. 30% discrepancy.

Step 1: Calculate. 22,400 / 15,700 = 1.43. Optimizely is 43% above GA4. That's above the expected range.

Step 2: Check GA4 filter scope. The GA4 report was filtered to "product detail pages" using a page path filter of /products/. The experiment, however, was running on URLs matching /products/ AND /shop/. The GA4 filter missed 25% of the experiment pages.

Step 3: Re-run GA4 report with corrected scope. GA4 shows 20,100 visitors. New discrepancy: 11.4%. Within expected range.

Resolution: Scope mismatch. No implementation problem. Document the finding and note it in the experiment record so future readouts use the correct GA4 filter.

Setting Up a Discrepancy Check in Your QA Process

Add this to your experiment launch checklist:

1. Confirm the GA4 property and view/filter matches the pages where the experiment runs
2. Check that the Optimizely snippet fires before GTM/GA4 in the page source
3. QA fire both Optimizely and GA4 events on a test visitor and confirm both appear in their respective debuggers
4. Record the baseline discrepancy ratio (Optimizely visitors / GA4 sessions) for 48 hours of QA traffic
5. After launch, check discrepancy at Day 3 and compare against the QA baseline. Flag if off by > 5 points.

**Pro Tip:** Create a Looker Studio (formerly Data Studio) dashboard that automatically calculates the Optimizely-to-GA4 visitor ratio daily for your current experiments. A ratio that suddenly spikes or drops is your early warning system for implementation problems — often catching them days before you'd notice them in the experiment results.

Common Mistakes

Expecting the numbers to match. They won't. Build stakeholder expectations around this before the experiment, not during the readout.

Using the wrong GA4 scope. Always confirm your GA4 report is filtered to the exact pages the experiment is running on. This single mistake accounts for most "alarming" discrepancies.

Recalculating significance using GA4 data. Optimizely's Stats Engine significance is based on Optimizely's data. Using GA4 conversion counts with Optimizely visitor counts (or vice versa) gives you meaningless numbers.

Ignoring directional discrepancies. If conversion trends in the two tools are moving in opposite directions during the experiment, that's always worth investigating regardless of magnitude.

Not having a documented baseline. Without knowing your site's typical Optimizely-to-GA4 ratio before the experiment, you have no benchmark to judge whether the experiment-period discrepancy is normal or anomalous.

What to Do Next

1. Pull your last completed experiment. Calculate the Optimizely visitor count vs. GA4 session count for the same pages and date range. Is it within 10-25%? Document this as your site's baseline discrepancy ratio.
2. Check your current page source: is the Optimizely snippet loading before your GTM or GA4 script? If not, make a ticket to reorder the scripts.
3. Add a discrepancy check to your experiment launch QA checklist. 10 minutes of upfront validation saves hours of post-experiment debates.
4. Review the results page walkthrough to build a clear picture of which Optimizely numbers matter most when discrepancies come up in your readouts.