Why variables are numbered
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Architects | This is how you design clean implementations |
| Admins and leads | Numbering scheme is governance |
The historical reason
Adobe Analytics was architected in the late 1990s. To make queries fast on the hardware of the day, the datastore used a fixed-width columnar schema. Every report suite had a fixed set of pre-allocated columns: 75 for props, 250 for eVars, 100+ for events. You could not add a column. You could only decide what to put in the ones you had.
So eVar1 is not a *type* of thing. It is a numbered container. It is a filing cabinet drawer. Drawer 7 has no inherent meaning — it means whatever your organisation decided to file in drawer 7 on the day someone made that decision, possibly in 2014, possibly for a site that no longer exists.
What this means in practice
1. eVar numbers are arbitrary and organisation-specific. eVar1 at Example Super and eVar1 at another fund have nothing in common. There is no standard.
2. The number is invisible to analysts — if you do your job. Every variable has both a number and a friendly name set in Admin. An analyst in Workspace sees "Internal Search Term", not "eVar12". The number only surfaces for implementers and admins.
This is the single highest-leverage governance act: rename every variable in Admin to a clear business name, and keep it renamed.
3. Slots are finite and reuse is painful. 250 eVars sounds like a lot until you have three brands, four journeys, and eight years of history. When you repurpose eVar30 from "old campaign code" to "advice appointment type", historical data does not get relabelled — you now have one column containing two incompatible meanings, split at an arbitrary date.
Rules for reuse:
- Never reuse a slot that has been populated in the last 13 months (breaks year-over-year)
- When you must, document the changeover date in the SDR *and* in the variable's description field in Admin
- Consider a naming convention that makes retirement visible: rename to
[RETIRED 2026-03] Old Campaign Codefor a quarter before reallocating
Group your numbering
Since numbers are arbitrary, impose meaning through blocks:
| Range | Purpose |
|---|---|
| eVar1–19 | Global / page context (page name, section, template, language) |
| eVar20–39 | Visitor & member context (persona, login status, member segment) |
| eVar40–59 | Acquisition & campaign |
| eVar60–79 | Internal search |
| eVar80–99 | Forms & lead capture |
| eVar100–119 | Tools & calculators |
| eVar120–139 | Content engagement (video, PDF, articles) |
| eVar140–159 | Advice & appointments |
| eVar160–179 | Chat & service |
| eVar180–199 | Reserved for new journeys |
| eVar200–250 | Reserved / experimentation |
Leaving deliberate gaps is not waste — it is what lets you add "search result page number" next to "search term" two years later.
The good news
This problem is going away. In CJA, there are no numbered slots. Your schema has fields with real names — search.keywords, _examplesuper.form.name — and you map them into a Data View. The numbering system is an artefact you are learning to work within, not a permanent feature of digital analytics.
Which is also an argument for how much energy to spend perfecting eVar allocation today: enough to be clean and documented, not enough to gold-plate.