Adobe Analytics Pre-Implementation Tasks: Planning Before You Track

The most expensive mistake in any analytics implementation is writing tracking code before you know what the business actually needs to learn. It feels productive to start tagging pages, but without a plan you end up measuring things nobody asked for while missing the things that matter. Every decision in an Adobe Analytics build should flow from a single question: what does the business need to know, and how will we measure it? The implementation is only ever as good as the planning that comes before it, and this article covers that planning, from translating business goals into measurable indicators through to designing the data layer that feeds Adobe Analytics.

From Business Goals to KPIs

The planning vocabulary is worth getting straight, because the same four ideas recur throughout. A Key Business Requirement, or KBR, is a goal critical to the business, such as increasing online sales or lead volume. A Key Performance Indicator, or KPI, is a measurement of success or failure against a KBR, such as revenue, average order value, or conversion rate. The Business Requirements Document, or BRD, is the prioritised master list of KBRs, KPIs, and the supporting requirements beneath them. And the Solutions Design Reference, or SDR, is the blueprint that maps all of that onto actual Adobe Analytics variables. The BRD captures what the business wants; the SDR captures how the implementation will deliver it.

Getting from a vague goal to a precise indicator is a four-step journey. You define the website goals, distil them into KBRs, identify the user actions that signal progress, and finally build KPIs that give those actions meaning.

The first step is genuinely a conversation, not a technical task. You sit down with strategic stakeholders and ask what the company’s core business is, how the website supports it, what the end goal of the site actually is, what you want visitors to do, why you want them to do it, and what you should measure to tell whether they are doing it. The honest answer varies enormously by industry. A retailer wants to influence visitors to buy products, a lead-generation business wants qualified visitors to submit a form, a finance site wants applications completed, and an automotive site might simply want brochure downloads. The end objective shapes everything downstream.

The second step is ruthless distillation. Stakeholder interviews always produce a sprawling list of needs, wants, and nice-to-haves, and the discipline is to reduce that list to just three to five key objectives. Anything that does not make the cut becomes a supporting requirement that feeds into one or more of the KBRs, and all of it gets written into the BRD. More than five KBRs is a warning sign, because too many top-level objectives dilute focus until nothing is truly prioritised.

The third step identifies the user actions that move the business toward its KBRs, which in Adobe Analytics are called success events and are always measured as numbers. Not all actions carry equal weight. A primary success event directly measures conversion and directly affects KBR success, the obvious example being a purchase. A secondary success event is a step along the path that contributes toward the primary one, such as a product view that contributes toward an eventual purchase. Separating the two keeps you from treating a halfway signal as if it were the finish line.

What Actually Makes a KPI

The fourth step is where many implementations quietly go wrong, because a raw number is not a KPI. Knowing you had 300,000 visitors or 100,000 pounds in revenue tells you nothing on its own, since you cannot say whether that is good or bad without something to compare it against. A metric only earns the title of KPI when it meets three criteria. It must be directly linked back to a KBR, so it measures real business progress rather than vanity. It must be actionable, meaning that if the number underperforms, you know what to do about it. And it must have context, which means it is trended over time or expressed as a ratio or percentage between two or more metrics, rather than sitting as an isolated count.

Building a KPI, then, is a matter of taking primary success event metrics and combining them into calculated metrics that carry meaning. Order conversion rate, the percentage of visits that ended in a purchase, is a ratio of those who finished to those who began. A product browse-to-buy ratio shows how often browsing turns into buying. A search yield rate shows how often site search leads to a desired action. Each of these passes all three tests, where a bare visitor count fails the context test entirely. If a metric fails any of the three criteria, it is not a KPI; it is a success event or a supporting metric, and labelling it correctly keeps the reporting honest.

The Solutions Design Reference

The SDR is the blueprint for the whole build, and like a blueprint for a house, it is created before construction begins, not after. It maps the entire chain, from the discovery questions you asked stakeholders, through the KBRs and KPIs those questions produced, down to the specific Adobe Analytics variables and how each one is populated. A single row might run from a discovery question like “what is the company trying to do through the site,” to a KBR of increasing leads generated, to KPIs of lead submissions and visits, and finally to the data element and the variable that captures it, such as an event for lead submission and a page-name variable for navigation.

For each variable, the SDR documents what it does, how it is populated, where it is implemented, and the exact syntax used to set it. That shared reference is what keeps a team of developers and analysts implementing consistently. Without it, variables get set in slightly different ways across the site, and nobody has a single source of truth to check against.

The Website Data Layer

With the planning settled, attention turns to how the data reaches Adobe Analytics, and the modern answer is a data layer. A data layer is a framework of JavaScript objects that developers place on the page, holding the data each page needs to report. Tracking tools, including tag management systems like Adobe Experience Platform Launch, then read from that data layer and populate the reports.

The key benefit is a clean division of labour. Developers do not need to learn how Adobe Analytics traffic, conversion, and event variables work. They simply populate page-specific data into JavaScript objects with sensible names, and Launch handles the job of reading those objects and mapping them onto the correct Adobe variables. The people who understand the page own the data, and the people who understand analytics own the mapping.

It helps to see the contrast with the older way. The legacy approach hardcoded Adobe Analytics variable assignments directly into the page.

s.pageName="RenewableEnergyPage";   // Page Name
s.channel="Science";                // Site Section
s.hier1="UK|Science|Features";      // Site Hierarchy
s.prop4="How Tidal Power Works";    // Content title
s.eVar6="Priya Nair";               // Author
s.eVar7="Article";                  // Content type
s.prop14="renewable energy,tidal power,engineering"; // Content topics
s.prop54="en-UK";                   // Content language
s.prop55="UK";                      // Article country
s.prop58="14/JUN/24";               // Published date

Every line here speaks Adobe’s private language. s.pageName sets the reported page name, s.channel sets the site section, s.hier1 sets a pipe-delimited site hierarchy, and the assorted s.prop and s.eVar assignments stash content title, author, type, topics, language, country, and publish date into specific traffic and conversion variables. To change anything, a developer has to know which numbered variable holds which value, which is brittle and unforgiving.

The data layer expresses the same information as a plain, readable object.

var digitalData = {
  "page": {
    "pageInfo": {
      "pageName": "Renewable Energy Page",
      "siteSection": "Science",
      "hierarchy": "UK|Science|Features"
    },
    "contentInfo": {
      "title": "How Tidal Power Works",
      "author": "Priya Nair",
      "contentType": "Article",
      "topics": "renewable energy,tidal power,engineering",
      "publishDate": "14/JUN/24"
    },
    "attributes": {
      "country": "UK",
      "language": "en-UK"
    }
  }
};

The top-level object name is arbitrary but must be used consistently, and everything nests under meaningful keys: page identity under pageInfo, content metadata under contentInfo, and locale details under attributes. The page name that was s.pageName is now digitalData.page.pageInfo.pageName, the author that was s.eVar6 is now contentInfo.author, and so on. The values are identical; only the structure and the readability have changed.

That difference matters in practice. In the legacy code, the developer must know Adobe variable names, the syntax is Adobe-specific, and a change means tracking down the right s. variable to edit. In the data layer, the developer works in plain object structure with descriptive keys, changes are isolated to the data layer while Launch owns the mapping, and a single data layer key can feed several Adobe variables at once. The one rule that keeps it all working is a consistent, predictable naming convention. If your developers already maintain a data layer, align with their format rather than imposing a new one, because mismatched names are exactly what breaks Launch rules later.

The Full Chain in One View

Pulling it together, a single business goal threads all the way down to a tracking call. A goal of increasing online sales becomes a KBR of increasing the conversion rate. That KBR is signalled by a primary success event of purchase, supported by secondary events like product view, add to cart, and checkout. Those events feed a KPI such as order conversion rate, defined as orders divided by visits, times one hundred. The SDR maps that KPI to concrete Adobe variables, setting the purchase event and the product string. The data layer then exposes the underlying data, the page or cart object the developer populated, and finally a Launch rule reads the data layer and fires the Adobe Analytics tracking call. Each link depends on the one above it, which is exactly why skipping the planning corrupts everything downstream.

The Pitfalls That Sink Implementations

A handful of mistakes account for most failed builds. Skipping the BRD and diving straight into implementation guarantees you will track things nobody needs and miss things that matter. Treating raw counts as KPIs leaves stakeholders staring at numbers with no baseline to judge them by. Identifying more than five KBRs scatters focus across too many priorities. Failing to create the SDR before implementation leaves variables set inconsistently with no shared reference to settle disputes. Hardcoding Adobe variables in the page, the legacy approach, makes every future change dependent on a developer fluent in Adobe syntax. And an inconsistent data layer naming convention quietly breaks Launch rules the moment a key name drifts, turning maintenance into a recurring expense.

Conclusion

Pre-implementation is where an Adobe Analytics build is won or lost. Start from the business question, interview stakeholders to define goals, distil them into three to five KBRs, identify the primary and secondary success events that signal progress, and turn those events into genuine KPIs that are linked to a KBR, actionable, and rich with context. Capture the priorities in the BRD and the variable mapping in the SDR before a single page is tagged. Then feed Adobe Analytics through a cleanly structured, consistently named data layer rather than hardcoded variables, so the people who own the page and the people who own the analytics can each do their job without tripping over the other. Plan in that order, and the implementation that follows is almost mechanical.