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.
In part 1 of this series, I explained the reason why we need a new tool. To summarise, there was no solution in the market that could be used in digital marketing with a true 360-degree view of the customer. In this post, I will explain the main core components of the Adobe Experience Platform.
If you have been using Adobe Experience Cloud (AEC) tools lately, you will have heard more than a few times the new kid in town, the Adobe Experience Platform (AEP). I first heard about it 3 years ago, when it was just an initial idea. Now it is with us and I am sure many do not yet understand it.
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.
I will be conducting a lab at the Adobe EMEA Summit. I will show how to implement Server-side Digital Marketing on Thursday at 14:00. If you want to know more about it, please join me! If you are at Summit, but cannot attend my lab, I will be at the Adobe stand most of the time. See you there!
Welcome back to another basic post about the Adobe Experience Cloud. One of the main pillars of any web analytics tool is the visitor identification. It is not only used for the visitors metric, but also as the basis of multiple other features in tools like Target and Audience Manager.
After a few weeks delay, I am resuming the multi-tenancy in the Adobe Experience Cloud series of posts. I had an issue with my internal sandbox, which prevented me from showing how to set up multi-tenancy in Adobe Target. I got it fixed this week and I am ready to show it to you. Let’s start!
The User-Agent parameter is a piece of information that all browsers attach to all HTTP(S) requests they make. In today’s post, I will demystify this HTTP parameter and explain how it works. There will be a second part, where I will explain how this parameter is used in Adobe products.
Adobe Target segments are probably the richest among the SaaS tools of the Adobe Experience Cloud. Target itself has segmentation capabilities, but it can also use segments coming from multiple other sources. Here you will see how to use all of them.
Now that I have clarified the data sources in Audience Manager, I can explain how to manage multi-tenancy in Audience Manager. If you have not read that post, please do so before proceeding with this one. But if you have, let’s get started!
A few weeks ago I introduced the concept of multi-tenancy in the Adobe Experience Cloud. Adobe Analytics has had support for multi-tenancy for a very long time. Recently, all user administration for Adobe Analytics has been moved to the Admin Console, where you now configure everything. Read on if you want to know how to configure multi-tenancy in Adobe Analytics with this new setup.
It is not too uncommon that you need to have multiple tenants in the Adobe Experience Cloud. Although it was not explicitly designed to support this feature, it is possible to achieve it. I must admit it is not straight forward, but not difficult either. I will start with an introduction to multi-tenancy and, in future posts, I will explain the details for each solution.