eVars, props, events
— and why they differ.

1 · The three families

Every custom variable in Adobe Analytics belongs to one of three families. They look similar in code — they're all just properties of s — but they behave differently in the reporting database. Confusing them is the most common cause of "the numbers don't match" escalations.

The mental model: props describe the page; eVars describe the cause; events are the count. A product detail page is described by props (category = "telescopes"), the SKU that led to a sale is captured by an eVar (eVar4 = "ASTRO-3000"), and the act of viewing it is incremented by an event (event1 = "Product View").

2 · Props — traffic variables

Props are simple. They report on the hit they fire with — nothing more. A prop set on a page view shows up in reports as the value for that page view's row.

s.prop1 = "logged-in";
s.prop4 = "telescopes";
s.prop15 = "homepage-hero-v3";
s.t();

If the same user later loads a new page and you don't set prop1 again, prop1 is empty on the next hit. Props don't remember. They report only on the hit that carried them.

2.1 — Pathing on props

Props have one unique superpower: they can enable pathing. When pathing is enabled on a prop, Adobe stores not just the value, but the sequence of values across a visit. This produces the Pathing reports — "Next Page Flow," "Fallout," "Previous Value."

You enable pathing per-prop in the Admin Console (Report Suites → Edit Settings → Traffic → Traffic Variables). Once enabled, that prop produces pathing reports for that report suite.

Pathing has a cost: it's computed at hit time. Enabling it on too many props slows your report suite. Pick deliberately — usually pageName, site section, and one or two business-specific flows.

2.2 — List props

A regular prop carries one value. A list prop carries many, comma-delimited, and each value is reported as its own row. Useful for things that genuinely co-occur on one page: all tags on an article, all filters applied to a search.

// Article tagged "science", "space", "telescopes" on one page
s.prop10 = "science,space,telescopes";
// In the prop10 report, each tag gets credit for one page view

The delimiter is configurable in Admin Console. The default is comma. If your values contain commas naturally (e.g. "Smith, John"), change the delimiter to a pipe and adjust your code.

3 · eVars — conversion variables

eVars are how Adobe Analytics models attribution. An eVar set on one hit can persist to later hits, where it then gets credit for events that fire there. This is the entire foundation of "Revenue by Last Internal Campaign" and similar reports.

// Hit 1 — page view
s.eVar15 = "homepage-hero-summer-sale";  // tracks the campaign
s.t();

// Hit 2 — later, on checkout, no eVar15 set
s.events = "purchase";
s.purchaseID = "ORD-9981";
s.t();

In the eVar15 report, "homepage-hero-summer-sale" will show 1 purchase and the order's revenue — even though eVar15 was not on the hit that fired the purchase event. That's persistence.

Persistence is governed by two settings on each eVar, both configured in the Admin Console: allocation and expiration.

4 · Allocation — who gets credit?

Imagine eVar15 was set to two different campaign names during one visit. Then a purchase happened. Which campaign value gets credit for the revenue? Allocation answers that.

Allocation cannot be changed retroactively. The value is baked into the eVar at the report-suite level, and it applies from the moment you change it forward. Pick wisely up front.

5 · Expiration — how long does it persist?

Expiration tells AA when to "forget" the eVar value. The default is Visit, but you can choose anything from one hit to never.

"Expire on event" is powerful and underused. A classic pattern: campaign eVar set to "Most Recent" allocation, expiring on the purchase event. The user clicks a Google Ads campaign, browses for a week, then buys — the campaign value persists across all those visits and finally credits the purchase. The moment the purchase fires, the eVar resets, so the next browsing session starts clean.

5.1 — Worked example

The same user touches the site four times across two visits:

Visit 1 (Tuesday)
  Hit A:  eVar15 = "google-paid-summer"      → page view
  Hit B:  no eVar15 set                       → page view
  Hit C:  eVar15 = "email-newsletter-08"     → page view

Visit 2 (Friday)
  Hit D:  no eVar15 set, events = "purchase" → checkout

With allocation = Last, expiration = Visit:

• Visit 1's pageviews show their respective campaign values.
• Visit 2's purchase is credited to nothing — the eVar expired with Visit 1.

With allocation = Last, expiration = on event "purchase":

• Visit 2's purchase is credited to email-newsletter-08 — the most recent value, persisted across visits, expiring now.

That single configuration change rewrites how every campaign report reads.

6 · Events

Events are metrics — counts, sums, or counters. They are configured in the report suite as one of four types:

Syntax for the wire:

// Counter — just name it
s.events = "event1";

// Numeric or currency — name + value
s.events = "event2=12.50";

// Multiple events at once — comma-delimited
s.events = "event1,event2=12.50,event3=89.99";

There are also standard events baked in: prodView, scAdd, scOpen, scRemove, scView, scCheckout, purchase. They behave like counters with a special role in the Products report — particularly purchase, which is the only event that registers revenue, units, and orders from the products string.

7 · Event serialization

Serialization solves "double-count this event if the page is refreshed." Tell AA: this event has an ID; if you ever see the same ID again, ignore it.

// Without serialization — a browser refresh counts the purchase twice
s.events = "purchase";
s.purchaseID = "ORD-9981";

// With explicit serialization
s.events = "purchase:ORD-9981";

// You can serialize any event, not just purchase
s.events = "event5:LEAD-2025-04-1199";

The syntax is eventName:uniqueID. AA keeps that ID for ~30 days and dedupes any hit that arrives with the same ID. Two patterns are common:

• purchaseID — the dedicated mechanism for the purchase event. Always use it. A confirmation page that the user bookmarks and reloads must not double-count revenue.
• Custom serialization — for any event where duplication is possible (lead form, signup, milestone). Generate a stable unique ID server-side and emit it.

8 · Merchandising eVars

The hardest variable type in AA. A merchandising eVar binds itself to a specific product, so when revenue arrives later, the eVar credits the right SKU.

Example. A user opens two product pages in one visit:

// Page 1 — viewing the telescope
s.pageName = "PDP: Astro-3000";
s.products = ";ASTRO-3000;;;;eVar20=organic-search";
s.events = "prodView";
s.t();

// Page 2 — viewing the camera, arrived via paid ad
s.pageName = "PDP: AstroCam";
s.products = ";ASTROCAM;;;;eVar20=google-paid";
s.events = "prodView";
s.t();

// Page 3 — purchase, two items
s.products = ";ASTRO-3000;1;299.00,;ASTROCAM;1;599.00";
s.events = "purchase";
s.purchaseID = "ORD-1122";
s.t();

With eVar20 configured as a Product Syntax merchandising eVar, the report shows:

• ASTRO-3000 revenue ($299) credited to organic-search
• ASTROCAM revenue ($599) credited to google-paid

A non-merchandising eVar20 would credit both products' revenue to the last value ("google-paid"), because that's how regular allocation works. Merchandising binds the value to a specific product across hits.

9 · Hierarchy variables

Five slots (hier1 to hier5) designed to capture site structure as a single path string. They produce a drill-down report — useful for sites with a deep, stable information architecture.

s.hier1 = "Shop|Telescopes|Refractor|Astro-3000";
// Delimiter is configurable in Admin; default is the pipe character.

The Hierarchy report lets you click "Shop" → see Telescopes / Cameras / Mounts → click Telescopes → see Refractor / Reflector. It's a tree.

Hier variables are powerful but under-used because most modern sites prefer flat eVars per level (eVar1 = section, eVar2 = sub-section, eVar3 = product) — which gives more flexibility in Workspace. Pick one approach; don't double-instrument.

10 · List variables

Three slots (list1, list2, list3) — like list props, but on the eVar side: persistent, allocated, expirable. Each value in the delimited list gets attributed independently.

// User filters search by three criteria
s.list1 = "color:blue,size:medium,brand:acme";
// Wire format: l1=…
// Each criterion shows in the list1 report as its own row

Configure delimiter and expiration in Admin Console → List Variables. Maximum 100 values per hit per list var.

11 · Lab 05 — Variable mechanics, hands-on

The sandbox is fully wired. Edit, run, and watch the hit decode. Every exercise below is solvable in this lab — try each before peeking at the next.

11.1 — Exercises

12 · Checkpoint

You should now be able to:

• Pick prop vs eVar vs event for any given business question.
• Choose allocation (last / first / linear) and explain the consequence.
• Set expiration on event for cross-visit attribution.
• Serialize an event correctly.
• Read a products string with merchandising syntax.
• Know when to reach for hier and list variables.

This is the conceptual ceiling of Adobe Analytics. Everything from module 06 onward — link tracking, SPA, mobile, Web SDK — is delivery mechanisms for the variables you understand now.