�۶���Ƶ

Analytics for Target implementation

Several steps are required when implementing �۶���Ƶ Analytics as the reporting source for �۶���Ƶ Target (A4T). The process varies depending on whether you implement A4T with the �۶���Ƶ Experience Platform Web SDK or with at.js.

Implementation steps for an �۶���Ƶ Experience Platform Web SDK implementation platform

The following sections describe the steps required to deploy this integration to your site if you are plan to use the Platform Web SDK:

Step 1: Request provisioning for Analytics and Target

Before you implement A4T, you must be provisioned for Analytics and Target. .

Step 2: Set up user permissions

User account requirements must be met before you can create an activity based on Analytics in Target. See User permission requirements.

Step 3: Create an Edge configuration

Create an Edge configuration using �۶���Ƶ Experience Platform using the edge configuration tool. Configure the Create and configure datastreams.

Step 4: Install and configure the Platform Web SDK

To start delivering Target experiences and to apply Analytics for tracking and analysis purposes, Install and configure the Platform Web SDK on your site pages.

Step 5: Enable the options for using A4T

In the Target UI, click Administration > Visual Experience Composer, then choose either Select per activity or �۶���Ƶ Analytics.

Implementation steps for an at.js implementation section_73961BAD5BB4430A95E073DE5C026277

The following sections describe the steps required to deploy this integration to your site if you are plan to use at.js:

Step 1: Request provisioning for Analytics and Target

After you implement Analytics as the reporting source for Target, you must be provisioned for Analytics and Target. .

Step 2: Set up user permissions

User account requirements must be met before you can create an Analytics-based activity in Target. See User permission requirements.

Step 3: Implement the Experience Cloud Visitor ID service

The visitor ID service lets you identify users across �۶���Ƶ Experience Cloud solutions. Implement or migrate to the required version of the Experience Cloud Visitor ID. For more information, see “Implementation Requirements” in Before you implement.

See Implement the Experience Cloud ID Service for Target in the Experience Cloud Visitor ID Service documentation.

Step 4: Update AppMeasurement for JavaScript or s_code

Implement or migrate to the required version of appMeasurement.js. For more information, see “Implementation Requirements” in Before you implement.

For new implementations, see JavaScript implementation overview in the Analytics Implementation Guide.

For a migration, see Migrating to AppMeasurement for JavaScript in the Analytics Implementation Guide.

Step 5: Download and update at.js

Implement or migrate to the required version of at.js using your production account. No modifications are required on the code.

For more information, see “Implementation Requirements” in Before you implement.

Step 6: Host at.js

If you previously deployed at.js, you can replace your existing file with the updated version. For more information, see “Implementation Requirements” in Before you implement.

Otherwise, this file can be hosted along with the Visitor ID service and AppMeasurement for JavaScript files. These files must be hosted on a web server that is accessible to all pages on your site. You need the path to these files in the next step.

Step 7: Reference at.js on all site pages step7

Include at.js below VisitorAPI.js by adding the following line of code in the tag on each page:

For at.js:

<script language="JavaScript" type="text/javascript"
src="http://INSERT-DOMAIN-AND-PATH-TO-CODE-HERE/at.js"></script>

The VisitorAPI.js must be loaded before at.js. If you are updating an existing at.js file, make sure that you verify the load order.

The default setting for Target and Analytics integration, from an implementation perspective, is to use the SDID that is passed from the page to stitch the Target and Analytics request together on the backend automatically.

You can control how and when to send analytics data related to Target to Analytics for reporting purposes. If you do not want to opt in to the default settings of having Target and Analytics automatically stitch the analytics data via the SDID, set analyticsLogging = client_side via window.targetGlobalSettings. Note: any versions below 2.1 do not support this approach.

For example:

window.targetGlobalSettings = {
  analyticsLogging: "client_side"
};

This set up has a global effect, which means that every call made by at.js has analyticsLogging: “client_side” sent within the Target requests and an analytics payload is returned for every request. When this option is set up, the format of the payload that is returned looks like the following:

"analytics": {
   "payload": {
      "pe": "tnt",
      "tnta": "167169:0:0|0|100,167169:0:0|2|100,167169:0:0|1|100"
   }
}

The payload can then be forwarded to Analytics via the . For Auto-Allocate and Auto-Target activities, you must also forward the sessionId. For more information, see Analytics for Target (A4T) reporting in the �۶���Ƶ Target SDKs guide.

If a global setting is not desired and a more on-demand approach is preferable, use the at.js function getOffers() by passing in analyticsLogging: “client_side”. The analytics payload is returned for this call only and the Target backend does not forward the payload to Analytics. By pursuing this approach, every at.js Target request returns the payload by default, but instead only when desired and specified.

For example:

adobe.target.getOffers({
      request: {
        experienceCloud: {
          analytics: {
            logging: "client_side"
          }
        },
        prefetch: {
          mboxes: [{
            index: 0,
            name: "a1-serverside-xt"
          }]
        }
      }
    })
    .then(console.log)

This call invokes a response from which you can extract the analytics payload.

The response looks like the following:

{
  "prefetch": {
    "mboxes": [{
      "index": 0,
      "name": "a1-serverside-xt",
      "options": [{
        "content": "<img src=\"http://s7d2.scene7.com/is/image/Target�۶���ƵTargetMobile/L4242-xt-usa?tm=1490025518668&fit=constrain&hei=491&wid=980&fmt=png-alpha\"/>",
        "type": "html",
        "eventToken": "n/K05qdH0MxsiyH4gX05/2qipfsIHvVzTQxHolz2IpSCnQ9Y9OaLL2gsdrWQTvE54PwSz67rmXWmSnkXpSSS2Q==",
        "responseTokens": {
          "profile.memberlevel": "0",
          "geo.city": "bucharest",
          "activity.id": "167169",
          "experience.name": "USA Experience",
          "geo.country": "romania"
        }
      }],
      "analytics": {
        "payload": {
          "pe": "tnt",
          "tnta": "167169:0:0|0|100,167169:0:0|2|100,167169:0:0|1|100"
        }
      }
    }]
  }
}

The payload can then be forwarded to Analytics via the .

Step 8: Validate the implementation step8

Load your pages after you have updated the JavaScript libraries to confirm that the mboxMCSDID parameter values in Target calls match the sdid parameter value in the Analytics page-view call.

It is especially important to confirm that these values match in Single Page Applications (SPAs) where the order of calls is not always predictable.

Step 9: (Optional) Remove previous integration code

�۶���Ƶ recommends that you remove the previous integration to simplify your implementation and eliminate the need to sort out discrepancies between the systems. You can remove any code you have deployed for a previous SC to T&T integration, including mboxLoadSCPlugin.

Step 10: Enable the options for using Analytics as the reporting source for Target

In Target, click Administration > Reporting and choose either Select per activity or �۶���Ƶ Analytics to enable the options.