George Jagodzinski (00:00):
Today's episode is part of a miniseries that we will be peppering in amongst our other interviews. For this series, we go inside the walls of Intevity and hear from experts who are doing the hard work to help our clients. We discuss the patterns and the pitfalls, and we glean some insight from their many years of experience. I love showcasing our team. They're solution-obsessed, and in my very biased opinion, I think they're some of the best out there. Let's hear from the team.
(00:34):
Welcome to Evolving Industry, a no-BS podcast about business leaders who are successfully weaving technology into their company's DNA to forge a better path forward. If you're looking to actually move the ball forward rather than spinning around in a tornado of buzzwords, you're in the right place. I'm your host, George Jagodzinski.
(00:59):
Today, we're going to discuss the death of the cookie. What the heck does that mean? What's the impact? What should people be doing? Let's just start with the easy question, I guess, which is what does that even mean, the death of the cookie?
Donal Casey (01:12):
Basically, what's happening, Chrome is making a major change to its browser. They are sun-setting the use of third-party cookies, basically, default-deny. This is all under the guise of privacy for the consumers. This has been a long time coming. They've actually been talking about this for about two-plus years. It's been deferred and kicked off for various reasons, including litigation, but also just the implementation wasn't ready for the new Google privacy sandbox and the proposed future.
(01:45):
But they're trying to harden the way that advertisers access information about its users and what type of information is actually transmitted between site-to-site.
Eric Webster (01:56):
Is this all cookies or are there specific cookies that are being targeted here?
Donal Casey (02:01):
No, this is limited to third-party cookies. The difference between cookies first-party and third-party. First-party cookies are anything that you write and distribute within your own domain, within your own four walls. Third-party cookies are basically bits of text that other sites have access and track behaviors from site to site to site.
George Jagodzinski (02:25):
The impact. Is it just ads, or is it more than that?
Donal Casey (02:30):
It's mostly ads. It's definitely targeted and centered around advertising. That's the general use case for third-party cookies. But there is some functionality that might be dated that could still rely on third-party cookies, such as single sign-on services that could be impacted.
(02:50):
The call to arms here is really pay attention to not only your advertising and analytic performance with other vendors and not Google Analytics specifically. But also, you should blanketly test your site using the provided tools and mechanisms by Google to audit for site functionality breakages. It's unlikely, but if your site contains a shopping cart and real dollars are exchanged, I would be hesitant to not give an audit a try.
Eric Webster (03:23):
Donal, when talking about impact, as well, there's a lot of impact potential for people who had just analytics on their applications and weren't doing anything specific with third parties, correct?
Donal Casey (03:33):
Absolutely. The types of analytics that you have on your site really matter here. I think it's super common to have Google Analytics tied to your site. Now, that's protected. Google has made sure that its solutions are trued up. This is actually a topic to get into a little bit as well.
(03:54):
It's a little bit nefarious, this action that Google is taking because it really takes power away from other solutions. Whether they're advertising, which good, I'm all for privacy. But also, other analytic solutions as well would have access to less data. Google has made the move a year plus ago from their usual gtag implementation to what they're referring to was the One tag. The reason why it's called the One tag, if you read their documentation, they actually call it a first-party cookie approach even though they are, themselves, a third party. But effectively, their systems are able to talk to each other with zero impacts on this change that they are making. Google Analytics, Floodlight, Google Ads, 360 CM all are going to be fine. They're still going to be able to access information. If you browse between sites and they are implemented with a Google product, such as Analytics, Ads, or other, that information is all still going to talk to each other in Google's proprietary way.
(05:02):
What everyone else is going to have access to or needs to adjust to is this very limited set of information that's really more topical. Not, "You're this age in this geolocation with this set of interests." I think there was a page that they used to share back in the day. I'm not sure if it's still up, where you could actually see who Google thought you were. It would provide an output of your, "Here's your interests. Here's a list of things that you're into and other sites that you browse." Everyone else is just going to get subscriptions to basically topical information. "This person likes to shop. They enjoy the color pink." They're really not going to have access to the same level of information, such as your age and address details.
Eric Webster (05:52):
Just last question around impact... What is the ownership of this problem? How is Google transferring over and who are they transferring it to?
Donal Casey (06:02):
It's really on the vendors. This is a tough scenario because a lot of these pixels and trackers, sites will just add these. It's very common, over my years, too, if we need a solution for tracking or ad retargeting, any sort of metric data, user journeys flows, it was a common process to just get out the company credit card and add the new tracker. Hopefully they promised some sort of lift against conversion or other that they can demonstrate. All of their individual solutions, these vendors, they're relying on the old cookie mentality that is suddenly going away.
(06:47):
It's not individual products and companies that need to respond to this. It's really on the advertising vendors. What makes this extra tricky, I just mentioned that it's very common for sites to build up a roster of these types of vendors. Each one of them is going to have to respond to this in their own unique way. It's extra critical, one, that you know who is on your site. Do a site audit, know what tags are in use and what's required, what's critical to your business. Then reach out to the vendors and ask them, point-blank, "What is your response to this change coming up? How is your solution going to be impacted? Is there anything we need to do on our end?" There are avenues for adjusting to this technology using the Topics API, partitioning cookies for more bespoke or custom solutions. But really, the onus is going to be on each individual vendor.
Eric Webster (07:47):
I know the funny thing is I saw it as more of a move of taking ownership as the provider, as the person who has the analytics to say, "Okay, great. I'm no longer going to trust this third party to do it. I'm intentionally going to make everything a first party cookie," and then send that integration over to that third party vendor. Basically, the property that owns the analytics now is in charge of the data, but then you're taking on more work than you used to.
Donal Casey (08:11):
There's a bit of a push-pull happening right now with this as well, where vendors are taking the opportunity to tell uninformed or maybe not-ready clients to say, "Hey, this thing is coming. You have our client-side cookie or solution implemented. Can you turn on this server-side offering?"
(08:33):
Just to explain that a little bit. Client-side, when you load up a website, you browsing that site, you're considered the client. There's a bunch of scripts, third parties that load. They could be Google Analytics. They could be other affiliate vendors, and other trackers. Server-side implementation is when that site that you were browsing moves these solutions to 100% server-side. It disconnects the vendor having access, direct client access to your browser window. Basically, the site you were browsing sends over very explicit data. If it's conversion flow, they're sending over what's being purchased, if they collect hashed emails or other. They're basically doing this for conversion tracking.
(09:24):
Everything is a data negotiation with these third parties. Unfortunately, the default side of that is they'll always ask for as much data as they can collect. Being or having access to the client side is the goldmine. Because even if you send things explicitly to an endpoint, they have access to the client. They can check the window referrer objects. They can see all this other behavior. Up until now, they could see all your other cookies and all this other information by all these third parties.
(09:57):
This isn't the solution. The move to server side is not the end all, be all here. Yes, it will work for some things. But what I've found - almost all of these vendors in that data negotiation where more is more, they still want you to keep the client side turned on, which is extra nefarious.
Eric Webster (10:17):
They want both.
Donal Casey (10:18):
Yeah, they want it all. Wait for it to break and let them respond, basically, because if they get some data, it's more data. That's what they want.
George Jagodzinski (10:28):
Kind of like Mother Nature, advertising always finds a way.
(10:32):
Evolving Industry is brought to you by Intevity. We bring order to chaos wherever people, process, and technology converge. Our culture drives our solutions, and we are solution-obsessed. We see every challenge as an opportunity, every partner as a collaborator, and every project as a chance to share our values and commitment to excellence. Give us a shout. We'd love to hear your challenges and turn them into opportunities. Find out more at intevity.com. Now, back to the show.
(11:01):
With all of this, will our privacy actually be better? Or is it all just window dressing?
Donal Casey (11:07):
To an extent. There is basically a fire drill going on that is going to shut off this connection to a slew of vendors. But Google's really positioning themselves as the identity management authority. That's problematic. They're still going to have, like I mentioned before, access to their own solutions as first-party. They're not going to be impacted by this.
(11:36):
Google's sense of view is going to go up still or continue to climb. Imagine all these other vendors, too, if they rely on anyone else that requires third-party cookies. They're considering now moving to Google as an out-of-the-box, potentially free solution. We're just going to end up giving more and more data to Google. Google is also the lion's share, I would think, with its suite of products because startups, mid-size companies. Why pay for an enterprise solution that you have to custom tailor or do things on your own side anyways when I can just drop a gtag on a site? All that access you see in Google Reporting, some of this changed with the move to GA4, where you had to be a little bit more explicit. But you don't need to add custom events to the site. They know when users are checking out. You can plug and play out-of-the-box metrics. How do they know that information? It's just their client access to your website.
Eric Webster (12:40):
Yeah. Talking about security and making it better, we've seen some really weird things that third parties were doing. Can you talk a little bit about some of the challenges that we were seeing with the landscape as it was, where third parties can just scrape other third party cookies as well?
Donal Casey (12:57):
Yeah. This messaging is really for if you own a web property, listen up. Client-side access is always tricky because you're basically giving your user's browser to these third parties. They have access. They can scrape for information. Even if you have an agreement, a contract, and an endpoint that says it's sending over just purchase IDs, the amount total, and other, it's really a lot of trust that they're not just binding of event listeners to the page.
(13:29):
Really, we have to discuss the architecture of these things. When I load up a third-party pixel, say a Meta conversion tag or an Instagram tag, to an e-commerce site, basically, you're loading up their third-party script. It'll be a main JS file, and you build the data points that you're sending to this endpoint. But ultimately, you are side-loading to your page, a third-party script that you have no control over. You don't host it. It's subject to change at any time. It's their proprietary solution. What that script could be doing is actually just loading other scripts.
(14:12):
That's actually happened in the past. We use site auditing tools all the time. What you find is a lot of piggybacking scripts. Not everyone rules their own solution from the top down. This is including your vendors. If they need a piece of functionality, they might load another script from someone else. What was actually happening in this case with an ad retargeting pixel that we had on our site, they had a sub-process, a third party piggybacking script. That third party was actually a Russian domain. Inside of our TrustArc modal. We had to swarm on this pretty quickly, especially question tensions rising high at the moment, to ask the vendor to break ties with this, put them on a disallow list, remove it from our modal and ensure that their property wasn't including this script onto our site.
(15:08):
These scripts can be guilty of all sorts of things. This one, in particular, actually had an event listener that was just blanketly attaching itself to every form input field on the site. Newsletter signup. But also, think about a checkout form submission with credit card information and others. On every key press, it would send the totality of information that you provided in that input to this third party.
Eric Webster (15:36):
Regardless of whether or not we'd like this solution any better, the Google, "Trust us, we know best," a change needed to happen. I feel like Google spent a lot of time trying to figure out the right way to attack the problem. What were some of the other ways that they were talking about potentially doing it?
Donal Casey (15:52):
Pretty much. The privacy API sandbox is the premiere solution. They also have an approach with partitioning cookies called Chips. You basically need to sign off and configure a very specific way if you are going to share these details, which is good, because then you're adding auditing to the process.
(16:13):
I agree. A big shift needed to happen. We've been trying to move server-side with everything for what seems like a while now. The hardest challenge there just goes back to these third parties that originally both the client-side and a server-side thing turned on. But ultimately, you should be sending explicit information.
(16:34):
There's another benefit that's going to shake out of this as well. What better way to perform an audit against your site with what details you send to third parties by just setting fire to the field, so to speak? If everything breaks immediately, then you're going to know who your bad actors are. You're going to weed a lot of things out and figure out what was critical to the process. It's almost like, "This credit card has gotten old. Let's cut it up, and cancel it, and start fresh because these subscription costs have gotten insane."
George Jagodzinski (17:06):
The kind of scenario where, all of a sudden, everything breaks, or is it going to play out differently?
Donal Casey (17:11):
Actually, we're marching through the timeline. It started Q1 this year. 1% of users actually experienced this new paradigm, where their browser is set automatically to deny cookies. There's a few fail safes in place. Mainly, part of the utility for auditing your site is opening up developer tools. You might have noticed this if you've done this recently. But there's now a couple warnings at the bottom that display with a count of how many cookies tried to be read by a third party or what was written by a third party. The warning states that, "These are going to be subject to break once we move full-time to this process," sometimes, I think, at the end of Q3 this year. But with that, if a site has a lot of infringes to this, or a lot of warnings and a site's not able to perform, there's actually nothing you have to do. It should automatically cut over as of now without experiencing breakage to the end user.
(18:17):
Now Q3, when this goes 100%, I don't think that's going to continue to be the case. There's a couple things going on right now. One, Google has been deferring this for some time. There is actually open litigation in the EU right now that I think they have outstanding questions that they need to answer before they turn the clock 100%. But there's also items that clients or web property owners can perform, such as filing for an exemption to this as well. I'm not sure if that's the preferred path. I don't know how many exemptions they're going to grant. But there should be time this year to respond and if your site breaks, there is a fallback process. Hopefully, it works.
George Jagodzinski (19:11):
Q3 is a scary time for e-commerce people. That's back to school, and it's right before the holiday season. I would imagine it's going to be important to prioritize this over the summer to make sure things are buttoned up.
Donal Casey (19:24):
That's part of the problem as well. If you raised this ... I've been trying to advocate for doing the appropriate auditing steps within the clients that I work on 100%. There's a couple different mentalities going on.
(19:40):
One is that now is a good time to clean house. But also, like I was saying before, it's very easy for a company or a product to treat advertising as the low totem priority. It's hard to promote this as something that we should absolutely be auditing for. First and foremost is site functionality. It's easy. If you go to the developers.google.com/privacysandbox or search for the Privacy Sandbox, Google third-party, Google deprecation, there's very easy documentation that's out for ways that you are able to test this. Including turning on a Chrome built-in flag setting, "Turn off third-party cookies," to test for this deprecation. Easily, you're able to audit your site for any functionality breaks.
(20:43):
I would highly recommend... My premiere client has a weekly QA regression schedule. I was able to pitch for, "Why not just have them turn on this flag for this week's QA regression?" It's something like 30 QA engineers placing test orders in lower environments. Happy to report no carts were lost. None of that critical functionality was lost. Still have yet to talk to each one of our vendors.
(21:13):
That's probably the hardest part here. If I were to implore anyone what they should be focused on, now's the opportunity to audit your site for what tags you're actually using and leveraging. Build up that lost roster of who's the owner on our side and who's our point of contact on their side, and begin having these conversations. How will this impact the vendor, and what are you doing to respond to this change?
George Jagodzinski (21:41):
I'm always curious on these things. Web, you might remember this. Any time we do an ecosystem audit, and we map it our for our clients, they're always surprised how many systems are in there. I think the same thing applies to tags. Donal, also, I'd be curious, pre and post-audit, how shocked are people at how many tags are actually in there?
Donal Casey (22:01):
It's always shocking. I feel like I've been raising the flagon the number of tags that we've been using for so long. So many of them are duplicative or redundant. It happens naturally. You're always merge, appending a new tag. You're never taking off or removing tags. There's never that process. It's, "No, I need Hotjar. No, I need AWIT. No, I need this added to the site now. They're promising this lift." No one's going through and saying, "We've had them on for so long. Are they still performing? Can we remove this?" They just see it as additional lift add. Everything is add, add, add.
Eric Webster (22:40):
They're still collecting data while they're connected to your application as well. Just because you're not using their service doesn't mean they're not pulling the data.
Donal Casey (22:47):
Absolutely. Yeah. Even if you're not ... A lot of these will have campaign dashboards where you create campaigns and try to help the funnel process. Exactly like you just said, if you're not leveraging them for any sort of campaign functionality, then it's just free data that you're shoveling off to a third party. It's valuable data. Data is money.
Eric Webster (23:11):
Outside of just the security concerns, we talk about all these tags being on the site, talk about the performance concerns and some of the benefit uplift you get from going through that process.
Donal Casey (23:21):
Yeah. It's exactly it. Developers know, but for everyone else, if you add another embed to your site, if you add another point of JS to your site, it's a performance cost just to download the thing. If you're talking about I'm in a global market, we're broken out by region, North America has something like 66 vendors for one of clients that I'm working on. That's 66 JS files that were loading. HTTP2 only can load 12 concurrent files at a time. Depending on how you load those tags, hopefully, it's deferred. Hopefully, it's async and kicks to the lowest part of the page. But if it's loading up higher, you're basically breaking or delaying the user's time to interactive. When you load up a site, and you can actually click on links or get that product into your cart, you're creating a disconnect.
(24:17):
I think users, you'll see this data everywhere, have a massive distrust with sites that do not perform lightning fast. I think the acceptance has gone from, when I started it was something like eight seconds was great. Now it's something like if you don't load in .5 to two seconds, something's majorly wrong, and users get suspicious of your site.
George Jagodzinski (24:40):
Yeah. Gone are the days of going to get a coffee while something's loading. We're aging ourselves a little bit on that one. But it's funny. I swear, we didn't mastermind this. But that connects directly to the episode that we did with Jason Anthony, where it's like, "Those performance increases directly relate to increased revenue numbers that you can have." The optimist in me just hopes that this forces the discipline that people will get their arms around what's really on your site, what's embedded in there. Then also, be more intentional about what you're doing with the data and build better experiences around that intentional use because you're going to have to be smarter.
Donal Casey (25:18):
Absolutely. This is going to force a massive paradigm shift. It's going to really promote and cause a closer eye on all of the things that we load to our site. It's going to impact your marketing departments. There's going to be a lot of maybe tough conversations coming down the road. But ultimately, from Google's position, now's the time to have them.
(25:41):
I think there's a video out there describing why by Google. They say something like, "We built the house, and we didn't know what the intent was going to be. Now that we know what these things are used for, it's time to start regulating them." That's true. This is just going to cause a major shift. Hopefully, it won't be real immediate dollar impact to your shop, but advertising is certainly going to take a hit. Like you said, Q3, we're going right into the holiday season, a big time for e-commerce platforms.
Eric Webster (26:19):
I will say this, is that this is a real tinfoil-lined hat. It's on tight. I firmly believe that there are parts of the Google organization that I don't trust. But Google has always been a company that's trying to build a better web. They really are. They see this as a major issue across all sites. If it's performance, if it's security, it's a problem. They've been really, really slow and careful about how they're rolling this out. Sure, it's anticompetitive a little bit because they're basically using the fact that they have the biggest browser stake and they also have one of the biggest analytic platforms, and they're tying those two things together.
(26:54):
But at the end of the day, this is a great move for people that own a web property and for the internet as a whole. We do need to find solutions to get around the problem. A lot of the analytics - and a product costs you $29.99 a month, or whatever it is, but they're offsetting that with your data. But now, this gives you, the property holder, the right to go, "Hey, I want that product. I'll trade you some data for that product," and you get to own that a little bit more. Whether or not it actually turns out to be that way, or they just try to figure out some sort of way to get the product and data for free again remains to be seen.
George Jagodzinski (27:31):
Do you guys think that this finally pushes a lot more people into being great with zero-party data, or does that can get kicked down the road with the workarounds?
Donal Casey (27:43):
I think it's going to force it a little bit.
George Jagodzinski (27:45):
It has to.
Donal Casey (27:46):
Yeah. I don't see any other way, which is ultimately a good thing. That server-side we've been pushing for, yes, right now, they're using it as a two-handed play, "Let's get both," but that has to change at some point. That's ultimately where we need to go. That also saves performance and increases security and privacy as well. That's the ultimate move that needs to happen. Google's in that camp as well. You can load Google Ads server-side. No one needs access to the dom, and if you can defer all of that traffic, all that performance cost saved, and privacy and security saved, that is where I'd like to see this go.
George Jagodzinski (28:26):
Yeah.
Eric Webster (28:26):
There are platforms that their sole existence is to be this data layer for you. You can feed it from any port, and you can pull from it at any port. There definitely is going to be a couple of new industries born out of this, product lines, but I think those are very real products that definitely need to be used.
George Jagodzinski (28:45):
Yeah. The optimist in me hopes that, somewhere down the line, zero party done well creates better experiences for us as the consumer. Ideally, puts maybe some of that ad spend back in our pockets rather than exploiting our data a couple layers up. But I also know that might be a little naïve.
Donal Casey (29:04):
Well, think about the challenges this is going to put for the entire media market. The entire media industry is built upon the fact that I'm pulling data and I'm reselling your data. When I can't do that anymore, what happens to all those free services that we know and love?
George Jagodzinski (29:20):
Then AI happens, and it fixes everything.
Eric Webster (29:21):
That's true.
George Jagodzinski (29:22):
You buy three AIs, and everything's good to go.
Donal Casey (29:26):
Solved. Ship it.
George Jagodzinski (29:28):
Well, this was fun, guys. Donal, thanks so much for joining us. I always like to finish with one question, which is what's the best advice you've ever received in life or career?
Donal Casey (29:37):
Oh, in life. Oh, I would just say stay curious. Always pull on that thread.
George Jagodzinski (29:44):
I love it. Well, me with the name of George, I'm always down with that. Curious George, I'm a big fan of. All right, gentlemen, thank you so much.
(29:53):
Thanks for listening to Evolving Industry. For more, subscribe and follow us on your favorite podcast platform, and pretty please, drop us a review. We'd really appreciate it. If you're watching or listening on YouTube, hit that subscribe button and smash the bell button for notifications. If you know someone who's pushing the limits to evolve their business, reach out to the show at evolvingindustry@intevity.com. Or reach out to me, George Jagodzinski, on LinkedIn. I love speaking with people getting the hard work done. The business environment is always changing, and you're either keeping up or going extinct. We'll catch you next time. Until then, keep evolving.