GA4 and Adobe Analytics are often compared like competing car trims, but they're built on genuinely different data models. GA4 is event-based: everything that happens is an event with parameters, and there is no native concept of a "page view" distinct from any other event — a page view is just an event named page_view. Adobe Analytics (formerly Omniture/SiteCatalyst) is built on hits, props, and eVars: a hit is a server call, props are session-scoped dimensions that reset, and eVars are persistent dimensions that can carry a value forward across hits for a configurable expiration window.

This isn't a cosmetic difference. It changes how you model everything downstream — what a "conversion" means, how a value gets attributed to a later event, and how much configuration work happens at collection time versus query time.

eVars: the feature GA4 has no real equivalent for

An eVar is Adobe's mechanism for persistence: set an eVar on one hit (say, a product viewed), and it can continue to be attached to every subsequent hit for that visitor until it expires or is overwritten, based on an allocation rule you choose per eVar — last-touch, linear, or a custom lookback. This is enormously powerful for mid-funnel attribution: you can set "campaign that drove this site visit" as an eVar with a 30-day expiration and have it silently ride along to the purchase hit weeks later, with the allocation model already applied at collection time.

GA4 has no native per-dimension persistence or allocation configuration. Session scope and user scope exist for custom dimensions, but you cannot define per-dimension lookback windows or allocation models in the UI — that logic has to be rebuilt downstream, typically in BigQuery, using the exported event stream.

GA4 pushes modeling to the warehouse; Adobe pushes it to collection-time config

This is the real tradeoff. Adobe lets an analyst configure sophisticated attribution and persistence rules in the admin console without writing a query. GA4 ships a comparatively bare event stream to BigQuery and expects you to build that same logic in SQL. Teams with strong SQL/analytics engineering capacity often prefer GA4's approach because it's transparent and version-controlled; teams without that capacity feel the gap immediately once they try to answer anything beyond last-click.

Processing rules, segmentation, and real-time flexibility

Adobe's Processing Rules let an admin rewrite, concatenate, or conditionally set variables based on other variables at collection time, before any report runs — effectively a lightweight ETL layer inside the platform. Adobe's segmentation builder (used across Analysis Workspace, Reports & Analytics, and the Audience Manager-style integrations) supports container logic (hit/visit/visitor-scoped conditions nested arbitrarily) that is more expressive out of the box than GA4's UI-based segment/audience builder.

GA4's equivalent flexibility exists, but it mostly lives in BigQuery SQL rather than point-and-click configuration. GA4's native UI segmentation (via Explorations) is usable for straightforward segments but hits a ceiling fast for the kind of nested, multi-scope conditions Adobe analysts take for granted.

GA4 vs. Adobe Analytics: core differences

Dimension	GA4	Adobe Analytics
Data model	Event + parameters, flat per-event	Hits, props (session), eVars (persistent, configurable)
Persistence/allocation	Not natively configurable; rebuilt in BigQuery	Native eVar expiration + allocation (last/linear/custom)
Collection-time transforms	Minimal (GTM handles most logic pre-send)	Processing Rules — transform inside the platform
Raw data export	Free, unsampled, to BigQuery	Data Feeds / Data Warehouse — paid, enterprise tier
Segmentation depth (UI)	Explorations — moderate	Analysis Workspace container logic — deep
Pricing model	Free tier generous; GA4 360 for enterprise SLAs	Enterprise license, typically six-figure annual minimum
Learning curve	Lower; event model is intuitive	Steeper; eVar/prop allocation takes real training

evar_vs_bigquery_rebuild.txt

text

Adobe (configured once, in admin UI):
  eVar5 = "last-touch marketing channel"
  Expiration: 30 days
  Allocation: Most Recent
  -> every hit for 30 days after a channel-tagged visit
     automatically carries that channel, no query needed

GA4 (rebuilt per-project, in SQL):
  1. Pull session_start events with traffic_source.*
  2. Window function: LAST_VALUE(source) OVER (
       PARTITION BY user_pseudo_id
       ORDER BY event_timestamp
       RANGE BETWEEN 30 DAYS PRECEDING AND CURRENT ROW
     )
  3. Join that derived channel back onto purchase events
  -> same outcome, but it's a maintained SQL asset, not a
     platform setting

Don't buy Adobe for features you'd never configure

Adobe's price tag is easy to justify on a feature comparison sheet and hard to justify on actual usage. If your team isn't going to staff someone who understands eVar allocation rules, Processing Rules, and Analysis Workspace container logic well enough to maintain them, you're paying enterprise pricing for a UI layer around capability you could replicate — more transparently — in BigQuery SQL on top of GA4's free export.

When Adobe's cost and complexity are actually justified

Adobe tends to earn its cost in a specific profile of organization: large enterprises with dedicated analytics teams, strict data governance requirements, multi-brand/multi-property setups needing centralized admin control, and — often decisively — existing investment in the Adobe Experience Cloud (Target, Campaign, Experience Platform, Customer Journey Analytics). Once Analytics data needs to flow natively into Adobe Target for personalization or Adobe Campaign for triggered journeys, the integration tax of bolting GA4 onto that stack frequently exceeds Adobe's license premium.

Conversely, a mid-market or digital-native company without an existing Adobe Experience Cloud footprint, with engineers comfortable in SQL, and without a dedicated analytics operations team is almost always better served by GA4 plus BigQuery — same modeling power, no license fee, more transparent logic.

What's next

Whichever platform you're on, the warehouse is where the real modeling happens once you need persistence, attribution windows, or cross-platform joins that the UI can't express. The BigQuery for Marketers module covers exactly how to rebuild that logic on GA4's export.

Next: BigQuery for Marketers →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →