We usually run a report in adobe analytics for all of our target A/B: tests currently running. In order to verify that our visitor traffic is correct I create a page report for the page we're testing next to it. Currently there's a few of our tests that aren't matching up with the page report. Sometimes I see only 50% of the traffic in analytics for target vs the page report. When I dig in further I see a good chunk of the traffic in the page report is "unspecified" visitors. Could you please explain why this might be happening?
Solved! Go to Solution.
Hi @Maple-Michelle1 they are referring to the marketingCloudVisitorId that is sent in the request payload to Target--ensure that matches the "mid" query string parameter in the server call to Analytics.
I had an experience a while back with a similar issue (reporting mismatch). After much digging around I found it was in fact due to an intermittent sdid problem. In our implementation, we originally used the default at.js behavior which has viewsEnabled set to true. This effectively generates 2 mbox server calls to Target--one for prefetch (which we don't use) and one for the actual getOffers() request. The problem is that the sdid for the useless prefetch matched the sdid in the Analytics server call, but depending on timing, the sdid used in the getOffers() request was different.
To make a long story short, at.js will not reuse the same sdid for requests to the same mbox name (global mbox or otherwise). Since both the prefetch and getOffers() call defaulted to the global mbox (we don't typically use custom mboxes), the sdid would change.
I resolved the problem by using the resetState() method in the Visitor.js library before the call to getOffers(). Since Analytics was set to wait on the getOffers() to execute before tracking the pageview, the sdid used in the getOffers() call matched the one that Analytics picked up when it came time to track the pageview.
This may not be at all what your issue is, but perhaps it is. Either way, I'm sorry I rambled a bit
Hi @Maple-Michelle1 how have you done the implementation of libraries. Please check on the pages where you are running AB Test if AA library is loading after AT library and if sdid and mid params are matching in both calls.
If this is all good, then check if you have used the audience segments in the AA page report also since AT activity report data comes when use qualifies for the activity segment.
our analytics library is loading after target library. the sdid is matching for both calls. not sure what you mean by mid params. could you elaborate?
Hi @Maple-Michelle1 they are referring to the marketingCloudVisitorId that is sent in the request payload to Target--ensure that matches the "mid" query string parameter in the server call to Analytics.
I had an experience a while back with a similar issue (reporting mismatch). After much digging around I found it was in fact due to an intermittent sdid problem. In our implementation, we originally used the default at.js behavior which has viewsEnabled set to true. This effectively generates 2 mbox server calls to Target--one for prefetch (which we don't use) and one for the actual getOffers() request. The problem is that the sdid for the useless prefetch matched the sdid in the Analytics server call, but depending on timing, the sdid used in the getOffers() request was different.
To make a long story short, at.js will not reuse the same sdid for requests to the same mbox name (global mbox or otherwise). Since both the prefetch and getOffers() call defaulted to the global mbox (we don't typically use custom mboxes), the sdid would change.
I resolved the problem by using the resetState() method in the Visitor.js library before the call to getOffers(). Since Analytics was set to wait on the getOffers() to execute before tracking the pageview, the sdid used in the getOffers() call matched the one that Analytics picked up when it came time to track the pageview.
This may not be at all what your issue is, but perhaps it is. Either way, I'm sorry I rambled a bit
Views
Likes
Replies