Product Management Insight

• The activation of both known (PII) and anonymous user data is possible in a CDP
• Profiles have a much longer data retention period in a CDP
• A complete customer profile (historical, demographic) is maintained in a CDP

Core Elements of Real-Time CDP

• XDM Schema & Datasets: The XDM Schema describes the logical model of all data coming into Adobe Experience Platform and contains information about the identities used to build the id graph. Essentially, any data that will be activated by Real-Time CDP has to be mapped to the XDM schema format. Datasets are tied to a schema and collect data either sent either via streaming or batch format from various sources (E.g. Audience Manager, Analytics, 3rd party sources) into AEP. 

• Real-time Customer Profile: The Real-time Customer Profile is a combined view of all customer identities collected across multiple channels. I recently wrote about the device graph which creates a holistic view of the customer across multiple touch points. Real-Time CDP taps into the device/id graph to create a unified view of both the known and unknown customer profile on the fly depending on the use case.

• Real-Time Web Data Streaming: The introduction of the AEP Web SDK has changed the dynamics of how Adobe data collection will happen moving forward. This essentially allows clients to send data directly to AEP in real-time as well as to Analytics, Audience Manager and Target from our website or mobile app. A lot of new content is being created on this which I'll share soon.

• Real-Time Activation of Profiles: Real-Time CDP allows us to send segments and PII profiles to external destinations quickly keeping in mind the rapid pace at how customers can interact with brands across multiple channels. 

• Built With Privacy By Design: All Adobe products including Real-Time CDP is built keeping privacy in mind. In case of the AEP UI, customers can use Data Usage Labeling and Enforcement (DULE) labels to mark mark identities or restrict how data will be activated based on GDPR and other privacy laws. The official Adobe documentation provides more details on this.

Adobe Solution Integration with Real-Time CDP

Real-Time CDP UI Overview

Profiles

A profile is a collection of an individual or entity which can be used to uniquely identify it. In this screenshot, the profile is tied to the ECID identity but there can be additional identities for this profile such as email address, phone number to name a few. This is embedded within the Adobe Experience Platform UI.

Segments

The segmentation UI for Real-Time CDP is the same interface which AEP uses and it looks very similar to the Segment Builder UI embedded in Adobe Analytics. Segments allow us to dissect very large amount of profiles into smaller and much more manageable chunks. 

Sources

Destinations

• Profile Export which allows us to export PII data to ESPs and other platforms. 
• Segment Export (anonymous) which allows us to export profiles which qualified for a segment to Demand Side Platforms and is similar to how Audience Manager exports data to DSPs. 

Concept of a Device Graph

There are primarily two types of device graphs which Adobe supports and these are ways by which you can create a true identity of your customers across multiple devices and sites. There's also an external graph option as well which allows companies to leverage 3rd party device graph data which is explained in detail here but it's not in scope for this post.

Device Co-Op

The Device Co-Op (available in US and Canada) allows companies to participate in a device graph which allows them to identify their "linked" customer devices (at a person and household level) across a magnitude of channels and websites in near real-time. The last time I heard about the scale of the Co-op, there were 100+ companies, about 300 Million users and 2 billion devices part of the Co-op device graph but this number is obviously higher now. 

Source: https://theblog.adobe.com/cross-device-marketing-three-tips-success/

The concept of the Co-op can be better understood based on the visual (above) taken from the Adobe blog: 

• A customer John Doe visits the travel website and authenticates on both his mobile device and laptop. 
• He then goes to a retail website but doesn't authenticate so the retailer doesn't know who this customer is.
• Device co-op enables the retail website to "link" the customer's devices assuming both websites (companies) participate in the Device Co-op and identifies the anonymous user as John Doe. 
• This in turn allows both companies to personalize the experience for this customer on both devices and websites. As you can see, the Device Co-op makes use of both the probabilistic and deterministic linking methods.

In contrast, if these companies didn't participate in the Co-op, then the retail company wouldn't be able to know what all devices did its customers use before purchasing something and treat it as 2 unique visitors instead of 1.

Below are some common use cases of the Device Co-op:

• If you want to access to a large pool of users for prospecting related use cases.
• If you want to perform frequency capping across devices.
• Some other use cases are covered here.

Here's a link to a document which covers the membership and eligibility criteria for companies to participate in the Device Co-op. One other requirement of the Device Co-op is for the company to make changes to its privacy policy so it takes into account all the necessary privacy requirements and it does not collect any kind of PII or behavioral data. You can view your all your devices linked to the Co-op here and can unlink your devices from it anytime.

Private Device Graph

• If you want to reconcile user identities across multiple devices into one.
• If you want to perform frequency capping across devices thereby optimizing ad spend.
• If you want to establish a common identity across online and offline channels.

Device Graph and Adobe Experience Cloud Solutions

Adobe Analytics

Device Co-op is a natural fit for Adobe Analytics given the availability of the "People" metric which deduplicates the user count tied to multiple device and provides a true representation of a user as opposed to a device. This was introduced back in 2017 so it's been around for a while now and you can find more information about it here. Below is an example of what this looks like in a sample taken from the Adobe documentation.

Source: https://docs.adobe.com/content/help/en/device-co-op/using/data/people.html

Audience Manager

What is all the Fuss About?

The World Before Google Chrome 80

The World After Google Chrome 80

What is the Recommendation for 1st Party Cookies on Safari?

Triggers Architecture with Adobe I/O

The steps till #7 in this diagram are almost the same as any regular Triggers lifecycle which I covered in my previous post so here, I'll cover everything from step 8 onwards. If some steps are not clear, don't worry as I will cover these in more detail later in the post. So, let's walk through these in more detail:

8a - A user subscribes to the Triggers API using Runtime by creating a webhook. A prerequisite is to subscribe to the Triggers API which is done in the Admin console (covered later).
8b - The webhook is registered in the Adobe Admin console which is validated by the Event Gateway.
9a - The Analytics Trigger is sent to I/O Events as soon as the trigger is executed (E.g. cart abandonment, some page is viewed etc.).
9b - I/O Events sends the Trigger JSON payload to the client which is collected at some endpoint leveraging Runtime via a POST request.
9c - A Runtime action is invoked  as a custom event to send the JSON payload to a 3rd party Email Service Provider (ESP). Please note Adobe Campaign will automatically receive the JSON payload (step 7).
10 - Runtime action is invoked to query data and receive the output.
11 - This output is sent to an SFTP location to Adobe Campaign or other ESPs via another action. 
12- ESP sends an email or SMS tied to the trigger payload and conditional logic.
13 - User clicks on the email and is routed back to the site.

Listen for I/O Events Via a Webhook

Setup ngrok

Create a Webhook "Listening" Server

Register Webhook in Admin Console

Create and Test Your Trigger

Aside from the Triggers UI, I can also see five Trigger events posted on the app.js page actively listening for the events. Based on my test, it took the between 20-30 seconds for me to receive the webhook (see below) and I got 5 triggers (POST requests).

Parse the Trigger POST Response

Finally, you can parse the trigger response by expanding the POST request. In the JSON response, we can see that there are two main components of the call where the first one has information about the timestamp, IMS org among others and the second one is the actual analyticsHitSummary payload that contains all the "enriched" data from Adobe Analytics. Please note that a valid use case for this would be to send this to a 3rd party Email Service Provider given that Adobe Campaign receives it automatically. Please note that the customer ID (used to link ACS with a customer ID) captured on your site needs to be sent in an eVar as part of the Payload.

BONUS: Send a Slack Message When a Trigger Occurs

Enable Incoming Webhook for Slack

In this step, we will integrate our webhook with Slack to send a Trigger response to a Slack channel when an event occurs. You can do that by going here which is the regular process. In my case, I went here and added this app to my Slack workspace and channel called #trigger-channel.

Once you complete the integration, you'll receive your Slack Webhook URL which looks like this: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Once the integration is complete, you can send a POST request to the hook and post a custom message like I did via Postman. 

Once it's done, you'll see a bunch of messages stating the the integration is setup including a "Hello World" message which I sent. 

Next, I'll show you how to enable Slack to receive your Triggers webhook.

Modify Code In app.js

Modify the app.js file and update your webhook URL and channel name.

Next, we'll modify the Triggers payload to customize what we want to send to our Slack channel. In my case, I want to display my ECID and URL which I've slightly modified in the script written by the Adobe I/O team.

Monitor Triggers in Slack

Finally, we can see that we got 5 Trigger responses in our Slack channel as well like we saw in the Triggers UI and the ngrok "listening" page. Again, not sure if this a good use case for Slack but you can use the model for other use cases which are more pertinent. 

So, that was it! Hope you found this helpful for your own use case on how to use I/O Events. Are you using Adobe I/O in any form today?