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.
Here we are again, at the end of another year, a year that many will want to forget. Still, some things have happened and I wanted to share with you my sensations about the last 12 months.
This week I saw a question in an Adobe-internal Slack channel, where an Adobe colleague was asking, on behalf of a customer, how to access the Launch library in case the servers were down. That really surprised me as I had never seen a similar request. To me, it looked like this customer did not trust Adobe’s edge network. This question prompted me to explain in more detail this edge network. The information is sometimes difficult to find in the Adobe documentation, so I will compile it here, both for you and me.
This post is the last of my mini-series on debugging with Charles. If you have not read the previous posts, you should, before you continue: Introduction to HTTP debuggers and Debugging Adobe Tools with Charles - Part I. In this post, I will skip some obvious steps, as I assume that you are familiar with Charles by now. If something is not clear, please, let me know in the comments.
Now that I have provided an introduction to HTTP Debuggers, I can explain how to use Charles to debug Adobe tools. In this post, I will show you how to start working with Charles, find the Adobe data and switch Launch environments.
In many blog posts, I have explained how to use the browser’s developer tools to debug or test implementations. In my day-to-day work, whenever I need to check an HTTP call or a cookie, I use these tools. I have used them so much, that I do not have to even look at the keyboard to press CTRL+Shift+I. However, there are some situations where you need more than what the browser can offer. Enter the HTTP debuggers.
One question that we hear from time to time is “why do I have so many places to create segments?” Or, its variation “why can’t I have a single place to manage all my segments?” These are uncomfortable questions, which require some detailed explanation. I am also aware that not all our customers accept the answer. In this post, I will go through the features of the various segments engines and why it makes sense that they differ.
As far as I know, all mobile operators impose data caps in their contracts. If you go over this limit, you may not be able to download anything else until the following month, may get a lower speed, may be charged an extra fee… This is in stark contrast with ADSL/cable/fibre providers, which generally offer unlimited downloads. In this situation, some companies feel it is unethical to have their visitors pay for any marketing activity they perform on their mobile website or app. I have even seen companies wanting their whole website to be zero-rated. If you are in this situation, here you have a few things you can do.
If you come from the Adobe Experience Manager (AEM) world, I do not think this post is for you; you already know what I am going to explain. However, if you are working with other Adobe solutions or are just starting to learn AEM, I hope to give you an initial overview of what Experience Fragments (XF) are.
This post may be a bit late, as 3rd party cookies have their days numbered. However, with Google’s decision to delay the end of these types of cookies, we will still have them for a bit longer. So, in case you wanted to know more about the demdex cookie, here you have all its uses.
One of my clients has recently asked me to implement this integration. While it is documented in the Experience League and I have managed to configure it, I believe the documentation could be clearer. My understanding of Adobe Analytics has also helped to fill the gaps. So, if you are trying to set this integration up, I hope this tutorial is what you are looking for.