Articles by category: Platform

Navigating an Experience Data Model (XDM) schema is not always easy. If your schema is simple, you can probably fit it on a screen and see it in full. However, the moment you start adding nested fields, things can get hairy very quickly. Not only this, but the XDM nomenclature can also feel confusing. The goal of this post is to clarify how to model the data in XDM, using a bottom-up approach: I will start with the most granular elements and how they are grouped to create an XDM schema.

In the last month or so I have noticed a developing interest in a new feature offered by Adobe Experience Platform: Federated Audience Composition. It has been some time in the making, a time during which I rarely heard about it. Now that it has been released, it looks like everybody wants it. Today I will explore what it is and what you can do with this capability. I will not explain how to configure it, maybe in a future post.

Today I am going to explain a trick that I have used once in an Adobe Experience Platform (AEP) implementation. I had a requirement where my customer wanted to personalize based on an entity that was not a person but could be shared by multiple people simultaneously. My solution was to create a schema for this entity. It worked well with this customer, but you need to be very careful and read the warnings and limitations that I will explain below.

One of the first tasks that you have to do when implementing the Adobe Experience Platform (AEP) is to select your identities. This is not a trivial decision, it will define how the identity graph will work, which, in turn, will have profound implications for the functioning of the tool. In all cases, the ECID will be one of the identities. The typical next candidate for identity is the email address. However, before you take this decision, read on.

Adobe Audience Manager offered a fundamental feature for a Data Management Platform: recency and frequency. However, the Adobe Experience Platform does not provide such a feature, at least not in the same way. Let’s see why this is so and what alternative options we have.

I am currently working on a project where my main activity is to support and guide the development teams in configuring a fairly new integration: Adobe Experience Platform (AEP) and Adobe Commerce (AC). The more I learn about this integration, the more interesting it becomes. In this post, I am going to introduce it and explain all its potential.

This is a post I have had on my list for quite some time and today I thought it was high time I wrote about it. If you do a quick Internet search, you will see that this topic is very popular, with hundreds of results. I will not repeat what others are saying. Instead, I will provide my point of view with the aim of clarifying what each acronym is and is not. I know there is some confusion about these terms.

Today’s post is going to be a short one. Adobe Journey Optimizer (AJO) has a very useful feature called test mode. This allows you to perform a dry run on a journey before publishing it. It will only use profiles that are marked for this test.

One of the reasons why some people start a blog is to document what they have recently learned. In my case, I have mainly written about things that I feel confident enough about. Today is going to be different, I will write about something I have recently come across: how Adobe Journey Optimizer (AJO) manages consent. In general, most people will never need to dive into it, as it is a bit internal to AJO, but I am in a project where I have to manipulate profiles’ consent. This post will be an introduction to this topic, where I will document what I learned so far.

One of the probably least understood tools that come with the Adobe Experience Platform (AEP) is Offer Decisioning Engine (ODE). It is currently bundled with Adobe Journey Optimizer (AJO), although I personally consider it a completely independent tool. I have used it in a couple of projects and, in the last one, we have configured it to do some cool stuff. While conceptually simple, it has so much flexibility that it is difficult to understand it in full. This post is just an introduction to help you understand it.

I have explained a few times that the main purpose of the Adobe Experience Platform (AEP) is to create segments. With AEP’s promise to be a real-time engine, it makes sense that segment evaluation is also real-time. In other words, as soon as a profile matches a segment definition, it qualifies for it and it is sent to the destination for activation. However, there are some nuances that you need to be aware of before you start creating segments.

Having lots of data in a data lake sitting idle is a waste of resources. If you store data, it is because you want to take advantage of it. If you have no use for some data, you should, at the very least, archive it, if not completely delete it. Let’s see a few options of what you can do with your Data Lake.

You should understand by now the Real-Time Customer Profile and the Data Lake. However, these building blocks need data, a lot of data, to operate. Just to give you an example, I am currently working on an implementation that will host more than 150 million profiles. And this is not the biggest that we have seen in our customers. This why I call this post “Feed the beast”.

Any system that stores a decent amount of data ends up needing a data lake. The Adobe Experience Platform (AEP) is no exception and there is surely one, which will be today’s topic. I want to particularly focus on the misconceptions, with the hope that you understand this building block and know how to use it.

At the heart of the customer engagement area of the Adobe Experience Platform (AEP), we have the Real-Time Customer Profile (RTCP). This building block is where you find capabilities like the profile store, the identity store and the various segmentation engines.

During the session I delivered during the 2023 Summit, I condensed a lot of information into just 30 minutes. Some of it I already knew, but there were other concepts that I had to learn. Some people like to follow a video so, if you are one of those, here you have the recording of my session: See Under the Hood of Adobe Experience Platform - S401. However, if you are like me and instead prefer to read, when it comes to learning new content, this post is for you. It will be the first of a series of posts where I am going to document what I explained during this session.

I am happy to announce that I will be delivering a session at the upcoming US Summit in Las Vegas in March 2023. This will be my first time at the US Summit (I have already been at the EMEA Summit) and I am very excited about it. If you are planning to attend in person, come and say hello!

I think that I have said a few times that, when I got trained in Adobe Audience Manager (AAM) in September 2014, I only understood about 50% of it and it took me another year to become an expert. With the advent of the Adobe Experience Platform (AEP) and its Real-Time Customer Data Profile (RTCDP) application, I did not need that much time to feel comfortable with it. One could say that RTCDP is the successor of AAM, which makes the transition easier. However, the two have very different backgrounds. So, what are the commonalities and differences between the two?

I am returning to my series of posts on Adobe Experience Platform (AEP), which I left a few months ago. We are at the last step, although it will take me a few posts to get into all the details I want to explain. The activation part of AEP is when we finally see the value of AEP, when we are finally using its results in our marketing efforts.

As I said in the introduction to RTCDP B2B, marketing automation activities are very different in B2B compared to B2C. If there is one detail that I have found particularly difficult to understand in B2B, that is the data model. The first time you see it, it feels too complex, until you start to understand what it is all about. This post is an explanation of the AEP B2B schemas, using my own words. My goal is to help you understand this data model if you, like me not that long ago, have no clue about it. Any subject matter expert could write a dissertation on each schema. However, my goal in this post is to help newbies. If you find any error, let me know in the comments and I will fix it.