Although I have been 10 years at Adobe, during 9 of those years I had been oblivious to the business-to-business (B2B) world that lies out there. My customers had been from many different verticals: retail, telecom, banks, gambling, CPG… but all these cases were business-to-consumer (B2C). Last year I had my first encounter with a B2B customer; this year I have had two RTCDP B2B implementations. If you are a bit lost regarding the differences between B2B and B2C in the Adobe Experience Platform (AEP), this post is for you.
One of the main purposes of Adobe Experience Platform (AEP) is to create a 360-degree view of your customers. In more technical terms, this is what we call the unified profile. While this is a conceptually sound capability, there are certain cases when this unified profile could be wrong, with information from other profiles which should not be there.
Today I want to tackle an area that I rarely mention in this blog: digital transformation. I know, this is a very broad concept, with many ramifications and ways of implementing it. Every digital strategist has their idea of what it is, how to approach it and how to implement it. My goal today is just to introduce the three pillars of a digital transformation program: people, process and technology.
If you have been following my series on the Adobe Experience Platform (AEP), you should now have data ready to work with. If you have the RTCDP or AJO SKUs, you will now want to start communicating with your customers. For that, the next step is to segment your total population, which is what I will describe here.
I have mentioned a few times the expression enable for profile, without explaining what it really meant and how to play with it. I wanted to document it a few months ago when I started writing more about the Adobe Experience Platform (AEP). However, as usual, I realised that I had to first explain some background before addressing this concept. This is what I have done in the past few posts, but now you should have all you need to understand it.
Creating an XMD schema does not also create storage for this schema. A schema is just a data model, not the data itself. To get the data in Adobe Experience Platform, you need to create datasets, which conform to schemas. In other words, the datasets are the storage where the ingested data is stored.
I had written this post a few months ago, but I realized that there were many topics that I needed to explain before I could finalize it. Now that you understand what the Experience Data Model (XDM), the AEP identities and the unified profile are, let’s see how all of these features are used together.
When people start working with Adobe tools, they are flooded with lots of new names, which are not always obvious. Or you start with one tool, but as you learn more, you start to get lost. This was my case, when I had to learn the rest of the Adobe Experience Cloud with a background of Adobe Analytics. If this is your case, keep on reading!
I have been a bit lazy and I have not addressed this topic for some time. I have read a few articles, but I was not sure what I wanted to write about. However, in the last few weeks, I have been involved in an initiative with a customer, where they are replacing their existing static data layer with an Event Driven Data Layer (EDDL). This has given me the final push I needed to learn it and decipher it for you.
One of the first clarifications I need to make about Adobe Experience Platform (AEP) when I start working with a new client is that it is not your typical database. People are used to relational databases and NoSQL databases, so, naturally, they try to classify AEP into a known category. I would dare to say that CDPs should have their own category.
Those of us in the digital marketing industry use very liberally some concepts, taking for granted that everybody knows what they mean. Two of such concepts are “segments” and “audiences”. I have used them in my posts very often, without giving much thought to which word I use. I had a recent enablement session with a customer and I realised that I have never explained these terms.
AEP stores a huge amount of structured data. Therefore, it makes sense that you can access that data in a way that resembles a database. In this post, I will show you a couple of ways to achieve it.
It has been a long journey, but here I am: in less than 1 week I will celebrate my 10th anniversary at Adobe. It has been an amazing journey, much better than what I thought 10 years ago. Without a doubt, it has been my best job ever. Not everything has been rosy, though. Let me summarize the positives and the negatives of these 10 years.
Now that you understand what the Experience Data Model (XDM) is, let’s move to another critical element of the AEP puzzle: identities. In theory, they look simple but, under the hood, they can become complex and difficult to manage.
If you are new to AEP, you will be trying to understand many new concepts. One of them is the Experience Data Model or XDM. This is one of the key components of AEP and you should understand it to master Adobe’s CDP. Since I also started scratching my head about this new concept when I first heard about it 3 years ago, I would like to use my learnings to help you understand it.
I have written multiple posts on Adobe server-side implementations. The last one was a few years ago because there was nothing new to report. Now, there is: Adobe has released the Edge Network Server API. I have just recently known about it, so I have not had the time to play with it. However, I thought that I would write an introductory post to it, in case you need it.
You probably remember from your school days, that there are 3 types of industries: primary, secondary and tertiary. It goes without saying that we are in the last one: tertiary or services. While jobs in all industries require knowledge, in the services industry it is all about the knowledge: we do not have factories or farms or mines or…, just our brains.
I remember being a bit nervous before my first AEP project. The tool seemed very complex and I had only received the training. Seeing what my coworkers were doing and the questions they had, meant that I saw myself as a noob. However, as I dived into it, it was not as difficult as I initially thought. Of course, it is not an easy tool but, once you get the hang of it, things start to make sense. I also received a lot of support from the experts. In this post, I want to share the approach that you should take in an ideal AEP project.
Once you have created an account in Adobe IO, you will want to use it to connect to the API you have configured. I do not know how other vendors work, but in the case of Adobe, before you can connect to the API, you need to authenticate. In this post, I will explain the process for the case of a service account (JWT). It is important to understand that the authentication happens against an endpoint, which is different from the API.
You plan to use one of the multiple APIs that Adobe offers. You know which API you want, you understand it and you are ready to start coding. But, before you do so, you will need to get the credentials for your script or application. Instead of using the Adobe Admin Console, you have to create these credentials through Adobe IO, which is what I am going to show today.