It’s time to re-think our rejection of third-party cookies

Ever since Google threatened to eliminate third-party cookies, there’s been a steady drumbeat that websites should switch to first-party data, which, many say, is better anyways. While it’s definitely a good idea to collect first-party data, third-party cookies were created for a very good reason, and they still remain a useful tool that website owners should not ignore — even as they become less common and reliable. 

What are cookies, and why do we have them? 

A cookie is a small text file that a website can write to your computer. It typically includes a unique ID for each visitor — that is, for each internet browser, like Chrome or Safari. 

Here’s how it works. You visit a website using an internet browser. The website wants to know if you’ve been there before, so it looks for the cookie on your browser. If the cookie exists, it registers you as a return visitor. If the cookie doesn’t exist, it assigns you an ID and writes that to a new cookie in your browser so the site can identify you on your next page request. 

Cookies are necessary because the internet was built on anonymous, stateless connections. Every time your web browser requests a page, the server sees that request as a new, anonymous visitor. The web server doesn’t know if a visitor is new or if it’s made 100 requests before — unless there’s a cookie. 

This anonymous, stateless environment made logins impossible (until cookies) because every page view was a new, anonymous request. In order to “maintain state” – that is, to recognize a visitor as the same user across multiple page views — the website has to have something to identify that user. That’s what the cookie does. 

Right now, your internet browser probably has cookies for hundreds of websites, and on some sites, like Amazon or Gmail, that cookie might keep you logged in. If you were to delete your cookies, the next time you visited any of those sites, you’d have to log in again. 

Dig deeper: Alternatives to third-party cookies: The state of play

First- and third-party cookies 

A first-party cookie is written to your browser by the site you’re currently on. A third-party cookie is written by some other site. 

If I visit nationalgeographic.com, the site will write a first-party cookie to my browser that only the National Geographic servers can read. I’ll also get a Doubleclick cookie. That’s a third-party cookie that allows Doubleclick to identify me on any site that uses Doubleclick for ads — including NatGeo. If I browse some pages on the National Geographic site, the site’s first-party cookie will allow National Geographic to track me through its site.

If I then go to llbean.com, the L.L. Bean first-party cookie will allow L.L. Bean to track me through its site. But Doubleclick — which I’ve never visited — will track me across both sites because National Geographic and L.L. Bean both use Doubleclick’s third-party cookie. 

The third-party cookie “follows you around,” so to speak, but for good reason. By tracking a user’s behavior across multiple sites, Doubleclick can create a profile of that user. For example, it will understand that he reads stories about Appalachia and looks at ads for campaign gear. That allows Doubleclick to show appropriate ads to that user on any site that uses Doubleclick for ads. 

Dig deeper: How one tech company is doing marketing without cookies

First-party cookie limitations

First-party cookies don’t follow you around. A first-party cookie is written by the site you’re currently on, and can only be read by that site. That creates problems for companies with multiple websites. 

Let’s consider ACME Dog Food Company. ACME owns 20 different websites, including feedthedogforgodssake.com (hereafter site No. 1) and wouldyoupleasefeedthedog.com (hereafter site No. 2). Each of those sites writes a first-party cookie to every browser that visits, and collects first-party data on all those visitors. 

The CEO of ACME Dog Food Co. wants to know how many people who visit site No. 1 also visit site No. 2, so he asks the IT manager to create such a report. 

The IT manager scratches his head and thinks, then he realizes that the only way he can do that is if there’s some common data point that links the users between the two sites. 

For example, if I visit site No. 1, that site will put a site No. 1 first-party cookie in my browser, which enables site No. 1 to collect information about my visits. If I later visit site No. 2, that site will also put a first-party cookie in my browser and collect information. But there’s usually nothing in either of those user records to say that it’s the same person — i.e., that it’s me in both cases. 

There are cases where such data does exist, and allows a connection to be made. If I make a purchase on both sites, the cart on each site will have collected my email address, which would enable the IT manager to tie those two records together.  

Without such a common record, our bewildered IT manager is out of luck. He can’t connect records between the two sites. 

Dig deeper: Google’s Privacy Sandbox: What you need to know

Wait, surely there are options 

I know what you’re thinking. Aren’t we always hearing about how everybody’s tracking us all the time, and has all this data on us? Certainly there’s a way for a business to identify a common user across two sites. 

Unfortunately, those are two different things. The people who track most of what we do are the big companies like Google or Facebook — because they’re using third-party cookies that most people have on their browsers. If you’re using Chrome, your Google account follows you all over the internet. 

(Did you wonder why Google decided not to eliminate third-party cookies? Maybe it’s because they like them too much.) 

What another company can collect on its own website is a different question. 

Having said that, yes, there are options. 

Remember, the problem we’re trying to solve is that we have independent records on the two different sites. The solution we need is a way to find some kind of a key to match those records and merge them. Here are a few ways to do that. 

• Establish site registration on both sites. When someone logs in — presumably with the same username or email address on both sites — that provides a common data point that allows you to merge the records. The downside is that not all your visitors will register, and this method will only work for the people who register and sign on. 
• Use browser fingerprinting. When a web browser visits a site, it hands over certain information to that site, like IP address, screen resolution, which browser is being used and so on. Using that information you can get a pretty good idea that a visitor on one site is the same person as a visitor on another site. It’s not perfect, but it’s good enough in some cases. 
• Borrow somebody else’s third-party cookie. If you use Google analytics on both sites, it’s sometimes possible to capture the visitor’s GA ID and use that to match the two records. 
• Pass a unique ID from one site to the other. If you link between the two sites, you can pass an ID as a query parameter in those links and use that ID to merge the records. This will only work for people who click on those links. 

Or… use third-party cookies 

Here’s another solution. What if ACME Dog Food Company created its own third-party cookie and implemented it on every one of ACME’s websites? The cookie would create a unique ID for each visitor that would follow the visitor from site to site. That ID would become the unifying record that would allow ACME to merge user data from all of its websites. 

“Hold on,” you say. “That’s too simple, and it seems too good to be true.” 

Yes, there are limitations and drawbacks. 

Even though Google has not eliminated third-party cookies, some other browsers have, so this technique won’t work for everyone. Also, Google is (allegedly) going to allow users to opt out of third-party cookies. 

Given all that, let’s make a pessimistic assessment and say this third-party cookie effort will only be able to match 50 percent of your users across different domains. 

I’d say 50 percent is better than nothing, and in combination with some of the other techniques I mentioned above, you should be able to do fairly well.