Context Data Variables

There is a way to hand data to Adobe that does not commit to a numbered slot at collection time, and this is it. Every other variable, props, eVars, events, list variables, needs a number you must know in advance. Setting s.eVar5 = "premium" means your developer has to know that eVar5 is "membership tier," and the day you want it in eVar6 instead, someone edits and redeploys code. That hardwiring is the problem context data solves. Instead of assigning numbered variables, you send meaningful named pairs, and the mapping to props, eVars, and events happens later, in Processing Rules, with no code change.

// Developers send named, human-readable data
s.contextData["user.status"] = "logged-in";
s.contextData["user.tier"]   = "premium";
s.contextData["page.type"]   = "product";

// Analysts map it later, in Processing Rules (no deploy):
// contextData["user.status"] -> eVar5
// contextData["user.tier"]   -> eVar6
// contextData["page.type"]   -> prop1

What it buys you

• Separation of concerns: developers speak business language ("user.tier"), analysts own the variable mapping. Neither has to live in the other's world.
• Re-map without a deploy: moving a value from eVar6 to eVar7, or sending one field to both a prop and an eVar, is a Processing Rules change, not a code release.
• Future-proofing: send everything meaningful now, decide where it lands as reporting needs evolve.

On mobile, it isn't optional

On the web, context data is a choice. In a mobile app it's the only way. The Adobe mobile SDK (v4 and later) cannot set events, eVars, props, hiers, or lists directly at all, you pass everything as context data through trackState and trackAction, and Processing Rules do the mapping. There's one exception: the products variable, which the SDK sets directly via the special &&products context data key.

This changes how you fire events from an app, too. Since the app can't fire an event directly, you send a context data value and let a Processing Rule map it to an event. The increment rule is worth knowing: when context data is mapped to an event, a text value increments it by 1 (so a simple flag like "true" means "fired once"), while an integer value increments it by that number (a context data value of 5 adds 5). So a plain flag counts occurrences, and a number carries magnitude.

Default context data you already get

Some context data shows up without you sending it. Adobe reserves the a. prefix for its own automatically collected variables, and you don't write Processing Rules for these, they're mapped for you, and these mappings don't count against your processing-rules limit.

Where this is heading

Context data is the AppMeasurement-era answer to "send meaning, map it later." The Web SDK world takes the same philosophy further: you send structured XDM to the Edge, and where it isn't auto-mapped, the Edge flattens it into context data (under an a.x. prefix) that Processing Rules can still pick up. If the idea of decoupling what developers send from where it lands makes sense to you here, you already understand the instinct behind the whole move to Web SDK and Customer Journey Analytics.

That naming instinct, describe what a value means and decide where it lands deliberately, is the same discipline this whole module has been circling. The final section makes it formal: Variable Planning, and the solution design document that captures every one of these decisions in a single place.