Monday, May 21, 2018

Adobe Audience Manager Campaign Template

The most common use case for any DMP is campaign activation, where the DMP acts as the intermediary layer between the client's website or CRM system and the Demand Side Platform to share audiences across. In such cases, it's imperative that we have a very well defined process and structure to get these campaigns launched. 

My colleague and I created a simple, yet detailed template/checklist for documenting everything from business requirements to all the nitty gritty details required for successfully launching a campaign using Adobe Audience Manager. Below is a screenshot of the template. Please click the image to get an enlarged view.


The template is divided into three main categories and has a lot of different steps but I'm only going to cover the ones relevant for this post as the other ones are self-explanatory. Let's take a look at some of these categories in detail.

Business Requirements (5 Business Days)

This is the first and most important stage in the entire DMP->Campaign workflow. This involves everything from defining your goals to determining the granularity of your incoming media data. Let's dive into the details.

  • Key Business Objectives (KBOs): For any analysis project, product or campaign to be successful, business objectives or goals need to be defined before getting started. In case of campaigns, there are a lots of different factors involved such as strategy, budget, targeting platform and many others that are outside of the scope of this article. For a DMP, we'll stick to overall objectives and the marketing channels such as display, search, email, social, personalization etc) as well as others included in the template.
  • Key Performance Indicators (KPIs): Once we know the goals, we need to determine the KPIs that'll be used to measure success such as Clicks, Impressions, Click Through Rate (CTR) and other website/app success metrics. These KPIs are instrumental and should tie back to the goals.
  • Target Audience: We need to determine what kind of audience will be targeted for the campaign. It can be anyone between the ages of 18-35, male or female, tech professionals, government officials, income > 100K per annum, location etc. Again, it all has to tie back to back to the overall business objectives.
  • Duration and Dates: Some businesses are seasonal and others are not but there's never a bad time to bring in new customers. It's very important to know when the campaign will run and for how long as timing is everything. Knowing how long the campaign will run can help us estimate how much traffic we'll drive as well as gauge the critical mass to determine success.
  • Identify Destinations: This involves documenting which Demand side platforms will be used to run the campaign. Some examples of DSPs are Adobe Ad Cloud, DoubleClick Bid Manager etc. which already have a server to server (S2S) integration with Audience Manager. There are other platforms which may not have a S2S integration so we need to know what those are so in advance that we can determine the best approach to send data to them. Outside of S2S destinations, we can share AAM data via data exports, cookies and pixels.
  • Data to be Shared with DSPs: We need to identify what kind of data (1st or 3rd party) has to be shared with the DSP. For prospecting campaigns, a very common use case is to purchase 3rd party data from the Adobe Marketplace which is a platform that allows marketers to purchase new audiences from data providers such as Acxiom and Dun & Bradstreet. In other cases, a marketer may want to retarget their existing customers who exited the site before submitting a lead.
  • Data to be Brought into AAM: Every DSPs captures media data at a click and impression level at the very least so we need to determine how will that data be brought into AAM. Data can be brought into AAM either via pixels or by ingesting Ad Server logs. Recent changes around GDPR readiness will impact log ingestion for global companies with European customers so it's important to gauge your ingestion approach beforehand.
  • Define and Receive Media Taxonomy: Finally for the requirements phase, we need to define and lock down our general taxonomy to structure the data in AAM. The campaign owner needs to send over the campaign ID, site, placement etc. matrix. This involves determining the granularity of data required to bring into the DMP. As an example, if you only care about measuring data up to the site level, it may not make sense to capture data at a placement level as it'll be too granular and will result in wasted effort.

Setup and Launch (6-7 Business Days)

This stage involves the operational and technical setup within AAM to prepare for the campaign. This also involves communicating with the campaign owner to receive the campaign taxonomy matrix that contains campaign ID, site, placement etc. information that is used to build traits and segments in AAM. Let's take a deeper look.
  • Send AAM pixel documentation (If applicable): Based on the campaign matrix received from the campaign owner, the AAM consultant creates a pixel documentation and tailors it to match the taxonomy requirements. This involves defining both click and impression level pixels that will be setup in the DSP. Please note that this is not a required step if you're already ingesting Ad Server log files but will be required if you're planning to deploy media pixels.
  • Trait and Segment creation: This step involves creating AAM traits to capture track audiences (1st or 3rd party) for activation in the DSP as well as traits to capture media performance. Activation specific traits are tied directly to the target audience defined in the business requirements state and media performance traits are either tied directly to media pixels or conversion activity on the site. It's a good idea to create both kinds of traits. Once the traits are created, map them to segments as that is how data is shared with external partners. Please note that both traits and segments take about 24-48 hours to initially start populating data and are then populated daily so timing is everything.
  • Pixel validation and sign-off: The campaign owner sets up the pixels in the DSP and shares the pixels with Adobe for validation. The AAM consultant validates the pixels, monitors data in the traits and provides their feedback or sign-off.
  • Map Segments to Destination(s): Once the traits have been setup and validated, we map the segments over to the DSPs and destinations which will be used to run the campaign. It's critical to map the segments at least 3-5 days before campaign launch so that we have enough time to validate data flow and fix any issues with the integration.
  • Campaign Launch!

Post-Launch

Once the campaign has launched, we need to start our post-launch activities which revolve primarily around reporting. Let's take a look into what some of these steps entail.

  • Monitor data: This step involves monitoring media traits and segments right after launch to make sure we're capturing data as expected. The other reason why monitoring reports is important because AAM samples certain reports such as the Overlap report that requires a minimum threshold to populate so it's important to assess it early on. 
  • Audience and Overlap report analysis: The last step is to analyze campaign performance in the Audience Optimization and Overlap reports. The Audience Reports are helpful in gauging overall segment performance, volume, trends and optimal frequency. The overlap reports help in identifying high overlap (less reach) and less overlap (high reach) which can be helpful in both prospecting and finding our commonalties. Finally, it's important that you leverage other reports in the DSP and your Analytics tool along with AAM to get the complete picture.

This is a good starting template for documenting and tracking all campaigns being activated from AAM. It will continue to evolve and get better as we start using it for more campaigns and as we get feedback from clients. Currently, this template is in excel format and needs to be created separately for each campaign but at some point we'll probably move it to SharePoint or some other online tracking platform. Feel free to contact me if you need a copy of this template. Out of curiosity, how are you tracking campaigns for your business?

Sunday, May 6, 2018

Migrate legacy Adobe Visitor ID to Experience Cloud Visitor ID

The Adobe Experience Cloud ID Service (formerly known as the Marketing Cloud ID Service) has been around for more than three years now but there are some Adobe Analytics customers who are still on the legacy visitor tracking system. This post covers the various steps involved in migrating from a legacy Analytics tracking solution to the new Experience Cloud Visitor ID Service.

The Experience Cloud Visitor ID Service leverages a common and universal cookie identifier across all Adobe solutions that enables us to seamlessly integrate Adobe solutions with each other.


The Visitor ID service provides the following benefits:
  • As explained above, the ID service provides us with the benefit of seamlessly integrating all Adobe solutions which isn't easy to do with the legacy visitor tracking solution.
  • Visitor ID service enables the Adobe Experience Cloud Device Co-op which is a feature that allows subscribed customers to identify customers across devices and mobile apps. Device co-op also provides customers with the “People” metric that shows a deduplicated count of your users across multiple devices.
  • It enables Customer Attributes that allows customers to upload offline CRM data and tie it to online behavioral data.
  • Customers can leverage the latest video Heartbeat tracking that provides a lot of functionality to track media events across multiple video player formats.
  • It sets a first party cookie (AMCV) that is less susceptible to deletion. The legacy visitor tracking method (by default) sets a third party cookie that is more likely to be deleted by browsers, firewalls and ad blockers. This benefit may not apply to customers who leverage a CNAME as the tracking server where they set the cookie on their own domain.
  • It removes the need to get tracking servers migrated to a CNAME (E.g. metrics.companyname.com) which would otherwise require additional support from the network operations team. This benefit only applies to customers who are already on RDC (covered below).

Before we proceed, let's first take a look at the various cookies involved in this process. 
The following table shows which cookies & IDs come into play during the Visitor ID migration. Please click it to enlarge if you're unable to see it clearly.



Now that we've looked at the various cookies involved, let's go through the steps we need to follow to migrate to the new Visitor ID service.


Migrate Tracking Server to RDC

Visitor ID Service requires the tracking server to be migrated to RDC (Regional Data Collection) which is a network of data collection servers that are faster, safer and more reliable compared to the older data collection servers. RDC connects to the closest data center thereby reducing response times of image requests and incorporates load balancing to switch servers in case of a failure. 

The RDC domain is on "omtrdc.net" as opposed to the legacy "2o7.net" domain so it's always a good idea to check if you're already on RDC (omtrdc.net) or 2o7.net. The steps outlined in this Adobe article shows you how to check if your tracking server is on RDC or not.


If you're on the legacy 2o7.net domain then you will have to switch your tracking server entirely or if there are other domain change scenarios involved in your case, then follow the steps outline in this Adobe article to proceed.


If you're already on CNAME pointing to 207.net legacy servers and don't plan to change your tracking server, then you will follow the following steps:

  • Contact Adobe client care to request a migration to RDC by providing them with your existing CNAME based 2o7.net secure and non-secure tracking server names.
  • Customer services provides you with the new RDC tracking server hostnames which will end with omtrdc.net.
  • Contact your network operations team to redirect your CNAME tracking servers to now point to the new RDC (omtrdc.net) domain.
  • Finally, test your tracking servers by pinging them and validating if they're redirecting to the omtrdc.net domain as described in this article.

Setup Grace Period

A grace period typically setup for 30/60/90 days is put in place when customers want to continue leveraging the legacy analytics s_vi cookie in place of the new AMCV cookie set by the Visitor ID service. This is most commonly put in place if certain areas of the website have an older code version that cannot upgrade to the Visitor ID service and the implementation is leveraging a global report suite. The reason why it's necessary to put a grace period in place so that we don't see visitor "cliffing" or inflation in visitor & visit counts. That's because the Visitor ID service leverages a new cookie to track visitors and will probably count a repeat visitor as a new visitor. A grace period can also be setup for a company that wants to avoid visitor "cliffing" as they prepare to factor in the eventual visitor & visit inflation. 

To request a grace period, contact the Adobe client care team and provide them with the following information:
  • Experience Cloud or IMS Org ID
  • Company Name
  • Data Center
  • Date to start Grace Period
  • Grace Period Length (Up to 180 days but can be extended)

Setup Visitor ID Service

Once a grace period has been put in place by client care, work with your IT team to setup the Visitor ID service. Here's an example from the Launch by Adobe Tag Management tool to show the Visitor ID service extension. Notice that the we have to put in the Experience Cloud Org ID and populate the secure and regular tracking server fields (highlighted in Red) to setup the Visitor ID service which is required to get grace period to work and for the 'aid' parameter to appear.


Once the ID service is setup, you will start to see the new first party AMCV cookie and third party demdex cookie appear in your browser instead of the legacy s_vi cookie. However during a grace period, the s_vi continues to be set and is populated in the AMCV cookie to avoid visitor & visit inflation. Below is a visual that explains how cookies are set during a grace period.

Source: Adobe Blog

Validate

The next step is to validate the grace period. This is done by checking if the "AID" and "MID" parameters appear in the Analytics image request. The "AID" will contain the Visitor ID value from the s_vi cookie and will continue to be set till the grace period is active. This screenshot shows what the image request during a grace period looks like.



Prepare for the Inevitable

Finally, the most important step is for you to internally prepare your organization for this change as it's a revamped methodology to track visitors and at some point, you will have to confront the reality of visitor inflation when the grace period is turned off. Please note that this visitor "cliffing" will ONLY impact repeat visitors as new visitors will automatically get the new AMCV cookie. 

It might be a good idea to estimate how much impact this change will have on your visitors & visits based on your repeat visitors. If you're on the grace period for 180 days and turn it off after that, what % of your repeat visitors come back to your site or app after 6 months. This number will vary based on the kind of business you're in so all in all, you need to weigh the pros and cons and determine when you want to take the plunge.


So, that was it! If you're already on the Visitor ID service and don't have to deal with any of these outlined steps, then Congratulations. If not, then I'd highly encourage you to give a serious thought to proceeding with it as it will be worth it if you're an Adobe Experience Cloud customer.  

Saturday, May 5, 2018

Launch by Adobe iFrame Page

Test Post to host AMP page Launch library

Test page created to host Launch by Adobe library for AMP.