Adobe Analytics and CJA: variables, processing rules, and the XDM migration

Adobe Analytics is the other enterprise dialect of web measurement, and it is a genuine dialect: the same underlying event record as every other tool, expressed through a vocabulary — eVars, props, success events, processing rules — that predates the modern event model and still shapes how thousands of report suites are wired. This guide covers the classic variable system, the server-side processing layer, and the migration path through the Web SDK toward Customer Journey Analytics (CJA), where the dialect finally converges on plain schemas. Vendor summary and alternatives live in the directory entry; privacy posture in the scorecard.

The classic variable model

Every Adobe hit — a page view via s.t() or a link/action call via s.tl() — lands in a report suite carrying three families of variables:

• props are hit-scoped strings. They exist on the hit that set them and nowhere else, which makes them the natural home for pathing analysis (props can have pathing enabled) and hit-granular debugging. GA4’s closest analog is an event parameter.
• eVars are persisting strings. A value set once continues to be credited on subsequent hits until it expires — and both the expiration (hit, visit, 30 days, on a success event) and the allocation (most recent vs original value) are report-suite configuration, not code. This is the single most important thing to understand about Adobe: persistence is configured server-side, decided at implementation-design time, and applied at collection. An eVar with the wrong expiration produces months of silently mis-attributed conversions and no error anywhere.
• success events are numbered counters (event1–event1000) incremented or summed on a hit via s.events. Conversion metrics are built from these, with optional serialization to de-duplicate (e.g. one order counted once per order ID).

Add s.products — the packed string syntax for per-product data and merchandising eVars — and you have the whole model. It is rigid, but the rigidity is legible: every dimension in a report traces to a numbered variable with documented persistence.

// Classic AppMeasurement purchase hit
s.events = 'purchase,event12';
s.products = ';WP-1;1;49.00;event12=1;eVar34=blue';
s.eVar12 = 'summer-sale';        // persists per its configured expiration
s.prop5  = 'checkout:confirm';   // this hit only
s.t();

The Beacon Decoder will unpack a live Adobe request — rsid, props, eVars, the events and products strings — which is the fastest way to learn the wire format.

Processing rules: the server-side rewrite layer

Adobe applies a configurable rewrite pass at collection, before data is written: processing rules. Their primary job is mapping context data variables — arbitrary key/value pairs sent as s.contextData['cart.value'] — into numbered eVars, props, and events. Context data that no rule maps is discarded, permanently.

This inverts the usual implementation contract, and mature Adobe shops exploit it deliberately: the page emits semantic keys (cart.value, page.type), and the mapping to eVar23 lives in the admin console where it can change without a code release. Three operational cautions:

• Processing rules run on every hit at collection time and are not retroactive. A mapping fixed today fixes tomorrow’s data only.
• They are a shared, mutable production surface with a thin audit trail. Treat rule changes like deploys: document, name, and review them.
• Complex logic beyond the rules UI historically lands in VISTA rules (Adobe engineering-services territory) — effectively unreviewable black boxes. Minimize.

AppMeasurement vs the Web SDK

There are, as of mid-2026, two live client architectures:

1. AppMeasurement.js (usually deployed through Adobe Launch/Tags) — the legacy library that speaks the variable model natively and sends hits directly to Analytics data collection.
2. The Adobe Experience Platform Web SDK (alloy.js) — one library for all Adobe products, sending XDM (Experience Data Model) payloads to the Edge Network, where a datastream fans the data out to Analytics, Target, Audience Manager, and Experience Platform.

With the Web SDK, you stop setting s.eVar12 in the browser. You send a schema-shaped object:

alloy('sendEvent', {
  xdm: {
    eventType: 'commerce.purchases',
    commerce: { purchases: { value: 1 } },
    _acme: { campaign: 'summer-sale' }   // your tenant-namespaced custom fields
  }
});

Analytics still expects its variables, so a translation happens at the Edge: standard XDM fields map to Analytics variables automatically, and everything else arrives as context data (keyed by the flattened XDM path) for your processing rules — or datastream-level Data Prep mappings — to route into eVars and props. The migration discipline that works: build the XDM schema first as the source of truth, generate the variable mappings from it, and keep a single document tying every eVar/prop to its XDM path. Teams that migrate by replaying their old s.eVarNN assignments into ad-hoc XDM fields get the worst of both dialects. The general schema-first argument is the events and schemas guide; if you need to audit what an existing Launch property actually does before touching it, that is what the Launch/Tags Explorer is for.

Customer Journey Analytics: the model without the numbers

CJA is Analysis Workspace re-founded on Experience Platform datasets, and it deletes most of the classic machinery:

• No eVars, props, or numbered events. Any field in the dataset schema becomes a dimension or metric in a data view. The 75/250-variable budgeting exercise disappears.
• Persistence and attribution move to report time. What was burned into collection — expiration, allocation — becomes a data-view component setting you can change and re-run retroactively over existing data. This is the single largest conceptual shift: in Adobe Analytics, persistence is an irreversible collection-time decision; in CJA it is a query-time one.
• No processing rules. Data lands as sent (Data Prep on ingestion covers mapping); fix-ups are dataset transformations, not hit rewrites.
• Sessions are defined per data view — timeout and definition are settings, also retroactive, which is exactly the warehouse-style approach described in sessionization.
• Cross-channel by design. Web, mobile, call-center, and offline datasets join through stitching on shared identities rather than through report-suite gymnastics.

Adobe positions CJA as the successor to traditional Adobe Analytics, and the Web SDK/XDM migration above is the on-ramp: once collection is XDM-shaped into Platform, standing up CJA is dataset configuration rather than re-instrumentation. What you give up: real-time is more limited than classic Analytics’ live reports, marketing-channel processing must be rebuilt as data-view logic, and historical report-suite data needs a deliberate backfill (Adobe provides a source connector for it) with the usual field-mapping archaeology.

Practical guidance

• On classic Analytics and staying (for now): document every eVar’s expiration and allocation in the solution design reference; undocumented persistence settings are where trust in the data goes to die. Emit semantic context data and map via processing rules rather than hardcoding variable numbers in pages.
• Migrating: Web SDK + XDM schema first, variable mappings generated from the schema, one release at a time with side-by-side validation against the old library (the report suite can receive from both during transition — dedupe carefully).
• Evaluating CJA: the pitch is real — retroactive persistence and schema-native dimensions remove the two worst constraints of the classic product — but the prerequisite is Experience Platform data engineering. If your organization is not ready to own schemas and datasets, you are buying a warehouse-shaped product without the warehouse team.

The through-line: Adobe’s classic model front-loads decisions into collection configuration, and its modern model defers them to query time. Every migration pain point is that inversion, playing out one variable at a time.