Sunday, May 26, 2019

Access Adobe APIs Using Postman

APIs (Application Programming Interface) facilitate the transfer of information between two systems and are leveraged in a magnitude of industries today ranging from Travel to Retail. Adobe offers open source APIs in its solutions across the Document, Creative and Experience Clouds. Major companies leverage APIs to allow users to do the following:

Share content on Social Media (Facebook)
Retrieve flight information (Alaska Airlines)
Real-time access to item price and availability (Amazon)
Access maps using GPS (Google Maps)
Tracking information on shipments (FedEx)
Server Side Analytics Implementation (Adobe)

In this post, I will cover how to leverage Adobe APIs for Launch by Adobe and Audience Manager but these APIs are also available to use across some other Experience Cloud solutions such as Adobe Analytics and Adobe Target via Adobe I/O. We won't go into the basics of how to create integrations as there's a lot of documentation available on it but we'll cover the steps on how to call the APIs using authentication tokens in Postman. Please note that Audience Manager is not part of Adobe I/O yet and we'll specifically cover REST APIs to work with elements within the AAM UI. Let's jump right in!

Launch By Adobe APIs

The first solution we will cover is Launch where we'll create a property and you can use this format to create , data elements, rules, environments etc. The first step is to go to the Adobe I/O console which shows you all the integrations setup for your experience cloud org. In this case, we've created an integration with Launch APIs using Adobe I/O.

Make sure you either select the Developer role or the Admin role (while creating the integration) in order to create properties. I had chosen Approver as listed in the instructions in our documentation which walks us through how to create an integration but that didn't let me create a Launch property.

The following screen will show you your API credentials which you'll need to access the API and the ones which is required is API Key and Client Secret. We'll also need the Org ID that needs to be sent as an additional attribute in one of the requests we'll make in one of the API calls covered later in this post.

The next step is to generate the JWT (JSON Web Token) which will be used to authenticate and access the Launch APIs. The Private Key is generated as part of the public certificate (CRT file) creation process outlined in the Launch documentation. Please note that during the creation of the certification, an additional file called private.key is generated which contains this information.

The next step is to use the generated JWT to create a Launch token that will be used to access Adobe APIs.

We need to now copy the generated JWT in Postman to create a new access token (valid for 24 hours) but before that, I want to share with you a tip which my colleague Gil Jimenez shared with me. The tip is to create global variables in Postman to store sensitive values that you'll need to access over and over again. You can do that by clicking on the Environment icon as shown below. The other thing you can do is to save these API calls as collections in the form of separate folders as shown below in the left section.

Generate a Launch Access Token

The next step is to generate an access token using the client_id, client_secret and jwt_token parameters by making a POST request to https://ims-na1.adobelogin.com/ims/exchange/jwt/ as explained here. Note how we're using the global variables to store sensitive information and accessing it in the call. We need copy this access token and store it. In our case, we're storing it in a separate variable calls access-token which is different that the jwt-token we need to create it.

Make a POST Request to Create a Property

We'll now create a new Launch property by making a POST request to https://reactor.adobe.io/companies/:company_id/properties as covered here. We can also create Launch rules, data elements, environments etc using this method. Below is how we can make this call.

Once we press send, we successfully (if everything goes well) create a Launch property as shown below. So using APIs, developers can literally do everything in Launch without having to login to Launch. These APIs are open source and super powerful!

Make a GET Request for a Property

We'll now cover how make a GET request to https://reactor.adobe.io/properties/:id to fetch the details of the Launch property we just created by entering the property ID (starting with PR) which you can get from the response you get when you created the property. We're going to leverage some mandatory attributes defined here as shown below (The {{property}} value stores the property ID). You can use this to get access to a lot of information such as name, creation timestamp, domains etc. We can also fetch the details of data elements, rules and extensions among other things.

Adobe Audience Manager REST APIs

We'll now cover how to make GET and POST requests for AAM using Postman to access REST APIs (centered around the AAM UI) which allow you to perform some basic functions without logging into the AAM UI. Please note that there's another set of APIs called DCS APIs (send data to AAM) which I'll save for a future post.

Generate an AAM Access Token

As I mentioned earlier, the AAM APIs are not yet part of Adobe I/O so in order to access the REST APIs, we need the following credentials to access the APIs:

AAM API user name (AAM Admin UI)- Adobe consultant can provide this
AAM API password (AAM Admin UI)- Adobe consultant can provide this
AAM UI Username (bank.demdex.com login)
AAM UI Password (bank.demdex.com login)

Once you have these credentials, we can leverage Postman to get the access token which is only valid for a few minutes. Here we enter the AAM API and password using Basic Auth and send a POST request to https://api.demdex.com/oauth/token.

The next step is to enter the AAM UI credentials as shown below to generate the access token that will be used to access additional APIs.

Make a POST Request to Create a Folder

We can access all AAM APIs in the Swagger API portal. The first thing we want to create is a folder by sending a POST call to https://api.demdex.com/v1/folders/traits/ using the Bearer Token auth type as shown below. The folder is "REST API Test" and it will be placed under the root "All Traits" folder.

Once the call goes through successfully, we should see the following message and the folder should show up in the AAM UI immediately.

Make a POST Request to Create a Trait

We'll now create a simple trait by sending a POST request to https://api.demdex.com/v1/traits/. The only additional attributes we're adding is the Folder ID and the Data Source ID which we can get from the AAM UI. The result is the following as shown in the screenshots below.

Please note that the API doesn't have a way to create traits in bulk so you can leverage BAAAM to do so which is a custom solution.

Make a GET Request to Retrieve all Traits

This is the final request in this post to get details about traits but you can retrieve data for segments, destinations, data sources etc. We send a GET request to https://api.demdex.com/v1/traits/ to retrieve all traits within our AAM instance. In our case, we can see that the trait we just created can be accessed using this method and you can export this JSON output and perform additional searches.

So, this was just a small glimpse into what's possible via APIs where we're able to perform the same tasks that we usually do in the Adobe solution specific UIs. This also shows us that almost everything that happens in the UI is driven by APIs so in a way we took a look under the hood of Launch and Audience Manager. Hope you found this post useful.

Saturday, April 20, 2019

Implement CTR tracking in Adobe Analytics via Launch

A client asked me to come up with a solution on how to track Click Through Rate (CTR) without tracking clicks due to server call constraints. Historically, I've always tracked Click Through Rate on a particular page by capturing the page name in an eVar along with a custom event for page view. For clicks, I've used a custom link name eVar and a custom click event. Then I would create a calculated metric which divides the custom clicks by custom page views (CTR %) and include that as a metric in the page name report.

This client didn't want to use ActivityMap due to security constraints as they had some links which had borderline sensitive information. The other requirement was to control the logic that constitutes a "click" but a majority of my clients use ActivityMap though and I do like it. So, they asked me how to calculate CTR WITHOUT capturing a click event as they were concerned about server calls which is a fair ask. After a few unsuccessful tries, I eventually stumbled upon this article from Adam Greco. This post will cover how to implement Adam's solution using Launch and show how that materializes in actual reporting.

What we need to set this up

A Tag Management Solution like Launch or some other TMS
A custom plug-in called getPreviousValue which will allow us to capture the value of the previous page name
A JavaScript variable to capture the previous page name
Products string
s.pageName
1 eVar (Merchandizing eVar to capture Page Name)
2 events (Clicks, Page Impressions)

Implementation In Launch

The first step is add the getPreviousValue plug-in to the custom code section of the Adobe Analytics extension instead of a rule. This is how I implement plug-ins in Launch so that they're readily available across the board and populate on every hit if needed.

The next step is to create a global page load rule tied to DOM Ready where we need to add some more custom code to track to wrap this solution up.

This is the crux of the solution where use the products string to create "fake" products and store the previous page name in a global variable called PrevPn. The code captures the current page name on page view along with a unique page view event (event7) on page view. On the next page, our code populates the current page name (eVar7) tied to event7 (Page Impressions) and also captures the previous page name in the same eVar7 along with a separate event8 (Page Clicks). Please note that we've assigned "fake" SKUs of "imp" and "click" in the products string which will show up in the Products report. Also, the if statements are key for this to work as each condition is meant to identify a page view with or without a previous page name.

Click to zoom in

Validation

In my sandbox site, I can see that I'm capturing both the current (company) and previous page name (activewear) in the products string after clicking a link.

Reporting

The first step is to create a calculated metric to calculate CTR (Page Clicks/Page Impressions) which I've shown here.

The next step is to put it all in a report to show how it all comes together. This report shows the merchandizing Page name along with the custom events and a calculated metric to capture CTR.

Drawback of this Solution and an Alternative

There's no way to differentiate which link performed well but an alternative will be to store the link name on click in a cookie and then retrieve that on the next hit in a separate merchandizing eVar within the products string. This will be in addition to the existing solution to track CTR based on the page name eVar.

So, that's a wrap and hope you like it! With this, we're able to implement a solution that captures the CTR on a page without tracking clicks thereby saving server calls.

Sunday, March 31, 2019

My Experience at The Adobe Summit 2019

I attended Adobe Summit earlier this week held at the Venetian hotel in Las Vegas and walked ~72,000 steps in 6 days (Saturday to Thursday). In these six days, I only went out of the hotel twice which in a way is shocking but that's because the Venetian hotel is a city in itself and it also goes to show how busy I was. This was my second Adobe Summit and my first as an Adobe employee but the important thing to call out is that attending Summit as an Adobe employee is completely opposite than that of attending as a client or partner. Simply put, you don't get to attend Summit (as a consultant) unless you're presenting or doing a lab which I personally think makes a ton of sense and I want to especially thank the Adobe leadership team who gave me an opportunity.

I did a lot of things at Summit and want to summarize all I did but the one I'm most proud of is the speaking session with Garrett Friedrichsen who's my client from Mastercard with whom we presented to over 200 people. Let's take a look at some of the things I did:

Teaching Assistant in pre-conference trainings- The pre-conference trainings happen right before Summit kicks off so I landed in Las Vegas on Saturday instead of Monday as the actual conference began on Tuesday. My initial TA duty was supposed to be on Audience Manager fundamentals but I ended up swapping to cover basics of Launch by Adobe at the very last minute. Even though it was very tiring due a commitment of eight full hours, it was still a great experience for me as I proactively helped the instructor and for one of the lesson, took over on his request. The most satisfying thing for me was being able to help the students and answering ad-hoc questions about their implementation. The other good thing about this was that I got a feel for how to face an audience of over 50 people.

Adobe Booth duty- This was one of the highlights for me as this is where I got to catch up with my rockstar co-workers and the leadership team in person. In addition to this, I answered ad-hoc questions from clients and partners primarily on Analytics and Audience Manager.

Ad-hoc Customer meeting- This happened as one of the account teams reached out to me and asked me to meet their client (not mine) to discuss my experience working with clients who incorporate agile methodologies in their analytics implementation. The conversation went well as the customer and I ended up addressing a lot of general challenges and potential solutions around agile, implementation challenges and enablement of resources within an organization. We have some next steps and the account team will work on executing those with the client.

Teaching Assistant in Labs (Video Heartbeat and Adobe Analytics)- Personally, I didn't add much value here as my main role was to work with other TAs to help attendees/students with their preexisting lab exercises and computers. All in all, it was a good experience to see how other instructors go about with their lessons.

Co-Speaking Session on Adobe Audience Manager- This was easily the most challenging and satisfying part of Summit for me. I wouldn't lie but I was quite nervous before the presentation as this was the biggest group of people (235 people attended) I had ever presented in front of (previous was probably 20). My session (Audience Driven Campaigns in Financial Services, Featuring Mastercard) started with an icebreaker but I did speak fast at times which is something I'll work on. As I got to presenting my core slides, my flow got much better as I knew the most about the subject. Overall, the presentation went well as the silver lining was that people came up to both Garrett and I to congratulate us but most importantly asked questions and engaged with us after the session. Having presented for the first time to a big audience, I would like to share some tips in case you want to do it as well:

Rehearse but not so much that you end up cramming the content
Get to the conference room 15-20 minutes early to prep and get set up
Have an ice breaker at the start (mine was to wish the Japanese audience Konnichiwa and also wish my co-speaker Happy birthday)
Try to include a relevant analogy for your presentation but be 100% sure that it's relevant and not overdone. We didn't include one but will probably do so next time
Speak slowly and take deep breathes in between
Stay hydrated (very important)
Gauge the audience reaction and mood to adjust if necessary. Sometimes, the audience in the room already knows a lot of what you're saying so it may make sense to go deep but there's a fine line here so be careful.
Make enough time available for questions and engage with the attendees after your session is over
Don't get intimidated and overawed by the situation. It's important to remember that the attendees are people just like you and they're attending to learn from you so relax and enjoy the moment
Finally, push yourself out of your comfort zone and take the plunge to speak. Trust me, if do it once you would want to do it again and again!

Got a demo of the Adobe Experience Platform- I feel the Experience platform is a game changer for Adobe and it will elevate Adobe to a whole new level. The real-time platform allows us to ingest any data (including PII), control privacy, query data, visualize data, leverage machine learning and AI at scale to name a few. Here's a link to it and I'll hopefully write about it as I learn more.

Killers Concert and Wrap up- Adobe summit wrapped up and did justice to the phrase "Work hard and play harder". Honestly, it was hard to enjoy myself before my speaking engagement but after I was done, it was the best feeling not just because it was over but because I felt the hard work paid off which is why I didn't miss any opportunity to enjoy myself at the concert.

All in all, it was a wonderful opportunity and I hope to come back in some capacity next year and continue to add value for the company. I've added some pictures from the conference.

The amazingly beautiful Venetian hotel

An awesome surprise for all AAM speakers from our track manager, Rakhi Patel

Dinner with client

In one of the labs

My presentation

Working our magic at the booth

Awesome Adobe booth crew and my coworkers

The Killers performing on stage!

This happened outside right after the concert where the DJ played some awesome music. It was completely unexpected and a ton of fun!

Sunday, March 10, 2019

Mobile App Marketing with Adobe Audience Manager

80% of smartphone users are more likely purchase from companies who have a mobile app (Google, 2018) and up to 70% of all Internet activity happens on a mobile device (Ciodive, Nov 2017). These are some of the many statistics that remind us about the importance and relevance of consumer behavior on mobile apps. This also means that companies who have mobile apps need to invest in marketing their apps. This post will cover how can customers leverage Adobe Audience Manager to share their audiences with Demand Side Platforms that deal with mobile publisher networks for two use cases which are Retargeting and Suppression.

Mobile App Device IDs and Advertising

The first thing I want to cover is the lack of a UUID (cookie ID) on mobile apps. Mobile Apps have their own device ids that are primarily used for advertising purposes. Apple iOS has IDFA (identifier for advertisers) and Google has the (Google ID) and this is the ID that gets sent to Audience Manager to integration purposes.

Mobile Advertising is primarily of two types:

In-App and Push Messaging: This is messaging and "advertising" within your own app to bring back users to your app once they've downloaded the application. The Adobe documentation covers this in a lot more detail.
External App Messaging: This type of advertising happens on other apps where you see ads of apps that you either have or don't have (see example below). This is what I will cover in this blog post.

Source: mobileads.com

Mobile App Device ID Sync

I recently wrote about the newly launched Adobe Experience Platform SDK which shows you how to deploy it using Launch by Adobe. I suggest that you deploy the new Adobe SDK on your App if you're starting new. For this post, I'll focus on SDK4.0 given that it's still the most popular SDK being used by our clients.

Assuming that you have the Adobe SDK already setup on either your iOS or Android Apps and Audience Manager deployed, we need to make sure you send the respective device advertising ID for iOS and Android to the SDK which enables advertising on your apps for Audience Manager. The methods are outlined here:

iOS: setAdvertisingIdentifier (More information here)
Android: submitAdvertisingIdentifierTask (More information here)

Once you deploy the device ID sync, you should expect to see the following output in a packet sniffer for your iOS app as an example:

http://dpm.demdex.net/id?d_ver=2&d_orgid=F7AC877056DFF0E87F000101@AdobeOrg&d_mid=68452733562309787373599334388622514953&d_blob=cIBAx_aQzFEHcPoEv0GwcQ&dcs_region=3&d_cid_ic=DSID_20915%01591B1212-F56B-4B8F-B026-A2C8D90323F1%011

Please note that 20915 a unique identifier for iOS and needs to be used in case you want to upload any records for specific device IDs to AAM.

Validate Mobile Apps Signals in Audience Manager

The first step is to validate incoming mobile app signals in AAM which you can do by looking for 'c_contextData.a.Launches' to confirm if a mobile app signal is coming into AAM. This attribute should show up only if you have a mobile app forwarding data to AAM.

Create Mobile App Traits in Audience Manager

Once mobile app signals are identified, we need to create a mobile app specific data source by selecting 'Device Advertising ID' as the type. Both iOS and Android app specific traits will be created based on this setting.

The next step is to create traits tied to our specific use cases of Retargeting and Suppression.

Retargeting Trait

The following example is to setup a trait for retargeting users who added to cart but did not purchase. The numbers in the trait builder are evaluated as strings so we have to be careful with the logic. The other thing to note is that you will have to send in specific context data variables which map to various events in the checkout flow.

Exclusion Trait (Suppression using Segments)

Suppressing an audience simply means that we want to suppress certain audiences who've either purchased a product or in my case, I'm showing an example of users who have launched the app who will be suppressed using an AAM segment. One other thing to note is the you can create these traits in all lowercase.

Map to Segments and Activate

Once retargeting and exclusion traits have been created, map these to segments. This particular example excludes users by leveraging instant cross device suppression using the "AND NOT" logic. You can also suppress the audience at the DSP level but my recommendation is to exclude it in AAM.

Finally, map segments to AAM destinations for activation. A few examples of Demand Side Platforms that work for mobile apps are AppNexus and DataXu. Criteo is another company that specializes in mobile app retargeting.

So that's it! I hope that gave you some insight on how to execute media campaigns on mobile apps with the sole goal of maximizing your return on ad spend.

Sunday, February 3, 2019

DTM to Launch Migration Tool Overview

There's a lot of buzz currently about upgrading from Dynamic Tag Manager to Launch by Adobe and there's a ton of good materials out there to help us plan and execute the migration successfully. Right off the bat, the three part series from 33Sticks comes to mind which I highly recommend you to read before this. My post will cover Adobe's migration tool which in my opinion provides a rather seamless method for upgrading to Launch. I'll share my experience with it and supplement the information that the Launch product team has already provided. I'm also not trying to provide a complete roadmap to migrate as there's already great content for it but I'm simply giving my opinion on this handy utility. Let's get started!

Overview

The migration tool is basically accessed by clicking the 'Upgrade to Launch' (highlighted in Red) button in DTM as shown below.

When you click this button, a popup will appear that shows you two check boxes and an 'Upgrade' button. The first checkbox allows you to use the same DTM embed code with Launch post migration. The second checkbox disables the existing property in DTM.

Once you click 'Upgrade', you'll see a brief message stating that the property is being migrated. Once that goes away, you'll see a link which will take you directly to the newly migrated Launch property. The new property in Launch contains the timestamp in its name as shown.

An important point to note is that only items that have been published in DTM will get migrated and anything that's unapproved in DTM will not get migrated to Launch. Here's a link from Adobe's documentation that covers what all will be migrated (Adobe Analytics, ECID, rules and data elements).

In case you want to migrate any additional rules that weren't previously migrated during the first round, you can migrate the property from DTM again. In my case, I forgot to publish a few rules in DTM that weren't migrated before so I ended up migrating the property again which added a second property in Launch with a different timestamp. Personally, I would recommend that you migrate just once and publish everything in DTM beforehand.

As far as the (migrated) rules are concerned, Launch creates a new rule to fire off an Analytics beacon (see below) in addition to the ones that get migrated.

Now that we've seen what the migration tool does, I want to share how I would approach a migration with this tool.

My Migration Approach

Before I begin, I want to share that I've upgraded a few clients using this tool as well as migrated clients by creating a brand new property in Launch. There's no hard and fast rule around which method to choose as both options will get you the desired results but if you have a very complicated Analytics set, the migration tool might be a better solution. Let's go through what my approach would be with the migration tool.

Treat this migration as an opportunity to do a cleanup of unnecessary data elements and rules and validate your data layer and tags in general.
Create a thorough launch schedule/plan to QA your staging environment and sure all tags are firing as expected. There's a lot of good material out there on how to build use cases and leverage QA tools & extensions to perform validation but that's a separate post for some other day but give this step the utmost importance.
Your launch plan needs to include a timeline of how long your tags will be tested in staging and when can they be pushed to production. I would typically give it about a month (depending on the complexity of your site) from when you begin testing in staging to when you can deploy Launch in production.
Make sure to publish all rules, data elements and tools in DTM that you want to migrate to Launch. As mentioned earlier, only Adobe Analytics and Experience Cloud ID Service tools will be migrated so other solutions such as Target or Ad Cloud will have to be created separately in Launch.
Click the 'Upgrade to Launch' button and do not select any of the checkboxes in the popup. The reason why I wouldn't select the DTM embed code option is because it's recommended to deploy Launch asynchronously which doesn't require the legacy pageBottom() call. As this call will have to be removed, there's no real advantage in keeping the DTM tag as you'll still need a release cycle to make this change. The other checkbox to disable the DTM property shouldn't be checked as you may need to go into DTM later.
Once the new (migrated) Launch property has been created, click into the property and do a quick sanity check to make sure all rules, data elements and the Analytics/ECID extensions have been copied over correctly. At this time, add any extensions in Launch that didn't get copied over from DTM such as Target. I've covered AAM separately in the last section.
Replace your existing DTM code hosted in your staging environment with the Launch embed code to begin your tag validation. Click the 'Environments' tab and copy the development script as shown below.

Test in staging and closely follow your migration plan. After meeting all your validation criteria, publish your new Launch property in production.

Audience Manager SSF Migration

If you had Audience Manager deployed via server side forwarding (SSF) in DTM, the AAM module will get copied over to Launch and the module will be present in the Analytics extension. My recommendation is for you leverage the in-built SSF integration for AAM inside the Analytics extension. Let's take a look.

Click 'Open Editor' in the Analytics extension.

Comment out the AAM module code in the library and save changes.

Choose 'Manage the library for me' option to let Launch host your Analytics library as well as automatically upgrade you AppMeasurement library. Also 'globalize' your Analytics object so that you can leverage the object elsewhere in Launch and in the browser console.

Finally, check the checkbox as shown below to enable the automatic AA->AAM SSF integration in Launch.

So that's a wrap. I hope you found this walkthrough helpful in case you decide to go with the migration tool but whatever approach you choose, it's imperative to have a sound migration plan and validation strategy.

Saturday, January 12, 2019

Miscellaneous Facts About Adobe Audience Manager

Happy New Year 2019 to all and Thanks for reading this post. Adobe Audience Manager just like any other data management has its fair share of characteristics that are not commonly known. Unless you've actually spent some working time on AAM, it's unlikely to find these facts readily available in our documentation. In this post, I've aimed to document some of these in a single post. So, let's get started!

1. The third party Audience Manager demdex cookie is the same across all sites (customers) that have AAM deployed. The reason why it's the same as it allows cross domain tracking of AAM customers and also forms the basis to share data across all AAM customers (2nd party data share). So, if you delete the demdex cookie, it gets refreshed for all AAM customer sites.

2. Metrics in Audience Manager are based off Cookies/Visitors tied to the UUID (device/browser) or demdex. Customer often ask about replicating Adobe Analytics segments based on Visits in AAM which isn't possible to replicate 1:1 so it's important to understand this nuance.

3. Server side Forwarded Adobe Analytics data to Audience Manager is billed separately in Audience Manager. Customers often assume that this data is forwarded for free which isn't the case as the same applies to data captured via the client side DIL data collection method in AAM which is billed separately.

4. Audience Manager variables starting with 'c_' are customer defined keys, 'd_' are platform level keys and h_ are typically browser header keys. Let's review of few of these.

o Following are some keys to filter for the URL and/or referrer.

§ d_referer (not traffic referrer) allows you to filter for the page URL

§ If you have Adobe Analytics forwarding enabled, you can also use c_pageURL.

§ If you want to filter for the traffic referrer and have Analytics data forwarded, you can use c_referrer.

o If you have a scenario where you capture the same page name across multiple sites (with different Adobe Analytics report suite IDs) and have SSF enabled, you need to use the d_dst_filter field. I've included a screenshot which shows how to filter it using a trait. See how the customer variable starts with 'c_' and platform variable starts with 'd_'.

o If you want to capture data tied to city or country based off automatic IP address which is collected in AAM, you can use the following Geo platform keys:

§ d_city

§ d_country

5. Given that Adobe Analytics data is now forwarded to AAM via report suites, the Audience Management Module is not required to forward data BUT should ALWAYS be implemented if you want yours users to qualify for segment as without it, you cannot leverage AAM for A/B testing and personalization. The other advantage of the module is that it creates a first party cookie for AAM (covered in #7).

6. One other confusion that clients have is around the data collection frequency and availability of rule-based traits in AAM. Rule based traits start collecting data in real time since creation even though the data may be take up to 24 hours to show up in the AAM UI. So, if you have a scenario where you want users to qualify for a trait in real-time for personalization, you can rest assured. To validate if you qualified for a trait, you can use Visitor Profile Viewer in AAM and other methods defined here.

7. UUID demdex cookie (covered in #1) which is usually a third party cookie can be captured as a first party cookie called 'aam_uuid' within the Audience Management module (#5). Once you set the UUID as a first party cookie, you can easily create a data element in Launch by Adobe (shown below) and map it to an Analytics variable.

8. Customer IDs synced using natural match upon authentication need to be hashed and should not contain any ids that are even borderline PII. A good method to anonymize your user ids is to leverage the SHA256. The other important thing to keep in mind is that you should leverage the same type of user ID across multiple sites and map them to the same AAM data source so that there's no ID collision.

9. Data onboarded via 3rd party data providers such as Acxiom or data onboarders such as LiveRamp upload data to AAM using a unique 'ic' (integration code) which is numeric (example below). In a previous post, I covered how to upload data using key value pairs but an 'ic' can also be used to upload your CRM data.

10. 3rd party ID syncs enabled by AAM consultants shares the AAM UUID with Demand Side Platforms where they store this ID in a match table so that they can target users on their own network using this ID. Adobe also receives a corresponding ID from that system as well so that each system's cookies can be synced with each other. This sync is used to calculate the match rate which is why it's recommended to ask your consultant to turn on these id syncs to get a higher match rate between AAM and your DSP. However, these cookies can be turned off by setting the disableThirdPartyCookies variable to true in the ID Service library.

Below is what these id syncs look like in the network tab of your browser (Adobe Ad Cloud) populated the very first time a user visits your site. Also, note that subscribing to a data provider in the Adobe Marketplace automatically turns on an id sync as well.

I hope you found this post helpful and feel free to share any other misc facts that you learnt about Audience Manager.

Product Management Insight