1 person found this helpful
Are you seeing the trait population or the segment population in AAM ? AAM shows the reporting for a device ID.
For your issue that List1 never expires in AA, but a visitor (device id) can be dropped from a trait after 120 days of inactivity, check this doc:
Apart from this you can go through following points while comparing AA numbers with AAM:
If you are seeing differences between numbers in Adobe Analytics (AA) and Adobe AudienceManager (AAM), here are some things to check and some points to remember.
What are you comparing?
Everything depends on what you are comparing. That’s vague, but here are some examples:
Comparing AA numbers/segments to AAM segments is VERY difficult, because they are counted so differently. For example, segments in AAM are always visitor-based and in AA, they can be visitor, visit (session), or page based. Also, even if it is visitor-based in AA, the number of uniques represent qualification for the segment and a visit on that very day. In AAM, total segment numbers don’t need a visit during the time period to count let alone a qualification. They just have to have already qualified for it in the past. And real-time segment numbers also don’t need a qualification during the time period, but they just need a visit to the site, having qualified in past or present. Segments are very hard to compare. You are much better off comparing AAM traits to AA numbers.
Sharing Segments via the Marketing Cloud
The differences get even more extreme if you are comparing numbers after sharing an Analytics segment to AAM via the Marketing Cloud.
AAM will see an initial spike in “Total Uniques” exactly when the segment is shared. This is because the users get sent into AAM in a batch process. When this happens, AAM does not retain historical uniques reporting on those users, so it will report on uniques for the segment as if they all came in on the day the segment was shared and uploaded into AAM.
For example, let’s say Analytics user A goes into Analytics on Monday and creates a segment of visitors who “Added Product XYZ to their Cart in the last 60 days”.
Analytics says there is a total of 400 unique visitors who qualify (assume about 200 uniques each 30 day period).
A goes back into Analytics on Tuesday and clicks “Share with the Marketing Cloud”.
This kicks off a batch process that sends all 400 unique visitors over to AAM
AAM receives the data that day in a batch file and records +400 uniques in the segment. Since historical reporting is lost in the process, all 400 uniques are reported on Tuesday in AAM.
This means if A goes into AAM on Wednesday and runs a report on the segment for “last 7 day uniques”, the result will be 400. This is different from what will be shown in Analytics because Analytics knows the true 7-day history of the segment, which is closer to around 50 uniques, assuming the segment was accumulating users at an even rate.
3rd Party Cookies and Browsers
If you do not have Visitor ID service enabled, but are still on the older method of visitor identification, then data is NOT collected in AAM from browsers that don’t accept 3rd party cookies, most notably iOS and Safari in general. This can cause quite a gap between AA and AAM visitor numbers, because AA does collect data from these browsers.
If you do have Visitor ID Service enabled, then this should not be an issue, as AAM will also collect data from browsers that don’t accept 3rd party cookies.
Lining Up Time Periods
When making AA and AAM comparisons, don’t compare time periods that would include the current day in AA. This is because there is a difference in the availability of reporting numbers between AA and AAM. For example, you DO have current day numbers in AA (within an hour or so), so when you do something like “current month”, you’ll get the current day’s numbers in AA but you won’t in AAM, because AAM only shows up to the previous day’s numbers. Instead, choose a certain day or week in the past to compare.
If you’re getting really specific about a day’s numbers, then you’ll also want to know that the AAM reports are on GMT, and many of our partners’ AA report suites are not on GMT, but rather in a different time zone, so the numbers could be different there.
Is the data really getting to both AA and AAM? In a debugger, make sure that all of the pages (or whatever you are comparing) are showing data going to both AA as well as AAM.
If you are on a server-side AAM implementation, you should make sure that the Analytics hit has the right data going into the Analytics variable AND that the response shows that the data is making it to AAM as well.
If you are on a client-side implementation, you should make sure that the Analytics hit and the AAM hit have the data going into the variable that you are comparing. If the AAM hit exists but doesn’t mirror the AA variables, you will need to check the DIL code to make sure that it is firing at the right time, and that it is hooking into the Analytics object correctly. For example, if you are not using the “s” object in Analytics, then you will need to make sure that the AAM DIL code is looking for the right object name as it hooks into Analytics.
Anyway, as you can see, there are many things that can affect the numbers to be different between Adobe Analytics and Adobe AudienceManager. In most cases, it is resolved by simply understanding what you are comparing and making sure that everything is accounted for. As said above, when you start comparing bigger numbers, there is a greater margin for error because of the potential difference in implementation and data collection. It’s best to be more granular when comparing the numbers.
Please go through following points.
1. I am comparing Unique Visitors in both platforms (well said , It depends what we look at)
2. Already, I have taken consideration of 'safari" issue or any browser where AAM fails to set set cookies or 3rd party cookies or browser. We have 20% such visits mostly from iOS. (Most generally found with Mobile/Iphone)
3. We have SSF, and I am comparing 1 month uniques only. So narrowing down chances of losing any signal in AAM due to device inactivity for >120 days. I hope List 1 variable feature "never expire" should not impact.
4. List 1 criteria brings significant Traffic to AA . Thus it is important for us to make sure we are not loosing unique cookies for re-marketing purpose in AAM
5.No issue if found with all rule based which is set on props but with eVar discrepancy is not convincing.
I am also trying to find logic and same time request you to help me out.
I will post in next 2 days about my findings.
In order to investigate the cause for this issue, I might need some more details from you.
I have sent you a DM, please check your message in forum's account.
Were you able to get a resolution to your problem? If yes, can you mark the correct answer for the benefit of others.