If you are working with a DMP like Adobe Audience Manager, I am sure you have come across the following problem: you want to target your visitors on site, immediately after they log in, using on-boarded data, even on the first visit. This last statement is, precisely, where the problem is. The way AAM processes on-boarded data is as follows: You upload your CRM data to AAM, either to an SFTP location or an S3 bucket Every 12h, AAM reads all on-boarded data and processes it, converting the signals into traits The traits are stored in the core servers A visitor logs in for the first time Since the communication between the browser and AAM is done through the edge servers, these servers have at this moment in time no on-boarded information for that visitor The edge servers where this visitor activity has happened, request the on-boarded traits to the core servers In a batch process, core servers send to the edge server the visitor’s on-boarded information
[UPDATE 07/01/2019] I have changed the operator in the trait expressions. Thanks Glenn! Initially, when we think of segments (or clusters) for ad segmentation, we think of ever-growing groups of cookies. Simple use case like purchasers, visitors to our website, subscribers to a newsletter or owners of a device fit in this model. However, advanced (and not so advanced) use cases do not work well with this model, where we have visitors entering and leaving regularly a segment, so a segment can shrink in size: Retargeting dropped baskets: the moment someone places an order, you do not want to retarget him again Customers of a mobile operator: it is very common nowadays to switch to a different provider frequently Age group: ever day, visitors enter one particular age group or leave it, as people grow older
My job as an Adobe Analytics consultant has involved, very often, bridging the gap between these two worlds. I have seen myself many times as a translator: getting a message from the marketer, translate it into technical terms and communicating it to the developers; and vice-versa. My developer background has helped me a lot in this case. In quite a few cases, I have been requested to join meetings just to make sure that the IT team understood what the marketer wanted. It does not help either the fact that web analytics is not considered as important as it should be.
Let me start with an anecdote I once heard. The marketing department decided that they wanted a new feature in the home page. The IT team received the request and implemented it as per the requirements. Three months later, the business owner of this new feature requested a report on the performance of this new feature to the web analytics team. To the team’s surprise, that was the first time the web analytics team had heard of this feature. Consequently, had not issued any tracking requirements and there was nothing to report on. In other words, three months had been lost.
Before I started working with Adobe Audience Manager, I had a very limited knowledge of the on-line advertising market. In the past, I had managed Google AdWords campaigns, but that was all I knew. Now that I have been working for some time with a few AAM customers, I have realised that the market for on-line campaigns is huge. There are many actors involved: agencies, trading desks, DMPs, DSPs, SSPs… I still have to learn more about this market.
Today’s post is going to be a different form the last few posts, a bit more hands-on. One of the typical questions I get from my AAM customers is “how do I detect a user browsing with an iPhone [model]”. The only solution we have to reliably detect the device is through the User-Agent. Although this should be very simple, in theory, there is one problem: Apple does not want you to detect the iPhone model. Android devices include in the User-Agent the name of the device, or enough information to get it from there. However, Safari browsers include the device type (iPod, iPad or iPhone) and the iOS version, with no hint of the model.
This is going to be a rather short post, but only from my side, as the poster: if you follow everything I am saying, it will be even longer for you to process than any of my previous posts. Let’s start by watching the one of the great TED talks: Sebastian Wernicke: How to use data to make a hit TV show
This is my first attempt to write an opinion article. I had it in my mind for some time, but the sparkle was a question during my talk at the London Analytics Labs. One attendee asked me about the future of on-line advertising if 3rd party cookies and/or ads were blocked from all browsers. So, this is my point of view.
I will be presenting at the Analytics Labs in London next Tuesday 26th January.
We are all aware of the importance of creating secure products. In a previous post, I explained how to set up a workflow for a DTM implementation. One of the consequences of using this workflow is that only a reduced number of users can cause damage to the website via DTM. This is also good from the security perspective, as it reduces the risks of a successful attack. This is probably enough for most companies.
Before getting into the details of the post… Happy New Year to all of you! I hope that 2016 is full of DMPs, DTMs and Analytics 🙂 Now, going back to today’s topic, I want to talk about how to create the products string in DTM using the W3C data layer. One of the reasons why we prefer a tag management solution (TMS) over hard-coded snippets is to write less code. All modern TMSs include features to set analytics variables using a point and click interface, usually through Web. In the case of DTM, you can create a data element that reads a data layer variable; you can then assign it to an eVar or a prop, without writing a single line of code.
In my experience as an Adobe Audience Manager consultant, I have noticed that many clients need a lot of hand-holding at the beginning when working with this DMP. Coming from the Web analytics world, this was a bit of a surprise to me at the beginning. I remember when I started an Adobe Analytics project I worked on 6 months ago, one of the client teams had a spreadsheet with 138 requirements… and that was only one of the teams involved. They knew exactly what they needed from the tool, which made my life easier. However, this is rarely the case in an AAM project.
If you have been in an Adobe Analytics implementation, it is highly probable that, at one point or another, you have heard the expression “VISTA rules”. However, many of you might still wonder what those little beasts are. First of all, let’s start with the name. Unless you dig in Google or in the help section, you will never have guessed that VISTA stands for “Visitor Identification, Segmentation & Transformation Architecture”. Do not get too impressed with this name, it was just an imaginative way of getting a fancy name.
As all digital marketers know, surveys provide invaluable information from visitors. They allow you to know various types of information from the visitors: the website itself, likelihood of buying, preferred products… The outcome of these surveys can be used to modify certain aspects of the experience or target the visitors with specific messages. All marketers would like every single customer to perform a survey and use that information to create a perfect experience for each visitor, but the reality is far from this ideal. Only very few visitors end up accepting the invitation and this usually happens when there is a potential reward.
Now, looking into the standard, we will get into the different sections that conforms recommended data layer. Let’s review each of them in the following posts.
The classical problem of how to make sure that, in hybrid apps, the journey is not broken when transitioning from the native app to the embedded browser, is well known and it has been solved a long time ago. My colleague Carl Sandquist wrote a great post in the official Adobe blog some time ago about how to stitch visitors in hybrid apps. Two years later I still reference it to my customers. I recommend that, before you proceed with the rest of this post, you read it.
This is the first post of a series of posts, in which I am going to describe the W3C data layer. A few months ago, I explained why it was a good idea to have a data layer. In this series, I am going to dive into the details of one particular data layer implementation: the W3C standard. For those of you who do not know what the W3C does, it is the international body that creates the standards that we use everyday on the web: HTML, CSS, Ajax… Although there are other options for data layers, like JSON-LD, I personally prefer the W3C standard; after all, this body has created some of the most important standards in the Internet.