Despite slick marketing from DMP start-ups, publishers need to know the truth about first-party data management technologies and why scaled connectivity is the key to success
by Adam Solomon, Chief Growth Officer, Lotame
As the head of marketing and product at Lotame with over 20 years experience working at marketing technology companies and some of the largest media companies on the planet (Viacom, Time Inc., and Hearst), I must tip my cap to DMP start-ups such as Permutive and 1+x for bringing new energy and interest to the data management needs of publishers and their commercial partners. In an ever-changing publisher media landscape that features fragmentation in delivery channels, consumer consumption behaviors, and privacy regulation, we should collectively focus our time and efforts 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.
While I admire the marketing prowess and focused messaging of these DMP start-ups, I can’t stand by while they purposely and repeatedly mischaracterize the technical capabilities of Lotame products, and for confusing publishers (and media outlets) on the facts related to profile identifiers, browser storage mechanisms, privacy compliance, and “match rates.”
In this series of 3 blog posts, I will set the record straight on these topics in a detailed, direct and truthful manner that is consistent with Lotame’s 13+ year reputation for honesty, integrity, and transparency.
In Part 1 below, I will detail the facts on profile identifiers, browser storage mechanisms and privacy regulation. I will demonstrate that Lotame does not “depend upon 3rd party cookies,” but rather uses 3rd party cookies, 1st party cookies, and browser local storage to give our publisher clients the most robust and flexible techniques to store profile identifiers associated with their website visitors.
Part 2 will focus on the evolution of data connectivity between platforms — including Google Ad Manager (DFP) — and what segment “match rates” really mean. I will demonstrate that Lotame features both server-to-server and in-page API activation connections for Google Ad Manager and over 90 other activation platforms. When using the same activation configuration as Permutive, the Lotame platform returns a ~100% segment match rate. When examining segment match rates against 90+ adtech/martech ecosystem platforms beyond Google Ad Manager, DMP start-ups such as Permutive don’t even come close to Lotame’s global scale and segment match rates.
Finally, in Part 3 I will propose a re-framing of what effective next-generation data management technologies should provide to publishers, with an emphasis on scaled and privacy-enabled connectivity between data sources and platforms. I will demonstrate that as an industry, we have seen at least 3 generations of DMP technologies, and the functionality currently being offered to publishers by start-up DMPs such as Permutive are more akin to DMP 1.0 from 10 years ago. While “DMP 1.0” is a cleaner story to tell when regulation is complex and increasing, regressive technologies won’t bring the industry forward or meet the needs of any but the most basic requirements.
True forward-thinking innovation for publishers will be based upon connecting publisher data to marketer data in meaningful ways across channels and platforms, and providing the means for all parties to analyze, enrich, and activate for commercial benefit — while always respecting consumer privacy and empowering choice.
PART 1
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.”
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, and by itself usually has no information in it 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 — 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 (it’s a text file), and you put a PID string inside the cookie.
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, which 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 2 PIDs stored in 1st party cookies — each only accessible when visiting the originating site.
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 that 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.
Lotame uses all 3 browser storage methods in a cascade manner to store and retrieve Lotame PIDs. We first try using 3rd party cookies — if 3rd party cookies cannot be set, then we place the Lotame PID in both a 1st party cookie and local storage. When retrieving the Lotame PID, we read it from local storage if the expected 1st party cookie is not present. Pretty simple and straight-forward.
When Permutive refers to a “cookieless technology,” it should be qualifying such as “3rd party cookieless.” It is worth noting that despite loud and repeated marketing claims to the contrary, Permutive uses 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.
So to repeat, Lotame uses 3rd party cookies, 1st party cookies, and browser local storage to give our publisher clients the most robust and flexible techniques to store PIDs associated with their website visitors. Lotame does not “depend on 3rd party cookies.” That is the truth, irrespective of what any DMP start-up might say about our technology.
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, but 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, and 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, and for the processors to enforce those consumer consent choices. Mobile devices don’t use cookies whatsoever in the app-space, but publishers still need to comply with GDPR.
In Q1 2018, Lotame released our Consent API, which provides publishers (and other client types) with a robust set of tools to transmit consumer consent signals for data collection, analytics, targeting and device graph use. The Lotame Consent API — and our global opt-out tools — are designed to be effective irrespective of whether the Lotame PID is being stored in a 1st party cookie, 3rd party cookie, or browser local storage.
GDPR compliance obligations for a publisher-as-controller and a vendor-as-processor does 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 would remain the same.
Well there you have it, a bit long and detailed, but as I stated at the outset, Lotame is dedicated to being truthful and clear with our clients and the broader market as to our platform capabilities. It is truly unfortunate that we need to take time and effort to push back against misleading claims about our platform and correct assertions about privacy regulation matters. But we love being in the arena on behalf of our clients, and we will work our hardest to provide publishers (and marketers and agencies) with data-driven technologies and solutions that help them engage consumers at scale with compelling and revenue-generating content and services.
How are marketers and publishers adjusting their customer acquisition strategies in light of nonstop industry change? We surveyed over 1,400 decision-makers to better understand identity’s role in their cookieless future, what they’re adding and removing from the next-gen tech stack, and where they plan to invest today and in the future. Get the report here.
