adobe

Adobe Launch (Adobe Experience Platform Tags) Implementation Checklist and Guide

By Laurent Fidahoussen on May 8, 2025

Most Adobe Launch implementations I audit do not fail because of the tool. They fail because nobody wrote down what should be collected, the data layer arrives after the rules fire, and the person who built the property left with the only copy of the naming logic. Six months later, nobody trusts the numbers in Adobe Analytics, and every new tag request turns into archaeology.

Adobe Launch is now called Tags in Adobe Experience Platform (Adobe’s own docs say “formerly known as Adobe Experience Platform Launch”), and it lives under Data Collection > Tags. The building blocks have not changed much: properties, extensions, data elements, rules, libraries, environments. What changed is the context around them: the Web SDK and the Edge Network, datastreams, event forwarding, and stricter publishing permissions. This guide is the checklist I use, followed by the details behind each line.

The Adobe Launch (Tags) implementation checklist

Before you start

Property and environments

Data layer and data elements

Rules

Adobe Analytics or Web SDK

Publishing and QA

Governance

Before you start: plan first, click later

The tracking plan is the contract: for each event, the business question, the user action, the variables, and who pushes it into the data layer. If you cannot fill that table, you are not ready to open Tags.

The second decision is the library. Adobe’s Analytics implementation guide describes two families. The Adobe Analytics extension loads AppMeasurement and sends hits straight to Analytics. The Adobe Experience Platform Web SDK extension “sends data to the Adobe Experience Cloud from web properties, through the Adobe Experience Platform Edge Network”. With the Web SDK, a datastream holds the server-side configuration: which Adobe services (Analytics, Target, Experience Platform) receive the data. Adobe describes the Web SDK extension as “typically the recommended path for new Web SDK implementations”. Starting from scratch, evaluate it first. With a large AppMeasurement setup that works, migration is a project of its own.

Third: permissions. Tags has three property rights that matter for publishing: Develop (create libraries and build to development), Approve (build to staging and approve) and Publish (push an approved library to production). Adobe is explicit: “these rights are not inclusive”. Giving external consultants Develop only is a healthy setup, and the example in Adobe’s own permissions guide.

Property and environments

A property is the container for rules, data elements, extensions, environments and libraries. A web property can be deployed on several domains, so the real question is how to group sites. Adobe’s guidance: if the HTML templates are the same and the data you collect is similar, one property can manage several sites. If teams, regions or data needs are very different, split them. One thing the original version of this article got wrong: do not name a property “MySite – Production”. Production is an environment inside the property, not a property.

When you create a web property, two advanced settings deserve a decision upfront, because changing them later changes runtime behaviour:

On creation, Tags adds a default host, three environments (Development, Staging, Production) and the default extensions. You can add development environments for parallel work. Each environment holds one library build at a time.

Embed codes are where I find the most damage. Each environment has its own embed code. Adobe warns that the production embed code supports browser caching while development and staging codes do not, so “you should not use development or staging embed codes in high-traffic or production contexts”. The loading mode matters too. Asynchronous deployment uses one script tag in the <head>. Synchronous deployment uses two: one in the <head> and one just before </body>. And if you switch hosts or change the archive setting, the embed code changes and must be updated in the HTML by hand.

Data layer and data elements

Data elements are the variables of Tags. You reference them as %Data Element Name% in rule fields, and with _satellite.getVar() in custom code. Each one has a few settings that are easy to skip and expensive to forget:

For the data layer itself, Adobe ships the Adobe Client Data Layer extension. By default it creates an array called adobeDataLayer, and its event types let a rule listen to all data changes, all events, or one specific event. The site pushes, Tags listens:

// Page code, pushed by the site once the data is known
window.adobeDataLayer = window.adobeDataLayer || [];
window.adobeDataLayer.push({
  event: "product-view",
  product: {
    id: "SKU-123",
    category: "skincare"
  }
});

For a custom code data element, the editor needs a return. Without it, the data element resolves to undefined, then Tags falls back to a stored value, then to the default value. That fallback chain explains many “why does this variable keep last page’s value” tickets.

// Custom code data element: "Site Section"
var parts = window.location.pathname.split("/");
return parts[1] || "home"; // without this return, the value is undefined

Rules

A rule is “if events and conditions, then actions”. Several events in one rule are joined with OR. Several conditions are joined with AND. An exception is a NOT condition. Actions run in the order you set, and one rule can trigger several tools at once, so there is no need for a separate rule per vendor.

The timing trap is the classic one. Adobe’s asynchronous deployment guide says that a rule using Library Loaded “might execute before your data layer is fully loaded”, and recommends Custom Event or Direct Call events triggered by page code once the data layer is ready. It also says that Page Bottom brings little value when the library loads asynchronously, and that page code should no longer call _satellite.pageBottom(). A Direct Call rule listens for an identifier that you fire from the page:

// Fired by the site when a form is really submitted (after validation)
if (window._satellite) {
  _satellite.track("form-submit-success");
}

Rule order: every rule has an order number, 50 by default, and lower numbers run first. Adobe recommends staying between 1 and 100 and keeping the scheme simple. Also remember that rules start in order but do not always finish in order: if rule A does something asynchronous, rule B can start before A is done.

Performance detail: actions of Library Loaded and Page Top rules are bundled into the main library; other actions load later, only when needed. Everything on Library Loaded means a heavier main file.

Adobe Analytics extension or Web SDK

With the Adobe Analytics extension

In the extension configuration, choose how the library is managed (“Manage the library for me” is the simplest) and set report suites for Development, Staging and Production separately, so test traffic does not land in production data. In rules, the extension offers three actions: Set Variables, Send Beacon and Clear Variables. Set Variables does not send anything; Adobe states it plainly: “You cannot send the beacon with the set variables action”. Send Beacon lets you pick s.t() (counts a page view) or s.tl() (does not). In my experience, a Clear Variables action after each link beacon is what stops values leaking into the next hit.

With the Web SDK extension

The main action is Send event, which “sends event data to the Edge Network”. The datastream decides where the data goes next. For Adobe Analytics, the Edge Network accepts an XDM object, a data object or context data. Adobe’s advice matters if Customer Journey Analytics is on the roadmap: it “advises against using the Adobe Analytics schema field group” and recommends your own schema plus datastream mapping, or the data object, so you are not locked into props and eVars. If you migrate from AppMeasurement, the data object is the smoother path.

Event forwarding

Event forwarding reuses rules, data elements and extensions, but runs on Adobe’s servers: it sends events received by the Edge Network to other endpoints. Data elements use {{name}} instead of %name%, and actions always run in sequence. It is a paid feature (Real-Time CDP Connections, Prime or Ultimate): check your contract first.

Publishing: libraries, states and rights

Nothing reaches the site until it is in a library and built. A library holds the changes (rules, data elements, extension configurations), and at build time those changes are combined with everything already submitted, approved or published upstream. A library moves through four states: Development, Submitted, Approved, Published. Development maps to the development environment, Submitted and Approved to staging, Published to production.

Three rules from Adobe’s docs save time:

The Active Library setting lets you save rules, data elements and extensions straight into the library you are working on, and build from there. It makes iteration much faster in development.

How to QA a Tags implementation

Adobe Experience Platform Debugger

The Debugger is a Chrome extension that shows which tag property, environment and build run on a page, and which report suites are active. Three features I use on every audit:

Assurance and Edge Trace

The browser only shows what leaves the page. With the Web SDK, the real question is what the Edge Network sent to Analytics or Platform. Adobe’s Web SDK tutorial shows the path: sign in to the Debugger, open Logs, select the Edge tab, then Connect. This enables Edge Trace, which starts an Assurance session in the background. Assurance itself was built for mobile apps with the Mobile SDK, where it is the main validation tool.

Then check the reports

A green network request is not a correct report. After release, compare a few days of real data with expectations: page views per page type, conversions versus the back office, empty values on key variables.

Pitfalls I see most often

Conclusion

Adobe Launch became Tags, but a good implementation still rests on three things: a data layer the site owns, rules that wait for that data, and a publishing flow where someone else looks before it goes live. Run the checklist before each release. If your property fails several lines, start with embed codes and rule timing: that is where most bad data comes from.

Related reading

Sources

Not sure your own tracking is right?

Book a call Or start with the free analytics audit →