Tim Juravich

Everything I know about the complexities of First and Third-party Cookies

Cookies may be the most heavily discussed topic in marketing, advertising, and analytics conversations. Like most complex solutions involving technology, in order to understand the challenges, we need to start at the beginning with clear terminology to find a path forward.

This article is my perspective on the First and Third-party cookie discussion starting with the initial purpose of cookies in 1994 through to the current state (as of July 19th, 2022). We’ll discuss the nuance of how cookies, trackers, and JavaScript were used and ultimately reflect on the challenges and clear impacts that companies face by continuing to rely on Third-party cookies.

Let’s meet Jon

Let’s start by talking about Jon, who wants to do business with your company, Acme.

Jon goes to your website acme.com, a company he’s heard about but has not interacted with in the past and excited to transact and purchase an item from your e-commerce solutions.

Now, this experience is one that has happened since the early days of the internet. So, let’s zoom through a few decade of experiences to see how the evolutions of cookies and technologies change the way we discuss the terminology and the impact on trust and privacy.

1990s: A Time Before Cookies

The same concepts of the early internet are the same, while the technologies have evolved, the principles remain the same.

When Jon loads the webpage of acme.com, he sees a page load in the browser. But behind the scenes, a website is represented by a client and server.

Client is what renders the HTML, evaluates the JavaScript and CSS to display the end user experience.

Server can technically be a many servers, APIs, or systems, but ultimately the server is responsible for resolving the URL of acme.com and providing logic to render the client.

In this way, companies developed web experiences for their clients using packaged software and custom solutions.

1994: Early First-party Cookies

In 1994, the web cookie was created by Netscape to help give the web a more personalized feel by allowing a server to save a small amount of storage within a visitors’ browser to support authentication, shopping carts, and configuring preferences. These cookies were saved with an expiration date and while still valid could be accessed from the browser on behalf of the user.

At this time, cookies were meant to allow data exchange between a user and the specific website that they have visited. This important concept defines what we mean when we say First-party.

Now, cookies can be sent two different ways, Server-side and Client-side. We’ll start by examining the original intent of using these methods in a First-party context.

First-party Server-side Cookies

This is sent from the server hosting the website (in our example acme.com). These are considered secure and certifiably created by your domain because they are without a doubt can be connected to the website you are visiting, but they cannot be extracted if you went to a competitor’s website.

As we talk about the evolution of cookies, these types of cookies are 100% still valid, necessary, and can be set with a very long lifetime (> 1 year). Sending a server-side cookie doesn’t hold any of the challenges that are faced by a third-party cookie.

First-party Client-side Cookies

These cookies are set within JavaScript, meaning that it doesn’t require code within the server of a client’s website itself. The goal was to make it easy to adopt cookies, without the technical complexity of having to mess with servers.

At this moment in time, we still consider this First-party, but as we see the evolution of technology in this space, we will see that the difference between First-party Server-side cookies and First-party Client-side cookies begins to make a big difference.

1990s-2000s: Early First-party Analytics

As web progressed in Web 2.0, there were growing needs to understand what users were doing, in the 90s this was in the form of “Hit counters”. If you browsed the web at that time of the internet, this picture might make you nostalgic, as it did for me.

This was the early form of web analytics, which was primarily all done through basic server views. These mechanisms have gotten more complex, but the early world of analytics revolved around the idea of having a server-side script collect the URLs that users visited and increment the counts so that you could see how many views occurred.

For this to work, website developers would either drop in a script on their website in PHP or Java and this would operate within their own system. Additionally, solutions emerged where it was a system generated image with the path of the website you were visiting (which started to evolve into a pattern similar to a web pixel).

This mechanism worked quite well, but it was challenging to understand:

  • What were unique views?
  • Where did visitors come from?
  • What did people like on the site and not like based on behavior?
  • What content was less or more interesting?
  • Which users came back?

2000s: Early Third-party Analytics

Before we progress, it is important to quickly mention the value of 3rd parties. No company in the early 2000s (or even today) should fully invest in building their own analytics system from scratch, there are far too many complexities and considerations and 3rd parties do provide capabilities that accelerate a companies capabilities. However, the theme that we’ll discuss at length is around ownership and residency of both data and identity of a user.

In the early 2000s, to confront the issues with server-side analytics, a small company called Urchin developed JavaScript code that could be placed on a website to collect data about users. The technology was heavily adopted in the industry and by 2005 was purchased by Google. This technology grew into what we know as Google Analytics. At the same time as Urchin, other similar technologies were created by large companies to create the foundation of enterprise analytics products.

For a trip down memory lane of Urchin, you can checkout this article.

In the simplest sense, an early analytics library acted just like any JavaScript a company might develop themselves. And it was placed onto a website as a small snippet of JavaScript, but this is where things get interesting.

In this example, I’m using an early google analytics example. Notice that the website of the company is acme.com, but the source of the JavaScript is coming from google-analytics.com. As we go back to the definition of First-party (a connection between a user and the specific website they have visited), the difference in domain of what the user visited, loading of a script from outside of acme.com and transfer of data outside of the domain of acme.com is considered Third-party

1990s - 2000s: Early Third-party Cookies

In 1996 - only 2 years after the invention of cookies, ad pixels and analytics began to emerge in the market using 3rd Party Scripts for analytics and using Client-side Cookies to connect an individual’s identity across multiple sites as a key function of their business model. This is what we’ll refer to as Third-party Cookies, which are heavily the backbone of the advertising world through the usage of Ad Pixels.

Let’s step through how it works.

  • Using our same example, let’s assume that a user goes to the website of acme.com and they have placed an ad pixel from Facebook on their page, which is again a Third-party script.
  • As the script collects usage information, it sends the data to a script on facebook.com (or other proxy domains)
  • As the script runs, it will see if there is an existing facebook.com cookie associated with it within the user’s current browser
  • If it does not exist, one will be created and tell the 3rd party JavaScript to create a cookie with an id of 123

The important delineation here is that even though the pixel was rendered from an owned website of acme.com, this would be considered a Third-party Client-side cookie, because it was:

  • Set via JavaScript (e.g. not a server-side cookie)
  • It is set by an application outside of your 1st party application (e.g. like from facebook.com)
  • Its purpose is to be used and connected across sites (e.g. not just the website that is viewed)

Expanded usage of Pixels

In isolation, the above process may not be concerning to the visitors of acme.com, but as we see the expanded usage of ad trackers and pixels began to cause issues with the usage of the cookie technology. Now, let’s imagine Jon went to acme.com like he did before, but now he also goes to another company northwind.com with the same browser and with the Facebook pixel also installed.

  • The difference in this flow is that when usage is collected from the end-users’ interaction with acme.com, the Third-Party JavaScript connects to facebook.com
  • Because (at the time) Third-party cookies could be reliably connected across domains, the same cookie set for facebook.com on acme.com could also be used and connected on northwind.com.
  • What this means, is that the identity of the user could be connected by Facebook across every single website that has the pixel installed.

To understand the reason for privacy concerns, you can see that with this connection of cookies, Jon’s hollistic browsing and viewing experience can be connected across domains, without his consent and without him having to have an account.

Even though I’ve gone into more details in this section, it is still quite a bit of an over generalization of how pixels and identity resolution work within large ad/pixel networks.

2010s - Now: Privacy and Consent Change The Cookie Conversation

As Third-party solutions grow, the concerns around privacy have also arisen, driven by GDPR and CCPA and other downstream privacy acts. While there are other implications of these acts, a large portion of the focus is around consent and privacy of Third-party data collection without the explicit consent of end-users. One of the largest culprits is focused around Third-party Cookies, which are primary set by Third-Party Client-side JavaScript.

Since the 90s, cookies have been the primary method of maintaining and persisting identity for Third-party analytics, marketing, and adtech systems. Their usage has larger implications around user’s not being able to have consent across systems due to the distributed nature of these items.

Due to the clear abuse of cookie technology, Apple set the ball rolling with a Safari feature called Intelligent Tracking Protection (ITP) in June 2017, setting a new privacy standard on desktop and mobile to reduce cross-site tracking by “further limiting cookies and other website data.”

The Impact

Based on programs like ITP, cookies begin to have a different lifetime based on how they are used.

  • First-party Server-side Cookies: Are not impacted and can be created for over a year. These cookies are “certifiable” that they have come from the domain that you visited and therefor can be remembered by this specific host (back to the early principles of cookies). This is the foundation by which auth and preferences will continue to use.
  • First-party Client-side Cookies and Third-party Client-side Cookies: The lifetime of a cookie varies based on the browser itself. In Safari, all cookies created via JavaScript have a max lifetime of 7 days, other browser may allow up to 2-weeks. The reason for this is even if you had for instance placed an analytics script on same domain, setting a cookie is very easy for any script to do, while still sending the cookie information to a Third-Party server.

2: JavaScript Tracker Blocking

On top of the limitations of cookie blocking, noted Third-Party tracking scripts and pixels are also being blocked at large and increasing rates.

Popular web browsers Edge, Brave, and Firefox all block third-party tracking cookies by default. Chrome has announced that it will phase them out, which is delayed until 2023, but is quickly approaching.

In various studies, it is found that currently due to Adblockers and security settings in browsers, approximately 15% (it ranges on some sites between 6% to 26% of users) are completely blocking Third-Party trackers from collecting any data. In websites where the audience is more technologically advanced, over 58% of visitors can be found blocking tracking scripts such as Google Analytics (https://plausible.io/blog/google-analytics-adblockers-missing-data#58-of-visitors-block-google-analytics).

The Impact

Similar to the cookie lifetime issue, the impact of these policies impact your scripts and cookies based on how they are used.

  • First-party Client-side JavaScript: JavaScript and code delivered without the Third-party attributes of populate analytics trackers will not be blocked by usage. However, there are increasing numbers of users that are blocking JavaScript all together, so it is recommended to ensure you have a plan to server side render your javascript to still enable a stable experience.
  • Third-party Client-side JavaScript: Regardless of the host origin of scripts, browsers evaluate the JavaScript inside of the tracker to determine if it should be blocked. Based on the policies of end-users, this JavaScript may not render.

3. Fingerprinting

In the face of these cookie-killing barriers to enhance privacy, companies have long used other attributes as alternative ways to combine identity through the usage of browser fingerprinting.

Fingerprinting is the process of building a unique identifier by combining multiple properties that by themselves are not unique to you, bypassing browser restrictions on cookies, and even being able to track you between devices (what cookies can’t do). Some properties include IP address, operating system version, browser version, computer language, computer time, the size of your screen, the pixel density of your screen, how fast your computer is, etc.

Browsers are taken equal measures to those of 3rd party cookies to the trackers and pixels that exist on a companies website. Common 3rd party trackers have been easily identifiable by browser (such as this example from Safari to the right). Although these trackers themselves are not being blocked, their ability to collect data from your device, such as IP address and other information are blocked.

The Impact

  • Third-party Domains: Regardless of the delivery mechanism (e.g. pixel, JavaScript), these Third-party domains will see less information that can be used to fingerprint identity.

4. Domain Cloaking

Some providers advise on creating a masked domain/DNS records, so that a URL such as “analytics.acme.com”, would look like it comes from a trusted acme.com domain, but behind the scenes it sends the data to a third-party system.

The objective of this is that the browser may be confused and allow this cookie to act as a 1st party client-side cookie, which while not as long lived as a 1st Party server side cookie, it would live longer than a 3rd party client-side cookie.

There are other solutions that are using domain cloaking to set Server-side Third-party cookies (which may be the best way to describe them), but acting as Server-side First-party cookies. This practice is being watched and several DNS and hosting solutions are beginning to block this as well.

The impact

  • First-party Domains: True first-party domains are not impacted at all
  • Third-party Domains acting as a First-party Domain: If it does get through to the browser without raising alarms, it will allow a JavaScript created cookie to last longer, but it has limited value for the effort.
  • Third-party Server-side cookies acting as First-party Server-side cookies: This method is unproven at scale and complexity and one that will have to be closely monitored.

The Impact Of Relying On Third-party Cookies and Scripts?

1. You will not see an accurate representation of “New Users” vs. “Returning Users”

In an analytics context, you will see a significant increase of New Users, because the impacts to Third-party client-side cookies (as defined above) will last for at most 7 days. This means that if a customer comes to your site today and then again after 7 days, both of those visits will count as new users.

2. You will see less users in your reports than are actually visiting

Currently, 42.7% of internet users worldwide report using an ad or marketing script blocker. If these scripts are blocked, these visitors will not ever be identified.

3. You will see less activity in your reports than is actually occurring

This means that the analytics and activity data itself are likely to be missing a large portion of actual activity and analytics data. This means that your decisions based on data might actually be skewed.

4. Your visitors may not trust your digital experience

Consumers are becoming more savvy and noticing the impact of Third-party scripts through performance of a page and using tools in their browser. Cookie consent popups and reliance on third-parties can damage your brand connection with them.

The Only Real Path Forward: First-party Ownership

Consumers are taking back their privacy, and this is a good thing!. However, for companies looking to properly manage analytics, marketing, and advertising solutions it is becoming increasingly important for organizations to take an active position in First-party ownership of Identity and Analytics.

In order to do this it requires clear ownership of First-Party identity following proper consent and privacy criteria. With that foundation in place, First-Party analytics and marketing solutions can allow you to provide transparency to your visitors. It’s important to know that vendors and technology play a strong role in this process, but fundamentally it is a strategic conversation.

Written on July 19th, 2022 by Tim Juravich