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!
Solved! Go to 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:
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?
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:
Using the new web SDK extension update for update variable:
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:
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?
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.
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?
Views
Replies
Total Likes
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.
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!
@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:
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?
Views
Likes
Replies
Views
Likes
Replies