Adobe Analytics Implementation with Adobe Launch — Step by Step

Adobe Launch — now officially called Adobe Experience Platform Tags — is the standard way to deploy Adobe Analytics on web properties. Done right, it gives you a clean, maintainable implementation that scales as your product and team grow. Done wrong, it becomes a tangle of conflicting rules that nobody dares to touch.

I have implemented Adobe Analytics with Launch across global enterprise properties in retail, financial services, and media. This guide covers the full process the way it is actually done at scale — not the simplified version in Adobe's documentation.

What Adobe Launch actually is

Adobe Launch is a tag management system (TMS) built on Adobe's Experience Platform infrastructure. It lets you deploy and manage tags — Adobe Analytics, Adobe Target, third-party pixels, custom JavaScript — without requiring code deployments from your engineering team every time something changes.

Four core concepts govern everything in Launch:

• Extensions — pre-built integrations for specific tools (Adobe Analytics, Adobe Target, ECID Service)
• Data Elements — variables that read values from your data layer, cookies, page elements, or JavaScript
• Rules — the logic that determines when tags fire and what data they send
• Libraries — compiled bundles of your extensions, data elements, and rules that get deployed to your environments

The relationship between these four is what most teams get wrong. Rules without proper data elements are fragile. Data elements without a clean data layer are unreliable. Understanding this dependency chain is the foundation of every good implementation.

Before you open Adobe Launch

Before creating a single data element or rule, you need clear answers to these four questions:

• What business questions does this analytics implementation need to answer?
• What user behaviors map to those questions?
• What variables — eVars, props, events — will carry that data?
• What does the data layer look like and who owns maintaining it?

If you cannot answer all four, stop. Build your measurement plan first. Launch is fast to configure — measurement design is not something you can rush.

Implementation architecture overview

Before writing a single rule, it helps to see how all the pieces connect. Here is the full architecture of a well-structured Adobe Analytics + Launch implementation:

The flow is linear — your website feeds the data layer, Launch reads the data layer via data elements, rules trigger the Adobe Analytics extension, and beacons hit your report suite. Everything downstream depends on every layer above it being clean.

Step 1 — Create your Launch property

Log into experience.adobe.com and navigate to Data Collection. Create a new property with these settings:

• Name it clearly — use your domain or brand name, not something generic like "Production Tag"
• Platform: Web
• Enter your primary domain
• Leave "Return an empty string for undefined data elements" checked — this prevents JavaScript errors when data elements cannot find their source values

Step 2 — Install extensions

Go to Extensions → Catalog. Install these two in order:

Experience Cloud ID Service — Install this first. Configure your Adobe Organization ID. The ECID extension must initialize before Adobe Analytics fires on every page. Control this through rule ordering.

Adobe Analytics — In the extension configuration:

• Report Suite ID: use your development suite here. Production suite goes in a separate environment config.
• Tracking server: use your custom CNAME (e.g. metrics.yourcompany.com) if available, otherwise your company.sc.omtrdc.net domain
• Library Management: choose "Load library" — not "Manage the library for me". The latter limits version control in production environments.

Step 3 — Build your data layer

Before creating data elements, your development team needs a data layer on the site — a structured JavaScript object that exposes page and user context consistently across every page type.

// Push on every page — values change per page type
window.digitalData = {
  page: {
    name:     "Home",          // e.g. "Checkout:Step 1"
    type:     "homepage",     // e.g. "product", "checkout"
    section:  "marketing",    // e.g. "shop", "account"
    language: "en-IN"
  },
  user: {
    loginStatus: "logged-out", // or "logged-in"
    userId:      ""             // hashed ID when authenticated
  },
  products: []                   // populated on product/cart pages
};

Step 4 — Create data elements

Data elements read values from your data layer and make them available inside rules. For every Analytics variable you need to populate, create a corresponding data element.

Use a consistent naming convention. I prefix data elements by source type: DL - for data layer, JS - for JavaScript variables, Util - for utilities. This makes it immediately obvious what each data element does when you are debugging at midnight.

Step 5 — Create the page load rule

The page load rule fires Adobe Analytics on every page and sends your core page-level variables. This is the most important rule in your entire implementation.

In the Set Variables action, assign your data elements to Analytics variables:

eVar1  = %DL - Page Name%
eVar2  = %DL - Page Type%
eVar3  = %DL - Page Section%
eVar10 = %DL - Login Status%
eVar20 = %DL - User ID%
prop1  = %DL - Page Name%
channel = %DL - Page Section%

Step 6 — Create event tracking rules

For every user interaction — button clicks, form submissions, video plays, file downloads — create a separate dedicated rule. One rule per event type. Never one rule with 20 conditions trying to handle everything.

A typical click tracking rule structure:

// Event: Core — Click
// Condition: CSS Selector matches ".btn-cta"

// Action 1: Adobe Analytics — Set Variables
eVar5  = "CTA Click"
eVar6  = %DL - Page Name%
events = "event5"      // your CTA click event

// Action 2: Adobe Analytics — Send Beacon
s.tl(this, 'o', 'CTA Click')

// Action 3: Adobe Analytics — Clear Variables
// Prevents variable bleeding into the next beacon

Step 7 — QA and validation

Build your library and publish to the Development environment. Use the Adobe Experience Platform Debugger Chrome extension to validate each of the following:

Common mistakes to avoid

After inheriting dozens of Adobe Analytics implementations, these are the errors I see most consistently:

• Sending data to production during development. Always use a separate development report suite. No exceptions.
• Configuring variables in the extension instead of rules. Extension-level config is invisible during rule debugging and makes auditing nearly impossible.
• One monolithic rule for everything. Rules with 20 conditions are impossible to debug and impossible to hand over to another team member.
• No data layer — scraping values from the DOM. CSS selector-based data elements break every time developers change the page markup. They break silently, without errors, often going undetected for weeks.
• Missing Clear Variables actions. Without clearing variables between beacons, values bleed from one interaction into the next. The resulting eVar persistence issues are extremely difficult to diagnose retroactively.
• No documentation. The next person to touch this implementation — whether that is a colleague, a new hire, or you six months from now — needs to understand every rule and data element without asking questions. Document as you build.