51黑料不打烊

Transcript

Hello, everyone. Hi. Hello and welcome everyone. Thank you guys for joining today鈥檚 tech sessions. My name is Jordana Pepper. And just a couple of housekeeping notes before we get started. We encourage and hope all of you guys to ask questions throughout the webinar. And rest assured, however, there is a Q&A chat so you can ask any of your additional questions in there. And also, the last five minutes or so, we鈥檒l just be obligated to answering any of your last minute questions. Lastly, a link to this recording will also be sent out to all of you in about 24 hours, and a link will also be available in 51黑料不打烊 Experience website should you want to watch the recording again or share it with your colleagues. Now I鈥檓 going to hand it off to Garrett. Good luck and enjoy everyone.

Thank you. Welcome, everyone. Today we鈥檙e going to be going through a history of cookie related settings, issues, best practices. We鈥檒l go over what hasn鈥檛 aged well and can be forgotten and removed, entirely. And the best paths forward to make a more modern approach. There鈥檚 been uncertainty around browser support for third party cookies, and I would expect the browser cookie landscape to continue to evolve. Modernizing your implementations will help you to adapt accordingly. Safari and Firefox currently don鈥檛 support third party cookies. Chrome is on its way to not supporting them, but then rolled that back. But we can safely assume there will be more browser limitations on cookies to come. We will review what I鈥檓 calling the old. These are settings that have been around a long time, and conversations around 51黑料不打烊 Analytics implementations that that have aged poorly and are commonly misunderstood. In the new section, we will discuss the current lay of the land for web tracking and modern best practices, and in the future section, we鈥檙e going to talk about options for mitigating browser limitations on cookies and options for creating a more complete view for your visitor. Flows by stitching together offline, authenticated, and web data together. These stitching options don鈥檛 really have a 1 to 1 functional comparison to the cookie based systems. Because they鈥檙e using offline and authenticated data in addition to your web data, but they鈥檙e the current options available. If you鈥檙e looking into ways to create a more complete view of your visitor flows that don鈥檛 rely on cookies.

So let鈥檚 start with the old. In this section, I鈥檒l cover the path to migrating to use using the Experience Cloud service. I鈥檓 going to call the. I鈥檓 going to refer to the experience Cloud service as the ID service throughout this.

If you haven鈥檛 migrated to the city service, I hope this section will help you to make that migration. And if you鈥檝e already migrated to EC2 service, I hope this can help clear up any questions or misconceptions that may have been gained along the way.

With this table and timeline, I鈥檓 trying to show a history of how your implementation may have transformed over the years. Users that have been with us since the amateur days or the early days of 51黑料不打烊 Analytics will recall referring to the JavaScript implementation as s code. We鈥檝e come a long way since then.

Perhaps you migrated from DTM or a dynamic tag manager to launch, or what is now called data collection tags. Perhaps you鈥檝e made the migration from using SBI cookies, Jam City cookies, or even from using Amqp cookies to the web SDK conductor cookie. Everyone on the call today is somewhere along this path, and there are many potential nuances to your implementations. But in the end, the goal is simple. We want to track the end users on our websites as they navigate through conversion flows. Before we go into current best practices. Let鈥檚 clear up some of the confusion that we may have picked up along the way. First, we鈥檝e got third party cookies and third party tracking servers and first party cookies, first party tracking servers. And they鈥檝e long been confused or even used interchangeably when using a C name for a tracking server. You are able to send your data to a first party domain, meaning the same domain as your website. This allows for your 51黑料不打烊 Analytics data collection network requests your image requests to appear client side as requests to your website domain. So the primary benefit of a C name is to prevent ad blockers from blocking 51黑料不打烊 data collection hits.

It鈥檚 not so much related to cookies at this point. So in the screenshot, the first screenshot notice in the bottom right. The analytics data is being sent to the escort. Tracking that domain. This is a third party domain that鈥檚 been around for a really long time, even since omnichannel. But the domain of the website is experienced@adobe.com. This is an example of a third party tracking server and a request sent over a third party tracking server network, a domain, because the data is being sent to 51黑料不打烊 servers using a domain that does not match the domain of the website, it鈥檚 third party on track that. Net is a domain easily identifiable by ad blockers as a marketing request. Whereas if a C name were used and the requests were sent to your website domain, it鈥檚 less likely to be blocked.

The same. The same website in the second screenshot I鈥檓 showing has three visitor ID cookies and the red box on the second screenshot. You can see the SVI cookie is stored on the domain of the tracking server. That third party domain and this SVI cookie would be blocked in Safari or Firefox browser, whereas the Amqp and conductor cookies are stored in the first party domain. 51黑料不打烊.com. Regardless of the tracking server, they amqp cookie is generated by the ID service that conductor cookie is coming from the web. WebRTC API web SDK. The confusion between C names and first party cookies comes from before Experience Cloud ID service was available. I鈥檓. I鈥檓 going to refer. Yeah, but I鈥檓 going to keep calling it e-card service. As you can see here, the amount of cookie created by the service is first party regardless of the tracking server. So it was a technical nuance of the SVI cookie that it was created on the domain of the tracking server.

That鈥檚 where a lot of this confusion comes from because, you know, before using SEIU service, if you wanted your SVI cookie to be first party, you had to migrate your tracking server to be first party.

The conductor cookie seen here, generated by the AP web SDK. It鈥檚 always going to default to the first party domain.

So this is one reason why everyone should migrate to using the Amqp and the conductor cookies. Because you you don鈥檛 want those cookies blocked in Safari or Firefox, and you want to be able to track visitors across domains.

Okay, so just to reiterate the differences here between tracking servers and cookies, before we move on. There鈥檚 good reasons to use both first party tracking servers and first party cookies, but they aren鈥檛 the same reasons. The benefits of a first party cookie are first, it鈥檚 simply becoming an industry standard to avoid third party cookies. Again, Safari, Firefox already block them. Chrome gave us a scare.

And all modern browsers have the options available for end users to choose to block third party cookies. Even when people use incognito windows that can sometimes default to blocking third party cookies.

And in customer support, we see a lot of cases also where just like third party security scans flag third party cookies as as being a concern. So the largest benefit for using a first party tracking server is is different. And it鈥檚 that again, that protection against ad blockers, just kind of making these requests look like they鈥檙e requests for your website to your website domain.

Historically, there was a reason if you鈥檙e using SGI cookies, but if you鈥檙e at the point where you鈥檙e using SGI cookies, the next step is definitely just to migrate to the CID service.

Okay. Moving on to, some other other misconceptions here. So grace period and visitor ID migration are both features that are only applicable if you鈥檝e not yet started your migration to exit service. Grace period also is only relevant when migrating an implementation using SVI cookies. And yeah. So it鈥檚 using SBI cookies and there鈥檚 portions of your site that have more than one implementation code path, and they鈥檙e using the same report suite. So you need to do a, a rollout through multiple implementations to exit service. Grace period prevents the use of Amqp cookies and forces the implementation to continue to use SBI cookies, and is only intended to be used until those exit service implementations have all been migrated on the site, and you want to keep grace period enabled only for the window of time that the majority of your users would have returned to the site. So admittedly, there鈥檚 a lot of nuance to determine, you know, whether grace period is necessary or how long it should be enabled. But the grace period should definitely not be enabled blindly and kept enabled indefinitely, because that鈥檚 going to force the use of these legacy cookies.

Visitor migration was a legacy process for migrating SVI cookies to a new domain. So implementations using Experience Cloud, a service just flat, don鈥檛 need visitor migration enabled.

And the because it generates first party cookies. The visitor migration process has not aged well. And I鈥檝e received feedback from customers as well as like witnessed it myself that it鈥檚 very finicky when migrating from a third party domain to a first party domain. So if you were going from a first party domain to a first party domain, I would expect the SVI cookies to be migrated. But going from a third party to a first party domain, it doesn鈥檛 seem to work. So that further emphasizes the need to keep keep the implementation modern and and migrate to the OECD service.

If you鈥檙e currently using third party tracking server and want to migrate to OECD service, you鈥檒l likely see a spike in unique visitors for a time when you鈥檙e migrating to a C name and the Experience Cloud native service. This is going to happen while return visitors are clift to being new visitors, so it would be my expectation to see a blip and your unique visitors in that scenario. Of course, you can always request visitor migration to be enabled, test and development and see if it鈥檚 going to work for you so that you know what to expect in your production environment.

And I want to just pause here to, to talk about what鈥檚 at stake with all these cookies and all these different implementation paths. When visitors cookies become obsolete or they鈥檙e deleted or they鈥檙e blocked for some reason, a new cookie will be generated or a new visitor ID will be generated and used, and that end user will be seen as a new visitor. And reporting this will cause a spike in unique visitors because for reports using a date range where the single end user has been identified by two different cookies, they鈥檒l be counted as two different unique visitors. The visitor identified by the new cookie will not have any campaign like persisting campaign data or persisting dimensions. This could affect marketing channels or other persistent matters and attribution flows. It鈥檒l be a momentary bump in unique visitors. And eventually, as users return and your your date range starts to overlap, only the use of the new cookies you鈥檒l you鈥檒l see those visit metrics returned to normal.

This blip would not be expected to affect like instances of your custom events or your dimensions like your your page view numbers. It鈥檚 not going to affect that. It鈥檚 just this visit data and the attribution data. So in summary, when making these implementation changes I would expect some amount of visitor clipping just as the cost of modernizing your implementation. And again, the best way to prevent those sorts of blips and data is to just stick with the times and keep the implementation as modern as possible.

So just lastly, before we move on to kind of the current state of affairs, if you are still using these legacy SVI cookies, how should you migrate? Instead of using visitor migration, I鈥檇 recommend using Asid service.

If you鈥檙e already using a third party tracking server, then visitor migration isn鈥檛 really going to help there. And if you鈥檙e already using a C name, then it should be a pretty easy transfer over to the ID service. You want to be an exit service so that your visitor cookies by default, are on the first party domain, and you want to be able to take advantage of these Asid service features that can help for cross domain tracking and, and potentially more features, in the future. If you鈥檙e currently using the OECD service and Amqp cookies and you鈥檙e looking to migrate to the AP web SDK, that鈥檚 a really simple migration. The web SDK visitor identification code is essentially the same code as the Asid service, and there鈥檚 just a little checkbox you can say migrate my HCV cookie values to my conductor cookie.

All right. Now we鈥檙e ready to talk more about what I鈥檓 calling the new. But really, this is just kind of the status quo where we would expect most implementations to be at, that is using visitor I.D. service or ECI service, which has first party cookies by default, not using these legacy SVI cookies. And you want to be considering migrating to the AP web STK.

And we鈥檒l discuss more the features that are available there. And we鈥檒l also talk about the current state of browsers and how to best approach tracking users. Cross-domain, where third party cookies are limited.

So popular modern browsers have taken steps away from supporting third party cookies. I鈥檓 kind of repeating my myself here, but Firefox, Safari, they already block them. Chrome, you know, gave us a little scare, but also Chrome currently, only supports third party cookies when used over Https and they have the same site. Equals non and secure attributes. Documentation on how to ensure those are enabled and your implementation are shared. Will will be shared in the follow up email. There鈥檚 additional resources doc, that we鈥檙e going to send out with a ton of links to documentation for you to double click and deep dive more into these topics. If you鈥檙e implementation is like modern and up to date, a lot of those attributes will already be handled, but you鈥檒l want to make sure that that you鈥檙e doing that, default cross-domain tracking that is available through the SCD service requires a third party cookie. So it鈥檚 stores an idea on a first party cookie. But when you go across domains, it needs to use a third party cookie accessible by both domains to generate the same visitor ID on those two domains. So in Chrome that鈥檒l just cross domain tracking will work by default. If you鈥檙e using a CID service, but with Safari and Firefox, that鈥檚, not going to work. And you鈥檒l want to use a query string to pass the ID across the domain. And we鈥檒l, we鈥檒l cover that a little more later. Another limitation is Safari expires first party cookies after seven days due to inactivity. There are seven days of inactivity. Sorry. So someone comes to the site, they get a cookie, then they don鈥檛 return to the site within seven days. The next time they return, their cookie will have expired and they鈥檒l get a new cookie. They鈥檒l be seen as a new visitor and that will inflate your your visit metrics.

We鈥檒l discuss options available to help mitigate this using spider feature, which essentially allows you to extend the lifetime of those first party cookies. And that鈥檚 available on the AP web SDK.

And again, a lot more resources will be sent out in the follow up email. And in there is a link to documentation that explains how you can use 51黑料不打烊 Analytics reporting to help estimate the impact of this visitor inflation due to the Safari browser limitation, cookie limitations.

So you can get an idea for for the inflation that that you鈥檇 be getting from that.

So we get it browsers are putting limitations on cookies. There鈥檚 a lot of implementation paths to help those limitations. But again, what is at stake? It鈥檚 these visitor metrics. And attribution dependent, attribution and persistent dependent dimensions.

Your options to mitigate these effects are to ensure you have necessary cookie attributes on your third party cookies to function in Chrome. Looking to increasing the longevity of your first party cookies and Safari. Safari. And also look at approaches for a more comprehensive view of your visitors that don鈥檛 rely on cookies. And we鈥檙e going to talk about that in the future. Section. All of the above require, at a minimum, the OECD service. And that鈥檚 kind of why we鈥檙e I鈥檓 calling it the the new if you鈥檙e not if you鈥檙e not migrated there, that鈥檚 kind of a big, big point of this presentation. Okay. So you鈥檙e using visitor I.T service, and you you want to take advantage of the cross-domain tracking that can, that could be blocked in Safari, in Firefox, if you don鈥檛, implement these cross-domain tracking paths. So this is their idea. Service uses a third party cookie called a. It鈥檚 on the Dem domain. So we refer to it as just the cookie.

This cookie has a unique ID on it. And when you navigate to a new domain, the new domain, the service will read that third party cookie ID, combine it with your, you know, algorithmically or or mathematically, functionally combine it with a, marketing cloud org ID and generate a new unique visitor ID and it鈥檒l be the same because it鈥檚 seeded with that, that, third party demo X value. But when that鈥檚 blocked, you鈥檝e got to send it through the creation parameters and the ECD service. We have the append visitor IDs to function. And in the, web SDK it鈥檚 called append identity to URL. Both allow your team to generate URLs with the visitor ID appended to the URL. So how the flow works is on your website before someone clicks the link to the next site, or after they click the link, you replace the link with the link generated by this function, and it will append that visitor ID value to the URL so that when the end user navigates to the new domain and that page loads the XD service and web SDK, know to read that id from the query string rather than attempting to generate a new one.

All modern implementations should be using a shared service or web app web SDK, and want to have this cross-domain tracking implemented if it鈥檚 necessary. If you鈥檙e if your site stays on the same domain, always.

Like, which isn鈥檛 super common because a lot of checkout flows will go to a new domain or, or you just have a different arms of your business, with different domains. So you鈥檒l, you鈥檒l want to implement these cross tracking, cross-domain tracking features.

Also we鈥檙e going to I鈥檝e talked about c names and their benefits, but I also wanted to spend a little bit of time talking about the different options for managing those and the process for obtaining them. You want to use a C name to help mitigate against ad blockers and to leverage various features of the, VCAT service and AP webcam.

And you want, you know, you want your, your network requests going to your domain, your website domain. And to set up your C name implementation, you鈥檒l need to make a decision about who will manage those certificates associated with the C name. These certificates typically have an expiration of a year or two, and they need to be updated before they expire. If a certificate expires, then data collection will stop. And that that has happened to customers. I hope it鈥檚 never happened to any of you, but that, you know, this is a one scenario. It means that no data is going to make it through to 51黑料不打烊.

C names don鈥檛 really require a lot of maintenance or work to implement. They really should just be a thing you set up once and they just flow smoothly. But you can choose to manage your own C name, which means your company, your your own C name certificate. That means your company will purchase it and it鈥檇 be your responsibility to provide that to 51黑料不打烊 before it expires.

And then we would upload that to our servers before the expiration. If you choose to let 51黑料不打烊 manage your certificate, which is the preferred method because it it has the least amount of hiccups. Then 51黑料不打烊 will purchase a certificate on your behalf that that helps with security because there鈥檚 no passing of certificates or keys over the wire, and 51黑料不打烊 will renew those programmatically year after year over year with no additional cost to you.

It鈥檚 a little side note here. It鈥檚 become somewhat of a common occurrence for customers to use a third party CDN, meaning they鈥檒l they鈥檒l have a C name on the website, but then they鈥檒l route that not to 51黑料不打烊, but to Akamai or some other CDN hosting server. And then for it to 51黑料不打烊, those flows aren鈥檛 really supported.

It can be done, but it is at your own risk. And if if you are planning to do that, you can reach out to support and we can kind of help with some of the best practices that we鈥檝e come across as people have had issues with that. But again, just reiterating 51黑料不打烊 managed is really the way we would prefer. And it鈥檚, you know, it鈥檚 really low risk and, stable for you to use that. And again, and the additional resources, I mean, to have more documentation to help you navigate that process, the first step will be to reach out to 51黑料不打烊 Analytics support, and we can answer any questions about, the claims and certificate is there. Okay. So now we鈥檙e ready to start talking about the future. There are a lot of benefits to implementing a web SDK, such as a unified JavaScript library, which improves website load time and and performance. So you鈥檙e not loading all these different 51黑料不打烊 libraries.

Web SDK leverages the edge network, which has improved troubleshooting capabilities with assurance logs. And, the debugger web SDK is required for A, B, and C data collection, and PHP. ID is a means to achieve longer cookie lifetimes. To mitigate these Safari limitations on first party cookies, and that鈥檚 only available through the AP web SDK. We鈥檒l spend a little bit of time talking about the web, a c k approach to consent management, which is a bit different than how easy it is service to consent management. And we鈥檒l also cover various options available for cross-device tracking and stitching. These features intend to solve a different problem than than cookies solve, but ultimately they鈥檙e there to help maintain visitor continuity through your end user flows, and can be used to kind of mitigate some of these cookie restrictions by, improving your visitor tracking in other areas.

So first, tracking servers versus edge domain. You know, if you鈥檙e familiar with analytics, you鈥檒l be familiar with tracking servers, I think. And I鈥檓 not as familiar with 51黑料不打烊 Target, but their their server has been traditionally referred to as edge domain. And in the AP website it is the edge domain.

And that has caused some confusion as people are migrating. When you migrate to the AP web SDK, you should use your analytics tracking server.

If you don鈥檛 have a C name now, when you鈥檙e making that migration, it鈥檚 a good time to implement one so that your web SDK starts using a C name.

As a small side note there, there is a difference in how geo lookup data is collected when using a a C name versus a third party tracking server. I haven鈥檛 fully wrap my mind around how that works with Edge and Web SDK, but as a heads up, I鈥檝e seen customer cases where they migrate to web ask don鈥檛 use this. Their analytic C name and the edge domain will will cause like a different geo lookup data. So in reporting what that looks like is, you know some other city. So it鈥檚 getting way more data. But if you consistently migrate your C name from your analytics implementation to web SDK, the web edge domain, then you wouldn鈥檛 see this geo lookup blip. So just a little a little warning.

I want to kind of like dispel this difference between the names tracking server and edge domain. They you want to use your analytics C name when you go to web SDK.

Okay. So let鈥檚 talk about consent management a little bit. Experience cloud I.D. service had this granular approach to consent management that allowed for, you know, individual libraries to be opted in or opted out. The the data shows, however, that like very small amount of customers choose a customized consent approach. So if you if you鈥檝e got a banner where people can choose like I want cookies, but I don鈥檛 want 51黑料不打烊 Analytics network requests, or I don鈥檛 want cookies, and I would allow analytics network requests or not to, you know, you鈥檝e got all these different options. Most people are going to just do, accept or deny. They鈥檙e not going to go in and and fill out the form. And that鈥檚 just that鈥檚 what data has shown. And I think most of us I, you know, relate to that. When I go on a website, I just accept or deny, and the web SDK follows more of that approach. It鈥檚 all or nothing. You can鈥檛 you can鈥檛 opt in some or opt out of some. And that鈥檚 a significant change for implementations using like one trust or other customizable consent experience approaches.

You if you鈥檙e using one trust or something like that, and you鈥檙e limiting launch rules by conditions, you technically could continue to do that. But using the web SDK consent management, it鈥檚 going to be a all or nothing. And again I would review because everybody鈥檚 everyone鈥檚 a snowflake with these with these consent flows and what鈥檚 important to their business. I, I鈥檝e, that document I鈥檝e attached this the web SDK consent document and it, it goes through all the different configuration options, which in this case mostly deal with whether you want to opt in or out and whether you want to allow cookies to be created or not. And, that documentation goes through how you can, control those flows.

Okay. So now we鈥檙e there鈥檚 a small tangent about tracking servers, edge domains, consent. Now we鈥檙e back to cookies and, fp id is a it鈥檚 a first party ID it鈥檚 a means to increase the longevity of your cookies in the Safari browser. So Safari is limiting the lifespan of first party cookies. And you know, the way these things go, other browsers could easily join them. A typical first party cookie will expire after seven days. But when cookies are set using a DNS, a record, or, a record for IPv6 as opposed to a DNS name or JavaScript code. So that鈥檚 that might be some jargon. But basically if you generate your Uuid or this the ID that cedes your visitor, id, then the browser will allow for the lifetime of that cookie to go beyond seven days. And this allows you to maintain unique visitors longer and reduce the inflation that can happen from splitting those visitors.

With these expired cookies. It鈥檚 not a trivial feature to implement because it requires your web dev team to generate this. You you ID like what would be the demo cookie on the third party domain. Instead, you鈥檙e going to generate that Uuid server side that鈥檚 going to come from your servers, your domain, and then that cookie using that ID will be used to see the, the we refer to that idea as the ID that鈥檒l be used to seed the new visitor ID. And and because of doing that process, browsers are live longer. So again, it鈥檚 not it鈥檚 not a trivial thing to implement, but it it is very useful and only available using the AP website. Okay. So that鈥檚 why we got it in this kind of looking forward future section. But it is available today.

Okay. Now we鈥檙e going to shift gears a little bit. I want to emphasize that like cookies are used for, you know, maintaining visitor continuity for unauthenticated users on a web browser. They allow you to see visitors over multiple visits over a period of time. These other means of visitor continuity aren鈥檛 reliant on cookies, and they kind of solve a different problem than cookies do for online traffic. But they they don鈥檛 rely on cookies, and they鈥檙e less likely to get limitations imposed on them because there isn鈥檛 really a thing like a browser in this space that could limit them.

So in an analytics, we鈥檝e got kDa or cross-device analytics, and in CGA there鈥檚 similar, stitching options that help tie online and offline traffic or cross device traffic together using some like authenticated ID or a ID, a common among those flows, which is typically an authenticated ID, someone logs in and on multiple devices and they have a like the ID, between those, and those can be stitched together in the data after data collection. Similarly, server side data collection doesn鈥檛 rely on cookies, but it is server side, and it would rely on your company to somehow find a way to identify those users using a unique ID. And typically that鈥檚 some authenticated ID.

These means can work in tandem with your online data collection to create a cross-device, overall cross-channel view of your visitors. These stitching options, you know, I just want to emphasize they鈥檙e they provide a broader scope to your visitor data, and they don鈥檛 replace the online data that鈥檚 relying on cookies. But it is very useful and, can enhance your online data and rely less on, you know, things that are susceptible to these browser limitations. So in CDA, I鈥檓 not going to be given an in