analytics for target and a page report not matching up | Community
Skip to main content
M
Maple-Michelle1
Level 2
December 12, 2021
Solved

analytics for target and a page report not matching up

  • December 12, 2021
  • 1 reply
  • 1787 views

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?  

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by jgrubbs

    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 🙂

     

    1 reply

    ambikaTewari_ATCI
    Community Advisor
    ambikaTewari_ATCICommunity Advisor
    Community Advisor
    December 13, 2021

    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.

     

      M
      Maple-Michelle1Author
      Level 2
      December 13, 2021

      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? 

        jgrubbs
        jgrubbsAccepted solution
        Level 3
        December 16, 2021

        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 🙂

         

          Terms & ConditionsAccessibility statement

          Loading footer...