Where the
implementation meets
the enterprise.

1 · Server-side forwarding

Recall from module 08 that the Web SDK sends one event to the Edge, which fans out server-side to multiple Adobe products. Server-Side Forwarding (SSF) is the AppMeasurement-era predecessor: an AA hit lands on Adobe Analytics' collection servers, and that same hit is forwarded server-to-server to Audience Manager.

Why this matters: without SSF, audience data flowed via the AAM client SDK (dil.js), which meant two network calls on every page. SSF collapses them into one, removing dil.js from the page entirely.

You enable it in the Admin Console (Report Suites → Edit → General → Server-Side Forwarding) and via a flag on AppMeasurement (s.usePlugins patterns vary by version). Once on:

• Every AA hit is duplicated to AAM, server-side, with no client-side hop.
• AAM segments evaluated in real time become available to AA for reporting.
• The Marketing Cloud Visitor ID becomes the join key — required.

For Web SDK implementations, SSF is implicit in the datastream — toggle "send to AAM" on the datastream and the equivalent fan-out happens. The mental model is the same; the configuration surface is different.

2 · Analytics for Target (A4T)

Adobe Target runs A/B tests and personalisation. Without integration, you have two separate data sets: Target reports activity converted in Target's UI, and AA reports activity in Workspace, and reconciling them is a nightmare.

A4T is the integration. When a Target activity uses A4T as its reporting source:

1. Target serves the experience and adds a "served experience" identifier to the hit.
2. AppMeasurement (or Web SDK) sends that identifier alongside the normal hit.
3. Adobe's processing layer joins on that identifier, attributing every subsequent event in the visitor's journey to the Target experience they saw.
4. Workspace gains a dimension: "Target Activity / Experience," which behaves like an eVar with visitor-level expiration.

What you get: A/B test results reported with the full power of AA's segmentation. "Conversion lift among iOS users in Germany who saw variant B" — instant. Without A4T this is hours of manual reconciliation, with error bars no one trusts.

Implementation requirements:

• Marketing Cloud Visitor ID Service must be running.
• Target must be configured with A4T as the reporting source for the activity.
• Target call must execute before AA call (so the experience ID is on the hit). The at.js or Web SDK Decisioning extension handles this when configured correctly.

3 · Customer Journey Analytics (CJA)

CJA is Adobe's next-generation analytics product. The relationship to AA is:

• AA stores data in fixed-schema report suites. Dimensions are eVar / prop / event slots; cardinality is bounded; processing is hit-time. Built for query speed at sub-second latency on familiar metrics.
• CJA stores data in the Adobe Experience Platform data lake. Dimensions are XDM fields; cardinality is unbounded; cross-channel stitching happens at query time. Built for deep cross-device, cross-channel analysis.

The implementation handoff: if your data is already going to AEP (Web SDK, Mobile SDK, server APIs), it can populate CJA with no additional client work — you build a connection in CJA that points at your AEP datasets, then a data view that maps XDM fields to CJA-style components (analogous to Workspace dimensions and metrics).

The skill transfer is small. Workspace UX is nearly identical between AA and CJA. The mental model shift is from "what eVar slot did I use?" to "what XDM field did I use?" — and from report-suite boundaries to data-view boundaries.

4 · Privacy & consent

Three layers, all of which an implementation must respect:

4.1 — Consent management

A CMP (Consent Management Platform — OneTrust, Cookiebot, TrustArc, etc.) collects user choice. Launch reads CMP state and decides whether AppMeasurement / Web SDK fire at all. The standard contract uses the IAB TCF v2.2 framework on the open web; private vendor agreements often layer on top.

Pattern in Launch:

Event:   DOM Ready
Conditions:
  - Custom code: window.OneTrust && OneTrust.IsAlertBoxClosed() == true
  - Custom code: OneTrust.GetDomainData().Groups.find(g => g.GroupName=="Analytics").AlertNoticeText
Action:
  - Adobe Analytics — Send Beacon

If consent is later withdrawn, you must stop firing — Launch supports a "destroy" pattern that clears cookies and disables subsequent calls.

4.2 — Server-side consent enforcement

Web SDK and Mobile SDK both propagate consent state in event headers; the Edge enforces it. Even if a hit arrives "by accident" after consent is revoked, the Edge can drop it before it reaches Analytics. Belt and braces.

4.3 — Data deletion (GDPR / CCPA)

Subject access requests and right-to-be-forgotten requests are handled via the Adobe Privacy Service API. You POST a request with the user's identifiers (ECID, hashed email, CRM ID); Adobe deletes matching records across AA, AEP, AAM. SLA is documented in Adobe's contract — typically 30 days for confirmation.

The implementation cost is small if you've set up identity correctly: hashed email or CRM ID in the Identity Map gives the Privacy Service something to match on. Without identifiers, deletion requests cannot be honoured — which is itself a compliance issue.

5 · Governance program

Any AA implementation that survives three years becomes unmanageable without governance. The program has four pieces, all owned by the analytics function (not engineering, not marketing).

5.1 — The variable register

A canonical spreadsheet (or, better, a wiki database) listing every eVar, prop, event, and XDM field with:

• Name and slot number
• What it captures (business definition, in plain English)
• Allocation and expiration (for eVars)
• Examples of valid values
• Who requested it, when, why
• Active / deprecated / reserved

This document is the contract between marketing, engineering, and analytics. New requests are reviewed against it; no slot is reused without retiring the prior definition.

5.2 — Change control

Launch has a publishing workflow (Development → Staging → Production); use it. Every change ships through a library, every library has a release note. Tag the library with a Jira ticket; maintain a quarterly retrospective listing each change and its measured impact.

5.3 — Periodic audits

Quarterly: walk every active rule in Launch, every classification, every processing rule, every report suite setting. Mark anything you can't justify; queue it for decommissioning. The Launch property gets fatter with no opposing force; the audit is that force.

5.4 — Implementation reviews

For every new feature shipping on the site, a fifteen-minute review before launch: what's tracked, what's not, why, by whom, who'll consume the data. This catches the "we forgot to add tracking" miss before it becomes a six-week historical data gap.

6 · The Solution Design Reference (SDR)

An SDR is the canonical implementation document. It contains:

• The variable register (section 5.1 above).
• For each business question the implementation answers, the chain from "user does X" to "the report shows Y" — including which rule, which eVar, which classification, which dashboard.
• Outstanding limitations: what the implementation can't measure and why.
• A version history.

Adobe's professional services teams produce SDRs as part of paid engagements. Most in-house teams maintain their own, often as a Confluence space. The format is less important than the discipline — without an SDR, every new analyst spends three months figuring out what the prior team built. With one, three days.

7 · QA & release cadence

The pattern that works for most teams of more than two engineers:

1. Development library in Launch. Engineers add rules and merge into a development library; that library is loaded by the development domain. They use _satellite.setDebug(true) to verify.
2. Staging library. A weekly cadence promotes the development library to staging. The analyst team validates against the staging site: every variable on every key page, every event on every key action.
3. Production library. A weekly cadence promotes staging to production. The analyst team monitors anomaly reports in Workspace for unexpected shifts.
4. Hotfix track. Bugs that escape get a fast-track promotion — staging-skip, with a written justification.

This is identical to how engineering teams ship code. Analytics implementations are software; treat them as such.

8 · Career arcs in this discipline

Where this set of skills takes people:

• Analytics Implementer / Engineer. Ships the variables, owns the data quality. Most teams of moderate scale hire two or three.
• Analytics Architect. Designs the variable map, the data layer schema, the governance program. Owns the SDR. One per large team.
• Solutions Architect at Adobe / a partner. Multi-client work; sees more patterns; spends as much time on contract conversations as on code.
• Customer Data Engineer. The role this work increasingly resembles — data layer is just one source feeding a broader customer data platform.
• Marketing Technologist / MarTech lead. Adobe stack expertise extends into Target, CJA, AEP, Campaign — a wider remit, less code per day.

9 · Where to go from here

You've now seen the full stack of Adobe Analytics implementation, from a single eVar to a multi-product enterprise architecture. The remaining mastery is repetition — fifty implementations, every one a fresh shape, the same underlying mechanics.

Recommended next steps:

1. Take the quiz. It synthesises across all twelve modules.
2. Build a personal project: an analytics implementation on a static site you control. The sandbox in module 03 is a starting point — extend it with real Adobe credentials if you have a trial account.
3. Sit on a real implementation team. Volunteer for QA, for SDR maintenance, for the dull work — every hour of that work is worth two hours of reading.
4. Stay current on Adobe's roadmap. The Web SDK + AEP + CJA stack is where new investment goes; AppMeasurement remains supported but is in maintenance.

The quiz is linked below. Good luck.