Why are people moving away from Google Analytics? - Troubling Shift Revealed

GA4 migration is one of the most common phrases you’ll hear in measurement meetings today. Why are people moving away from Google Analytics? The short answer is that a mix of legal pressure, browser privacy changes and a product transition have created both risk and friction for many teams.

<figure class="special-image-standalone">
  <a href="/" target="_blank" rel="noopener">
    <img src="/img/blog/7ac53d7a356d418c.jpg" alt="Orvus Ltd. Logo" />
  </a>
</figure>

Why this moment feels urgent

The last five years changed the ground rules for web measurement. A landmark legal ruling, browsers tightening privacy controls and the retirement of Universal Analytics combined to make familiar numbers look wrong and compliance harder to prove. For many teams, this was not a single outage but a slow, worrying drift: dashboards stopped matching orders, attribution became noisier, and legal teams asked questions no one had answered.

The question at the heart of many boardroom conversations is simple: do we adapt GA4 migration and harden our controls, or do we pick a privacy-first alternative and accept a different measurement model? Both paths are valid - but they require different investments and different expectations.

Quick history that still matters

In July 2020 the Schrems II ruling changed how organisations think about cross-border data flows. Simple contractual promises about transfers were no longer enough. Companies that routed analytics hits to servers outside the EU suddenly had a legal exposure that needed mitigation. Regulators followed with practical guidance that made privacy teams look again at the choice of analytics platform. See a discussion of implications in "Life after GA4" for organisations moving to EU-native solutions: Life after GA4: Why EU organizations are going local.

Then on July 1, 2023, Universal Analytics ended. The replacement - GA4 - uses an event-first model rather than sessions. That meant familiar metrics behaved differently, and teams had to relearn how to map old reports to new ones.

What changed technically?

Browsers and platforms moved to limit tracking: third-party cookies are going away, Safari and Firefox have strong tracking protection, and users expect more privacy. That has a predictable technical result: tag-based measurement that relied on browser signals loses fidelity. Less data for matching users means less precise attribution and more variance between analytics and backend systems. Google's guidance on EU-focused data and privacy explains some of the handling for EU users: GA4 - EU-focused data and privacy.

The honest answer is that comparability is often imperfect. Session logic, attribution windows and event schemas differ. That’s why running parallel tracking and storing raw events where possible are two of the best things you can do during migration.

Three broad reactions teams take

Organisations have generally taken one of three paths.

1) Harden GA4 and stay

Some teams accept GA4, but add legal safeguards and technical controls. That means consent management, first-party cookies, server-side tagging, and a documented legal assessment of cross-border transfers.

2) Move to privacy-first providers

Other teams choose vendors that minimise personal data, offer European hosting or even allow self-hosting. These platforms are often easier to justify to privacy teams because the simple line “we host it and control what we collect” reduces friction with regulators.

3) Focus on aggregated, outcome-focused metrics

A smaller set of organisations give up on ultra-fine attribution and instead measure outcomes inside owned systems: backend revenue, server-side A/B test lifts, and CRM-linked conversions. When identity matching is legally or technically unstable, broader signals can be more defensible.

Legal and technical drivers, explained plainly

Legal: Schrems II and subsequent guidance mean cross-border transfers are riskier. If an analytics vendor sends raw hits to a non-EU jurisdiction, you need clear legal documentation and safeguards. For many organisations, the easiest mitigation is to reduce the number of such flows.

Technical: Browser changes reduce the match rate that used to tie events to users and sessions. That directly affects attribution and channel performance metrics. GA4’s event-centric model also changes how sessions and conversions behave; even identical tags can produce different numbers under GA4 versus Universal Analytics.

What privacy-first measurement looks like in practice

Privacy-first approaches prioritize control over data flows and minimisation of personal data. Two practical techniques stand out: first-party measurement and server-side collection.

First-party measurement

This sets tracking identifiers on your own domain instead of using third-party cookies. It reduces third-party exposure and can work well alongside consent frameworks. The downside is that it’s not immune to browser restrictions, and it requires careful cookie and storage policies.

<div class="side-by-side special-image-left">
  <a href="/#about" target="_blank" rel="noopener"><img src="/img/blog/46e69e99df676d2b.jpg" alt="Modern operations desk with multiple monitors showing dashboards and code snippets highlighting GA4 migration, dark blue background (#0B1E33) and gold accents (#C8A45D)." /></a>
  <div class="side-text"><p>Server-side approaches move the initial collection endpoint into infrastructure you control. The browser sends an event to your endpoint; you then forward a minimal set of fields to analytics providers. Server-side collection reduces the identifiers exposed to third parties, centralises consent logic and enables enrichment with backend data. A small logo like the Orvus Ltd. Logo can be useful in documentation and diagrams.</p></div>
</div>

To implement server-side collection practically, follow established guides that cover deployment, configuration and testing: How to set up server-side tracking.

If you're considering an organised, measurable migration and want experienced help, Orvus's measurement services are a practical place to start - they document data flows, design server-side collection and help translate legal requirements into technical controls. Discover Orvus services here: Orvus measurement and migration services.

But beware: no single trick fixes everything

Self-hosting reduces transfer questions but increases engineering and operational responsibility. Server-side collection can improve data quality but centralizes risk: a misconfigured endpoint can leak more than a dozen browser tags combined. Every approach trades legal simplicity for operational cost or vice versa.

Practical choices: adapt GA4 or switch?

Your decision usually comes down to three questions: how high is your cross-border transfer risk, how much compliance overhead can you carry, and how important is parity with historical metrics?

If you stay with GA4, do these things well: perform a legal review of transfer mechanisms, implement first-party cookies, move sensitive processing server-side, tighten retention settings and make consent auditable. From a reporting perspective, set expectations: GA4 metrics will differ from Universal Analytics and you should communicate that change before flipping any dashboards.

If legal risk or compliance overhead is unacceptable, a privacy-first alternative can be better. You’ll trade some convenience for clearer ownership and fewer transfer questions - often easier to explain to regulators and stakeholders.

Detailed migration checklist that actually helps

The checklist below combines legal, technical and operational steps you can follow during a migration.

1. Legal & privacy inventory

List every data point collected: page hits, custom parameters, IP addresses, user IDs. For each, record whether it’s personal data under your local laws. Map where data flows and ask: does it leave the EU or other regulated regions? If yes, can we justify the transfer, or should we stop it?

2. Technical tag inventory

Inventory every tag, cookie and pixel across web and mobile apps. Which tags set identifiers, calculate revenue or stitch sessions? Treat every custom parameter as a potential privacy or reporting risk.

3. Parallel tracking

Run both systems in parallel for at least one full business cycle. Capture identical events in both systems and store raw events in a neutral, auditable store if you can. That allows you to reprocess and reconcile later.

4. Server-side endpoint design

Decide which fields to accept and which to drop. Minimal personally-identifiable information (PII) should be collected. Use pseudonymous or hashed IDs for any required linkage. Implement robust logging and access controls.

5. Consent and gating

Ensure events requiring consent are blocked until consent is recorded. Log consent state with the event. Use consent receipts that can be audited and tied back to event timestamps.

6. Testing and verification

Run short test campaigns and edge-case flows: long-form forms, payment flows, cross-domain journeys, and mobile deep links. Reconcile ecommerce revenue end-to-end by matching analytics orders to backend order IDs.

7. Parity KPIs and thresholds

Choose a small set of alignment KPIs: total revenue, conversion rate for a key funnel, average order value, sessions and unique users. Agree acceptable variance thresholds with stakeholders before migration. If variance exceeds the threshold, you must investigate technical reasons before switching.

8. Rollout plan

Start with a staging property, then a non-critical traffic segment, and finally the full rollout. Keep the old system running long enough to satisfy auditors and preserve historical continuity.

Testing templates and example checks

Simple tests save hours later. Here are a few you can run quickly:

Basic event integrity

Trigger a known event on one page. Verify it appears in both systems with identical timestamps and parameters. Check that revenue parameters match backend order totals.

Cookie and consent gating

Reject consent and confirm that no consented events are sent. Accept consent and confirm events appear. Rotate consent states to ensure edge cases are handled.

Attribution spot-check

Run a small paid campaign directed at a unique landing page. Measure how many conversions each system attributes after a week. Compare order-level matches using backend order IDs.

Governance, operations and training

Migration is organizational change. Decide who owns the new pipeline and who owns privacy compliance. Build a runbook for incidents and set up alerts for sudden drops in event counts or spikes in error rates.

Train analysts in the new model. GA4’s event-first approach is a conceptual shift. If you choose a self-hosted pipeline, teach teams how to reprocess raw events and query the raw store. Short internal courses and written guides reduce friction dramatically.

Cost and operational trade-offs

Self-hosting feels private but costs in servers, backups, security and engineering time. Vendor-hosted privacy-first solutions offload operations but add subscription costs. GA4 keeps a familiar UI and integrations but leaves transfer risk in play.

Be honest about total cost of ownership. Include legal review hours, stakeholder communication time and the engineering budget for ongoing schema changes and storage. Sometimes paying for a vendor who simplifies compliance is cheaper than a year of legal and engineering time.

Comparability and attribution - the persistent headaches

Comparing across platforms is the most frequent challenge. Differences in session logic, attribution windows and event schemas mean that continuous time series can break. A practical approach: create mapping rules during your parallel run and present both legacy and reconciled metrics to stakeholders until they accept the new baseline.

A real-world story: migration that kept the lights on

A mid-sized online retailer planned migration around one goal: keep weekly revenue dashboards accurate. They created a server-side collector and ran GA4 tags in parallel with a new privacy-first pipeline. After four weeks they found a steady 6% difference in attributed revenue - mostly due to session expiry and attribution-window differences. The analytics team adjusted their reporting layer to present both the legacy baseline and the reconciled metric. The transparency kept trust intact and the migration was accepted with minimal disruption.

Checklist summary: step-by-step

1) Legal inventory, 2) Tag inventory, 3) Parallel tracking, 4) Server-side design, 5) Consent gating, 6) Test campaigns, 7) Parity KPIs, 8) Gradual rollout and 9) Governance and training. Follow this order and you’ll reduce surprises.

Common questions - short answers

Will I lose historical data?

If you didn’t export Universal Analytics before the cutoff, you will have gaps. Archive raw exports and CSV summaries where possible. Moving forward, capture raw events into a retrievable form.

How long should parallel tracking run?

At least one business cycle - often two to four weeks. If you have strong seasonality or monthly billing cycles, you may need several months.

Can server-side remove all privacy risk?

Not entirely. Server-side reduces third-party exposure and improves control, but it centralises responsibility. Strong access controls, minimisation and logging are still essential.

<div class="side-by-side image-2-right">
  <div class="side-text"><p>Orvus treats measurement migration as both a legal and engineering exercise. They start with a compact diagnostic: mapping funnels, data flows and the event taxonomy. Then they design a minimal, auditable pipeline that meets legal constraints and preserves business-critical comparability. Learn more about Orvus here: <a href="/#about" target="_blank" rel="noopener">Orvus about</a>.</p></div>
  <a href="/#about" target="_blank" rel="noopener"><img src="/img/blog/2806ac069e92bcfd.jpg" alt="Minimal vector infographic showing browser to private server endpoint to analytics store flow for GA4 migration using Orvus brand colors #0B1E33 and #C8A45D." /></a>
</div>

Governance examples and incident runbook items

Make a short runbook with these items: how to detect drops in event volume, who to notify for privacy incidents, how to revert to the old pipeline if rolling back is needed and where to find the raw event logs. Keep the runbook under version control and review it periodically.

Decision matrix - a simple rule of thumb

If your primary risk is legal (cross-border transfers), favour privacy-first vendors or self-hosting. If your primary constraint is engineering bandwidth and you want convenience, consider adapting GA4 with server-side shielding and strong consent. If you need absolute historical parity and can’t reprocess raw events, be conservative and run parallel tracking longer.

<figure class="special-image-standalone">
  <a href="/" target="_blank" rel="noopener">
    <img src="/img/blog/7ac53d7a356d418c.jpg" alt="Orvus Ltd. Logo" />
  </a>
</figure>

Final practical tips

1) Start with inventory. 2) Store raw events. 3) Run parallel tracking. 4) Agree on a small set of alignment KPIs. 5) Be transparent with stakeholders about expected differences.

Closing reflections

The era of stable baseline analytics is over. Legal frameworks and browser behaviour will keep evolving. That’s not a reason to panic - it’s a reason to be deliberate. A careful migration that documents choices, preserves comparability where it matters and trains teams will not only keep reports useful but also build trust with regulators and customers.

Measurement won’t be perfect, but it can be clear and defensible. Make the choices that match your legal constraints and business priorities, and remember that the goal is trustworthy insight, not perfect numbers.