Saturday, August 25, 2018

3rd Party Pixel Implementation in Launch by Adobe

Launch by Adobe is gaining a lot of popularity among clients who are either migrating from Dynamic Tag Management or from a different Tag Management system. I've already helped a few clients migrate to Launch and have experienced how robust this TMS is especially in terms of managing the firing of Adobe specific tags and other 3rd party scripts. A 3rd party script or tag is a snippet of code that is deployed either on marketing landing pages or purchase funnels to attribute marketing campaigns to conversion activities.

Launch has a lot of 3rd party tags (see example below) that are supported as extensions which can be deployed via a user friendly UI and the list is ever growing but there will always be a need to deploy 3rd party tags that won't be available in the catalog. 

As an example, below is a screenshot from the Adobe Advertising Cloud extension UI that makes it very easy to deploy this pixel without writing any custom JavaScript.

This post shows how to deploy a 3rd party tag called PepperJam not yet added to Launch and covers the various steps needed to to get it done successfully. Let's take a look.

  • Evaluate 3rd Party Tag Deployment Documentation: Typically, you will get a tag deployment/requirement documentation from your vendor. Once you get the 3rd party tag documentation from the agency or vendor, make sure to go through it to understand the JavaScript snippet, where the tag needs to fire, what attributes need to be passed and how to test the snippet. These are some of the key questions required that need to be answered before deploying any 3rd party tag.

  • Capture all relevant Meta Data using Data Elements: In this case, the vendor requires us to capture the currency code, order total, order ID and a query string parameter called "clickid" that needs to be persisted for the visitor. In the next two screenshots, we create two data elements. The first data element captures the order total by tying directly to a data layer/JSON attribute on the page called dataLayer.orderTotal. The second data layer captures a query string parameter called "clickid" that needs to be persisted for the visitor and we've used the "Visitor" duration. This post covers persistence in Launch in more detail.

  • Create a Rule: The first step in a Launch rule is to create an event. In this case, our event is page load and we're going to choose "DOM Ready" to fire this event. DOM ready is an event which is executed when the document object model has loaded. The next step is to choose a condition. In our case, we want to fire the pixel on a page called activewear.html. You can validate the condition by putting in the URI in the Regular Expression Tester as shown below. 

  • Implement the PepperJam Pixel: The last step in the pixel implementation process is to add an action within the existing rule. We do that by clicking on "Open Editor" and pasting the JavaScript snippet provided by the vendor. Take note of the two highlighted data elements in the screenshot from the code snippet which have been manually added to the pixel to pass additional meta data.

  • Validate the PepperJam Pixel: The final step is to validate the pixel in a browser. As per the first screenshot below, we can see that additional attributes (meta data) such as amount and Click ID are populating based on the data elements tied to the data layer and query string parameter respectively. The second screenshot shows that the Click ID is still populated even if the clickid query parameter is not populated in the URL as we created a Visitor based data element.

Hope you found this post useful. Is there a 3rd party pixel that you've deployed in Launch that isn't supported via an extension yet?

Sunday, August 12, 2018

LiveRamp and Audience Manager Integration

Digital marketers since the onset, have strived to deliver personalized and targeted content to users. That coupled with knowing where users are in the purchase funnel and showing tailored content across multiple devices and channels is what makes their experience truly omni-channel. There's another term coined for this type marketing and it's called People-based marketing. So, how is it all accomplished? 

The following visual shows the various steps involved in delivering a truly unified experience to users across multiple channels and devices. One of the steps we'll cover as part of this post is to do a deep dive on the process of data on boarding.

Data on boarding (step 2) is the process of taking in customer's offline personally identifiable information (PII) and anonymizing it to make it available for online digital marketing efforts. Companies such as LiveRamp specialize in ingesting PII and device/cookie data from various sources and sharing it with Data Management Platforms for further activation. Typically, clients who are unable to connect their customer's hashed profile ID upon authentication with AAM (natural match) leverage LiveRamp but other customers leverage data onboarding as well. Let's dive into how data is shared between LiveRamp and Adobe Audience Manager:

LiveRamp to Adobe Audience Manager

Clients have often asked me how does LiveRamp send data to AAM and how is LiveRamp able to take PII data and anonymize it. At a high level, customers share their CRM data such as email address with LiveRamp which is translated into cookies and device IDs. For AAM, that cookie is the third party UUID that LiveRamp maintains a match table with and provides a batch file that's uploaded to AAM thereby enabling activation in the DMP.

Let's take a look at the various steps involved in bringing LiveRamp data in AAM.
  • Create 3 Data Sources: The first step to create three data sources for taking in LiveRamp data from cookies, iOS IDFA and Android Google IDs. The iOS and Android data sources are created in a similar way and the Cookie data source is created slightly differently as shown below. Please note that these data sources are only created once and can be replicated for all future file based on boarding.

  • Create 3 On Boarded Traits: The next step is to create on boarded traits in AAM based on the 10 digit numeric integration code (ic) provided by LiveRamp for each uploaded (file) set of cookies & device IDs. Please note that for each upload or data point, we are supposed to use the same integration code to create these traits. The following screenshot shows an example of a trait that's created to tie uploaded Android device Id data from LiveRamp to AAM. Make sure to create three flavors of these traits tied to each data source (iOS, Android and Cookies).

  • LiveRamp to upload data to AAM (S3 or FTP): Once all the relevant data sources (can be reused) and onboarded traits are created, the LiveRamp contact will push UUIDs or device IDs to AAM via a batch file process.
  • Monitor Onboarding Status Report: The last step is to monitor the Onboarding Status report and onboarded traits in AAM to validate if the LiveRamp uploads are setup correctly.

Finally, once data has been successfully onboarded from LiveRamp, you can map these traits into segments and then to various AAM destinations for marketing activation.

Audience Manager to LiveRamp

Almost all scenarios involving LiveRamp deal with data being onboarded to a DMP, but there is a way to send Audience Manager segments back to LiveRamp as well. That is made possible with the Server to Server (S2S) integration that AAM has with LiveRamp where UUIDs and mobile IDs are sent back to LiveRamp. A use case for that is propensity modeling where customers take in "enriched" audiences originally shared from LiveRamp to AAM back into their CRM system for further optimization and enrichment. 

To summarize, we covered what role LiveRamp plays in anonymizing customer's PII data, how that data is shared with activation platforms and how it flows back into the CRM for further enrichment. I would like to hear about how you're leveraging data on boarded to a DMP back into your own CRM system.