See inside an Adobe Launch container: every rule, data element, and extension from _satellite

Auditing an Adobe Launch (now Adobe Tags) deployment usually assumes you have a seat in the property. Often you don’t: agencies inherit sites whose Launch property lives in a client’s Adobe org, engineers debug pages where all they can see is a minified launch-*.min.js, and measurement managers get asked “what does our tag manager actually do?” with no export in hand. The configuration is right there in the page — Launch’s runtime keeps the whole container in window._satellite — but it is an undocumented object buried in the console, not something you can read.

The Adobe Launch / Tags Explorer turns that runtime object into a browsable tree. Grab the container off any live page with the built-in bookmarklet, or paste an exported container object, and the explorer flattens it: every rule with its events, conditions, and actions, the full data-element inventory, and the extension list. It runs 100% client-side — the JSON is parsed in your browser, nothing is sent anywhere, and the page works offline.

What it does

• Two ways in. The Bookmarklet tab gives you a drag-to-bookmarks link that reads window._satellite._container (falling back to .container) on any page running Launch and copies it to your clipboard as JSON. The Explore container tab accepts that paste — or JSON.stringify(_satellite._container) run by hand, an exported library container, or any container-shaped object.
• Property header with counts. The property name and token/id, plus chips counting rules, data elements, and extensions.
• Extensions actually used. A summary line lists every extension referenced by a rule component — distinct from the installed-extensions table, so installed-but-unreferenced extensions stand out.
• Rules as expandable accordions. Each rule shows its event/condition/action counts up front; expanding it groups the components under Events, Conditions, and Actions, each with a readable label like adobe-analytics · sendBeacon, the full module path, a (negated) flag on inverted conditions, and the component’s settings pretty-printed as JSON.
• Data elements table. Name, type, module path, and storage duration for every data element.
• Extensions table. Name, display name, and whether the extension carries settings.
• Diagnostics. A parser-notes panel records every decision the normalizer made, so when a container parses oddly you can see exactly what the tool saw.

How it works

The page is a UI shell over a small dependency-free engine (launch.js, exposed as window.LAUNCH) that does all the parsing. The engine is pure logic — no DOM access, no network — and its core contract is that normalizeContainer never throws: every path is defensive, and anything unexpected is recorded in a notes array instead of raised as an error.

Unwrapping. Input can be a JSON string (parsed first; a non-JSON string is noted and yields an empty result), the _satellite object itself, or a bare container. If the object has a _container property, that is unwrapped; a .container property is only treated as a wrapper when the outer object does not itself look like a container but the inner one does. “Looks like a container” means having any of the keys rules, dataElements, extensions, property, buildInfo, or company — that check also drives the “no recognisable Launch sections” diagnostic.

Shape tolerance. Because _satellite internals vary by library version, every section is read through a helper that accepts either an array or an id/name-keyed object, turning both into key/value entries. Object keys double as fallback names, so a rules map keyed by rule id still produces named rows. Components can be full objects or bare module-path strings; settings that are not a plain object are coerced to {} rather than crashing the render.

Labelling. Component labels are derived from the module path: core/src/lib/events/click.js becomes core · click — first path segment is the extension, filename minus .js is the module. The same derivation supplies a data element’s type when the container does not carry an explicit type field. Property tokens are read from property.token or property.id, with a further fallback into property.settings for libraries that stash identifiers there.

Extension usage summary. summarize walks every event, condition, and action across all rules, takes the first path segment of each component’s modulePath (or ref) as its owning extension, deduplicates and sorts the set, then maps each name to its display name via the installed-extensions inventory. That produces the “extensions used across rule components” line.

Diagnostics. The notes array logs each step: whether JSON string input was parsed, whether _satellite._container was unwrapped, the raw type of each section (rules section type: array), and any recovered error. The UI surfaces these under Diagnostics, which is how a BETA tool for an undocumented format stays honest about what it did and did not understand.

Rendering safety. The UI never interpolates your input into innerHTML — every node is built with createElement and textContent, so container settings containing markup or script render as inert text.

How to use it

1. Open the Bookmarklet tab and drag the Copy _satellite container link to your bookmarks bar (or copy the code and paste it as a bookmark URL).
2. On a page running Launch, click the bookmarklet. It reads _satellite._container (or .container), copies the JSON to your clipboard, and confirms with the character count. If clipboard access is blocked, it falls back to a prompt you can copy from. It makes no network request.
3. Back in the tool, paste into the Container JSON box on the Explore container tab and click Explore (or press Ctrl/Cmd+Enter). The status line confirms, for example, 2 rules · 2 data elements · 3 extensions parsed.
4. Read top-down: property header, extensions-used line, then expand rules to inspect each event, condition, and action with its settings. Finish with the data-element and extension tables, and check Diagnostics if anything looks thin.

No Launch site handy? Sample container loads a realistic two-rule Adobe Analytics property: a pageview rule gated on an environment-equals-production condition, and an add-to-cart click rule with a custom-code action — enough to see every part of the output at once.

Limitations

• BETA, built on undocumented internals. _satellite._container is not a public, versioned API. Its shape shifts between Launch library versions, and some builds (minified or older ones) do not expose it at all. When nothing is found, the tool says so and shows its parser notes rather than guessing.
• Configuration, not behavior. The explorer shows what is registered in the container — it cannot tell you which rules actually fired on a page, what a beacon contained, or what custom code did at runtime.
• Custom code is shown, not resolved. Custom-code actions and data elements appear as source strings inside their settings JSON; the tool does not execute, format, or fetch external code the deployed library loads separately.
• The runtime container is what shipped. You are inspecting the library deployed to that page and environment, which can lag behind unpublished changes sitting in the Launch UI.
• Treat the JSON as sensitive. Everything stays in your browser, but a container can embed org IDs, endpoints, and custom code — only inspect containers you are authorized to look at.

FAQ

Is my container uploaded anywhere? No. Parsing and rendering happen entirely in your browser; the page works offline, and the bookmarklet only reads a window object and writes to your clipboard.

The bookmarklet says no _satellite or no container — what does that mean? Either the page is not running Adobe Launch / Tags, or that library build does not expose the container under _container or .container. Both cases get an explicit alert; the second is a known gap in some minified and older builds.

Can I paste the launch-*.min.js file itself? No. That file is minified JavaScript, not JSON — the parser will note “input was a string but not valid JSON” and stop. Use the bookmarklet on the live page, or paste JSON.stringify(_satellite._container) from the console.

Why do the extensions table and the “extensions used” line differ? The table lists what is installed in the container; the summary line lists only extensions that a rule’s events, conditions, or actions actually reference. An extension in the table but not the summary is installed without any rule using it — worth a look during cleanup.

Does this work for “Adobe Tags”? We don’t call it Launch anymore. Yes. Adobe Tags is the renamed Adobe Launch; the runtime is the same _satellite object, and the tool handles both the id-keyed and array-shaped containers different library versions expose.

Related

• Adobe Launch / Tags Explorer — the tool itself, and the full tools index.
• Background: the Adobe Analytics guide covers the stack these containers usually serve, and how web tracking works sets the wider context.
• On Google’s stack instead? The GTM Container Explorer is this tool’s Google Tag Manager counterpart, with the GTM guide as background.
• Data elements reading a digitalData or dataLayer object pair naturally with the dataLayer Event Spec and the dataLayer Validator.
• The explorer maps what the runtime exposes; TagForge goes further — resolving the custom code behind each rule and auditing what actually fires. TagForge is pre-launch: declarative management of exactly what this tool lets you inspect, and subscribers at /#subscribe get first access.