This tutorial applies to you if you have both Adobe Audience Manager (AAM) and Adobe Analytics, and you are currently sending a hit from the page to AAM using DIL (Data Integration Library) code, and also sending a hit from the page to Adobe Analytics. Since you have both of these solutions, and since they are both part of the Adobe Experience Cloud, you have the opportunity to follow the best practice of turning on server-side forwarding, which enables the Analytics data collection servers to forward site analytics data in real time to Audience Manager, instead of having client-side code send an additional hit from the page to AAM. This tutorial walks you through the steps of making the switch from the older client-side DIL implementation to the newer server-side forwarding method.
When comparing and contrasting these two methods of getting Adobe Analytics data into AAM, it might first be helpful to visualize the differences in the following image:
If you use this method to get Adobe Analytics data into AAM, you have two hits coming from your Web pages: One going to Analytics, and one going to AAM (after having copied the Analytics data on the Web page. Segments are returned from AAM to the page, where they can be used for personalization, and so on. This is considered a legacy implementation and is no longer recommended.
Beyond the fact that this is not following best practices, the disadvantages of using this method include:
It is recommended that you move to a server-side forwarding method of AAM implementation.
As shown in the image above, a hit comes from the Web page to Adobe Analytics. Analytics then forwards that data to AAM in real time, and visitors are evaluated into AAM traits and segments, just as if the hit had come directly from the page.
Segments are returned on the same real-time hit back to Analytics, which forwards the response on to the Web page for personalization, and so on.
There is no timing downside to moving to Server-Side Forwarding. Adobe highly recommends that anyone who has both Audience Manager and Analytics uses this implementation method.
There is quite a bit of info on this page, and it is all important, of course. However, it all boils down to two main things that you need to do:
If you skip either of these tasks, server-side forwarding will not work correctly. Steps and additional data have been added to this document to help you do these two steps correctly for your setup.
As you move from client-side to server-side forwarding, one of the tasks you will have is changing the code to the new server-side forwarding code. This is done using one of the following options:
doPluginsfunction inside of your
appMeasurement.jsfile, if you are not (yet) using Adobe Launch
doPlugins, wherever the other tag manager is storing the AppMeasurement code
We’ll look at each of these below in the Updating the code section.
The following steps describe the implementation.
The main prerequisite for moving to server-side forwarding is to have the Experience Cloud ID Service implemented. This is most easily done if you are using Experience Platform Launch, in which case you simply install the ECID extension and it will do the rest.
If you are using a non-Adobe TMS, or no TMS at all, then please implement ECID to run before any other Adobe solutions. See the ECID documentation for more details. The only other prerequisite is regarding code versions, so as you simply apply the most recent versions of the code in the following steps, you will be fine.
Please read this entire document before implementing. The “Timing” section below has important information on when you should implement each piece, including ECID (if it is not yet implemented).
As you get ready to move from client-side DIL code to server-side forwarding, the first step is to identify everything that you are doing with DIL code, including custom settings and data sent to AAM. Things to notice and consider include:
siteCatalyst.initDIL module - You do not need to worry about this one, because its job is just to send the normal Analytics variables over, and that happens by virtue of simply having server-side forwarding enabled.
DIL.createfunction, make a note of the
partnerparameter. This is known as your “partner subdomain,” or sometimes “partner ID,” and will be needed when you place the new server-side forwarding code.
In Implementation options (above), multiple options are given regarding how and where you are implementing server-side forwarding. In order for this section to be effective, we need to break it out into these sections (with two of them combined). Go to the method of this section that best describes your needs.
Watch the video below to learn about moving implementation options from client-side DIL code into server-side forwarding in Experience Platform Launch.
Watch the video below to learn about moving implementation options from client-side DIL code into server-side forwarding in AppMeasurement code, residing either in a file or in a non-Adobe tag management system.
So far in this tutorial we have spent all our time on switching the code from client-side DIL code to server-side forwarding. That is fine, because it is the more difficult part. This section, although you will see is super easy, is just as important as updating the code. In this video, you will see how to flip the switch that enables the actual forwarding of data from Analytics to Audience Manager.
NOTE: As stated in the video, remember that it will take up to 4 hours for the enablement of forwarding to be fully implemented on the Experience Cloud backend.
As a reminder, there are two main tasks for moving over from client-side DIL to server-side forwarding:
But the question is, which one do you do first? Does it matter? OK, sorry, that was two questions. But the answers are… it depends, and yes, it can matter. How’s that for vague? Let’s break it down. But first an additional question that can come up if you are a large organization with numerous sites: Do I have to do everything at once? That one is a little easier. Nope. You can do it piece by piece.
The reason why timing and order matter is because of how forwarding really works, which can be summarized in the following few technical facts:
Based on these technical details, here are the recommendations for the timing of what to do and when:
Flip the switch in Analytics for each report suite that you will enable for server-side forwarding.
Per site, update your code from client-side DIL to server-side forwarding (this could be in Platform tags) or on the page, as discussed in another section above).
Prepare and plan so that you are ready to update your code from DIL to server-side forwarding PER report suite that you will enable for server-side forwarding:
Flip the switch in Analytics to enable server-side forwarding.
As soon as possible, update your code from client-side DIL to single-side forwarding (this could be in Platform tags or on the page, as discussed in another section above).
It is important to do these two steps as close to each other as possible, because between steps 1 and 2 above, you will have duplication of data going into AAM. In other words, single-side forwarding will have started sending data from Analytics to AAM, and since DIL code is still on the page, there will also be a hit going directly from the page into AAM, thus doubling the data. As soon as you update the code from DIL to server-side forwarding, this will be alleviated.
If you would rather have a small discrepancy in data rather than a small duplication of data, you can switch the order of steps 1 and 2 above. Moving the code from DIL to server-side forwarding would stop the data flow into AAM until you were able to flip the switch to turn on the server-side forwarding for the report suite. Typically customers would rather have a small doubling of data rather than miss getting visitors into traits and segments.
This topic is briefly touched on in previous sections, in that the main strategy can be summarized by the following:
Migrate one site/report suite (or group of sites/report suites) at a time.
However, this can get a bit tricky based on a few possible scenarios:
Because of these items, it can get a bit complicated. The best things I can suggest are:
The main way to validate that the server-side forwarding is up and running is by looking at the response to any of your Adobe Analytics hits coming from the app.
If you are not doing server-side forwarding of data from Analytics to Audience Manager, then there is really no response to the Analytics beacon (besides a 2x2 pixel). However, if you are doing server-side forwarding, then there are items that you can verify in the Analytics request and response that will let you know that Analytics is communicating correctly with Audience Manager, forwarding the hit, and getting a response.
Beware the false “Success.” If there is a response, and everything seems to be working, ensure that you have the
stuff object in the response. If you don’t, you may see a message that says
"status":"SUCCESS". As crazy as this sounds, this is actually proof that it is NOT working correctly.
If you see this, it means that you have completed the code update in Platform tags or AppMeasurement, but that the forwarding in the Analytics Admin Console has not yet completed. In this case you need to verify that you have enabled server-side forwarding in the Analytics Admin Console for your report suite. If you have, and it hasn’t been 4 hours yet, be patient, as it can take that long to make all the necessary changes on the backend.
For more information about server-side forwarding, please see the documentation.