eVars and events in product variable are proceeded by 1&2 respectively.
we are passing eVar17,19.
but in product string in debugger it's capturing as eVar117,119.
similarly for events, we are passing as event52
but in product string in debugger it's capturing as event252
@Jennifer_Dungan @yuhuisg @Andrey_Osadchuk @akt0m3r
Solved! Go to Solution.
Views
Replies
Total Likes
Yes, Adobe is confusing that way.. but this is actually expected....
The "Name" that you see when tracking eVars and events (i.e. eVar17, eVar19, event52) are different than the raw data identifiers in the database.
You get to know this really quickly when you work with the Raw Data Feeds (well at least for events... I actually had to contact support for the eVar mappings to support post_product parsing).
Remember that there are standard reserved events like "Purchase", "Product View", "instance of eVarX", etc... all of those show up in processed data....
So if you look at the event.tsv file that comes with Raw Data Feed, it will map them out:
Purchase is event ID 1
Instance of eVar1 - Instance of eVar100 are actually IDs 100-199 (these are standard account eVars)
Then when Prime and Ultimate packages came along, Instance of eVar 101-250 are actually IDs 10000-10149
You custom events (event1, event2, through to event100) are actually IDs 200-299 (again standard package)
Premium package events (event101-1000) are actually IDs 20100-20998
Most of the mobile instance of events are in the 5xx, AMO in the 6xx, Mobile App Lifecycle in the 7xx; etc...
Likewise, eVars have mapping to Adobe's DB...
101-175 | eVars 1-75
275-299 | eVars 76-100
1200-1349 | eVars 101-250
Since you are looking at "Post Processed" Data, you will see things appear like this, but it's expected.
Yes, Adobe is confusing that way.. but this is actually expected....
The "Name" that you see when tracking eVars and events (i.e. eVar17, eVar19, event52) are different than the raw data identifiers in the database.
You get to know this really quickly when you work with the Raw Data Feeds (well at least for events... I actually had to contact support for the eVar mappings to support post_product parsing).
Remember that there are standard reserved events like "Purchase", "Product View", "instance of eVarX", etc... all of those show up in processed data....
So if you look at the event.tsv file that comes with Raw Data Feed, it will map them out:
Purchase is event ID 1
Instance of eVar1 - Instance of eVar100 are actually IDs 100-199 (these are standard account eVars)
Then when Prime and Ultimate packages came along, Instance of eVar 101-250 are actually IDs 10000-10149
You custom events (event1, event2, through to event100) are actually IDs 200-299 (again standard package)
Premium package events (event101-1000) are actually IDs 20100-20998
Most of the mobile instance of events are in the 5xx, AMO in the 6xx, Mobile App Lifecycle in the 7xx; etc...
Likewise, eVars have mapping to Adobe's DB...
101-175 | eVars 1-75
275-299 | eVars 76-100
1200-1349 | eVars 101-250
Since you are looking at "Post Processed" Data, you will see things appear like this, but it's expected.
Just wanted to add that all the variable/event number lookup file are sent inside the ZIP file with Data Feed files. You should find the file "lookup.tsv" after extracting the Data Feed ZIP file. So no need to contact the support for these look up files.
Cheers!
Well if I could get the Data Team (the recipients of the files), who always asks for my help on how to process the data to send me those files... that would be a big help
To be fair though, when I took over the analytics after the two branches of the company merged, they probably weren't sure if I knew my stuff (the previous people on their side probably couldn't help them much)... I've more than proven that I'm actually a good resource and we work together well. And when I took over.. they first told me they didn't even have the events.tsv... I don't think their job processes it, and no one looked in the actual S3 bucket
Views
Replies
Total Likes
Thanks a lot for explanation, this is probably the reason, in reports it's showing proper eVars and events.
While I don't use WebSDK yet, it make sense that it targets the deeper identification... since this can be used for more than just Analytics... I think it will take a while for us to shift our thinking.. but glad it's working for you.
Views
Replies
Total Likes
yep, and just FYI this behavior is only for product string, rest events and their eVars are working as it was with app measurement.
Views
Replies
Total Likes
Views
Likes
Replies