51ºÚÁϲ»´òìÈ

Transcript

Hello, everyone. Hi. Hello and welcome everyone. Thank you guys for joining today’s 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’ll 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’m going to hand it off to Garrett. Good luck and enjoy everyone.

Thank you. Welcome, everyone. Today we’re going to be going through a history of cookie related settings, issues, best practices. We’ll go over what hasn’t aged well and can be forgotten and removed, entirely. And the best paths forward to make a more modern approach. There’s 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’t 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’m 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’re 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’t really have a 1 to 1 functional comparison to the cookie based systems. Because they’re using offline and authenticated data in addition to your web data, but they’re the current options available. If you’re looking into ways to create a more complete view of your visitor flows that don’t rely on cookies.

So let’s start with the old. In this section, I’ll cover the path to migrating to use using the Experience Cloud service. I’m going to call the. I’m going to refer to the experience Cloud service as the ID service throughout this.

If you haven’t migrated to the city service, I hope this section will help you to make that migration. And if you’ve 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’m 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’ve 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’ve 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’s clear up some of the confusion that we may have picked up along the way. First, we’ve got third party cookies and third party tracking servers and first party cookies, first party tracking servers. And they’ve 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’s 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’s 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’s 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’s less likely to be blocked.

The same. The same website in the second screenshot I’m 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’m. I’m going to refer. Yeah, but I’m 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’s 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’s 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’t 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’s good reasons to use both first party tracking servers and first party cookies, but they aren’t the same reasons. The benefits of a first party cookie are first, it’s 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’s that again, that protection against ad blockers, just kind of making these requests look like they’re requests for your website to your website domain.

Historically, there was a reason if you’re using SGI cookies, but if you’re at the point where you’re 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’ve 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’s using SBI cookies and there’s portions of your site that have more than one implementation code path, and they’re 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’s 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’s 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’t need visitor migration enabled.

And the because it generates first party cookies. The visitor migration process has not aged well. And I’ve received feedback from customers as well as like witnessed it myself that it’s 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’t seem to work. So that further emphasizes the need to keep keep the implementation modern and and migrate to the OECD service.

If you’re currently using third party tracking server and want to migrate to OECD service, you’ll likely see a spike in unique visitors for a time when you’re 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’s 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’s at stake with all these cookies and all these different implementation paths. When visitors cookies become obsolete or they’re deleted or they’re 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’ll 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’ll 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’ll you’ll 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’s not going to affect that. It’s 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’d recommend using Asid service.

If you’re already using a third party tracking server, then visitor migration isn’t really going to help there. And if you’re 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’re currently using the OECD service and Amqp cookies and you’re looking to migrate to the AP web SDK, that’s a really simple migration. The web SDK visitor identification code is essentially the same code as the Asid service, and there’s just a little checkbox you can say migrate my HCV cookie values to my conductor cookie.

All right. Now we’re ready to talk more about what I’m 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’ll discuss more the features that are available there. And we’ll 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’m 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’s additional resources doc, that we’re 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’re implementation is like modern and up to date, a lot of those attributes will already be handled, but you’ll want to make sure that that you’re doing that, default cross-domain tracking that is available through the SCD service requires a third party cookie. So it’s 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’ll just cross domain tracking will work by default. If you’re using a CID service, but with Safari and Firefox, that’s, not going to work. And you’ll want to use a query string to pass the ID across the domain. And we’ll, we’ll 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’t return to the site within seven days. The next time they return, their cookie will have expired and they’ll get a new cookie. They’ll be seen as a new visitor and that will inflate your your visit metrics.

We’ll 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’s 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’d be getting from that.

So we get it browsers are putting limitations on cookies. There’s a lot of implementation paths to help those limitations. But again, what is at stake? It’s 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’t rely on cookies. And we’re going to talk about that in the future. Section. All of the above require, at a minimum, the OECD service. And that’s kind of why we’re I’m calling it the the new if you’re not if you’re not migrated there, that’s kind of a big, big point of this presentation. Okay. So you’re 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’t, implement these cross-domain tracking paths. So this is their idea. Service uses a third party cookie called a. It’s 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’ll be the same because it’s seeded with that, that, third party demo X value. But when that’s blocked, you’ve 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’s 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’s necessary. If you’re if your site stays on the same domain, always.

Like, which isn’t 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’ll, you’ll want to implement these cross tracking, cross-domain tracking features.

Also we’re going to I’ve 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’ll 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’s 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’t 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’d 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’s 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’s a little side note here. It’s become somewhat of a common occurrence for customers to use a third party CDN, meaning they’ll they’ll have a C name on the website, but then they’ll route that not to 51ºÚÁϲ»´òìÈ, but to Akamai or some other CDN hosting server. And then for it to 51ºÚÁϲ»´òìÈ, those flows aren’t 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’ve come across as people have had issues with that. But again, just reiterating 51ºÚÁϲ»´òìÈ managed is really the way we would prefer. And it’s, you know, it’s 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’re 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’re 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’s only available through the AP web SDK. We’ll 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’ll 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’re 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’re familiar with analytics, you’ll be familiar with tracking servers, I think. And I’m 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’t have a C name now, when you’re making that migration, it’s 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’t fully wrap my mind around how that works with Edge and Web SDK, but as a heads up, I’ve seen customer cases where they migrate to web ask don’t 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’s 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’t 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’s 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’ve got a banner where people can choose like I want cookies, but I don’t want 51ºÚÁϲ»´òìÈ Analytics network requests, or I don’t want cookies, and I would allow analytics network requests or not to, you know, you’ve got all these different options. Most people are going to just do, accept or deny. They’re not going to go in and and fill out the form. And that’s just that’s 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’s all or nothing. You can’t you can’t opt in some or opt out of some. And that’s a significant change for implementations using like one trust or other customizable consent experience approaches.

You if you’re using one trust or something like that, and you’re limiting launch rules by conditions, you technically could continue to do that. But using the web SDK consent management, it’s going to be a all or nothing. And again I would review because everybody’s everyone’s a snowflake with these with these consent flows and what’s important to their business. I, I’ve, that document I’ve 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’re there’s a small tangent about tracking servers, edge domains, consent. Now we’re back to cookies and, fp id is a it’s a first party ID it’s 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’s 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’s 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’re going to generate that Uuid server side that’s 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’ll be used to seed the new visitor ID. And and because of doing that process, browsers are live longer. So again, it’s not it’s not a trivial thing to implement, but it it is very useful and only available using the AP website. Okay. So that’s why we got it in this kind of looking forward future section. But it is available today.

Okay. Now we’re 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’t reliant on cookies, and they kind of solve a different problem than cookies do for online traffic. But they they don’t rely on cookies, and they’re less likely to get limitations imposed on them because there isn’t really a thing like a browser in this space that could limit them.

So in an analytics, we’ve got kDa or cross-device analytics, and in CGA there’s 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’t 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’s 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’re they provide a broader scope to your visitor data, and they don’t replace the online data that’s 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’m not going to be given an in-depth instruction for how to implement these stitching options, but I’m going to go over the prerequisites and kind of directions for getting started. And again the additional resources will have more documentation to help you double click into it. CDA is again cross-device analytics. It’s a feature of 51ºÚÁϲ»´òìÈ Analytics doesn’t require AP or CJA.

But you do have to have a contract that includes the 51ºÚÁϲ»´òìÈ Analytics Ultimate skew, and CDA is enabled on a report report suite by report suite basis.

It helps give this more person centric view by augmenting your web data with device and offline data and or stitching that data together.

It’s worth noting that you have to update your implementation to take advantage of this. And it’s not just a flag on a report suite. You need to implement set customer IDs function within your, web data. That will help create a user specific repository of device IDs and and your other data. Sorry, you’re off your web and offline data. This is, change that would need to be implemented by your development teams. And within your implementation code. And then with the field based stitching options, you collect. So rather than using set customer ideas, you would use kind of your own authenticated ID that identifies a person on an idea that’s on a proper and ever. And that would also require updates to your implementation potentially, if you don’t already track, data consistently like that.

Okay. And for CJA stitching, it’s really similar.

It fulfills the same general function, but it’s only available for CJK customers, obviously. And it’s built off the data in your AP data set. So if your, like the, the idea is that your AP data set has data from many different channels that share a unique ID at some point in their user journey. Then a kind of like web of those IDs can be stitched together to to tie that information all together.

It can improve this, this can again improve the scope of your visitor data. It’s not intended as a replacement for your online data. It’s less cookie dependent and and very useful. But again emphasizing like to use CGA stitching. This is an even bigger leap.

For people that one aren’t CGA or AP customers. That’s a really big paradigm shift. So this may not be an option for everyone, but if you if you are using CJR, AP, it’s definitely, good option to look into.

And now to just kind of wrap up, I’ve got two more slides here. I’m going to talk about next steps and key takeaways. So again at the beginning we had this timeline and people could, you know on this call could be at any point in that journey. I hope if, if this was kind of this kind of began much further than you’ve progressed, maybe it can help just further understand any, any concepts or dispel any misconceptions. But, the first thing you want to do is if you’re not on a C name, migrate to a C name, it’s not going to affect your cookies, but it’s going to let you, it’s going to make your implementation more modern and take advantage of newer features, as well as prevent your data collection calls from being blocked by ad blockers. You want to migrate to the SCA service to take advantage of these features or the web SDK, so you can take advantage of the ID and these other, data collection options. And just to to stay with the times as new features are developed, they’re going to be developed for these, newer libraries, especially the web seeker.

Also website can help your load times. It’s less about visitor identification, but that’s a it’s a real benefit. It’s more efficient. And it has these more up to date features such as the speed. And that will improve the longevity of your visitors as they’re tracked in Safari. And finally, you can consider other options that are less cookie dependent.

Okay. Key takeaways browser limitations. They’re going to continue to evolve. It’s we’ve come a long way in the last, you know, decade.

And the the real key takeaway there is to keep your implementation modern. There’s always going to be something new. And as you keep with the times, you won’t get stuck in these hairy situations where the migration paths aren’t as as clear or clean. AP well, as the case, the next big step for most customers, it’s not trivial to, migrate, but it’s it’s worth it. And it’s necessary to to stick with the times and have a modern implementation. And finally, again, consider augmenting your your online data with these offline channels through stitching. And yeah, thank you everyone for for tuning in this morning, spending all this time with us.

We’ll do our best to address questions in the chat. And, again, if we’re unable to get to your question, please review that documentation, open a support ticket and let us know how we can best help you.

And I’m going to be, yeah. Looking through these.

Okay, Damon has a question here. We’re on the SDK currently. Website. Okay, but we’re sending data to 51ºÚÁϲ»´òìÈ Analytics rather than to, to C-j at this point is how I understand it. And you’re wondering, is it a good idea to migrate to using Spid before, migrating to sending data to CGI? And yes, absolutely. There’s no you can you can definitely migrate to using Spid now, as long as you’re just as long as you’re using edge.

Now is a great time to make that migration. You want to have to wait until you’ve implemented, like, a schema, and, and data collection for CGI or AP specifically if you’re just sending data through a data stream to, to 51ºÚÁϲ»´òìÈ Analytics, that’s fine. And you could start using, the Spid feature through the SDK. Now, that that is great.

Looking at some other ones here. Yes. Is there a easy way to determine whether you are using the Sid service? Yeah. What what Brian mentioned there is great. You can you can also use this. How do I, I’m trying to see how I can respond in the chat right here. Okay. You can also do this s underscore c underscore I l will show all of the libraries used on your page.

And, that’s gonna include, your visitor ID, service, app measurement, your analytics library. If you’re using alloy, then s underscore and C underscore file isn’t going to return anything. But if you’re using visitor ID service, you’re going to see a visitor object in there. And that’ll tell you another simple way to tell would be to look at your cookies. And if you have an amqp cookie then your you’re use any Sid service.

Okay. There’s, a question from Annie, too, that I’d like to address, too. So it says we migrated to web SDK and AP and as a consequence, lost some tagging, a lot of tagging data with AMP, CV. We could send tags without a cookie. With the conductor cookies, it’s apparently not possible. And they’re always sent. So compared to our previous situation and they were set back and set up for it. So there’s a little bit to unpack there that like I would love Annie to talk on, on a support ticket in more depth. I, I do know I think this is kind of coming into the consent realm where, like you, you could have a, granular approach for various solutions. So I think it’s possible maybe, like, you could block a, a target cookie or a target flow, but keep an analytics cookie or an analytics flow. And I could see that, I could see that scenario being maybe the case here. In general, the cookies shouldn’t be like preventing data from being sent. It might cause like blips in this visitor identification. So it looks like there might be something else going on there that I would that like. I would love to get more information and double click into but that’s that’s good feedback. I again I just reiterate like migrating to the AP web SDK isn’t it’s not trivial and and you you do want to do a lot of like testing because it is possible that, you know, some flows aren’t aren’t supported in the, in the AP web SDK, but I don’t want to jump into like too many conclusions there. But, yeah, I hear you there. And and maybe that maybe looking into that consent documentation could help. There might be options to kind of mitigate whatever flows were were lost there.

Yeah, I will keep looking here.

Okay. This is a great question. Well, migrating to AP whether CDK affect, 51ºÚÁϲ»´òìÈ target implementation. So the web SDK includes all of these, all of the various solutions like 51ºÚÁϲ»´òìÈ App Measurement or the Atlas code. So you can implement 51ºÚÁϲ»´òìÈ Target with the web SDK.

But it is possible to have an implementation where like you’re using web SDK just for your analytics data collection. Like maybe you’ve just, you’ve just migrated your analytics implementation and haven’t migrated, target yet. And there shouldn’t be any, you know, real there shouldn’t be any real technical reason why you couldn’t do that. I think most migrations, you know, could do like, a fragmented approach, redo one process, one solution at a time or something.

But there shouldn’t be any, any real reason why you couldn’t do that.

But eventually would want to like a real benefit of the API is that all of the solutions can be implemented through it. So you would eventually want to one of migrate everything.

Okay.

Oh, okay. So there’s this question about. Yeah, using ECI service and first party tracking server. You’re collecting data. You’re you’re getting IDs. You can see that by using the, the, underscore satellite functions, but somehow, instead of getting one unique visitor per those x id values, you’re getting multiple. So in 51ºÚÁϲ»´òìÈ Analytics reporting, it doesn’t expose these cities. So I think I think what you’re saying here is you’re capturing that asid, Rajiv on like a, some dimension, a proper and ever. And then when you look at unique visitors against that proper and ever, you see multiple visitors. This this scenario typically occurs when a site has, has, some other means of visitor identification, for example, an SVI cookie. It it may not be the case for you, but a scenario that would explain that would be if grace period were enabled on your implementation, then visitors are still getting this SVI cookie and that is actually what is identifying visitors.

Because it gets like it’s preferred in the hierarchy of visitor IDs. So there could be a scenario where let’s say you have one, one section of your site, like let’s say you have two different browsers, sorry, two different domains in your website, flow and grace period is enabled. Then on those two different domains, the visitors might have the same Ssid service through the cross domain tracking. For example, in Chrome. That would work, but they have a different SVI cookie on those two different domains. So that visitor in the back end is actually being identified as two different visitors. So that’s a possible explanation. I don’t know exactly what it is in your case, but if you open a support ticket, that’s something we could help help dig into and explain. That’s a that’s a great question. And, the scenario that can definitely come up.

Okay. There’s this question here about consent. So it says our biggest challenge had been about consent, where users do not accept a cookie, and echidna always requires a cookie. That’s that’s true. It. Yeah. Like cookies. If someone doesn’t accept a cookie, it really just wrecks this visitor identification. And it will, you know, basically any time they come back, they’d be a new, you know, unique visitor. It sounds like the website doesn’t fundamentally change how easy it works in terms of the dependency of the cookie. That is true. ECI service is going to have a different cookie conductor cookie, but it still has this mid. And if anything, the biggest difference between ECI service and web SDK is that web SDK will more, kind of aggressively set a cookie. Any time you hit the edge network, even if it were to set consent to false or opt out, every request edge network is going to return a cookie. So if you have a limitation where you need to prevent a cookie, then in the AP web, ask paradigm, that would essentially mean just no data collection is allowed. It would it be under the same class of option as just completely opted out? If they if they don’t accept a cookie, then the only way to not get a cookie is to not collect data.

And that goes into this idea of like having different options accept a cookie or decline a cookie and accept data collection, or accept data collection and decline a cookie. It’s just usually users don’t get that granular, and it’s just if it’s a negative response, then it’s just don’t do anything.

But it’s a good thing to note if you need to prevent cookies and web SDK, it’s a little more, aggressive at setting cookies. You would want to just. And that that’s in the documentation too. That will will send out. So I definitely look at the AP web SDK consent documentation.

Looking at some more here.

Oh, okay. This is a this is a great question. Igor asked. We tried to use the visitor, append visitor IDs to the cross-domain tracking function, and it’s. There’s a tricky problem. If the destination domain already has a link to acid, it will ignore the past one. And that is the default behavior.

But there is a option to overwrite. You can tell the destination domain to always overwrite with a mid if it’s in the creation parameter. That’s a much more common flow in mobile flows. But let me get that doc for you right now.

It’s call it something called like overwrite marketing cloud ID.

Overwrite cross-domain msi ID is what that feature is called. I will send that in a reply here.

For one, okay. RuPaul. Yeah, that’s a this is a really good question. And I do kind of gloss over this. It’s like, we’ll make sure that Safari and Firefox never delete the visitor ID cookie after seven days. Not very clear to you. I wish that were more clear to me as well. I just have to admit my own ignorance there. Because I agree. Like documentation I’ve read has been a little bit unclear. I know that it extends it longer than the seven days, and I’m not sure if that’s variable, but, definitely. I know I’m kind of leaning on these additional resources that’s going to come out in the follow up email, but consulting some, some 51ºÚÁϲ»´òìÈ consultants wrote a really good outline for how to implement its usefulness. And I would I would, just review that and and look there for that answer. I don’t I don’t know the answer off the top of my head now, but, I do know that it won’t it won’t make it, indefinite. That cookie will still expire. It just increases the longevity of it.

Okay. Jacob asks, if we are linking to a third party site. So your website goes to a third party site. Is it still recommended to use the append visitor IDs to function? Or will be, or should you exclude those links? Yeah. In that scenario, the the destination domain is only going to pick up the ID from the URL if it shares the same marketing cloud or guide. And so in the case where we go into a third party site, they’re not going to have your tags implementation on it. So in that scenario, the it’s not going to hurt anything. But I also want to help anything.

So I think if it became like, a roadblock for development to exclude those links, then I would just include it. It’s not going to hurt anything. But just know that it’s not. It’s not necessary.

Yeah. Let me type that here.

Okay, Rajiv, you say you don’t see, Svi. Cookie.

It says you don’t then see, svi cookie. So we wouldn’t expect to see us via cookie if did service or, web SDK is being used.

It also, could it, it could be a third party cookie and it could be blocked.

Also not used when exit service is implemented.

And grace period is not enabled.

Yeah. And I’m going to respond also to your message here. Achieve.

Okay. Yeah. I think this is probably our last question. We’re going to have to wrap up, but, will we still have a damn cookie after implementing the AP website? And the the answer to that is yes. The web SDK still uses the CID service library. And, and that’s why we still need those. The I, append identities to URL function in the Weber. Okay. So yeah.

And yeah. Thanks again everyone, for for coming and for your questions. And again, if we can’t get to your question, please, please open a support ticket and we’d love to help you out. Perfect. Thank you so much, Garrett. And also, thank you so much to Brian also for answering so many of your questions. And most importantly, thank you all for attending Tech sessions. Just a reminder, in about 24 hours, you will all receive a link to this recording and will also be posted into experience for you guys to rewatch and share. Thank you again everybody! We hope to see you again in our next session. Bye!