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.

I have had to recently help a customer with the integration of Adobe Experience Manager (AEM) with Adobe Launch. If you have been following this blog for a while, you already know that my area of expertise is not precisely AEM, so I had to do the whole process to learn it first. To keep it handy for the future, I thought I would share the experience with all of you.

This post is going to be very different from those I usually write. Instead of talking about Adobe technology or related topics, today I want to explain how I became an architect in the Adobe consulting organisation. This came as a suggestion from a colleague, in case others would like to follow the same path.

At beginning of this year, I wrote a blog post on a cookie-less web. In it, I explained where did this witch hunt against the cookies come from and what would the (expected) next chapter in this drama be. However, a recent plot twist has sent ripples, which have been felt in every corner of the Internet.

Every time I check the Adobe Analytics reports of this blog, the most visited post is How to debug an Adobe Analytics implementation. That post was written back in 2016 and, in technology, 5 years is an eternity. More importantly, one of my recommendations does not exist anymore. It is time to update that post and to talk about the successor of the Adobe Debugger: the Adobe Experience Platform (AEP) Debugger.

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.

As I said at the very bottom of my 2020 Retrospective post, one of my personal projects for 2021 was to migrate this blog from Wordpress to Jekyll. I am not sure there was a clear goal, I just thought it would be fun. With all the time that I have spent at home during this long British winter in lockdown, it has been a distraction that has kept my mind busy. Finally, after so long and so much time invested, here it is. I hope you like it!

A few weeks ago I heard of a conversation between Adobe and a customer about server-side implementations of web analytics and optimisation tools. In this case, the problem was that some vendor was misleading our customer. Well, actually, this vendor blatantly lied. I wanted to explain this situation so that none of my readers fall into this trap.

When people talk or think about Adobe Analytics, the first idea that comes to their minds tends to be “reporting”. In fact, this idea applies to any visualisation tool. However, this is only half of the story. Many forget that these tools actually have another, very important, capability: data analysis.

You all know that Adobe Analytics has an out-of-the-box solution to track download links. It just works and few people even care about it. You may not know that you can even extend its functionality, by adding additional eVars/props/events to the server call. Not very common, but I had to do it for one client. However, what happens when someone downloads content through a direct link or you have a server-side implementation?