The new
collection path.

1 · What the Web SDK is

The Web SDK (codename Alloy) is Adobe's replacement transport for client data. Where AppMeasurement is the AA-specific library that fires hits to a Data Collection server, the Web SDK is solution-agnostic — it fires events to the Adobe Experience Platform Edge Network, which then routes them to whatever Adobe products you've configured (Analytics, Target, Audience Manager, Real-Time CDP).

AppMeasurement era                        Web SDK era
──────────────────                        ───────────
                                          
  Web SDK (Alloy)                         AppMeasurement     mbox.js (Target)     dil.js (Audiences)
  ↓                                        ↓                  ↓                    ↓
  AEP Edge Network                        ↓                  ↓                    ↓
  ├─ Analytics                            Analytics          Target               Audience Mgr
  ├─ Target                               
  ├─ Audience Mgr                         (three networks, three contracts,
  └─ CDP                                   three SDKs, three sets of bugs)

One library, one event payload, one network call — the Edge Network decides what to do with it based on your "datastream" configuration. For sites running multiple Adobe products, this is a significant operational simplification.

2 · Edge architecture

A hit goes through the following stages:

1. Browser calls alloy("sendEvent", { xdm: {...} }).
2. The Web SDK serialises the payload and POSTs to edge.adobedc.net (Adobe's globally distributed edge servers).
3. The edge server reads your datastream config ID from the request header. The datastream tells it which downstream services to fan out to.
4. The same payload is forwarded — server-side — to each enabled service. For Analytics, an internal mapping converts the XDM payload into the legacy report-suite variables that the AA backend understands.
5. The edge returns a single response to the browser, possibly carrying personalisation decisions (Target offers, audience evaluations).

Two consequences worth dwelling on:

• One network call instead of N. Faster page, less battery, less ad-blocker friction.
• The mapping from XDM to AA report-suite variables happens server-side. Your client code stops thinking about eVars. You think about XDM fields, and the datastream config maps them.

3 · XDM — Experience Data Model

XDM is Adobe's open, JSON-Schema-based data model for customer experience events. Where AppMeasurement uses unnamed slots (eVar4, prop15, event10), XDM uses named fields with strong types.

// A product view event in XDM
{
  "xdm": {
    "eventType": "commerce.productViews",
    "web": {
      "webPageDetails": {
        "name": "PDP: Astro-3000",
        "pageViews": { "value": 1 }
      }
    },
    "commerce": {
      "productViews": { "value": 1 }
    },
    "productListItems": [
      {
        "SKU": "ASTRO-3000",
        "name": "Astro 3000 Telescope",
        "priceTotal": 299.00,
        "quantity": 1
      }
    ],
    "_yoursandbox": {
      "campaign": "summer-sale-2025",
      "loyaltyTier": "gold"
    }
  }
}

The standard fields (xdm.web, xdm.commerce, xdm.productListItems) come from Adobe-published schemas. Custom fields live under your tenant namespace (_yoursandbox in this example), so they can't collide with Adobe's reserved space.

3.1 — Schemas and field groups

Each XDM schema is composed from field groups — reusable building blocks. Common ones:

• Web Details — pageName, URL, referrer.
• Commerce Details — productListItems, purchases, checkouts.
• Marketing Channels — campaign codes, tracking codes.
• Environment Details — browser, OS, viewport.
• Identity Map — known IDs (ECID, hashed email, CRM ID).

You assemble a schema in the AEP UI by mixing field groups, then extend it with your tenant's custom fields. Every event you send must validate against the schema; invalid events are dropped at the edge.

4 · Alloy commands

Alloy is initialised on the page (Launch does this for you in production):

// (Snippet that Launch injects — you usually don't write this by hand)
!function(n,o){o.forEach(function(o){n[o]||...})}(window,["alloy"]);
alloy("configure", {
  edgeConfigId: "abc12345-...-xyz",  // your datastream ID
  orgId:        "ABCDEF1234@AdobeOrg"
});

From then on, every interaction is a command:

// Page view
alloy("sendEvent", {
  xdm: {
    eventType: "web.webpagedetails.pageViews",
    web: { webPageDetails: { name: "Home", pageViews: { value: 1 } } }
  }
});

// Click event
alloy("sendEvent", {
  xdm: {
    eventType: "web.webinteraction.linkClicks",
    web: {
      webInteraction: {
        name: "Add to Cart · PDP",
        type: "other",
        linkClicks: { value: 1 }
      }
    },
    commerce: { productListAdds: { value: 1 } },
    productListItems: [{ SKU: "ASTRO-3000", quantity: 1 }]
  }
});

Other commands you'll use: setConsent, getIdentity, applyPropositions (Target), appendIdentityToUrl (cross-domain).

5 · Mapping XDM to legacy eVars

When the edge forwards your XDM event to Analytics, it needs to know which eVar / prop / event each XDM field maps to. This mapping lives in the datastream configuration in AEP — outside your code, outside your Launch property.

Datastream config (Adobe UI)
────────────────────────────
xdm.web.webPageDetails.name        → pageName
xdm.web.webPageDetails.URL         → page URL
xdm._yoursandbox.campaign          → eVar15
xdm._yoursandbox.loyaltyTier       → eVar22
xdm.commerce.productViews.value    → event1
xdm.commerce.productListAdds.value → scAdd
productListItems[].SKU             → products string SKU
productListItems[].priceTotal      → products string price

This is the seam that lets a Web SDK implementation populate a legacy AA report suite without rewriting reports. Workspace still shows eVar15 and event1; analysts using existing dashboards see no difference. But your client code has moved off slot-based variables.

6 · Launch with the Web SDK

The mechanics of Launch don't change — you still have rules, events, conditions, actions, data elements. What changes is the extension you install: Adobe Experience Platform Web SDK instead of Adobe Analytics.

The Web SDK extension provides actions like:

• Send Event — fire an XDM event. You build the XDM object inline or reference a data element.
• Update Variable — append to a persistent XDM object across rule invocations (rare; most teams build the object per-event).
• Reset Variable — discard accumulated XDM state.
• Set Consent — propagate consent decisions.

The data layer pattern from module 02 is even more important here, because XDM objects are much larger than eVar lists. A single rule that hand-assembles a 50-field XDM object becomes unreadable. The strong pattern is: a data element per logical XDM section (xdm.web, xdm.commerce, xdm.productListItems), each derived from the data layer.

7 · When to pick which

For new implementations in 2025–2026, the default answer is Web SDK. The remaining reasons to choose AppMeasurement are: an existing, heavily-customised implementation; a vendor-built integration that hasn't been ported; or organisational risk-aversion. All three resolve with time.

8 · Checkpoint

You should now be able to:

• Explain the role of the AEP Edge Network in a single sentence.
• Write an XDM payload for a page view and a product-add event.
• Identify where the XDM-to-eVar mapping lives (datastream, not Launch, not client).
• Recommend Web SDK vs AppMeasurement for a given scenario.