Reporting Metrics, Part 3: When Third-Party Target Reporting Doesn’t Match Expectations

[#1]

By Christopher Davis and Kevin Scally 

This is Part 3 of our series on Target Activity Reporting FAQs & Troubleshooting which focuses on instances where Target reporting is done using a third-party tool. Check out Parts 1 & 2 for troubleshooting tips & tricks when using Target as your reporting source, or when using Analytics for Target (A4T) as your reporting source! 

Response Tokens 

In general, third-party reporting means that Target activity reporting is being handled by a non-Adobe solution. This is usually achieved by passing Response Tokens contained in a response from Target to some other solution. Response Tokens let you expose information about activities, experiences, responses, geography, profile attributes, etc. in the response from Target. While on their own, they are useful tools for debugging information in the Target Visitor Profile, they can also be used to integrate with third-party solutions. Response Tokens are managed from the Administration tab in the Target UI, and can be activated or deactivated only by users with the Target Approver role. Activated tokens will be contained in Target responses that contain activities. 

{ 
    "status": 200, 
    "requestId": "aa53be53-bb2a-4ff1-bbfd-741054002b37", 
    "client": "yourclientcode", 
    "id": { 
        "tntId": "d359234570e04f14e1faeeba02d6ab9914e.34_0", 
        "thirdPartyId": "12345" 
    }, 
    "edgeHost": "mboxedge34.tt.omtrdc.net", 
    "telemetryServerToken": "PXNJsW1KyKyR5IJFGtOjCQop+Vm5SwAtF3dVreV7cPc=", 
    "execute": { 
        "pageLoad": { 
            "options": [ 
                { 
                    "content": { 
                        "specialOffer": "onlyForSampleValueA" 
                    }, 
                    "type": "json", 
                    "responseTokens": { 
                        "activity.name": "Param XT Qualification", 
                        "profile.loyaltyTier": "Gold", 
                        "profile.thirdPartyId": "12345", 
                        "geo.state": "florida", 
                        "experience.name": "Experience A", 
                        "geo.domainName": "sbcglobal.net" 
                    }, 
                    "sourceType": "target" 
                } 
            ] 
        } 
    } 
} 

An example Target Response containing Response Tokens. 

Passing Response Tokens to Third-Party Solutions 

At a high-level, the approach to pass response tokens to another solution is to set up a listener for Target responses. That listener should then check the response for tokens and, if there are any, pass them to the third-party solution. In a common example, Google Analytics customers will push Target Response Tokens into their Google Data Layer so that they can then be processed by Google Analytics. Keep in mind that Target needs to return an activity in its response in order for there to be Response Tokens present. For more detailed information on how to pass Response Tokens to other apps, check out this detailed guide. 

// response event listener - create after at.js is loaded, before request is fired 
document.addEventListener(adobe.target.event.REQUEST_SUCCEEDED,function(response) { 
        //if the response contains tokens, make them accessible  
        //to your third-party solutions in a manner they expect 
      }); 

An example of an AT.js custom event listener, which would be used to listen for Target responses. 

Reporting Windows and Settings 

Now that we’ve established how third-party integrations are generally performed, we can talk about different factors that might contribute to reports from a third-party source not matching expectations. This first one may seem obvious, but it can be the culprit much more often than you think. Target reporting defaults to showing the entire lifetime of the campaign. If your third-party reporting source’s data is telling an extremely different story than Target is, it’s usually best practice to double check your timeframe settings in both Target and your third-party solution. Here’s a deep dive into all the different options you have for Target reporting. 

An example report in the Adobe Target UI 

Counting Methodologies 

Another important factor to consider is that there are often differences in counting methodologies between applications. Since testing ultimately compares the behaviors of distinct groups under varied circumstances, Target tracks at the Unique Visitor level. Third-party applications may encounter variance from Target if they track at Visit or Hit level, or even if they track Unique Visitors differently (e.g., difference in anonymous profile merge methods). You should take great care to configure your third-party reporting solution to mirror how Target tracks behavior as closely as possible. 

Expected Variances 

Even with everything as close in parity as possible between solutions, given differences in timing, counting methods, etc. – it is expected behavior that there will be some variance between Target and third-party reporting solutions. The normal expected variance when methodologies are similar is 15-20%, and when differences in counting methodologies come into play, that variance can rise to 35-50%. We recommend utilizing Adobe Target or Analytics for Target (A4T) reporting over third-party reporting to avoid having discrepant data sources for Target activity performance.