From an AEM site to Adobe Experience Platform
with the Platform Web SDK

Read this first — what is sourced from where

You asked me to build this from the ZeroBag Adobe documentation dump. I need to be straight with you about what that dump could and could not give me, because it changes how much weight to put on each part.

The mental model: what actually moves

Before the clicks. This is the thing most people get wrong when they describe Web SDK as "the analytics tag."

Why each hop exists — the problem it solves

AEM → Client Data Layer. AEM renders components. Without a standard contract, every tag would need to know AEM's DOM, which changes with templates and component versions. The Adobe Client Data Layer is a JS object AEM Core Components populate automatically — window.adobeDataLayer — carrying component state and firing events like cmp:show. It decouples what the page knows from what the tag reads. That decoupling is the whole reason an implementation survives a redesign.

Client Data Layer → Web SDK. Web SDK does not scrape the DOM. It sends a structured XDM payload. Data elements are the bridge: small functions that pull a value out of the data layer and expose it to a rule. This is where you decide your event's shape, and it is the step that most directly determines whether your profile data is trustworthy.

Web SDK → Edge → datastream. The critical architectural point, and the one your corpus (AEP-02-sdk-01-01-AEP-datastreams.md) supports: the website does not know about Adobe destinations. Web SDK sends one XDM event to the Edge Network. The datastream — configured server-side, not in the page — decides which sandbox it lands in and which datasets or applications receive it. Adding Adobe Analytics, or Journey Optimizer, or a warehouse export later is a datastream change, not a re-tag of the site. One collection, many consumers, no redeploy.

Prerequisites and permissions

Both sides need access, and this is where implementations stall more often than in any technical step. LIVE AEM Web SDK tutorial, Prerequisites

Missing permissions are granted through the Adobe Admin Console. Your corpus also lists the finer-grained tag rights needed for a full implementation — T1 AEP-10-platform-14…web-sdk-tutorial.md:

1Deploy the AEM site

Everything downstream is demonstrated against WKND, Adobe's sample AEM Sites project. In your own estate this step is simply "the site exists" — but the two properties that matter are that it runs AEM as a Cloud Service and uses Core Components, because those are what make the data layer appear without custom code.

What to check before going on

• Open the site, hit F12, type window.adobeDataLayer in the console. If it is undefined, the components are not emitting a data layer and nothing downstream will work.
Checkpoint — before scrolling on: if window.adobeDataLayer is undefined, which of the four hops has failed, and what does that tell you about the remaining steps?
Answer. The AEM → data-layer hop. Nothing downstream — data elements, rules, Web SDK, datastream — has anything to read, so configuring them is pointless until it is fixed. Likely causes: not Core Components, an AEM version without the layer, or a custom template. This is Step 2's whole point: verify the source before building the chain.
• Note whether you are on AEMaaCS or AEM 6.5 — Step 6 differs materially between them.

2Understand the data layer you are about to read

You cannot configure data elements in Step 5 without knowing what the layer exposes. This is the step people skip and then guess at.

3Create the XDM schema in Experience Platform

Switch to AEP. You are creating the shape your web events will take. The tutorial's instruction is to build a schema and add Adobe's own field group AEP Web SDK ExperienceEvent rather than inventing fields — LIVE Integrate AEM Sites and Experience Platform Web SDK, "Create XDM Schema".

Select AEP Web SDK ExperienceEvent and preview it before committing:

4Create the datastream

The datastream is the routing contract. Your corpus states its purpose plainly: T1 AEP-02-sdk-01-01-AEP-datastreams.md — a datastream configures the connection between the Edge Network and Experience Platform, and tells the Edge where to send collected data and which sandbox it belongs to.

What you are deciding here

5Create the Tags property and install Web SDK

Now the tag container. Per the tutorial LIVE, the property needs two extensions — Core and Adobe Experience Platform Web SDK — plus custom-code data elements for page-name, site-section and host-name, an XDM Object data element bound to the Step 3 schema, and one rule firing on the data layer's cmp:show event.

Data elements — the code that reads the data layer

Verbatim from the tutorial's accordion LIVE. These are custom-code data elements:

if (event && event.component && event.component.hasOwnProperty('dc:title')) {
    return event.component['dc:title'];
}

let pagePath = event.component['repo:path'];
let siteSection = '';

// check for .html in the URL
if (pagePath.indexOf('.html') > -1) {
    siteSection = pagePath.substring(0, pagePath.lastIndexOf('.html'));
    siteSection = siteSection.replaceAll('/', ':');   // slash to colon
    siteSection = siteSection.replaceAll(':content:', '');
}
return siteSection;

if (window && window.location && window.location.hostname) {
    return window.location.hostname;
}

Notice what is happening: event.component is not a browser event — it is the data layer component state, handed to the rule by the code in the next section. The rule's event, not the DOM, is the data source.

The rule — listening for cmp:show

The rule's custom event code is the bridge between AEM's data layer and the Tags rule engine. LIVE verbatim:

var pageShownEventHandler = function (evt) {
    // defensive coding to avoid a null pointer exception
    if (evt.hasOwnProperty("eventInfo") && evt.eventInfo.hasOwnProperty("path")) {
        console.debug("cmp:show event: " + evt.eventInfo.path);
        var event = {
            // path of the component that triggered the event
            path: evt.eventInfo.path,
            // state of the component that triggered the event
            component: window.adobeDataLayer.getState(evt.eventInfo.path)
        };
        // Trigger the Tags Rule, passing in the new 'event' object.
        // It is then referenced as 'event' by the data elements:
        //   e.g. event.component['dc:title']
        trigger(event);
    }
}

// set the namespace to avoid a potential race condition
window.adobeDataLayer = window.adobeDataLayer || [];
window.adobeDataLayer.push(function (dl) {
    dl.addEventListener("cmp:show", pageShownEventHandler);
});

Publish

6Connect the Tags property to AEM

This is the AEM-specific hop, and the one your corpus cannot help you with at all. The mechanism is an Adobe IMS service credential plus a Tags in Adobe Experience Platform cloud services configuration in AEM. LIVE

Once bound, AEM injects the published tag library into the page — on both author and publish instances:

7Create the dataset and bind it to the datastream

Nothing collected so far has anywhere to be stored. Your corpus describes a dataset as "a storage and management construct for a collection of data like a database table that follows a schema" T1 AEP-05-datasets.

Then go back to the datastream and attach it — this is the "Add Service" screen the Step 4 screenshot showed empty:

8Generate traffic and verify ingestion

Browse the WKND site — the tutorial's point is that you must actually produce events, then confirm the platform received them. This is the step that turns a configuration exercise into evidence.

Validation, debugging, and the failure modes that actually happen

1 — Is the tag even loading?

2 — Is the event firing and shaped correctly?

The tutorial lists exactly what to verify with the Experience Platform Debugger Chrome extension LIVE:

• Tag property details — extension, version, name
• Platform Web SDK library version and datastream ID
• The XDM Object present as part of the events attribute in the Web SDK request

Failure modes, ordered by how often they bite

Where this meets your identity contract

Your stated contract for the production Web SDK layer: an authenticated event carries ECID plus Contact ID, Contact ID is primary, and consent is collected before activation. Map that onto what you have just seen:

Gaps in this document

Stating these is more useful than pretending coverage.

• Identity namespace configuration is not covered. See the gap above. Next topic.
• Screenshots are from Adobe's April 2023 tutorial tenant. Names like "Luma" and "AEP Launch 3" are Adobe's demo fixtures, not a production estate. Layouts have moved since.
• Video frames are 854×480 source, upscaled to 1280. Adobe only published that rendition — I probed for 720p and 1080p and both returned 404. Legible, not crisp.
• No AEM-author-side detail — component-level data layer configuration, and how a custom (non-Core) component emits state. Your corpus has no AEM material at all, so this is entirely live-sourced.
• Consent implementation is named but not walked through. The Web SDK consent options and how AEM's consent state reaches the tag deserve their own document — and it is the topic your own architecture treats as the single most important capture point.
• The xdm: field-group mapping detail is thin. How each AEM data layer key maps to each XDM field is where real implementations get argued about, and neither the dump nor this tutorial gives a table.

Source table

Retrieval dates. Corpus documents 2026-10-18. Live sources retrieved 2026-10-19. AEM tutorial last substantial update 2023-04-26. Numeric limits and UI labels move between releases — verify anything load-bearing against the live page before repeating it.