Questions
- What is the difference between a 1st party cookie, a 3rd party cookie and a server-side or http cookie?
- What impact does the loss of 3rd party cookies in Chrome actually have on businesses?
- How, if at all, does this apply to mobile apps (native + wrapper)
- Should we be planning for all cookies being deprecated at some point?
- Does moving our tracking to server-side solve any of the cookie challenges?
- Are there certain types of tracking that just can’t ever be moved server-side?
- What technology options are there for server-side tracking and are these all or nothing solutions?
- How do the changes to Consent Mode that Google have imposed upon people get affected by all of this?
- How should a business get started planning what to do and putting a process in place to improve their current position while also avoiding getting themselves
- trapped with technology
Answers
1. While third party cookies are their own thing entirely, actually when we talk about HTTP or server-side cookies we are still referring to first party cookies.
First party cookies refer to any cookie that is being set directly on your site. Now that could be via code that runs on your webpage (traditionally how AA/GA/Ads/Facebook do their first party bidding), or it could be via a HTTP network request.
So we hear the term “HTTP” again, and that’s where HTTP cookies come in – they are not set from scripts, but instead from network requests. Although these are set from the server, they can be read from other scripts on your site. By contrast, true server-side cookies are set by the same HTTP method, but they can only be read by server-side scripts themselves. The main benefit of these true server cookies is that they have no limits at all in terms of expiry. But as server-side tagging remains in its infancy, for our purposes their limitation remains the lack of site readability. With vendors such as Facebook and Google already embracing this new approach though, it surely won’t be long before many others follow suit.
As any script on your site can drop that first non-HTTP form of first party cookie, we’re seeing browser vendors trying to clamp down on the potential risk to security and user privacy that this poses. But HTTP cookies can only be set by a conscious effort of your site’s server, so that’s why browser vendors are less concerned about them, and because any site tags can still read them they’re a great way to improve your first party cookies without having to change how your current tracking behaves.
The main improvement on offer with HTTP cookies is of course how long a cookie is able to exist. Tech like Apple’s Intelligent Tracking Protection has long sought to limit the lifetimes of cookies (and indeed any data) set by site scripts alone. We’re at a point now where any cookie set by a script will expire after seven days of Safari usage at best, but it could expire in as little as 24 hours if certain tracking parameters were detected in the page URL where the cookie was set. With an HTTP cookie there are in theory no such limits to the expiry timeframe, meaning you can identify repeat visitors more reliably, personalise customer experiences more accurately, and measure campaign attribution for much longer.
The downside to the HTTP cookie approach is that you often need direct assistance from the site developers to implement, unless you have a very specific sGTM setup, and few tag vendors provide detailed guidance on how to compose their cookie values. So it can be a lot of effort, and it’s definitely worth considering how limiting a 7-day cap really is for your particular site before jumping-in.
While the mechanisms for setting third party cookies are pretty much the same as we’ve just discussed above, the difference is that the same third party cookie can be read from any site that loads the same tracking code. This introduces a cross-site / domain element that has traditionally made third party cookies incredibly useful for ad targeting and measurement. Unfortunately the days for these are truly numbered, and no direct workarounds exist like they do for first party cookies right now – we cannot just set them using a different method for example. There are ways to lessen the impact though, which we’ll no doubt explore later.
2. Let’s dive deeper into that theme of advertising / ad targeting then. With third party cookies we are able to identify the same person across multiple sites without any manual setup work being required. So if they view several items on site A, then a further few on site B, we can quickly build-up a profile of their interests and desires. We can then target them on site C with ads for products that are specifically crafted from their online behaviour – products they viewed, added to cart but never bought, and so forth.
Best of all, when they return to site A or B to buy the products that were shown to them on site C, we’ve stored third party data to tell us that’s exactly what happened so, even if they don’t come back directly, we can ensure the right credit is attributed to the banner they saw.
This is the use case that browsers phasing-out third party cookies is really going to hurt. It’s not going to be some apocalyptic loss of all tracking – if you want to analyse behaviour and personalise content on your site alone then first party HTTP cookies are going to do that for you just fine. If you own multiple domains then you can send an id between each one to keep a user consistent between them, or employ more advanced techniques such as CDPs to unify profiles based on a user’s logged-in account id. For now, even users clicking through directly from an ad on a third party site can still be measured using a mixture of query parameters and first party cookies.
Although third party cookies are harder to replace for some certain scenarios, this is not something that has happened overnight, and advertisers have been preparing for it too. Apple began restricting third party cookies in Safari on macOS and iOS with its early ITP releases as far back as 2017, and by mid-2020 it had blocked them entirely.
Because of this we already have some promising solutions to replacing third party cookies, such as the Enhanced Conversions model that is being adopted by many advertisers. This relies on first party data more than cookies per se. If you are logged-in on a site, a hashed version of your email address is sent to the advertiser. The products you view, the ads that you see, are stored against this hashed id. Then if you go to another site and log-in, provide your email during the checkout flow, or are already logged into the browser with a matching email account, the same hash of your email is sent to the advertiser, creating the cross-domain link between the two sites and the actions you took on them.
Of course this approach favours the big ad networks where customers regularly provide this first party data – users logging into Facebook regularly, or using Google SSO for their accounts across multiple websites. The irony then is that without first party data, this third party cookie replacement doesn’t work at all.
So the recent announcement that Chrome is going to disable third party cookies is not a surprise for many advertisers, and it’s already being handled as robustly as possible. Also bear in mind that Google isn’t just turning-off third party cookies, this is part of a wider introduction of their Privacy Sandbox, and in particular its Topics API. This feature would learn about a user’s interests as they move from site to site, processing and storing it on-device to ensure privacy compliance. Advertises could then draw on this anonymous data for their own specific needs.
Of course, it’s all early days, and as such there are no guarantees just yet. Those who have been following this area a while will recall Google’s previous attempt at this – the Federated Learning of Cohorts – of which Topics is the new successor. We may go through a few further iterations before landing on the full solution here.
3. Anywhere there’s a browser there are cookies. For apps that merely wrap a mobile version of a site, cookies can operate just like they would on any other website. Even with native apps we commonly see mobile web pages being interspersed with native screens. These are called webviews, and they can also store or use cookies.
The difference is that these cookies have always been “sandboxed” – any cookie set for one app cannot be read or modified by another on your device. So the idea of using cookies in apps for the same third party cookie purposes such as ad retargeting has always been a complete non-starter. Instead advertisers traditionally relied upon the device’s own identifier to achieve the same result, which is why there was so much furore when Apple announced the restriction of their IDFA (device id) under the AppTrackingTransparency framework in mid-2021. That’s a discussion outside of the scope for today, but suffice to say that the deprecation of these cookies has no impact on app tracking.
For first party cookies the same HTTP cookie mitigation tactics that we’ve already discussed can be applied to apps that are wrappers or run webviews. This could be useful for setting more persistent user ids across such apps to enhance analytics and personalisation. But it depends very much on the specific analytics or personalisation solution that’s in use – a lot of these app trackers run their own native code for generating ids and storing them within the app’s data directly.
4. That’s not likely to happen any time soon. It’s easy for us to look at what’s been happening with ITP and similar technologies over the past few years and think that cookies must mainly be used for analytics and advertising, but that’s really not the case.
I’m talking here about first party cookies only of course, but in that context sites use cookies for all sorts of things – from simple session management, remembering when a user has logged-in to the site or the items they’ve added to their cart, to core UX preferences such as language / currency, theme (e.g. “dark mode”), and content layout (e.g. PLP / search tiling options). If we simply got rid of all cookies then a huge number of sites would either stop working or become far more cumbersome to use, right now it would be a disaster.
Right now that means any cookies set from the site’s servers, whether HTTP cookies that can be read from the site, or true server cookies that are inaccessible to all but server-side code, are probably safe for a while. After all, Apple states that, “the goal of ITP is to limit tracking while still enabling websites to function normally.”
If I had to guess at the next step for first party cookies I’d say we’ll see the site-readable HTTP cookies drop away over the next few years. In the quest of performance and security sites are slowly becoming ever more server-side, with all content being pre-rendered by the server before it’s sent back to the browser and so forth. This could mean that sites no longer need to be able to read cookies from the browser to work properly, and so HTTP cookies could reasonably be embraced by ITP also.
5. Absolutely it helps for sure. Continuing on from my last point about how all first party cookies may eventually only become accessible, or at least stay without restrictions, from the server-side, it’s clear that starting to implement a server-side tracking strategy now would insure you against such a situation occurring.
Ultimately the usefulness of moving your tagging to server-side from a cookies perspective will depend on two things – the TMS you choose, and the tag vendors you work with most. On the TMS options, some are very flexible and can allow you to use your own tracking domain and set HTTP or server-side cookies (GTM), while others will allow you to send data via your own site domain but can’t manage the cookie part themselves (Launch / TiQ).
Your mileage may vary to a similar extent with the tags as well. Some vendors have native support for “bring your own ID”-style HTTP cookies, such as GA4 and Adobe WebSDK, while some provide detailed guidance for how to replicate their proprietary formats for setting via the HTTP method, such as Meta. Many however do not provide any such guidance yet, forcing you to reverse engineer the logic from their client-side code if you’re really desperate to innovate at this very moment.
But it’s important not to get some sort of tunnel vision here. Moving your tagging to server-side has many benefits aside from extending the lifetime of tagging cookies. Chief among those is protecting against browser features and extensions that seek to block all third-party requests being made from a site. What we mean by this is the code required to run tags from your site can be blocked entirely by certain browsers and extensions. Near the end of last year Apple started blocking not cookies but Google Analytics, Google Ads, and Google Tag Manager from loading entirely if users were in Safari’s Incognito Mode. Given previous release trends it’s likely this will filter into the standard browser mode before too long.
By moving to server-side methods that either load libraries or receive data (or both) via your own site’s domain, the tagging becomes indistinguishable from the rest of your site, and therefore all forms of tracking from analytics, to ads, to personalisation become far more robust and reliable once again.
So when viewed as a suite of solutions, from future-proofed cookies, to more reliable tracking, right down to the basics of improving your site performance and stability by running fewer tagging scripts on it directly, server-side begins to make a lot of sense. Focussing on Meta’s CAPI alone, as they’re one of those who’ve been pushing this the hardest and longest, we’ve seen clients report a 29% increase in conversion rates from social traffic, and a decrease of 18% in their ad spend when they started running the vendor server-side (TUI, from Tealium x CAPI slide deck). Another client who we’ve recently implemented this for has forecast a three year revenue uplift of just under £150,000 (SiS, from the same deck). These are very tangible benefits to what can often feel like an intangible solution.
6. Probably though we need to start taking a more holistic strategy when it comes to mitigating the effects of the cookie crackdown. A good place to begin would be by revamping how first party data is collected and used across a site and its connected tagging platforms. The only guaranteed way to be able to track a user across different sites, browsers, and even devices is by collecting and storing a first party identifier that they have offered-up in a privacy compliant manner. Typically this is a hashed email address, but this could be a phone number, physical address, both hashed again of course, or even just their account number will suffice in most circumstances.
There are many methods of achieving this, from the basic newsletter subscription banners, to offering loyalty discounts for sign-ups, simply requiring users to sign-in to view content, or naturally from them giving their details during the checkout flow. Once you are able to start collecting this data into your own warehouse, stitching it together with cookie IDs, appending other details from your CRM system and so forth, then you have the basis of CDP. Because this is built on your own data it’s much more resilient and useful than any cookie mitigation programme could be on its own. Then you can start building-out your own audiences and sharing user lists with Meta, Google Ads, or whichever vendor you fancy.
Probably the biggest use case that doesn’t really work with server-side tagging would be that of session recording. The very essence of session recording is capturing every single action that a user takes directly within the browser or app itself. There would be no point or benefit in trying to replicate that in server-side code, as you would simply end-up sending every single action back to your site server / TMS to then forward it onto the recording tool anyway.
Let’s be clear, when we’re using the term “server-side” here we are actually not talking about removing the TMS from the client-side entirely. We would want to keep that for tracking user interactions in real time, whether via DOM scraping or the data layer itself. But instead of doing anything with that information, like it would now, the client-side TMS just sends that information directly to the server, from where all our tracking and personalisation occurs. In that sort of setup we can move not only our analytics and ad-tracking pixels to the server, but through direct integrations with the site code we can even begin running our testing and personalisation efforts entirely from the server-side also.
Again this is probably a whole topic in itself but it’s worth bearing in mind that, while such efforts are entirely achievable, they require a markedly different approach to the testing and personalisation efforts that we would consider standard today. For example our CRO tools would not be designing and displaying HTML content any more, they would instead be returning attributes and recommendations that the server code could incorporate into its own rendering of each page component. For better or worse, some of the freedom of our existing CRO tools, the ability to change content or even pages on a whim with no involvement of the site developers, would likely be lost.
7. If you’re looking for a straight-up OTB solution then probably Adobe Event Forwarding would be a tempting option, particularly for existing Adobe users. The package runs off of the Adobe Edge Network, and takes its data in the same XDM format that Adobe’s WebSDK client-side tagging library uses for the likes of Adobe Analytics and AEP. The ability to customise the config, hosting, or bring in any external data is limited, but that also means there’s less to manage or damage, and their library of pre-built integrations has grown rapidly over the past year.
The more adventurous might look elsewhere to the likes of Tealium EventStream. Although config and hosting options are again limited, EventStream can be combined with their Data Connect offering to import data that can enrich site tracking with additional user data, product data, and so forth, before it is sent on to each tag vendor. Beyond that there’s also the opportunity to bring their CDP AudienceStream into the mix, enriching tags with full first party user profile attributes in near real time.
Finally of the pre-builts would be GTM Server, or sGTM for short. This can be configured and hosted in multiple ways, which can really enable power users to create the most robust server-side setup possible if the desire is there to take such a customised approach. Again it has a Firestore integration for enriching tags with external data in real time, but no CDP integration alas.
Of course all these solutions are just hybrids – they combine client-side tracking with server-side endpoints. To get a solution that was truly server-side only would require the sort of tight integration with your own site code that no OTB solution could hope to achieve. Then we’re probably getting into another workshop, but to get something like that stood-up you need at least four things – an events collector, an events processor, a data lake, and updates to your site’s codebase to send every action and piece of data you want to track to that collector you just created.
8. Consent Mode is the Google-centric solution for handing-back privacy controls to the users of a site or app. In its v1 flavour Consent Mode had two consent types – “ads_storage”, and “analytics_storage”. Just like a consent banner might store a user’s preferences for “Analytics” or “Marketing” cookie categories, so Consent Mode essentially piggy-backed off of these settings to control what cookies its own solutions were allowed to store.
If a user allows “Analytics” in their banner, then Consent Mode would interpret that “analytics_storage” is allowed, and therefore cookies such as the main GA cookie for user/session id would be allowed. If a user allows “Marketing” in their banner, then Consent Mode interprets “ads_storage” is allowed, and then the various cookies for Google Ads and Floodlight would be enabled also.
No doubt you’re wondering what the point is of Consent Mode if it just copies the existing cookie banner behaviour. That’s where the “advanced” option comes into play. Most tags controlled by a cookie banner are either enabled or disabled, on or off. They know either everything or nothing. But with advanced Consent Mode the Google tags can know something at all times, thanks to the fact that so-called “cookieless pings” can transmit anonymous data to GA / Ads / Floodlight even for users who have not consented to any form of cookies.
Then the boffins at Google can model that anonymous data such that it enhances the real “known user” data that has been collected by the same set of tags. This means improving the insights available in analytics reports, and increasing the conversion rate for Google Ads reports.
It’s up to each business to determine whether the benefits of modelled behavioural and conversion data, which is essentially spewed from a black box with ML initialled on the side, is worth capturing data from users who have never consented to Google’s services.
Clearly the EU has been contemplating the same dilemma, as from March 2024 all businesses running Google advertising services on users in the EEA must upgrade their Consent Mode to version 2. This second iteration of consent mode adds a bit more granularity by introducing two further flags – “ad_user_data” must be set if first-party user data is being collected or GA4 is sharing conversion data with Google Ads, while “ad_personalization” must be set if data is being collected for Google remarketing purposes. It does not actually change what or when cookies are set, it simply tells the Google servers how that data can or cannot be processed after it’s been collected.
In a server-side world the approach is no different in theory, though depending on the TMS being used (e.g. if it’s not Google’s own sGTM offering) the practice of controlling whether the server sets cookies, and ensuring that GA/Ads/Floodlight requests are sent with the correct consent mode parameters, could be much more of a manual process.
9. The most important thing is to actually get started. We find that most clients fall at the first hurdle because it can seem like a large and daunting task but actually it’s not that complex. It just requires a bit of planning and coordination yet the impact is potentially very significant! He recommend this flow:
- Audit your current data collection strategy
- What tags are being fired and why
- What data points are being sent and why
- What value to you get from each of these
- What are then known issues
- Rationalise exactly what is needed and why
- This will require working closely with your marketing team and/or agency
- Really interrogate what is actually needed and whether any consolidation can occur
- Create a solution design for updating to the most performant outcome (likely a blend of client and server-side)
- You may need to work with a developer or someone who has created these sort of solutions before
- Yes, DMPG is of course available and willing to support you if you wanted an easier solution with a guaranteed positive outcome
- Update based on these requirements and ensure the updated framework allows for growth/change
- This will also require QA and validation with each of your tag vendors