Experience Cloud Integrations
In this lesson, you will review the key integrations between the solutions you just implemented. The good news is that by completing the earlier lessons, you have already implemented the code-aspects of the integrations! You don’t need to do any additional work in this lesson besides reading and validating.
Learning Objectives
At the end of this lesson, you will be able to:
- Explain the basic use cases for Audience Sharing, Analytics for Target (A4T) and Customer Attributes integrations
- Validate the basic client-side implementation aspects of these integrations
Prerequisites
You should complete all of the previous lessons in this tutorial before following the instructions in this lesson.
NOTE- Review the full requirements of the Core Services integrations
- Review the full requirements of the Analytics for Target integration
Audiences
Audiences is part of the People Core Service and allows you to share audiences between solutions. For example you can create an audience in Audience Manager and use it to deliver personalized content with Target.
The main requirements to implement A4T—which you have already done—are to:
- Implement the Adobe Experience Platform Identity Service
- Implement Audience Manager
- Implement other solutions which you would like to receive or create audiences, such as Target and Analytics
Validate the Audiences integration
The best way to validate the Audiences integration is to actually build an audience, share it to another solution, and then fully use it in the other solution (e.g. confirm that a visitor who qualifies for an AAM segment can qualify for a Target activity targeted to that segment). However, this is beyond the scope of this tutorial.
These validation steps will focus on the critical part visible in the client-side implementation–the Visitor ID.
-
Open the Luma site
-
Make sure the Debugger is mapping the tag property to your Development environment, as described in the earlier lesson
-
Go to the Network tab of the Debugger
-
Click Clear All Requests just to clean things up
-
Reload the Luma page, making sure that you see both the Target and Analytics requests in the Debugger
-
Reload the Luma page again
-
You should now see four requests in the Network tab of the Debugger—two for Target and two for Analytics
-
Look in the row labeled “Experience Cloud Visitor ID.” The IDs in every request by every solution should always be the same.
-
The IDs are unique per visitor, which you can confirm by asking a co-worker to repeat these steps.
Analytics for Target (A4T)
The Analytics for Target (A4T) integration allows you to leverage your Analytics data as the source for reporting metrics in Target.
The main requirements to implement A4T—which you have already done—are to:
- Implement the Adobe Experience Platform Identity Service
- Fire the Target page load request before the Analytics page view beacon
A4T works by stitching together a server-side request from Target to Analytics with the Analytics page view beacon, which we call “hit-stitching.” Hit-stitching requires that the Target request which delivers the activity (or increments a Target-based goal metric) have a parameter which matches a parameter in the Analytics page view beacon. This parameter is called the supplemental data id (SDIDs).
Validate the A4T Implementation
The best way to validate the A4T integration is to actually build a Target activity using A4T and validate the reporting data, however this is beyond the scope of this tutorial. This tutorial will show you how to confirm that the supplemental data ids match between the solution calls.
To validate the SDIDs
-
Open the Luma site
-
Make sure the Debugger is mapping the tag property to your Development environment, as described in the earlier lesson
-
Go to the Network tab of the Debugger
-
Click Clear All Requests just to clean things up
-
Reload the Luma page, making sure that you see both the Target and Analytics requests in the Debugger
-
Reload the Luma page again
-
You should now see four requests in the Network tab of the Debugger—two for Target and two for Analytics
-
Look in the row labeled “Supplemental Data ID.” The IDs from the first page load should match between Target and Analytics. The IDs from the second page load should also match, but be different from the first page load.
If you make additional Target requests in the scope of a page load (not including single-page apps) that are part of A4T activities, it’s good to give them unique names (not target-global-mbox) so that they will continue to have the same SDIDs of the initial Target and Analytics requests.
