XDM vs. Traditional SDR
Traditional SDRs map business requirements to numbered variables: eVar1, prop5, event12. The XDM (Experience Data Model) approach is fundamentally different. Instead of arbitrary slot numbers, you design a schema using standardized field groups that describe what the data actually represents.
This shift matters because XDM schemas are shared across the entire Adobe Experience Platform ecosystem. The same schema that powers your Analytics reporting also feeds Real-Time CDP segments, Journey Optimizer decisions, and Customer Journey Analytics. There is no need to maintain separate mapping documents for each product.
Key Differences
In a traditional SDR, eVar1 = Product Name is a mapping convention. In XDM, the field is productListItems[].name, a semantically meaningful path that every Adobe product understands natively. No processing rules, no classification uploads, no ambiguity about what the variable contains.
When designing your XDM schema, start with the standard Adobe field groups and only extend with custom fields when the standard model does not cover your business needs. This approach maximizes compatibility and reduces long-term maintenance.
Core Field Groups
Adobe provides pre-built field groups that cover the most common data collection scenarios. Select the field groups that match your business requirements. Here are the four essential groups for most web implementations.
Web Details
| XDM Field | Type | Description |
|---|---|---|
web.webPageDetails.name | String | Page name for reporting |
web.webPageDetails.URL | String | Full page URL |
web.webPageDetails.server | String | Server or domain hosting the page |
web.webPageDetails.siteSection | String | Site section or channel |
web.webReferrer.URL | String | Referring URL |
Commerce
| XDM Field | Type | Description |
|---|---|---|
commerce.productViews.value | Integer | Product detail page view count |
commerce.productListAdds.value | Integer | Add to cart action count |
commerce.checkouts.value | Integer | Checkout initiation count |
commerce.purchases.value | Integer | Purchase completion count |
commerce.order.purchaseID | String | Unique order identifier |
productListItems[].name | String | Product name |
productListItems[].SKU | String | Product SKU identifier |
productListItems[].priceTotal | Double | Line item total price |
Identity
| XDM Field | Type | Description |
|---|---|---|
identityMap.ECID[] | Array | Experience Cloud ID (auto-generated) |
identityMap.CRMID[] | Array | CRM or login identifier |
identityMap.Email[] | Array | Hashed email identifier |
Consent
| XDM Field | Type | Description |
|---|---|---|
consent.collect.val | String | Data collection consent status (y/n/p) |
consent.marketing.preferred | String | Marketing preference (email, sms, push) |
consent.personalize.content.val | String | Content personalization consent (y/n) |
Custom Extensions
Standard field groups cover 80% of typical requirements. For business-specific data that does not fit into any standard group, you create custom field groups within your tenant namespace. This keeps your extensions isolated and prevents conflicts with future Adobe schema updates.
When to Extend
- Industry-specific dimensions: Fields like loyalty tier, subscription plan, or account type that are unique to your business model.
- Internal campaign tracking: Custom promotion IDs, A/B test variant names, or personalization segment labels.
- Calculated attributes: Session-level computed values like engagement score or lead quality tier that your data layer provides.
How to Extend
Naming Convention
All custom fields live under your tenant namespace: _yourTenantId.customFieldName. Use camelCase for field names, group related fields into sub-objects, and always document the purpose and allowed values. Example: _yourTenantId.loyaltyProgram.tier with values "bronze", "silver", "gold", "platinum".
Keep custom extensions minimal. Every custom field adds maintenance overhead and requires manual mapping in downstream systems. Before creating a custom field, verify that no standard field group already captures the same data.
Identity Configuration
Identity resolution in Adobe Experience Platform is schema-driven. Each identity namespace you configure determines how visitor profiles are stitched together across devices and sessions. Getting this right is critical for accurate audience building and personalization.
| Namespace | ID Type | Source | Primary | Notes |
|---|---|---|---|---|
ECID | Device | Auto-generated by WebSDK | Yes | Default primary identity for all web events |
CRMID | Cross-device | Login / authentication event | No | Links anonymous and authenticated profiles |
Email_LC_SHA256 | Cross-device | SHA-256 hash of lowercase email | No | Enables match with CRM and email platforms |
Phone_SHA256 | Cross-device | SHA-256 hash of phone number | No | Optional, for SMS campaign matching |
Identity Graph Best Practice
Set ECID as the primary identity for web events. When a user logs in, send both ECID and CRMID in the same event so the Identity Service creates a link between the two. Never send PII (plain-text email, phone) as identity values. Always hash them before sending to the Edge Network.
Configure identity namespaces in the Adobe Experience Platform UI under Identities before building your datastream. Each namespace must exist before events referencing it can be processed.
Consent Schema Configuration
The Adobe consent field group integrates directly with your Consent Management Platform (CMP). When configured correctly, consent preferences travel with every event, enabling real-time enforcement across all Adobe products.
Consent Field Group Setup
- Add the Consent field group: In your XDM schema, add the "Consent and Preference Details" field group. This adds the standard consent object to every event.
- Map CMP signals: Your CMP (OneTrust, Cookiebot, etc.) provides consent state. Map these signals to
consent.collect.valusing Launch data elements. - Set default consent: In the WebSDK datastream configuration, set the default consent to "pending" (
p). Events are queued until explicit consent is received. - Send consent updates: When the user interacts with the consent banner, call
alloy("setConsent", ...)to send the updated preferences. The Edge Network processes or discards queued events based on the response.
GDPR and CCPA Compliance
The consent schema supports granular preferences: data collection, personalization, and marketing by channel. For GDPR, set default consent to "pending" and require explicit opt-in. For CCPA, you can default to "in" with an opt-out mechanism. Configure these defaults per-region in your datastream settings.
Migration Mapping: eVar/prop to XDM
If you are migrating from a traditional AppMeasurement implementation to WebSDK, this mapping table shows the equivalent XDM fields for common eVar and prop assignments. Use this as a starting point and adjust based on your specific SDR.
| Traditional Variable | Common Usage | XDM Equivalent |
|---|---|---|
pageName | Page name | web.webPageDetails.name |
channel | Site section | web.webPageDetails.siteSection |
products | Product string | productListItems[] array |
events | Custom events | commerce.* or _yourTenantId.* |
eVar1 | Product name | productListItems[].name |
eVar (campaign) | Tracking code | marketing.trackingCode |
eVar (custom) | Business-specific dimension | _yourTenantId.customField |
prop (traffic) | Hit-level dimension | _yourTenantId.customField (no expiration) |
purchaseID | Order ID | commerce.order.purchaseID |
transactionID | Data source link | _experience.analytics.customDimensions.eVars.eVarX |
Dual Mapping During Migration
During migration, you can send data to both AppMeasurement variables and XDM fields simultaneously using the Analytics mapping in your datastream configuration. This allows you to run parallel reporting in both Adobe Analytics (traditional) and Customer Journey Analytics (XDM) until you are confident the new schema captures everything correctly.
