Migrate from the Adobe Analytics tag extension to the Web SDK tag extension

[pradeep_07]

Hi!

We are in process of Switching our App measurement code into AEP Web SDK and send data to Adobe Analytics (Use the same Schema and share data with AEP Data Lake in near future). And I see in one of the articles, adobe have mentioned that using default Adobe analytics experience event schema can create confusion for data admins or architects and it also make it difficult to use other platform services such as Adobe journey optimizer or Real - Time Customer Data Platform.

Adobe also recommended to use data object that allow you to send data to Adobe analytics without confirming to XDM schema .

My questions is, what exactly the drawback of using Experience event schema ?  and has anyone used data object to send data to adobe analytics and how it works ?

Send data to Adobe Analytics using the Web SDK tag extension | Adobe Analytics

Thanks,

Pradeep

[bjoern_k]

Hi @pradeep_07 

one of the huge benefits is that the use of the Adobe Analytics ExperienceEvent schema does all the mapping from XDM to Adobe Analytics props/eVars/events,... for you which, if you just added data anywhere else than in the _experience.analytics object in the XDM schema, you would have to map all by yourself with processing rules in Adobe Analytics.

So, if you are planning on moving to CJA anyway and since CJA is not relying on the old props and eVars anymore, you would have to either way come up with a new data XDM structure that has to be mapped to CJA at some point.

The suggestion with the "data" object breaks the rigid boundaries of a typed XDM schema and can be compared to the context data you may know from Adobe Analytics which essentially contains unstructured data that you can set and use freely. So, you could technically throw the whole dataLayer into it (whether this makes sense or not), and just apply mapping to whatever you need have mapped.

Using "data", you will be less limited in terms of what structure and types of data AEP expects, which surely has pros and cons to carefully think about.

One of the big advantages of a given XDM structure is surely that the system knows what to expect and complains if your data does not meet the requirements e.g. when an incorrect type is encountered. This way, you can be sure that you can apply operations on a numeric value that would fail on a string value.

If you solely rely on unstructured data, you may encounter situations where data mapping is not working as expected e.g., for the aforementioned type issue.
Unless you have a clear documentation on your data structure and find ways of how to enforce that the data coming in from your data layer matches these requirements, you may run into trouble during a later stage.

Hope that helps
Björn

[Jennifer_Dungan]

I agree with @bjoern_k, if you are planning to move to CJA any time soon, you could look into doing a full XDM Schema overhaul...

However, it might be an easier transition to use the Adobe Analytics Experience Event Schema for now, to help eliminate a lot of potential transitional issues (basically you would be changing the process but keeping mapping intact), then you can take a slower transition to the formal XDM Schema over a longer period of time.

I haven't started the XDM transition myself, but this is going to be my plan of action to reduce the number of changes all at once.

[pradeep_07]

@bjoern_k @Jennifer_Dungan  - Thanks for your answers !

Agreed ! - We have like 40 domains in App measurement code and I am just trying to avoid the amount of Re-work we need to do When CJA comes in to picture . This is what I decided :

 Phase 1 - I have to move all our site to Web SDK compilant and use Adobe Analytics Experience Event Schema .

 Phase 2 - Take slower tranisition to XDM schema .

But only concern is how the Historic data will look in CJA ? will there be sync issue b/c of new XDM schema ?

For Example : If I use Adobe Analytics Experience Event Schema and sent data to Adobe analytics and when I move to custom XDM schema switch to CJA . Will there be any difference in Historic data load ? Because Schema is going to be completley different .

[bjoern_k]

Hi @pradeep_07 

sounds like a complex setup  

About the AA data in CJA, valid point! It should - @Jennifer_Dungan corrrect me if I am wrong - be possible to use AA data and map it in a Data View to new data fields.

Have unfortunately not done it myself yet, so curious about the answer as well.

https://experienceleague.adobe.com/en/docs/analytics-platform/using/cja-dataviews/data-views 

Cheers

[Jennifer_Dungan]

I also have not done this (we don't have CJA, and I haven't yet migrated to Web SDK)... but I will be a similar situation... we have 30 "sites", but more complex than that is that each of our sites has external content sites....

By this, I mean: we have a network of Newspapers, each of those has a classified site, an obituaries site, a games site, digital editions, etc....

Each of these variants has it's own Launch property (due to different code bases).

So feel your pain about transitioning to WebSDK.... 

Since I don't have CJA, but I did find this document about ingesting Analytics data: 

https://experienceleague.adobe.com/en/docs/analytics-platform/using/cja-data-ingestion/ingest-use-gu...

[prads]

I agree with @Jennifer_Dungan and @bjoern_k. It is very important.

[VinayC]

I completely resonate with @bjoern_k and @Jennifer_Dungan 

One major advantage of using the Adobe Analytics ExperienceEvent schema is that it handles the mapping process from Experience Data Model (XDM) to Adobe Analytics properties (props), conversion variables (eVars), and events for you. This saves you from having to manually map the data, which would be necessary if you placed data elsewhere in the XDM schema.

If you're transitioning to Customer Journey Analytics (CJA), which no longer relies on old props and eVars, you'll need to develop a new XDM structure regardless. The suggestion to utilize the "data" object allows for more flexibility compared to the structured XDM schema. It's akin to the unstructured context data in Adobe Analytics, enabling you to freely set and use data. While this offers more freedom, it also requires careful consideration of its implications.

Structured XDM ensures that the system expects certain data types, which helps in identifying errors. Conversely, relying solely on unstructured data may lead to issues like incorrect type mapping. Without clear documentation and measures to ensure data consistency with requirements, problems may arise during later stages of data processing.

[pradeep_07]

Thanks @VinayCVinayC.

Looks like using the Experience event schema has lots of advantages, but how does it work CJA? we can still use the same schema to report on CJA (I know you mentioned issue with eVars and props).

But, irrespective of whether we use Experience event schema or custom XDM structure, how the schema will work with CJA?

For Example: If I use one schema which has 20 domain and share data with AEP data lake. How can I filter the data while creating the dashboard in CJA? is there a way I can filter the data by domain? or all twenty domains' data will contribute to CJA? 

[Jennifer_Dungan]

I would say similar to Adobe Analytics, you would need to have a dimension that can be used to identify the domain, and dimensions for everything that you need to segment on or view as a breakdown.

The fundamental difference between Adobe Analytics and CJA, is that CJA is more open to data types.. in Analytics, all dimensions are stored as text, whereas CJA can store numeric values, arrays, json, etc. The other big thing is that attribution (expiry) models don't need to be set up-front, but can be derived on the fly, and the same data can actually be derived to many different attributions.

But at the end of the day, both AA and CJA are fundamentally "dimensions" and "metrics"... it's just the way they are stored and where the modelling is applied that separates the two architectures. They both use Workspace (though CJA has some new fancier visualizations that AA doesn't have), the way in which you pull data into your reports should be very similar.