Why eVar conflicts are the silent killer of enterprise analytics, and how to build a variable allocation map that survives the next acquisition, rebrand, and regional expansion.
Every broken Adobe Analytics report can be traced back to a moment someone repurposed an eVar without asking permission. It starts innocently enough. A regional team needs a slot for a local loyalty tier. A product manager wants to track a new recommendation widget. An acquired brand imports its existing implementation and quietly maps its checkout events to the same custom events the parent company uses for lead generation. Six months later, the global campaign attribution report shows impossible numbers, the internal search dashboard flatlines, and no one can agree which report suite is telling the truth.
The culprit is not bad analysis. It is a missing or abandoned tagging dictionary.
A tagging dictionary is the master variable allocation map for your Adobe Analytics implementation. It defines which eVars, props, events, and list variables are reserved for specific purposes across all report suites. When it is enforced, teams can build reports that compare markets, brands, and journeys without manual reconciliation. When it is ignored, every regional team becomes its own analytics island, and cross-suite reporting becomes an archaeological exercise in guessing what each variable once meant.
A tagging dictionary is not a tagging plan. A tagging plan is feature-scoped. It asks what user behaviours on a new checkout flow or product carousel must be measured, and maps those behaviours to variables for that feature. A tagging dictionary is enterprise-scoped. It asks which variables may be used for what purposes everywhere, and who has the authority to change the answer.
The dictionary becomes the contract between business intent and technical execution. Developers do not guess which event to use for a purchase. Analysts do not discover that a re-purposed prop pollutes their segment. Governance leads do not spend quarterly audits playing detective across forty regional spreadsheets.
The Core + Local Allocation Model
The most practical framework for enterprise Adobe Analytics is the Core + Local model. It splits your custom variables into two tiers.
Global Core variables are reserved for dimensions and events that must be implemented identically in every report suite. These are the variables that make global comparison possible. If one region redefines a Global Core variable, cross-market reporting breaks.
Local Flex variables are reserved for region-specific, brand-specific, or function-specific tracking. A US team might use eVar111 for the local loyalty tier. An EU team might use the same eVar111 for consent status. That is acceptable because eVar111 is in the Local Flex range. Its meaning differs by report suite, and the dictionary documents those differences.
This model is the professional standard for multi-market deployments because it balances comparability with autonomy. It also gives central governance a clear boundary. You fight hard to protect the Global Core range. You delegate Local Flex authority to regional leads with less friction.
Adobe Analytics provides a generous number of custom variables: up to 250 eVars, 75 props, and 1,000 events. These limits are large enough that most organisations can afford to reserve substantial ranges for Global Core and Local Flex without running out of slots. The mistake most enterprises make is not scarcity. It is using the space chaotically.
A Practical Variable Reservation Framework
There is no universal allocation template because every organisation has different priorities. What matters is that you choose a structure, document it, and enforce it. The example below is a starting point for a large enterprise with multiple brands and regions.
eVars
Reserve eVar1 through eVar100 for Global Core dimensions. These should capture the variables that every report suite needs to answer the same questions in the same way. Typical Global Core eVars include Page Name, Site Section, Internal Search Term, Campaign Code, Product Category, Product SKU, Order ID, Customer ID, Marketing Channel Detail, Content Type, User Type, and Error Category.
Reserve eVar101 through eVar250 for Local Flex. This is where regional teams, brand teams, or market-specific functions define their own dimensions. A US team might capture the local loyalty programme tier in eVar111. An EU team might capture consent status in eVar131. A brand team might capture a category structure that only applies to its own property. The dictionary records what each Local Flex variable means in each report suite.
Props
Reserve prop1 through prop30 for Global Core pathing and page-level attributes. These should be defined consistently across every report suite so that navigation patterns can be compared globally.
Reserve prop31 through prop75 for Local Flex navigation and interaction attributes. Regional or brand teams can use these for their own pathing and interaction tracking needs.
Events
Reserve event1 through event400 for Global Core KPIs. These should reflect the actions that matter most to the whole organisation. Typical examples include Orders, Revenue, Registrations, Form Submissions, Add to Cart, Checkout Start, Content Engagement Milestones, Video Interactions, and Error Events.
Reserve event401 through event1000 for Local Flex. Regional teams can use these for conversion actions that only matter in their market, such as local store visits, regional webinar registrations, or brand-specific loyalty actions.
The boundary between Global Core and Local Flex is not set in stone. By consuming Global Core from the start of the range and Local Flex from the end, you leave a flexible middle zone that can be shifted over time. If the organisation later needs more Global Core variables, the Local Flex boundary can move downward. If regional autonomy grows, the Global Core boundary can stop earlier. The dictionary should record the current split and the date of any change.
The Governance Rituals That Keep the Dictionary Alive
A dictionary written once and stored on SharePoint is only slightly better than no dictionary at all. The following rituals convert it from a document into a governance mechanism.
1. Central Ownership
Assign a single Data Steward or governance lead who owns the dictionary. This person does not need to be a senior executive, but they must have the authority to reject variable requests and the time to enforce decisions. Ownership should not rotate every quarter. Consistency matters more than seniority.
2. Approval Gate for Variable Requests
Any change to the Global Core range requires written approval from the Data Steward and at least one regional representative. This prevents a single team from quietly redefining a variable that other teams depend upon. The approval should be logged in the dictionary itself, with a reason and a date.
Even Local Flex requests should pass through a lightweight review. Before approving a new Local Flex variable, ask whether the dimension or event has potential value beyond a single region or brand. If it does, promote it to Global Core. If it is genuinely local, approve it for Local Flex. This simple gate prevents perfectly good global standards from hiding inside regional silos.
3. Quarterly Variable Audit
Every quarter, export the current variable configuration from every report suite and compare it against the dictionary. Flag any variable that is being used for an unapproved purpose or any approved variable that has been left empty. The output of the audit becomes the governance backlog for the next quarter.
4. Deprecation Workflow
When a variable is retired, do not delete its definition. Mark it as deprecated in the dictionary, note the date, and record what replaced it. This preserves historical continuity. An analyst looking at a report from two years ago must still understand what the variable meant at the time.
5. Version Control
Store the dictionary in a version-controlled repository such as GitHub or a wiki with full change history. Treat it like code. When someone proposes a change, they submit a request, it is reviewed, and the merge is documented. This replaces email chains and hallway decisions with an auditable trail.
Common Failure Patterns
Knowing the failure patterns helps you spot them before they metastasise.
The eVar of Many Names. One variable has been used for three different purposes over two years, and each report built on it tells a different story. This usually happens when there is no deprecation workflow.
Spreadsheet Proliferation. Each region maintains its own variable map. None of them matches. The central team tries to merge them and discovers that the same eVar means opposite things in different regions.
The Emergency Repurpose. A launch deadline looms. Someone reuses an empty-looking eVar rather than requesting a new one. Six months later, that “empty” variable was actually critical to another team’s attribution model.
The Acquisition Integration Dump. A newly acquired brand’s implementation is imported unchanged. Its events, eVars, and props collide with the parent company’s global KPIs because no one mapped them to the dictionary first.
Dictionary Decay. The tagging dictionary was created during an implementation project and then abandoned. New features ship without updating it. Within two years, the dictionary describes a fictional implementation.
Why This Matters for the Long Game
Variable allocation governance is not glamorous work. It does not produce dashboards or insights on its own. But it determines whether every dashboard and insight your teams produce can be trusted.
Enterprise Adobe Analytics implementations typically last five to ten years. Over that lifespan, markets change, brands are acquired, privacy regulations evolve, and new platform features appear. A disciplined tagging dictionary is the mechanism that lets your implementation absorb those changes without requiring a complete rebuild every eighteen months.
For the full framework, including report suite architecture, access control, data governance, and the operational rituals that keep enterprise analytics healthy, see Adobe Analytics: A Champion’s Handbook.
Leave a Reply