Fill in the form like a developer planning a page. Watch the right-hand panel emit three
representations of the same data: a classic digitalData object, an Adobe Client
Data Layer event push, and the AppMeasurement code Launch would produce from it.
Edit any field below. The output panel updates instantly. Switch the three tabs at the top of the panel to see how the same business data flows through three different implementation surfaces. The AppMeasurement tab is the closest to what fires in the browser; the Data layer tabs are what your front-end framework should produce.
Identifies the page in reports. Lowercase, colon-delimited names work
well: shop:pdp:astro-3000.
Login state and any identity you can safely emit client-side. Never put PII in the data layer in plain text — hash emails before they touch the page.
One row per product on the page or in the cart. Leave price empty for a product-view; populate it for cart and purchase events.
What just happened. The mapping to AA events runs in Launch — you emit the business concept, not the eVar slot.
Loading…
The Adobe Client Data Layer pattern — an event-driven push to a shared queue. The recommended
pattern for SPA implementations: every state change pushes a new object, and Launch reacts to
the event field. Modules 02 and 07 cover this in depth.
The W3C CEDDL pattern — a single mutable global object. Older, simpler, and still common in
traditional multi-page sites. Launch reads it via percent-token data elements:
%digitalData.page.pageInfo.pageName%.
What Launch would produce after applying its rules — the eVar / prop / event assignments and
the final s.t() or s.tl() call. Copy this into the sandbox lab to
watch it fire as a wire-level hit.