Information to help you minimize the effects of inflated Visit and Visitor counts when using Adobe Analytics as the reporting source for Adobe Target (A4T).
On November 14, 2016, Adobe Analytics changed the way some data is processed for customers using Analytics reporting for Target (A4T). These changes bring Adobe Target data into better alignment with the data model for Adobe Analytics . These changes were rolled out for all customers using A4T. These changes specifically address an issue where some customers have noticed an inflated visitor count when Target activities are running.
This change is not retroactive. If your historical reports show inflated counts, and you would like to exclude them from your reports, you can create a virtual report suite, as explained below.
The mbox.js library does not support redirect offers with A4T. Your implementation must use at.js.
When Adobe Analytics is used to measure Target activities (called A4T), Analytics collects extra data that is not available when there is no Target activity on the page. The Target activity fires a call at the top of the page, but Analytics typically fires its data collection calls at the bottom of the page. In the implementation of A4T to date, Adobe includes this additional data whenever a Target activity was active. Going forward, Adobe includes this additional data only when both the Target and Analytics tags have fired.
Adobe prides itself on data accuracy and quality. When the Target tag fires, but the Analytics tag does not, Analytics records “partial data” (sometimes called “unstitched hits”). These unstitched hits would not be captured by Analytics if there was no Target activity. Although including this partial data in Analytics reporting provides additional information, it also creates inconsistency with historical data from periods when there were no Target activities running. This situation can cause problems for Analytics users who are analyzing trends over time. In the interest of ensuring data consistency in Analytics, Adobe excludes all partial data.
Adobe has encountered some customers with high rates of partial data in Analytics. High rates of partial data can result from improper implementation, but there are legitimate causes as well.
The identified causes of partial data include the following:
visitorAPI.js) to make sure that data is sent as efficiently as possible. To learn more about implementation requirements, see Before You Implement.
Review the following steps to reduce partial data collection:
|Ensure that the report suite selected in Target is the same as the one on the pages where the activity is presented.|
|Ensure that the visitorAPI.js, appMeasurement.js, at.js / mbox.js libraries are on A4T-compatible versions. To learn more about implementation requirements, see Before You Implement.|
|Ensure that the SDID is getting set on all Target and Analytics calls leaving the page and that they match.
Use a network analyzer or debugging tool to ensure that the
|Confirm that the implementation libraries load in the correct order on your sites. For more information, see Analytics for Target Implementation.|
Although this information is not available directly in Analytics, you can contact Adobe Customer Care to retrieve a Partial Data report. This report is intended to aid in debugging.
This processing change affects data only after the release date (November 14, 2016). If you want to adjust your historical metrics to match, Adobe recommends that you create a segment to exclude partial data.
The following information relating to this change includes instructions to help you define the segment and apply it to a virtual report suite so that this segment is always applied to your Analytics views.
In most situations, a Target hit is stitched with an Analytics hit on each webpage. This stitching happens if there is a consistent SDID in both the Target and Analytics call and a Experience Cloud ID (MCID) in the Analytics call on the same page. Target typically has the MCID as well, but if the call to Target happens before the visitor ID returns, the hit is still stitched because of the SDID. Also, the user must remain on the page long enough to fire an Analytics call after a Target call was fired. This scenario is ideal.
Partial-data hits: Users sometimes don’t remain on a page long enough to send an Analytics call, but Target has a proper MCID. This scenario results in partial-data hits (hits with no Analytics page view). If these users come back to your site and view a page containing Analytics code, they are properly counted as returning visitors. These hits would have been lost if you had only Analytics code on the page. Some clients don’t want data for these hits because they inflate certain metrics (visits) and deflate other metrics (page views per visit, time per visit, and so forth). You also see visits without any page views. However, there are still valid reasons for keeping this data.
To minimize partial-data hits, you can make your page load faster, update to the latest versions of the libraries, or create a virtual report suite that excludes those hits. For step-by-step instructions, see Create virtual report suites in the Analytics Components Guide.
The following illustration shows for the segment definition for the virtual report suite:
When creating the virtual report suite, specify the following configuration for the segment definition (as shown in the above illustration):
Orphaned hits: In fewer situations, users don’t remain on the page long enough for an Analytics call and Target didn’t get a proper MCID. These hits are what Adobe defines as “orphaned” hits. These hits represent customers that rarely return and they inflate visit and visitor counts inappropriately.
To minimize these “orphaned” hits, you can create a virtual report suite that excludes those hits, as explained above.
Once this change occurs, you might see a decrease in new visitors and visits to live tests because Adobe does not process incoming partial data. Conversions and hits to other Analytics metrics will not change.