Information to help you minimize the effects of inflated Visit and Visitor counts when using Analytics as a reporting source.
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.
Note that 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 additional data that is not available when there is no Target activity on the page. This is because 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, we included this additional data whenever a Target activity was active. Going forward, we will include 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, we are recording “partial data” (sometimes called “unstitched hits”), which would not be captured by Analytics were there no Target activity. Although including this partial data in Analytics reporting does provide additional information, it also creates inconsistency with historical data from periods when there were no Target activities running. This can cause problems for Analytics users who are analyzing trends over time. In the interest of ensuring data consistency in Analytics, we will be excluding all partial data.
We have seen some customers with very high rates of partial data in Analytics. This 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 data is sent as efficiently as possible. To learn more about implementation requirements, see Before You Implement.
Review the following steps, in order, to reduce partial data collection:
|Make sure the report suite selected in Target is the same as the one on the page(s) where the activity will be presented.|
|Ensure 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.|
|Check to make sure the SDID is getting set on all Target and Analytics calls leaving the page and that they match.
Do this by using 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.
Because this processing change affects data only after the release date (November 14, 2016), if you would like to adjust your historical metrics to match, we recommend 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 will still be 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 is the ideal scenario.
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 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’ll be properly counted as returning visitors. These are hits that 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 will 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 are what we define 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 will not process incoming partial data. Conversions and hits to other Analytics metrics will not change.