Adobe Analytics
Checked: 2026-08-16
The enterprise analytics incumbent, and a genuinely different data model from GA4 — variables carry their own persistence and attribution rules, decided at collection time and permanent thereafter. Meeting it is what makes GA4’s model visible as a choice rather than as how analytics works.
§0 The one idea
Attribution is a property of the variable, not a setting on the report.
In GA4 you collect events and decide attribution later. In Adobe Analytics you declare, per variable, how long a value persists and which value gets credit — and that decision is applied as data arrives.
GA4
collect events → decide attribution
at report time
ADOBE ANALYTICS
declare persistence + allocation
↓ applied at COLLECTION
data is pre-processed with those
rules baked in
↓
reports read the result
The consequence that defines working in it: a variable configured wrongly is wrong for all the data already collected, permanently. There is no re-processing. This is why Adobe implementations are documented obsessively and changed reluctantly — and why the newer Customer Journey Analytics exists, which moves the same calculations to report time — Adobe Experience Cloud.
At a glance
| The two variable types | props and eVars |
| props | No persistence, 100-byte limit |
| eVars | Persist, 255-byte limit |
| Limits | 75 props · 250 eVars |
| Events | Success events — counters and currency |
| The container | Report suite |
| The analysis tool | Analysis Workspace |
| Visitor ID | ECID |
| Processing | Pre-processed at collection |
| The successor | Customer Journey Analytics |
props versus eVars
The distinction everything else hangs on, and the one to get right first.
PROP (traffic variable)
value applies to THIS HIT only
no persistence, no attribution
100 bytes
→ "what page was this?"
eVAR (conversion variable)
value PERSISTS beyond the hit it
was set on
carries expiry + allocation rules
255 bytes
→ "what brought them here, and does
it still get credit for this order?"
Verified: eVars persist beyond the hit they are set on by default; props do not. eVars have a 255-byte limit in reports, props 100 bytes.
Seeing it
The same visit, recorded both ways:
HIT PAGE prop5 eVar5
(campaign) (campaign)
1 landing summer-sale summer-sale
2 category – summer-sale
3 product – summer-sale
4 PURCHASE – summer-sale
↑ credited
The prop is empty from hit 2 onward. The eVar carries. So a “revenue by campaign” report is only possible from the eVar — the prop can only tell you which page the campaign value appeared on.
This is the whole reason both exist. props are cheap and describe the hit; eVars are the attribution machinery.
The two settings that decide everything
Every eVar carries two configuration choices, set per report suite.
Expiration — how long the value persists
Hit one hit only (an eVar acting
like a prop)
Visit until the session ends
Visitor until the visitor cookie dies
Never until the visitor clears cookies
7 / 30 / 90 days
On an event until a chosen success event
fires — e.g. expire on purchase
Verified: with expiration set to Never, the value persists until the visitor deletes their cookie.
After expiry, success events are credited to None. That’s the source of one of the most common Adobe confusions — a large “None” or “Unspecified” row is usually not missing tracking, it’s values that expired before the conversion — the symptom list.
Allocation — which value gets credit
ORIGINAL VALUE (first)
visit: email → paid → direct → PURCHASE
▲
email keeps the credit until
the eVar expires
MOST RECENT (last)
visit: email → paid → direct → PURCHASE
▲
direct takes it
LINEAR
credit split equally across all values
← use with a Visit expiry, not longer
Verified: with Original Value allocation the first eVar value keeps credit for success events until it expires; Linear allocates equally across values and should be paired with a Visit expiration.
In plain terms: allocation is the attribution model, chosen per variable, at implementation time. Adobe made you decide first-touch versus last-touch when you set the variable up — where GA4 defers it to a report setting — Attribution Models.
Events, and the counting model
Success events are the things being counted — orders, revenue, form submissions, custom milestones. They’re the metrics; props and eVars are the dimensions crediting them.
COUNTER EVENT event1 = 1
"a lead was submitted"
CURRENCY EVENT purchase, revenue=50.00
money
CUSTOM event20, event21…
Serialisation is the deduplication mechanism — attach an ID to an event and Adobe counts it once, no matter how many times the page fires. Use it on purchase. Order-confirmation pages get refreshed, bookmarked and re-opened, and without serialisation each one is another sale — Revenue Metrics, Tool Discrepancies.
Report suites
The container for data, and a structural decision rather than a settings one.
REPORT SUITE
├─ its own variable configuration
├─ its own processing rules
├─ its own currency, timezone, calendar
└─ its own data
VIRTUAL REPORT SUITE
a saved segment presented as a suite
no duplicate collection
GLOBAL REPORT SUITE
everything in one, with a dimension
to separate brands or regions
The classic mistake is one suite per site. Cross-property analysis then becomes impossible, because a visitor in two suites is two visitors. The global suite with a separating dimension is nearly always right — the timezone and currency being shared is a much smaller problem than never being able to see a journey end to end.
Analysis Workspace
The analysis interface, and genuinely the strongest thing about the product.
- Freeform tables — drag dimensions and metrics into a pivot. Fast, and more flexible than GA4’s exploration
- Segments apply at hit, visit or visitor scope, and retroactively, which is the crucial difference from the variables themselves
- Fallout and flow — funnel and path analysis without pre-declaring the funnel
- Calculated metrics — derived metrics saved and shared
- Cohort tables — retention, built in
Segments are retroactive; variables are not. That single asymmetry explains most of Adobe practice: put as much as you can into segments, because those you can change your mind about — Segmentation (analysis).
Where the data comes out
- Data Warehouse — non-real-time, raw-ish exports for deeper work
- Data Feeds — hit-level raw data delivered on a schedule. The route into a warehouse — Warehouse-First Analytics
- Reporting API — programmatic access to Workspace-style reports
- Analytics for Target (A4T) — Target activity data reported on Analytics metrics — Adobe Target
Data Feeds are the escape hatch. If reporting hits the model’s limits, hit-level data in a warehouse removes them — at the cost of rebuilding sessionisation and attribution yourself — Sessionisation.
The trap: 250 eVars is not a lot
It sounds generous and it isn’t, for a specific reason: eVars accumulate and are never safely retired.
YEAR 1 eVar1–20 carefully designed
YEAR 3 eVar1–60 several campaigns' worth
YEAR 6 eVar1–140 three agencies later
eVar 47 is "test - do
not use"
nobody knows what
eVar 92 holds
Repurposing an eVar means historical data holds one meaning and new data another, in the same dimension — so the safe move is always to take a new one, and the numbers only go up. A mature Adobe implementation’s variable map is an archaeological record, and reading it is the first job on arriving — Metric Drift, Tracking Plans.
CJA’s unlimited dimensions are a direct answer to exactly this — Adobe Experience Cloud.
Versus GA4
| Adobe Analytics | GA4 | |
|---|---|---|
| Model | props, eVars, events | Events with parameters |
| Attribution | Per variable, at collection | Report-time setting |
| Retroactive fixes | Essentially no | Partly |
| Dimension limit | 75 props, 250 eVars | Custom dimension limits |
| Analysis | Analysis Workspace | Explorations |
| Raw data | Data Feeds | BigQuery export |
| Cost | Enterprise contract | Free tier exists |
| Sampling | Rare | A real constraint |
The honest comparison: Adobe is more rigorous and less forgiving. It makes you decide attribution up front and holds you to it; GA4 lets you defer and change your mind, at the cost of a model that answers “what happened” less precisely.
Neither is better. Knowing both makes you better at either, because you stop treating your own tool’s choices as facts about analytics — Attribution Models, Metric Design.
Where it hurts
- Permanence. A variable configured wrongly is wrong forever for collected data
- The learning curve. props, eVars, allocation, expiry, serialisation, report suites — six unfamiliar concepts before your first report
- Accumulated debris in any implementation older than a few years
- Cost, and the specialists it requires
- Two products in flight. Analytics and CJA both exist, and which one a team uses tells you where they are — Adobe Experience Cloud
Related
- Adobe Experience Cloud — where this sits, and the CJA question
- Adobe Target — A4T reports test results here
- GA4 — the model you already have
- Attribution Models · Attribution Windows — what allocation and expiry are
- Sessionisation · Identity Stitching — what a visit and a visitor mean underneath