Variable Planning

Adobe hands you the materials: props, eVars, events, the built-in variables, the products string, list variables, and context data. This section is about the thing that turns materials into a building: planning. Think of yourself as the architect. An architect does not pour concrete everywhere, they use concrete where strength is needed, brick where it fits, wood where it is warranted, each material in its right place, at the lowest sensible cost. Your concrete, brick, and wood are your variables, and choosing the right one for each job, without waste, is the whole discipline. The tool will faithfully collect whatever you tell it to; deciding the right thing first is what separates an implementation people trust from one they quietly stop using.

The stakes are higher here than in most software, because of the rule from report suites: data is captured forward, not backward. A variable you forgot to plan is not a quick fix later, it is months of data you will never have. Planning is how you avoid measuring the wrong things well.

Start from the end report, not the variables

Here is the single most useful planning instinct, and it runs backward from how beginners approach it: visualize the report the business actually wants to see first, then assign variables to produce it. The report dictates the variable, never the reverse.

Take a real choice. You want to capture product ratings from 1 to 5. Which variable? It depends entirely on the report you are after.

If the business wants average rating per product, you need a numeric event to carry the rating (Adobe sums the values), and the average itself is a calculated metric, the summed rating divided by the number of ratings (from events). If instead they want to see how often each rating value was chosen, the rating belongs in a prop or eVar as a dimension, counted by a simple event. Same raw input, two completely different variable decisions, and only the end report tells you which is right. Build the habit: picture the finished report, then work backward to the variables and event types that produce it.

The planning process, step by step

Variable planning is not a separate task bolted on at the end; it is entangled with your entire Adobe Analytics configuration. Done well, it follows three steps.

Step 1: Discovery. Sit down with the business stakeholders and understand, in detail, what they need to learn from the data. Not "track everything," but the actual questions: which campaigns drive revenue, where people drop out of checkout, what content converts. Every real requirement is, underneath, a report someone wants. Capture those reports, they are your specification.

Step 2: Design the plan (the SDR). Now translate each desired report into the variables and events that produce it, and write it all down in a Solution Design Reference (SDR), your implementation's single source of truth. It is a living document that says exactly what every variable is, what it holds, and why, and it is what stops the slow rot where, two years in, nobody remembers what eVar37 was for. Document each variable with:

• Number and friendly name: eVar1 = "Internal Campaign ID".
• Business purpose: the question it exists to answer.
• Expected values: format and real examples.
• Configuration: type, allocation, expiration (the settings that shape the data, from eVars and from report suites).
• Source: the data-layer element or context data key it comes from.

The decisions themselves come down to a handful of repeatable choices, the whole module distilled onto one page:

Step 3: Review and trim. Before anyone writes code, look at the SDR again with fresh eyes and ask two questions of every variable. First, could a cheaper variable do the same job? Don't spend an eVar on a value that only ever describes the current page, a prop is enough; don't burn a list variable on something a list prop handles; don't reach for a numeric event where a counter is all the report needs. Second, can anything be cut or combined? This pass matters because variables are a budget, not a free resource, and some are far scarcer than others:

Allocating every variable on day one leaves nothing for the requests that always come later, and with only three list variables, a careless early choice can leave you stuck (list variables). Spend deliberately, and keep room to grow.

Notice that almost every mistake here is a planning failure, not a technical one. The tool will faithfully collect whatever you tell it to, which is exactly why deciding the right thing first matters so much.

That completes the module

You now know every variable type Adobe Analytics offers, props and eVars, events, the built-ins, the products string, list variables, and context data, and, just as importantly, how to plan them as an architect rather than assemble them at random. You can look at a business question, know which material it calls for, and document that decision so it survives the people who made it.

That also closes the first of this course's five phases. As the left navigation and the map both show, the journey runs in five: you have finished Foundations, the what and the why, and everything that follows now has a vocabulary to build on. The next phase is Collect, the how, where planned variables stop being a design on paper and start flowing from a real site or app into your report suites. It opens with Data Collection, and the first question it answers is the one every implementation starts from: which collection method, and why.