Migrate your site’s Audience Manager implementation from client-side DIL to server-side forwarding migrating-your-site-s-aam-implementation-from-client-side-dil-to-server-side-forwarding

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.

Client-side (DIL) vs. server-side client-side-dil-vs-server-side

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:

Client-side DIL implementation client-side-dil-implementation

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.

Server-side forwarding implementation server-side-forwarding-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.

You have two main tasks you-have-two-main-tasks

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.

Implementation options implementation-options

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:

We’ll look at each of these below in the Updating the code section.

Implementation steps implementation-steps

The following steps describe the implementation.

Step 0: Prerequisite: Experience Cloud ID Service (ECID) step-prerequisite-experience-cloud-id-service-ecid

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.

Step 1: Record currently used options from DIL code step-record-currently-used-options-from-dil-code

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:

Step 2: Update the code step-updating-the-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.

Adobe Experience Platform tags launch-by-adobe

Watch the video below to learn about moving implementation options from client-side DIL code into server-side forwarding in Experience Platform Launch.

“On the page” or non-Adobe tag manager on-the-page-or-non-adobe-tag-manager

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.

Step 3: Enabling the forwarding (per Report Suite) step-enabling-the-forwarding-per-report-suite

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.

Timing timing

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.

A little deeper dive a-little-deeper-dive

The reason why timing and order matter is because of how forwarding really works, which can be summarized in the following few technical facts:

Best practices best-practices

Based on these technical details, here are the recommendations for the timing of what to do and when:

If you do NOT have ECID yet implemented if-you-do-not-have-ecid-yet-implemented

If you do have ECID implemented if-you-do-have-ecid-implemented

Migration timing when you have many sites and report suites migration-timing-when-you-have-many-sites-and-report-suites

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:

Validation and troubleshooting validation-and-troubleshooting

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.

For more information about server-side forwarding, please see the documentation.