Before you implement Analytics for Target (A4T) with at.js

Several changes occur in your data collection process when enabling Adobe Analytics as the reporting source for Adobe Target (A4T).

Before you decide to use this integration, review the following sections and consider the impact to your reporting processes.

Implementation requirements

This A4T integration requires that you implement the following library versions (or newer), depending on whether you want to use redirect offers with A4T or not.

Requirements needed if not using redirect offers with A4T

This integration requires that you implement the following library versions (or newer) if you do not plan on using redirect offers with A4T. The order listed is the order of operations.

• Experience Cloud Visitor ID Service: visitorAPI.js version 1.8.0
• Adobe Target: at.js version 0.9.1
• Adobe Analytics: appMeasurement.js version 1.7.0

For information about implementing A4T with the Platform Web SDK, see Adobe Experience Platform Web SDK.

Requirements needed if using redirect offers with A4T

To use redirect offers with A4T, you must implement the following library versions (or newer). The order listed is the order of operations.

• Experience Cloud Visitor ID Service: visitorAPI.js version 2.3.0

  NOTE

  at.js 1.8.0+ and at.js 2.x+ no longer work with Visitor API versions older than 2.5.0 for passing Adobe Audience Manager (AAM) parameters.

• Adobe Target: at.js version 1.6.2

• Adobe Analytics: appMeasurement.js version 2.1

Download and deployment instructions are listed in Analytics for Target Implementation.

For information about implementing A4T with the Platform Web SDK, see Adobe Experience Platform Web SDK.

Things to know before you implement

• This integration is enabled on new activities when you select to use Analytics as the reporting source. After you make the implementation changes described in this document, your existing activities are not impacted.
• The process of setting up Analytics as the reporting source for Target includes several implementation steps, followed by a provisioning step. It is a good idea to read through the process as described below before implementing. After you complete these steps, you are ready to use Analytics as your reporting source when it is enabled for you. The provisioning process can take up to five business days.
• The Visitor ID service creates a shared Visitor ID across the Adobe Experience Cloud. Although it does not replace the Target mboxPC id or Audience Manager UUID, it does replace the way Analytics identifies new visitors. If set up properly, returning Analytics visitors should also be identified via their old Analytics ID. Similarly, because the Target mboxPCid remains intact, no Target visitor profile data is lost when you upgrade to the Visitor ID service.
• The Visitor ID service must execute before your Analytics and Target page code. Make sure that VisitorAPI.js appears above the tags for all other Experience Cloud solutions.

Latency

After this integration is enabled, you will experience an extra 5-10 minutes of latency in Analytics. This latency increase allows data from Analytics and Target to be stored on the same hit, allowing you to break down activities by page and site section.

This increase is reflected in all Analytics services and tools, including the live-stream and real-time reporting, and applies in the following scenarios:

• For live stream, real-time reports & API requests, and current data for traffic variables, only hits with a supplemental data ID are delayed.
• For current data on conversion metrics, finalized data, and data feeds, all hits are delayed an extra 5-7 minutes.

The latency increase starts after you implement the Experience Cloud visitor ID service, even if you have not fully implemented this integration.

Supplemental ID

All Target calls used by an A4T activity to deliver content or record the goal metric must have a corresponding Analytics hit that shares the supplemental ID for A4T to work properly.

Hits that contain data from Analytics and Target contain a supplemental data ID. You can see this ID in the Adobe Experience Cloud Debugger as the sdid parameter. For example: sdid=2F3C18E511F618CC-45F83E994AEE93A0. This ID is generated anytime the following criteria are in place:

• The visitor ID service is in implemented

When troubleshooting, be sure to confirm that the supplemental ID is present on Analytics hits.

Client-side Analytics logging

If at.js, the Experience Cloud Visitor ID Service, and appMeasurement.js are on the page, Analytics, and Target correctly stitches events for reporting and analytics purposes in the backend as long as the correct supplemental ID is included from the page. You do not need to manage and perform any additional operations for A4T to function correctly.

There are cases when you might want to have more control on when and how to send analytics data related to Target to Analytics for reporting purposes. You might have an in-house analytics tool that you use for internal purposes. However, you also want to send the analytics data to Analytics via your in-house analytics product so that other members of your organization can continue to use Analytics as a visual reporting source. See Step 7: Reference at.js on all site pages in Analytics for Target Implementation for more information.

Shared audiences

While filling in the Marketing Cloud Integrations Provisioning Form, be aware of the following important information concerning the Shared Audiences option listed under “For which capabilities are you requesting provisioning?”

When you request Shared Audiences, you enable Target and Adobe Audience Manager (AAM) to share information, in this case audiences.