As a 20-year marketing technology and media vet, I must tip my cap to data management platform startups for bringing new energy and interest to the needs of publishers and their commercial partners. We face an ever-changing media landscape characterized by fragmentation in delivery channels, evolving consumer consumption behaviors, and privacy regulation. To navigate it successfully, we need to focus our time and effort on finding innovative and effective ways to connect, enrich, and activate consumer data for publishers in a manner that respects consumer privacy and empowers choice.

I admire the marketing prowess and focused messaging of these data management platform (DMP) companies. However, I can’t stand by while they purposely and repeatedly mischaracterize technical capabilities and confuse  publishers (and media outlets) on the facts related to profile identifiers, browser storage mechanisms, privacy compliance, and “match rates.”

In a series of three pieces, I will set the record straight. This first piece will focus on the facts on profile identifiers, browser storage mechanisms, and their relationship to privacy regulation.

The facts about profile identifiers and browser storage mechanisms

If I had a dime for every time I’ve heard the term “cookieless DMP” in the last year, I’d be a very rich person. This is purely a marketing term with no basis in fact or function. If we’re talking about data management technologies that are operating in a web browser context, then there is no such thing as a “cookieless DMP.”

PIDs

All data management technologies — including DMPs — use profile identifiers (“PIDs”) in a web context to organize and connect consumer data. A PID is typically a string of randomly generated letters and numbers. By itself, a PID usually has no information that can directly identify an individual in the real world.

In a web browser environment, these PIDs can be stored using one of three browser storage mechanisms. These are: 3rd party cookies, 1st party cookies, or browser local storage (sometimes referred to as HTML5 web storage). It’s important to understand that a cookie is just a storage mechanism (a text file), and you put a PID string inside the cookie.

1st and 3rd parties

Many years ago, DMPs primarily stored PIDs in 3rd party cookies because they provided a consistent and scaled container to access PIDs across websites and over time. In 2017, Apple released their Intelligent Tracking Prevention (“ITP”) functionality in Safari. It blocked the setting of 3rd party cookies by default and made that storage mechanism an ineffective tool for storing and retrieving PIDs. As a fallback mechanism, DMPs could use 1st party cookies to store and retrieve PIDs. 

The difference between 3rd party cookies and 1st party cookies is that 3rd party cookies can be accessed by the entity that originally set the 3rd party cookie irrespective of which website the consumer is visiting. In contrast, 1st party cookies can only be set and accessed when a consumer is visiting a specific website domain.

So, for example, a PID that is placed in a 1st party cookie when a consumer is visiting Publisher_A.com can only be accessed when the consumer is at Publisher_A.com. If the consumer subsequently visits Publisher_B.com, then a different PID will be generated and placed in a 1st party cookie that can only be accessed from the Publisher_B.com domain. Now this same consumer has two PIDs stored in 1st party cookies — each only accessible when visiting the originating site.

Storage issues

Within the past year, Apple has continued to ratchet-up the ITP restriction on cookies in Safari, and now even 1st party cookies are being squeezed. In many situations, 1st party cookies will now only persist for 24 hours before being deleted. As a result, web developers — including DMPs — have increasingly used browser local storage as a fallback for storing PIDs.

Browser local storage is a standard technology built into all major web browsers. It allows for the storage of larger amounts of data (e.g., HTML code) than cookies, and over longer periods of time than cookies. Browser local storage isn’t magic technology — it’s standard web browser technology — and using it to store PIDs isn’t innovation.

When companies  refer to their tech as “cookieless,” it should be qualifying such as “3rd party cookieless.” It is worth noting that, despite loud and repeated marketing claims to the contrary, these companies use 1st party cookies as the centerpiece of their platform for data collection. We know this factually and objectively because they say so in their documentation. 

The facts about profile identifiers, browser storage mechanisms, and privacy regulation

I’m not exactly sure how the idea came about in the press that “cookieless DMPs” are automagically GDPR compliant. However, that’s a misunderstanding that needs to be corrected. Whether a PID is stored in a 1st party cookie, 3rd party cookie, or local storage has no bearing on GDPR compliance obligations as a processor for a publisher’s data.

Consumers have a set of rights under GDPR. Therefore, any technology company processing consumer data on behalf of a publisher needs to provide a means for publishers to transmit to such processors the consent signals for data collection and use. They must also provide a way for the processors to enforce those consumer consent choices. Mobile devices don’t use cookies whatsoever in the app-space. However, publishers still need to comply with GDPR. 

Regulation

GDPR compliance obligations for a publisher-as-controller and a vendor-as-processor do not differ based on whether a vendor’s PID is stored in a 1st party cookie, 3rd party cookie, or browser local storage. Even if no 1st or 3rd party cookies were used — and if browser local storage was exclusively used — the GDPR obligations for the parties remain the same.

True forward-thinking innovation for publishers will be based upon connecting publisher data to marketer data in meaningful ways across channels and platforms. It requires providing the means for all parties to analyze, enrich, and activate for commercial benefit — while always respecting consumer privacy and empowering choice.

---

About the author

As Chief Marketing Officer, Adam leads Lotame’s global marketing and product teams in helping publishers, marketers and agencies solve complex business challenges with unstacked data solutions. His diverse experience balances art and science. It includes stints as an aerospace engineer and patent attorney, plus 21 years in consumer media and marketing technology in leadership roles at Viacom Media Networks, Time Inc., Hearst, and PebblePost. Adam is co-inventor on four issued U.S. patents related to interactive video advertising technology.