![]() ![]() One of the reasons I’ve waited to write this post is that it took awhile for a large enough client, with enough different sites, to be ready to try this approach out. ![]() Adobe’s own documentation says this approach will only work if you’ve set up a first-party cookie subdomain with them (that painful process I discussed earlier). This cookie can then be used if your site spans multiple domains, allowing you to use the same ID on each one of your sites. The other thing this extra request does is allow Adobe to set an additional third-party cookie with the same value, which it will do if the browser allows. But there is an extra request added in (at least on the first page load) that page-load time and performance fanatics will want to be aware of. What comes back is a bit of JavaScript that contains the new ID, which the browser can then use to set its own first-party cookie. When your browser loads that JavaScript, Adobe sends off an additional request to its AAM servers. However, unlike Google’s visitor ID cookie, it’s not set exclusively with logic in the tracking JavaScript. Unlike Adobe’s “s_vi” cookie, this cookie value is set with JavaScript and will always be first-party to your site. So, where to begin? Let’s start with the new cookie containing your Marketing Cloud Visitor ID. The good news is that it’s a major focus of Adobe’s product roadmap, which means those bumps in the road are getting smoothed out pretty quickly. And even if you get that far, it’s then an additional challenge to migrate to the latest version of Target that is compatible with AMCV – a few of my clients that have tried doing it have hit some bumps in the road along the way. It’s a bit more challenging than a simple change to your s_code.js or mbox.js files. One caveat is that while the AMCV has been around for almost 2 years, it’s been a slow ramp-up for companies to implement it. The idea here is that if you implement the Marketing Cloud Visitor ID Service, and then upgrade to the latest code versions for tools like Analytics and Target, they’ll all be using the same visitor ID, which makes for a much smoother integration of your data, your visitor segments, and so on. ![]() Notice that I didn’t say all Adobe products – but things are finally moving in that direction. The biggest advantage a company gains in switching to this new approach is a way to finally, truly integrate some of Adobe’s most popular products. The really great thing about this new approach is that it represents something that Adobe customers have been hoping for for years – a single point of visitor identification. Note that you don’t need to be using Audience Manager to take advantage of the Visitor ID service – the service is available to all Adobe customers. AAM is the backbone for identifying visitors using its new “Marketing Cloud” suite, and the Marketing Cloud Visitor ID service (AMCV) is the new best-practice for identifying visitors to your website. The next change Adobe introduced – and, though it happened well over a year ago, only now am I starting to see major traction – was built on top of the Demdex product they acquired a few years ago, now known as Adobe Audience Manager (AAM). That may be because, at the time it happened, Adobe already had something better in the works. That was nice, but it wasn’t a very publicized change, and most analysts may not even know it exists. This is a fallback visitor ID cookie set purely in JavaScript, used when a browser visiting a website still on third-party cookies rejected Adobe’s cookie. So a few years back, Adobe came up with another alternative I discussed a few months ago – the “s_fid” cookie. ![]() I remember having to go through the process when I worked at – because companies rightly take their websites, networks, and security seriously, what is essentially 5 minutes of actual work took almost 3 months! If that sounds like a pain to you, you’re not alone. This is done by having your network operations team update its DNS settings to assign that subdomain to Adobe, and by purchasing (and annually maintaining) an SSL certificate for Adobe to use. Many Adobe customers have gone through the somewhat tedious process of allowing Adobe to set that cookie from one of their own subdomains, making it first-party. This cookie is set by Adobe’s servers – meaning that by default it is third-party. You’ll remember that Adobe has historically used a cookie called “s_vi” to identify visitors to your site. Those two topics set the stage for a discussion on Adobe’s current best practices approach for visitor identification. Originally written by Josh West on April 19, 2015Ī few months ago, I wrote a series of posts about cookies – how they are used in web analytics, and how Google and Adobe (historically) identify your web visitors. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |