Web SDK + AEP Data Type Validation Issues: Best Implementation Strategy for Analytics and Experience Platform

Hi ​@MaheswarRe,

Your concern is valid, especially if you are using the data object as a way to avoid fixing the invalid data.

Just because the Adobe Analytics reporting is successful doesn’t mean the payload meets the AEP schema requirements. Analytics maps supported fields into Analytics variables, while AEP ingestion requires data to conform to the target XDM schema. That explains why the two destinations can produce different outcomes.

The data object is a valid long-term solution. Adobe currently recommends data.__adobe.analytics for setting Analytics-specific (eVars, props, and events). Adobe also documents this approach for implementations that plan to adopt CJA. Using it does not inherently weaken governance or prevent future Platform use cases.
This is documented in the Adobe Experience League doucmentation.
 

The key distinction is that data destined for AEP must ultimately become valid XDM, regardless of how it leaves the browser. You can either:

• Send correctly typed fields directly in the xdm object.
• Send a governed data layer through the data object and use Data Prep for Data Collection to map and transform it into XDM at the Edge.

Both are supported approaches. Moving an invalid value into data only helps AEP if the mapping or transformation resolves the mismatch. If the field is no longer mapped into AEP, the validation error may disappear simply because AEP is no longer receiving that field.
 

For your existing implementation, my recommendation would be:

1. Investigate the failing fields first.
   Compare the actual payload, any Edge mappings, and the destination dataset schema. Correct mismatches such as "123" versus 123, "true" versus true, or an object where an array is expected. Successful Analytics reporting should be one validation checkpoint, alongside successful AEP ingestion.
    
2. Keep a governed event model for shared business data.
   Fields required by AEP, CJA, or activation use cases should have clear definitions, types, and mappings. Since you already have an XDM implementation, I would fix those fields before considering a broader redesign.
    
3. Use data.__adobe.analytics where appropriate for Analytics-specific variables.
   You can include both xdm and data in the same sendEvent call. Be deliberate about overlapping mappings: recognized Analytics fields in data overwrite corresponding values mapped from XDM. 
    
4. Treat a separate datastream as a routing decision.
   It may be appropriate for different destinations or a phased rollout, but it does not itself correct data types. Adobe documents adding AEP to an existing Analytics datastream and mapping data fields into XDM, so a second datastream is not inherently required.

For CJA, the essential outcome is that the required data reaches the AEP dataset used by the CJA connection. Fields sent only to Analytics through data, without an AEP mapping, will not be available through that direct dataset path.
 

This then leads to the question of whether the proposal is intended to transform the failing fields into valid XDM, or route those fields exclusively to Analytics. Each has different consequences.

My recommendation is to retain a governed XDM destination model for Platform use cases, use the appropriate collection and mapping approach for each field, and resolve the underlying validation errors. The choice between xdm and data is secondary to ensuring that every destination receives the correct, validated data.

Hope This Helps,
Dan