While some consumers express skepticism or negative reactions when confronted directly with questions about having websites use cookies to track their on-site behavior, a growing number believe that the benefits of having personalized ads or chatbot engagements are more “cool” than “creepy” according to a recent survey by Cheetah Digital. This makes sense as one of the primary drivers of these personalized experiences is to improve the overall experience of the user by serving content and advertisements that users are more inclined to like. Whether it’s Amazon’s “You Might Also Like” or scrolling Facebook and seeing ads from Fanatics related to your favorite sports team, consumers are increasingly accustomed to seeing ads that strike their interest.

To facilitate these interactions, the modern web relies on a system of tracking user behaviors, engagements, and preferences across multiple sites and selling that data to advertisers. Sure, some consumers find this behavior objectionable and some companies cross the line from a privacy standpoint, but generally speaking this arrangement works out well for all parties involved. Consumers are able to access most websites without paywalls preventing access, content creators are able to monetize their audiences and keep the content free for their users, and advertisers are able to reach their intended target audiences without wasting ad spend on less interested prospects.

But did you ever wonder how it all happens?

Simply stated, cookies play a huge role in powering today’s ad tech ecosystem, even though they are increasingly under fire. While there are multiple uses and types of cookies, this post will focus on how cookies enable on-site tracking of user behaviors. We’ll address how cookies are used in cross-site tracking in a future post.

First, let’s start with a quick definition to ensure we’re all on the same page.

What is a Cookie?

Cookies are small pieces of data that are sent from a website to a user’s browser and stored on their device. They are commonly used to store information such as login credentials, preferences, and shopping cart contents. Cookies can also facilitate the tracking of events such as a website page view, button clicks, external link or outbound clicks, and more.

Now that we have an understanding of what a cookie is, let’s see it in action.

Fair warning, the next section will be a bit screenshot heavy as we’re showing you pictures of what we’ve found when performing normal web activities, and using Amazon.com as a proxy. These screenshots showcase how to find cookies served by a website and how those cookies interact with your browser.

For the TL;DR version, suffice it to say that cookies enable the site to track a variety of identifiers, events, and behaviors, such as page views, clicks, and timestamps.

Setting Cookies for a First-Time Visitor

I’m starting a new website visit to Amazon.com. Because I want to first show up for this exercise as a brand new visitor, I’m using the Chrome incognito mode. You can access incognito mode by clicking CTRL + Shift + N to open a new incognito window or by right-clicking and selecting new incognito window from the menu. Using an incognito window for testing ensures that the website I’m visiting won’t immediately recognize me as a user.

Now that I’m on the Amazon home page, let’s see what cookies are firing. To do this, I’ll right click to open a menu and select Dev Tools. From there, I click on the Application tab and open the Storage menu on the left, specifically the option for Cookies.

For the TL;DR version, suffice it to say that cookies enable the site to track a variety of identifiers, events, and behaviors, such as page views, clicks, and timestamps.

There are three main areas we’ll be viewing in the Storage area today: Cookies, Local Storage, and Session Storage. The team over at Xenonstack has a great write-up about the differences if you want to learn more, but for our purposes, we can simplify the differences and say that cookies are readable by the server (whereas the other two are not), they have a set expiration date and are capped at 4KB capacity.

Local Storage stores data on the user’s web browser and it stays forever unless manually deleted by the user, up to about 10MB worth of data, and this data is never transferred to the server, but it can be read by the browser. Session storage, on the other hand, destroys all of it’s data when the user closes the current tab or ends their browsing session. What’s important to note with both local and session storage is that cookies can write data to them that can be called upon to enhance user experiences.

Examples of Cookies Being Set On A Website

First, I’ll visit the Amazon.com home page, open up my dev tools, and view the cookies, local and session storage. I’ve added screenshots in the sliders below so you can follow along. Simply hover over any image in the slider and the animation will pause.

Notice that the “csm-hit” value set by the cookie, tb:B3M4H7BMGD06HBCR3YPM, is also showing up in both local and session storage. Notice that the cookie also defined a session ID, 137-6969085-8705905, a value that can match up all of my browsing behavior on the server as it logs every interaction and timestamps them for this visit.

Event Tracking With Cookies

Next, I’ll take an action by clicking on the “Early Prime Day Deals” link in the top banner. In tracking parlance, this click is known as an “event”. By looking at the Cookies, Local Storage, and Session Storage once again, you can see that new values have been added that correspond with this event, while some stay the same.

Calling your attention to the screenshots below, when looking at the cookie values, you can see that our “csm-hit” value has now been updated to tb:s-R0MC6GVBY13KZ5568DN3. This will become important later on as you see how each page view is linked together. You will also notice that in the Local Storage images, there is the key “csa-tabbed-browsing”.  Here you can see that the browser is recording a “pid” parameter and a “tid” parameter. Throughout my browsing sessions, the “tid” value is constant whereas the “pid” value changes with each page. These values are copied into both local storage and session storage and serve an example of how browsing activity within a user’s session is synced by creating links with a unique identifier for the browsing session along with links for each unique page name, along with the “used: true” indicating a positive response that I did indeed view the page.

Linking Events Together

Taking another action from my Prime Day preparation to check out “Today’s Deals”, we see the pattern continue. The cookie has updated the value for “csm-hit” to tb:s-PCKGX731PMKAJPEX5CGM and the “csa-tabbed-browsing” parameter has also been updated with new “pid” values, including an ID for my last interaction, meaning the ID of the link I clicked.

There is another important callout here as we look at the Session Storage image in that there is a “CSM_previousURL” parameter as well. If you’re following along, you’ll notice that this is the third page that I’ve gone to in this visit to Amazon’s site, but when looking at the value of the previous URL parameter you can see that the value of the “csm-hit” from my first page is included in the link. This was the B3M4H7BMGD06HBCR3YPM value I highlighted earlier.

As I continue to take actions on the site, such as searching for cookies (because why wouldn’t a post about cookies NOT use a search for “cookies”), the same sets of behaviors take place. Browsing activity is linked to my session ID via the cookie placed on my site.

Differences in Tracking Anonymous vs. Known Visitors

I’ll continue to take actions on the site, but it’s important to recall that all of my searches thus far have been completed in a Chrome incognito window. That means Amazon doesn’t know who I am, aka I am an anonymous visitor. 

To demonstrate the differences, I have conducted the same search for “cookies” in two separate windows – one normal browsing and the other incognito. Notice in the screenshots below that since I’ve logged in to my Amazon account there are a number of new cookie values that are being tracked. I won’t pretend to be able to decipher the meaning or intention of each one of these parameters, but there are a few things that I would like to call out.

First, the sheer volume of parameters. In the incognito window as an anonymous visitor, there are only seven parameters being tracked. Once I’m logged in, there are seventeen. The volume discrepancy in and of itself is not meaningful, but what’s important to note is that when you have authenticated users, you are able to capture much more data about them and sync their events together in the back end. Typically, having more data about consumers leads to better personalization, communication, user experience, and overall better outcomes vs anonymous users.

Second, you’ll notice for a logged-in user a value for “aws-mkto-trk” which is a slight variation of the common naming convention for Marketo’s “_mkto_trk” which is used to store and track user interactions. As a full disclaimer, I do not have inside knowledge of whether or not Amazon uses Marketo, but this is a close enough coincidence that I believe we can make a reasonably educated inference, especially given that the value of that parameter so clearly contains both an ID and a token, along with a reference to the munchkin javascript library which Marketo uses.

So, assuming Amazon uses Marketo, what purpose would this serve? The most likely scenario for the use of aws_mkto_trk parameter is to create a unique user ID that is matched with the visitor’s session ID and other parameters to track the usage of a site by a unique individual. By default, these cookies have a lifespan of two years, with an expiration date that is reset for another two years each time the user interacts with the website. For sites that are visited frequently, and for users who do not clear out their cookies, this creates the potential for perpetual tracking of all online behaviors.

Finally, it’s important to note that the cookies served by Amazon.com are all from Amazon-related domains. These are known as first-party cookies. (link) First-party cookies are cookies that are served by the website the user is visiting and may be necessary to enable select functionality of the website, and can also be used for tracking purposes as we have seen here. As part of the shift to first-party data, more and more companies are beginning to leverage first-party cookies and to stop relying on third-party data.

Conclusions and Future Learning

From these examples, you have seen how cookies can be used to identify both anonymous and known users and track their online behaviors natively or by syncing with other systems such as Marketing Automation Platforms or Ad Servers. While this post has focused on how cookies are used in an on-site, first-party context, you can learn more about how to identify cookies used as third-party trackers and how that works in a future post.

Ultimately, there are a number of ways to expand the tracking capabilities of your owned media but must be balanced with your business needs, consent from your visitors, and regulatory concerns. To learn more about how to improve your on-site tracking with privacy-preserving methods, contact our expert team or check out other Resources on our site.