Wednesday, October 31, 2018

Adobe Experience Platform SDK Setup (iOS)

There were 178 billion apps (statista) downloaded in 2017. With that amount of volume, it'll be unthinkable for any major organization today to not have a mobile app that allows existing and potential customers to interact with its brand. Most Apps regardless of their purpose have some kind of analytics tracking embedded in them and one of the tracking solutions they leverage is Adobe Analytics.

Adobe Experience Platform SDK (informally known as SDK V5.0) was recently launched and it aims to give clients more flexibility around mobile SDK deployment as it leverages Launch by Adobe to publish changes in an external environment outside of the native app. This was not the case with the previous version v4 of the SDK. The reason why that's exciting is because any configuration changes to the SDK around Analytics can now be done in Launch without having to go through the App Store. There are other differences between the two versions which is covered in more detail here.

There are two primary methods to setup the AEP SDK which are either using CocoaPods or the manual method but in this post, I'll cover how to set this up manually. A lot more information is provided in the Mobile team's official documentation but my aim is to take their instructions and document it visually using my sandbox. I'm covering two main components of this setup which leverage Launch by Adobe and XCode (V10) to setup the SDK.



Launch by Adobe Setup


This is a big enhancement of this SDK over V4.0 where we're now able to deploy the configuration library using Launch by Adobe as opposed to the ADBMobile.json config file that we have with V4.0. The primary advantage of this is that we're able to make basic configuration changes such as changing report suites, enabling/disabling tags, activating the Experience Cloud ID service etc. directly in Launch without having to go through the App Store. There will obviously be a need to publish the app at the start to the App Store to submit the app. Please note that we currently cannot setup any trackAction (clicks) or trackState (page views) calls in Launch and need to do that directly in the App so that does require us to to go through the App Store for each change. Let's go through the steps.
  • Create a mobile property in Launch and select the platform as Mobile.


  • We then setup extensions in Launch and by default, you should see two extensions already added called "Mobile Core" and "Profile" which are explained below. I'm not going to cover these in detail as we only need to add some basic details to the Mobile Core extension. Additionally, we also need to add the Adobe Analytics from the Catalog and install it. Let's review these extensions.
    • Mobile Core: This provides essential SDK related functionality as well as the library to deploy the Experience Visitor ID service
    • Profile: It stores user attributes on the client and more details can be found here
    • Adobe Analytics: It provides the Adobe Analytics library to the SDK. 

Add your tracking server

Add your report suite and tracking server
  • Once we've installed the extensions, we need to retrieve the iOS libraries that are accessible in the Environments section in Launch. This snippet contains a reference to libraries that need to be included in XCode to deploy the SDK (see below). 

  • Finally, we need to publish these extensions to either the development or production environment depending on the scenario. Note that you can also disable Analytics tags from the App by publishing it in Launch if required.

XCode Setup


Before diving in, I highly recommend that you review the steps outlined in Adobe's official documentation on configuring the SDK. Some of what I'll cover is outlined in the documentation but I'm including a lot more detail in the form of screenshots from XCode which the documentation doesn't include. So, let's continue.


  • Download XCode and setup a basic App which allows you to simulate an iOS App experience.


  • Download the AEP iOS SDK from Adobe Experience Platform's Github branch located here.


  • The downloaded zip contains a bunch of files and folders but the one we need to use is called "iOS" which contains two sub folders called "device-only" and "universal". 

  • The "iOS" folder needs to be added to XCode and mapped to the Target in XCode. Once the mapping is done, we need to add some frameworks to the "Embedded Libraries" section in XCode to provide the necessary libraries to the SDK. Please note that for an actual iOS Apps, you need to use the frameworks present in "device-only" but for Simulators (my use case), you need to use the frameworks present in the "universal" folder. I've tried to color code the relevant details in this screenshot.

  • Once the required frameworks are added, we need to reference all libraries and call specific methods to activate lifecycle calls, enable logging and other methods as explained here. I'm using Objective C but the documentation covers Swift and Android syntax as well. Please note that I copied the installation code directly from the Environments section in Launch (covered above) and included it in XCode which ties the SDK with Launch. I've included these methods in the AppDelegate.m file of my App. The integration with Launch is done via the configureWithAppID call to which we pass the Launch App/Environment ID.


  • Once the basic lifecycle tracking methods are added, we can add a trackState (page view) method call to trigger an event. I'm basically sending data to the "screenName" variable populated with a value of "homeview". That is typically done in the ViewController.m file.

  • Finally, we need to make sure that the App build is successful and test the Analytics call. In my case, I'm looking for the variable called "screenName" which is populating in the debugging console as shown below.

The Adobe Experience Platform SDK is still relatively new and is being evolved but the process of installing the SDK is fairly easy once you get through the initial learning curve. I will continue to keep track of all upcoming features and will write about other functionalities tied to Launch by Adobe to trigger different types of mobile events.

Sunday, October 14, 2018

Adobe Audience Manager Email Pixel ID Sync

I wrote about email marketing back in 2009, and it's still very relevant and effective in 2018. According to this recent (2016) article, "users of email marketing systems are achieving $38 in ROI for every $1 spent". Almost all my clients do some kind of email marketing to send email newsletters to either existing or potential customers. Some of these clients leverage a Data Management Platform to connect data from multiple sources and email is one of the most common choices.

From an Audience Manager perspective, a very useful data point for clients is to capture custom email attributes upon impression or click and user IDs to sync them with AAM for cross device targeting. This post covers the various steps to capture email data in AAM.

  • Configure the Email Pixel: The general format of the email pixel is very similar to display banner pixels with some minor differences. Below is a screenshot of an email pixel as well as a walkthrough of the various parameters.

(Subdomain).demdex.net/event?d_event=imp&d_cid=(DataSourceID)%01(HashedEmailID)%011&c_emailopen=true&c_campaignname=thanksgiving2018
    • Subdomain: This is the Audience Manager subdomain. In my example, it's "ags542" as per the screenshot. 
    • d_event: This is the event type which can either be 'imp' (impression) or 'click'  depending on where you want to capture this event.
    • d_cid: This parameter allows us to sync a user ID with AAM.
    • DataSourceID: This is the data source ID created for this data point. It's '133374' in my case and I've covered this in detail below. 
    • HashedEmailID: It's 'ABC789' as per the example but it can be any numeric or alphanumeric ID for ID syncing purposes.
    • c_emailopen and c_campaignname: You can pass any customer specific parameters (c_) which in my case are outlined in the screenshot. Note that we will need to create rule based traits to capture these parameters.

  • Create Data Source to Capture User IDs: Given that we will be syncing user data with AAM, we need to create a cross device data source as shown below.


  • Create Rule Based Traits: The next step is to create rule based tied to custom attributes that you want to capture for the email pixel. In my case, they are c_emailopen and c_campaignname. Below is what one of these customer specific traits look like.

  • Deploy the Pixel in the Email Marketing Software: As explained above, once you've completed the prerequisites of setting up the data source and the necessary traits, you can go ahead and setup the pixels in your EMS. Please make sure that there are no extra spaces and the pixel should look very similar to this example where you need to include the additional "%01" and "%011" characters to follow the ID sync conventions. https://ags542.demdex.net/event?d_event=imp&d_cid=133374%01ABC789%011&c_emailopen=yes&c_campaign=ags542_test. 

  • Monitor Audience Traits: This process is often not known to everyone but there is an easy way to test if user IDs synced as part of the email pixel, made it into AAM. This can be done by going to the Audience Traits folder and clicking into the ID sync trait created for email as shown below.


  • Upload CRM Files (if applicable): One interesting use case of syncing user IDs with AAM is to upload demographic or other customer data from the CRM. The process is the same for uploading files in AAM and I've covered it in detail here. 

Email marketing is not going anywhere and with a minimum amount of effort, we're able to ID sync users with the DMP. It is a great alternative to ID sync users if you're unable to capture user IDs upon authentication. So, are you capturing email marketing data in AAM and ID syncing your users?

Sunday, September 30, 2018

Adobe Analytics Reporting Issues and Tips

It's been a while since I've been a full time analyst but I do get to dabble in data in my current role as Technical Consultant. This post covers some of the reporting/segmentation challenges I've faced with Adobe Analytics and some tricks I've learnt in my role. My primary purpose of writing this post is to share it with other technically focussed users and capture it for my own documentation. Let's get started!

  • Cardinality Issue: One issue that has caused me some strife is the Unique Exceeded issue where only the top 500,000 rows for a particular month are shown. This happens when cardinality for a particular dimension (E.g. Page URL) is very high and Analytics outputs a string called "Low Traffic" as shown below where it's the most popular data point. This means that any segments leveraging Page URL will not show accurate results as only the top 500,000 values are shown in the UI.
    • How to Address the issue: I can think of 2 solutions to tackle this issue:
      • Add Dimensions with Low Cardinality: In your implementation, define a unique page name or sub sections for a combination of URLs and capture query string in a separate variable to keep the URL clean. Basically, look at alternative dimensions that have a low cardinality.
      • Leverage DataWarehouse: DataWarehouse (shown below) allows you to export more than 500K rows so you can essentially, export as many rows and then filter the data offline.

  • Single Page App Issue: In a recent client scenario, we had a situation where they had a Single Page App (SPA) built using AJAX and the UI experience changed but the page didn't refresh. These experiences often times leverage callback functions which developers can configure so that we can fire off "artificial" page views even if the page doesn't reload. 
    • Issue: My client wanted to see how many users landed on the SPA experience when the "cmpid" URL query parameter was present. They populated an Analytics event tied to this query string but saw a very high number of instances which exceeded the actual page views on this landing page. The issue was tied to the fact that the Analytics URL (highlighted in Red) did not get updated when in fact, the SPA URL changed (highlighted in Green) for additional steps in the flow. Given that the Analytics URL is used to evaluate if the query string is present, the instances of the event kept getting inflated despite the fact that "cmpid" was not present anymore.

    • Solution: The solution was to update the Analytics URL by overriding the s.pageURL (Analytics URL variable) with document.URL using JavaScript. This allowed us to ONLY track events when "cmpid" was populated.

  • Visitor Stitching Segment: A very common use case for enterprise clients is to stitch visitors across mobile app and mobile web where they want to attribute downstream events to visitors coming from a mobile app to a mobile web view. An example is a conversion funnel that is embedded in a native app where there is a mix of native app screens and web specific HTML or AMP pages. It will make sense to define a unique variable to differentiate between mobile app and mobile web and use that in a segment as shown below.

  • Sequential Segmentation: Sequential segments are explained very well here and I highly recommend you read this but my example is much simpler and deals with a recent question I got from a client.
    • Question: How many people stayed on the "about-us" page for at least 2 minutes and then clicked on the "visit-homepage" link?
    • Answer: The answer is a simple sequential segment which did take me a few tries and it's shown below:

  • Exclude Segments Work Well: I've used exclusion segments quite extensively to remove users tied to a particular dimension or event. I've also used exclusion as an option to create "inverse" segments to test my results. Below is a simple example of an Exclude segment that worked really well for me recently where I had to exclude visits who spent less than 15 seconds on a page:

  • Finally, a Segmentation Container Primer: I'll wrap up by covering a simple yet confusing concept of segment container which has often stumped me. It's the general difference between the various segment containers (namely Visits, Visitors and Hit) and when to use these. In the following screenshots, we see how each container affects the underlying data.
    • Hit Container: This container when applied, yields the fewest page views and instances as it confines the data to the actual hit level. The requirement for this container to work is for the variable to be set in the image request. It will show the lowest number of page views or instances.
      • Use Cases: Apply this when you want to get the most accurate results for a particular dimension or event. E.g. You can use this container if you want to get actual page views or video views for a particular time frame or search term. You should also use Hit level segments to create Virtual report suites.

    • Visit Container: This container shows data for a particular visit where something happened without a gap or timeout of 30 minutes. The will show page views or instances that are more than that of a 'Hit' container and less than that of a 'Visitor' container.
      • Use Cases: If you're looking to analyze user behavior that can only happen within the same visit such as Bounces, Click on a Call to Action on the Homepage, Landing page Visits tied to a marketing campaign etc.          

    • Visitor Container: This container will show data tied to a Visitor cookie (typically 2 years) and will show all page views and instances for the lifetime of the Visitor. This will show the most number of page views or instances as the scope of this is the biggest among the three containers.
      • Use Cases: If you're looking to find out total revenue captured across all visitors or to see how many visitors traversed from a mobile app to a mobile web view.

I hope these tips will help you answer some simple, yet confusing concepts that often requires additional investigation and can lead to unforeseen delays. 

Saturday, September 15, 2018

Adobe Audience Manager Billing Overview


Every paid digital analytics tool and platform in the market has a structured revenue model and Adobe Audience Manager is no different. Audience Manager's revenue model is essentially based on the number of records ingested and the cost clients pay is tied to usage. Similar to AAM, Adobe Analytics is another platform whose revenue model is based on usage. Here's a link to some documentation that shows how Adobe Analytics reports its server calls which has now been updated to a visual format embedded within in the Analytics UI. 

Audience Manager currently doesn't display client server call data in the AAM UI and is often a common complaint that clients have so this is my attempt to fill some of that gap through this post. Let's dive into the details!



Types of AAM Server Calls


AAM server calls are divided into four types of activities as outlined below:
  • Onsite Server Calls: As the name suggests, these are Audience manager server calls captured either on mobile apps and websites. Essentially all page views and clicks are captured as server calls so any hit that's considered a server call by Analytics is considered an AAM server call if data is forwarded is enabled. These server calls are captured whether a site/app has a client side Data Integration Library (DIL) or Server Side Forwarding (SSF) AAM implementation.
  • Pixel Calls: This is data collected from ad or email impression/click calls made to Audience Manager. An example of how this is captured is outlined here.
  • Ingested Log File Records: This type of server call is incurred when you ingest ad server log files in AAM that populate the Audience Optimization Reports (AOR). The way clients typically get these enabled is by leveraging Actionable Log Files (ALF).
  • On-boarded Records: These server calls are incurred based on records ingested from CRM or an offline data file (e.g. call center, customer demographic data etc).

How to Avoid Extra AAM Server Calls

Recently, I came across a scenario where my client burnt through ~75% of their AAM server calls allocated for a year in the first 5 months. One of the reasons for that was the lack of understanding and visibility of what their server call usage was by activity. Given that majority of their server calls were exhausted early, they had to turn off data collection in the DMP for some time. Below are some easy steps to avoid exhausting server calls earlier than anticipated:


  • Monitor Server Calls Regularly: "Prevention is better than cure" is one quote that comes to my mind to explain this point. I cannot stress how important it is to proactively monitor your server call usage to avoid a scenario similar to what our client faced. Your AAM consultant should be able to pull server call data for you so it might make sense to ask your consultant to schedule a monthly pull of your server calls to avoid any surprises.
  • Collect Onsite Server Calls Only Via One Method: There are two main methods of AAM onsite data collection which are client side DIL and Server Side Forwarding. It's recommended to forward Analytics data to AAM using either client side DIL OR SSF to avoid being charged twice for onsite activities. My preference is the SSF method as it forwards Analytics data to AAM using one call.
    Last year, a change was added to SSF Adobe Analytics data to AAM using Analytics report suites. This method allows clients to selectively forward data ONLY to those report suites whose data you want to forward to AAM. Previously, data for all report suites used to be forwarded over to AAM. Below are screenshots of how Analytics data is forwarded now and how it used to be forwarded before. 
Latest method of selectively forwarding Analytics data to AAM.

This method used to forward data for all report suites to AAM. It's advisable to turn it off even though the new method takes precedence and it can only be done by your AAM or AA consultant.

  • Collect Media Data Either Via Pixels or Logs: Campaign media data collection is another area which can contribute to server call inflation if not done correctly. Last year, the AAM product team introduced Actionable log files (link above) which is a programmatic way to ingest DCM logs and create audience traits without deploying pixels. This method is widely used across AAM to ingest DCM log data for Non-EU markets. The other method is to manually deploy media pixels to capture impression or click level data.
    It's highly advisable to capture media data using ONLY one of these methods to avoid being charged twice.


Finally, What Do I Want to See Added?

Given that one of my client has called AAM billing a black box, I'd like to see the following items added to the AAM UI and billing reports:

  • Display Server Calls in the AAM UI: Like Adobe Analytics, I'd like to see Audience Manager server calls being displayed in the AAM UI so that clients can regularly monitor AAM server calls themselves and make necessary adjustments.
  • Add Report Suite Breakdown in AAM Billing: I don't believe there's a way to see a drill down by report suite ID so I'd like to see that level of granularity added to AAM onsite server calls even though clients now have the ability to control that.

Hopefully this post provides you a general understanding of how AAM server calls are categorized and how to be better prepared moving forward.

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.

Sunday, July 29, 2018

Adobe Analytics and Audience Manager Data Sharing Scenarios

Recently, I wrote a post about Audience Library which was about data/segment sharing within the Experience Cloud. A similar question came up while working with a client and colleague around the type of data that can be shared between Audience Manager to Analytics and vice versa. That gave me an idea to write about it and share my insights on what kinds of use cases can be met by sharing data between these solutions.

I'm going to cover three different scenarios in which data can be shared between Analytics and Audience Manager and the use cases that go along with it and will be using the Hedge Trimmer garden tool as an example. So, let's get started!


Analytics to Audience Manager (Batch)

This is the easiest way to share segments from Analytics to Audience Manager as this integration is available for any customer subscribed to People Core services. We do that by clicking on the checkbox as shown below but there is a cap of 20 segments that can be shared by this method. To share Analytics segments with AAM and the Experience Cloud, click on the checkbox as shown in the screenshot below and it takes about 24-48 hours for it to show up in AAM. The other thing to note is that you don't require a technical integration between Analytics and AAM as this method automatically shares segments but I highly recommend setting up the integration using either of these methods.

Below are some analysis use cases that can be satisfied using this method of sharing.

  • Complicated Segments that Cannot be Easily Created in Audience Manager: A very common scenario I've seen with clients is to share any Analytics segment by default that they can easily create in AAM such as traffic to a particular page. However, it makes more sense to ONLY share segments that cannot be easily created in Audience Manager. An example is Revenue which is not readily available as a metric in AAM but it is available in Analytics. In the example below, we've created a segment that is tied to users who spent $30 or more on Hedge Trimmers and shared it with AAM by clicking the checkbox. 

  • Technical Analytics->AAM integration is Not Set Up: The other use case where you may want to share Analytics segments to AAM is when either the client side or Server side forwarding integration is not setup between these two solutions. A few clients in the early stages of Audience Manager implementation or during a POC may want to leverage this feature to start sharing segments with Demand Side Platforms for marketing purposes.

  • Need to Send Historical Audiences before Technical Integration: The final use case is prevalent when clients want to send audiences from the last 3 months to DSPs for a media campaign but their technical integration is only 7 days old and don't have enough data. That's where we can leverage this segment sharing feature. 

Analytics to Audience Manager (Real-Time)

This is the most common and recommended method to share segments between Adobe Analytics and AAM and it requires either a client side or server side integration of Analytics with AAM. The advantage of this integration is that this data is collected in real-time and rule-based traits created with this data can be mapped to a segment and activated on immediately. Below are some classic use cases that are executed using rule-based traits.
  • Retargeting: Site analytics data captured in AAM can be leveraged for retargeting use cases. The example below is a rule-based trait that is created to retarget potential hedge trimmer customers who viewed the product but did not purchase yet.

  • Personalization: Another very common use case is personalization where site analytics data can be leveraged and segments sent over to Adobe Target to show contextual content to users. An example of this can be showing a page customized for garden tools to visitors who are actively shopping for Hedge trimmers.

  • Conversion: We can measure conversion by creating Conversion traits. This type of rule-based trait is created by selecting "Conversion" from the "Event Type" drop down in the trait UI. As an example, a Conversion trait can be tied to either campaign landing pages or actual orders captured in Adobe Analytics and be analyzed using the Optimal Frequency report in AAM to measure campaign effectiveness.

Audience Manager to Analytics (Audience Analytics)

I'm not going to give a walkthrough of Audience Analytics as it's already covered in detail here but it's a way to send Audience Manager segments to Analytics. Audience Analytics is still relatively new and there'll be more analysis use cases that customers will find from it but in this section, I'm going to cover three use cases that will be helpful to measure via Audience Analytics. One important thing to call out is that AAM data will only start flowing into Analytics once we add a report suite to the Analytics destination in AAM.
  • Tie Offline Conversions/Attributes to Online Activity: With Audience Analytics, we can tie offline attributes to online sales as well as tie offline sales to online activity. In the example, we're looking at demographic information captured from a CRM system and tying it to online sales for garden tools.

  • Customer Journey Analysis: Another important analysis use case for Audience Analytics is cross journey analytics where we can measure how prospective customers traverse across various channels/sources and land on the website. This can inform marketers where their marketing budget needs to be spent or shifted. In this example, we see how visitors present in a 3rd party data set move through various sources and eventually land on the website.
Source: https://marketing.adobe.com/resources/help/en_US/analytics/audiences/use-audience-data-analytics.html


  • Measure View-Through Conversions: We can also use it to easily see how many visitors who saw an impression and not clicked, convert or visit certain pages on your website or app. This type of analysis can also be done in AAM but given that Audience Analytics is built within Workspace, you get more opportunities to do breakdowns and analysis than AAM.

The opportunities to measure audiences flowing in and out of Analytics/Audience Manager are plentiful and will continue to evolve but the first step is to leverage this amazing integration between two powerful solutions. How are you leveraging this integration for your business?