What are the pros and cons of each approach?

[Dave_Hamel_2024]

One of my love/hate things about Adobe Analytics is that there are many ways to do everything.  

I watched this video here: Upgrading to Modernized Data Collection for Adobe Analytics with Web SDK - YouTube and it seems pretty straight forward.  Mapping the eVars and s.props is more or less the same as it was using the Adobe Analytics plugin.

But I can achieve the same effect using the XDM schema Adobe Analytics ExperienceEvent Full Extension

I don't know what the pros and cons of each approach is though. The first one is more familiar I suppose, but the second seems like it would mesh better with other data sources, I could send it to AEP.  So which approach is better, assuming I still want to send data to Adobe Analytics now, but may want to send data to AEP in the future. Or do I need to retag when I go to AEP?

Thanks!

[Ankit_Chaudhary]

Hi @Dave_Hamel_2024 

The best approach depends on your specific needs and goals. If you prioritize future-proofing your data collection and leveraging the full power of RTCDP & CJA then sending data to AEP is the recommended option. However, if you need a simpler solution for collecting data for Adobe Analytics, the new web SDK extension update might be sufficient.

Using Schemas and sending data to AEP:

• Pros:
  • Allows you to leverage the full power of AEP, including real-time customer profiles, data science, and marketing activation.
  • Provides a standardized way to collect and manage customer data across all Adobe Experience Cloud solutions.
  • Future-proofs your data collection for potential upgrades and new features.
• Cons:
  • Requires more initial setup and configuration.
  • May have a steeper learning curve compared to the web SDK extension update.

Using the new web SDK extension update for update variable:

• Pros:
  • Easier and quicker to implement for adobe analytics.
  • Simplifies collecting data for Adobe Analytics.
• Cons:
  • Limited to collecting data for Adobe Analytics only.
  • Doesn't offer the same level of data management and analysis capabilities as AEP.
  • May not be ideal for future-proofing your data collection strategy.

The importance of XDM:

No matter which approach you choose, it's crucial to have your data available in the XDM format in the data lake to AEP solutions such as CJA or AJO. This is because:

• XDM is the standard data model for AEP: Using XDM ensures seamless integration and analysis of your data across all AEP solutions.
• Improves data consistency and quality: XDM provides a structured and standardized way to define and manage your data, leading to better data quality and consistency.
• Enables future-proofing: By adopting XDM, you're preparing your data for future upgrades and new features within AEP.

[Dave_Hamel_2024]

Hi @Ankit_Chaudhary,

Thanks for the response.

I didn't find the implementation of the Adobe Analytics ExperienceEvent Full Extension to be onerous. A few extra steps with the data stream but that's not that big of a deal.  I feel comfortable using that and sending the data to AA & AEP. 

I guess my concern using it is that if the analysts are going to use the web dataset in CJA, they will need some sort of cheat sheet that tells them what all the props and eVars are. Is there a way to pull the labels from the report suite so that things are consistent?

[Ankit_Chaudhary]

CJA no longer bounded with the concept of evars and props you can configure up to 5000 metric and 5000 dimensions per data view, to provide context to your CJA variables in analytics workspace you can provide some additional description while setting up components in CJA data view that would help your analyst. It would work in a similar fashion as you use to provide description to evars props and events in report suite settings and view it on click of info button in analytics workspace. 

I would recommend to create a maintain a SDR.

[Dave_Hamel_2024]

I think that is what I need.  But if my understanding is correct those labels are attached to the data view, not the data set itself. Meaning if my analysts created a data view of "web data + call center" and then another data view of "web data + survey data" they would need to update the data in both, correct?

[Ankit_Chaudhary]

yes, but there is another way around to this as well you can also provide a description at schema level, by selection any field of the schema you will get the option to provide description.

You'll find this description will already be available for some default field while constructing the schema, however you can also change this by your liking.

Now, the same will be available as description for your components in CJA.

Now the catch is you can create multiple dimensions, metrics using same schema filed in CJA in that case I believe you'll have same description for all the dimensions(I haven't tested it yet by myself by providing any custom descriptions and creating multiple dimensions with same field will keep you posted)

Also, some fields by default have a vague description but you change it anytime to make it more meaning full either in schema or data view.

Also I've seen fields with different path but same discerptions as well you need to keep an eye on those too.

check the path for both the screenshots it's different but they have same description

I guess I've mentioned a lot, hope it will be helpful but still recommend maintaining a SDR though.

[Dave_Hamel_2024]

I totally agree with you about the SDR.  I can see where the nomenclature of variable is going to become very important.  You could very easily end up with 10 things called "name" and each refer to something different!

[yuhuisg · Accepted solution]

---

@Dave_Hamel_2024 wrote:

I guess my concern using it is that if the analysts are going to use the web dataset in CJA, they will need some sort of cheat sheet that tells them what all the props and eVars are. Is there a way to pull the labels from the report suite so that things are consistent?

---

So there are 2 schools of thought regarding your question:

1. Use the ExperienceEvent field group.
   1. Main pro: no additional work is needed, e.g. if you set a value to _experience.customDimensions.eVars.eVar1-100.eVar1, then you can be rest assured that the value will get reported in Analytics under eVar1.
   2. Main con: you're stuck with Analytics variable names, i.e. eVar1, prop29, event203, etc. If your long term goal is to use CJA, then you will need to maintain a mapping of what each prop/eVar/event/etc refers to.
2. Use your own custom field group. Then in your Datastream, map your custom fields to Analytics' variables.
   1. Main pro: you can name your fields according to what makes sense in your business, and everyone using CJA should "get it".
   2. Main con: you have to manage that mapping in Datastream, particularly when you add new fields. That step can be easily forgotten in the implementation process, resulting in lost/incorrect data in Analytics.

There's probably a 3rd option, i.e. including both the ExperienceEvent field group and your own custom field group, then ensuring the same values are set in the respective fields. But I think that can become a pain very quickly.

So which of the two options you choose depends on your business' analytics direction, which I think boils down to: is your business going to use CJA 90% of the time within the next 2 years?