Minimizing inflated visit and visitor counts in A4T

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.

Also, several JavaScript libraries have been updated to help minimize inflated counts. Adobe recommends that you upgrade to the following library versions (or newer):

  • Experience Cloud Visitor ID Service: visitorAPI.js version 2.3.0 or later.
  • Adobe Analytics: appMeasurement.js version 2.1.
  • Adobe Target: at.js version 0.9.6 or later (except version 1.1.0 if using redirect offers with A4T).

What changed?

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.

Why did Adobe make this change?

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.

What contributes to 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:

  • Misaligned report suite IDs (Implementation): The report suite specified during activity setup does not match the report suite on the page where the test is delivered. The data cannot be reconciled on Analytics servers, so it looks like partial data.
  • Slow pages: Target calls are at the top of the page and Analytics calls are typically at the bottom of the page. If the page loads slowly, it increases the likelihood of a visitor leaving the page after the Target call fires, but before the Analytics call. Slow pages can be especially problematic on mobile web sites where connections are often slower.
  • Page errors: If there are JavaScript errors or other scenarios where each of the touchpoints do not fire (Experience Cloud ID service, Target, and Analytics), partial data results.
  • Redirect offers in Target activity: For redirect offers in activities using A4T, your implementation must meet certain minimum requirements. In addition, there is important information that you must know. For more information, see Redirect Offers - A4T FAQ.
  • Old versions of the libraries: Over the past year Adobe has made several improvements to the JavaScript libraries ( appMeasurement.js, at.js, and visitorAPI.js) to make sure that data is sent as efficiently as possible. To learn more about implementation requirements, see Before You Implement.

What are the best practices to reduce partial data?

Review the following steps to reduce partial data collection:

Step Task
Step 1 Ensure that the report suite selected in Target is the same as the one on the pages where the activity is presented.
Step 2 Ensure that the visitorAPI.js, appMeasurement.js, and at.js libraries are on A4T-compatible versions. To learn more about implementation requirements, see Before You Implement.
Step 3 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 mboxMCSDID parameter on Target calls matches the SDID parameter in the Analytics call.
Step 4 Confirm that the implementation libraries load in the correct order on your sites. For more information, see Analytics for Target Implementation.

How can I see how much partial data I have?

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.

How can I view historical trends without partial data?

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):

  • Show Hit:
  • Analytics for Target: Exists
  • And
  • Page Views: Does not exist
  • And
  • Custom Link Instances: Does not exist
  • And
  • Download Link Instances: Does not exist
  • And
  • Exit Link Instances: Does not exist

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.

What does this mean for my Target reporting?

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.

On this page