CASE 24 / AEM + AEP / DATA COLLECTION
AEM + AEP: Web SDK, Identity and Consent
Architecture exploration of an AEM experience connected to Adobe Experience Platform through Web SDK. This is a proposed PoC design, not a deployed integration or a claim of production AEP ownership.
Engineering path
Governed event path
Proposed engineering sequence
- 01AEM experience
- 02Approved event
- 03Consent decision
- 04Web SDK
- 05Configured destination
01 / Context
Start with one approved event
- PLATFORM
- AEM + AEP / proposed integration PoC
- SCOPE
- Events · identity · consent · presentation
- TYPE
- Architecture exploration / proposed PoC
Use a synthetic page-view and interaction fixture, an isolated test configuration and no real visitor records. AEM owns content delivery; an application-owned event adapter defines what may leave the browser. Primary documentation was reviewed on 13 October 2026.
02 / PROBLEM
A rendered page is not a governed event contract
Component lifecycle events can produce duplicate collection or export fields never approved for analytics. An authenticated AEM session, an analytics identifier and consent are different facts; none should silently stand in for the others.
03 / CONSTRAINTS
Boundaries the design must preserve
- Use synthetic data; exclude private content and raw credentials.
- Do not infer consent from authentication or identity.
- Preserve baseline content when personalization is unavailable.
04 / ARCHITECTURE
Keep content delivery separate from event routing
The proposed adapter maps approved fields to the selected XDM event contract. Adobe documents datastreams as server-side SDK configuration selected by datastreamId. The destination and enabled services must be checked explicitly; receiving an event does not establish profile readiness or personalization eligibility.
Content and collection are separate systems
Illustrative architecture. The datastream configuration determines enabled downstream services.
Content delivery
- AEM
- Dispatcher / CDN
- Browser content
Event collection
- Approved event
- Consent policy
- Web SDK
- Edge / datastream
- Configured AEP dataset
Combined path
- Independent validation
05 / IMPLEMENTATION
Define event ownership before adding a tag
Assign one owner for page views and route changes, allowlist fields and version the event mapping. Record which consent state permits each intended collection action. Adobe’s setConsent documentation distinguishes send/discard behavior and explains persistence; it is not a substitute for an approved consent policy or CMP integration.
06 / IDENTITY / PERSONALIZATION
A personalization response must not authorize access
Namespace and identifier selection need an agreed identity contract. Test login, logout and shared-device transitions with synthetic identities. Treat any returned personalization as optional presentation: retain a baseline experience and independently authorize protected content. Selection, rendering and measurement are separate responsibilities; no response-time or audience-availability guarantee is implied.
07 / VALIDATION
Observe the payload, not just the dashboard
Proposed PoC checks: inspect outgoing fields, event count, consent denial/change, destination selection and identity transitions. Verify baseline rendering if an integration fails. These are acceptance criteria, not captured test output or evidence of an operating AEP environment.
Acceptance scope and limits
TO VALIDATE
Proposed checks, not captured results.
- Proposed PoC checks: inspect outgoing fields, event count, consent denial/change, destination selection and identity transitions. Verify baseline rendering if an integration fails. These are acceptance criteria, not captured test output or evidence of an operating AEP environment.
DOES NOT CLAIM
Owns proposed browser event integration, not production AEP administration or measured personalization results.
- A completed customer deployment or measured production outcome
- A passing test run without retained execution evidence
08 / RISKS / TRADEOFFS
Decoupling collection adds a contract to maintain
A shared event adapter limits component coupling but requires ownership and schema-change tests. Personalization can add dependencies and inconsistent experiences across consent states. Consent withdrawal must follow the approved downstream policy; changing a browser setting does not prove deletion of previously collected data.
| Risk | Consequence | Proposed check |
|---|---|---|
| Duplicate page event | Misleading collection | Assert one intended event per journey |
| Identity survives logout incorrectly | Cross-user association | Exercise anonymous/login/logout transitions |
| Denied collection still sends | Policy boundary fails | Inspect network requests under denied state |
| Personalization fails | Broken experience | Verify baseline content without a decision |
09 / ENGINEERING VALUE
Make each boundary inspectable
The intended outcome is a small, reviewable integration contract and failure checklist. This scenario makes no legal-compliance, conversion, production activation or AEP operations claim.
10 / ENGINEERING VALUE
Engineering value sought
Intended value: a bounded event and consent contract that can be reviewed before a PoC. No live collection or production AEP result is claimed.
Technical references
These sources document product behavior. The scenario and proposed validation are engineering interpretations, not vendor claims or execution evidence.