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.
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.
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.
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.
Last week, a reader left a comment in my post on Declared IDs, asking for ideas on how to capture more or better 1st party data. As the world inches towards a cookie-less web, this is a challenge I see with more customers. The problem is that not all websites are created equal.
Last year, Adobe released a framework (not exactly a new product), called Project Firefly. I barely noticed it when it was announced. However, one of my customers requested me a very specific feature, for which Firefly was the perfect tool. Although it has been ages since I last did any serious development, it was a good opportunity to learn this new tool. This is an introduction to this tool and, in future posts, I will get into more details.
So you have finally decided to start a project with the AEP Web SDK and Adobe has provisioned it for you. There are now quite a few steps you need to take, so I will go one by one. While you could start in many places, I will start with the edge configuration.
A year ago I wrote about Declared IDs. I briefly mentioned then an issue that arises with setting these IDs: lazy loading and Adobe Target. However, I know that I did not explain too much about the issue. In this post I will get into more detail.
Now that you are familiar with what a bot it is, I am going to explain how the Adobe Experience Cloud (AEC) interacts with bots. However, if you landed on this page directly and do not know what a bot is, I suggest you first read my previous post on bots, crawlers and spiders.
If you have a website, sooner or later it is going to be found by bots. There is no way you can prevent this from happening, so you need to be ready to deal with them. This is the first of a 2-part series on this topic.
When I wrote about siloed teams, I left a lot of ideas out. This is a follow-up post, expanding on the same topic. If you have landed on this page for the first time, I suggest you first read my previous post and then come back here.
The concept of consumer journeys is becoming one of the key techniques to digital marketing. It is an innovative way of creating campaigns, which requires all teams rowing together towards a common goal. If you have not heard about them, in the few posts I will explain consumer journeys in more detail.
Today I am going to diverge from the typical, more technically-oriented posts I have written in the last few months. Most of the companies I have worked with in the last 5+ years had the same issue: different Adobe tools where used by different and disconnected teams. Although this seems like an obvious issue, I wanted to put it in writing.
As I explained in my EMEA Summit lab, you should not use the ECID server-side if you are in a web environment. The solution I proposed was to use a hybrid approach. This means that the ECID must still be generated client-side, and then used server-side.