Digiday+ Research: A guide to the top 10 ID alternatives for publishers

Privacy-friendly identifiers allow publishers to rely on user-volunteered first-party data – such as email addresses, names, clicks and more – in larger, more open markets without compromising user privacy. These publisher first-party IDs can be matched with advertiser-created first-party IDs to find ad placement matches within DSPs or other shared tools. Most IDs are built from both deterministic identity data (easy to personally identify: name, email address) and probabilistic identity data (connecting individual data points from disparate sources such as device and browser usage, to probabilistically identify a user).

As more companies enter the complex identity space and experiment with ID compliance, construction and matching, Digiday created this guide of the 10 leading alternative IDs, selected on the basis of adoption and innovation. Digiday researchers spoke with executives and product leaders at each of the ID companies and conducted additional independent research. In the following encyclopedic resource, we dive deep into all 10 to map out exactly how they work and who should use them. 

10 alternative ID options

Here is a comprehensive overview of what makes each of the IDs unique and for whom they’re best suited.

How the data stacks up

Digiday collected information from each of the ID companies about what data they use to build the backbones of their IDs. Email addresses are the most common data type used to construct IDs. While most IDs don’t use third-party cookies, they are still the most common way to match across the ecosystem for now.

Privacy mechanisms employed for ID creation

ID companies have to be compliant with EU privacy regulations and some US state privacy regulations like CCPA. Three key compliancy traits Digiday identified are consent, transparency and user data protection mechanisms. Most companies are encrypting user data. Others are taking it a step further by offering constantly changing ID tokens. The tokens both protect data and help to avoid a lag between when a user consents to receive personalized marketing and when they might opt out on another publisher domain or device. 

Deep dives into the IDs

If the ad tech ecosystem was not complex enough, with privacy and alternative IDs added to the mix, publishers are racking their brains to understand what ID solution is right for them. To simplify the issue, Digiday breaks down the key characteristics of each of the leading IDs and maps out their ideal use cases. 

The login-based ID solution

Based on an interview with Iván Markman, Yahoo’s chief business officer, and Gio Gardelli, who leads product for Yahoo’s ad targeting, identity and trust

What is ConnectID?

ConnectID is a first-party, consent-driven identity solution owned by Yahoo that uses consumer login information, such as email addresses, to identify users across publisher and advertiser websites. ConnectID is for publishers and advertisers who have direct relationships with users. (Yahoo also has a contextual targeting solution, Next-Gen Solutions, for those who do not.) 

It utilizes Yahoo’s large consent-based identity graph of deterministic data from opted-in users to reconcile users and build IDs. ConnectID only works with Yahoo’s DSP, which provides audience activation for millions and media measurement ranging from traditional display to CTV, programmatic audio and digital out-of-home.

Who should use it?

Publishers and advertisers with more resources and direct user relationships who want to outsource ID matching.

What does it do?

ConnectID is used for omni-channel planning, activation and measurement and attribution through to the supply side where Yahoo integrates with publishers who have consent from their customers. It also connects advertisers who have consent-based login information from customers via their CRM files, loyalty programs and more. Advertisers and publishers can connect with Yahoo’s identity graph, so the identities run inside of Yahoo’s unified stack.

Why is it unique?

ConnectID taps into Yahoo’s vast identity graph of user data. Because Yahoo itself is a large publisher, it has rich consent-based login, demographic and contextual information on millions of unique users. It reaches 148 million deterministic logged in users in the US alone.

How does it work? 

• When a user logs onto Yahoo.com or another publisher’s or advertiser’s portal, they provide their email address to the site and consent to the site’s use of their information.
• The user’s email address is sent to Yahoo using APIs. It is hashed and an additional layer of encryption is added before it is sent back to the publisher as a ConnectID to share for real-time bidding. It is a one-way process.
• The ConnectID is linked to Yahoo’s identity graph and shared in Yahoo’s DSP. In the DSP, the publisher and advertiser IDs are matched, providing secure ad placement.
• The DSP allows for activation and measurement across multiple media channels.

Who are the partners?

Publishers: Over 11,000 publisher domains like BuzzFeed, The Arena Group (formerly Maven), CafeMedia, Mediavine and Newsweek

Advertisers: Over 1,200 advertisers activate first-party data with the ID. Over 2,000 advertisers placed ads where Yahoo ConnectID was enabled as of December 2021.

Technical: Yahoo has over 20 partnerships with DMPs and CDPs to provide interoperability and support for ConnectID, including Epsilon, Catalina, NCSolutions, IRI, mParticle, Adobe and Merkle’s Merkury.

Adoption: Yahoo, through both direct consumer relationships and industry partnerships, reaches 148 million deterministic logged in users in the US across over 240 million unique profiles, tied to 100 million IDs and 400 million unique devices.

What kind of data does it use to identify users?

Core deterministic data: Login information, mainly in the form of email addresses, which are reconciled at an individual user level. For instance, if multiple email addresses with @gmail.com, @yahoo.com or @aol.com are used by the same person for site logins, they are reconciled to form a single ConnectID for one person.

Other deterministic data: N/A

Probabilistic data: N/A

Does this solution use third-party cookie data?

No. Third-party cookie data is not used to build a ConnectID. The ID itself, however, can connect with other IDs that use third-party cookies.

How does this ID solution address consent and user privacy?

• Consent: ConnectID relies on the publisher’s, advertiser’s or Yahoo’s own login data that a user provides by choice.
• Transparency: ConnectID relies on the publisher’s and advertiser’s notices.
• Data protection: An email address provided by a publisher or advertiser is hashed and encrypted. The same email is encrypted differently on various publisher sites, so it cannot be easily intercepted. Additionally, a user cannot be tracked across publishers because the encryption keys are periodically refreshed every two weeks as an extra layer of security to prevent data abuse, leaking or de-anonymization attempts. On the interoperability side, the ID works slightly differently depending on its use. For instance, in targeting, the data flows one way from DMPs and CDPs, or in some cases advertisers, directly into Yahoo’s platform. Yahoo simply enables the platforms or advertisers to send hashed emails through APIs, and the hashed emails are converted into ConnectIDs. The ConnectIDs are used for targeting, forecasting and planning.

About Yahoo

Yahoo is a global internet services provider, headquartered in Sunnyvale, California. Stanford University graduate students Jerry Yang and David Filo founded Yahoo in 1994. Verizon Communications acquired Yahoo in 2017, merged it with AOL and rebranded the combined entity as Oath. It later changed the name to Verizon Media Group. Verizon Media launched ConnectID in December 2020. In September 2021, private equity firm Apollo Management Group acquired a 90% stake in Verizon Media and changed its name back to Yahoo. Yahoo owns ConnectID.

The first-party data resolution ID solution

Based on an interview with Sara Stevens, Epsilon’s former VP of digital capabilities

What is CORE ID?

CORE ID is a person-based identity resolution offering for publishers and advertisers that is rooted in deterministic data, in particular offline name and address data. Epsilon’s Publisher Link, an identity solution, activates first-party authenticated data and a user’s unique PubCommon ID which reads to the already established CORE ID. On the publisher side, this is achieved through an integration specific for the publishers; on the client site side, it uses a tagging integration.

Epsilon’s PubCommon ID, which is an open source first-party cookie ID in the publisher’s domain, was adopted by Prebid in 2020 and merged with SharedID. 

What does it do?

Publishers and advertisers can connect their first-party data to CORE ID’s established users’ digital identities. Publishers and advertisers can connect with the same IDs, allowing CORE ID to provide ID resolution and matching, while keeping PII safe.

Why is it unique?

An offline name and address is the basis of CORE ID. And once a user opts out on one device, they are opted out on all devices, making user consent a dominant factor. 

Who should use it?

Publishers and advertisers with more resources to outsource ID resolution and matching.

How does it work? 

• A tag is placed on both the publisher website and the client/advertiser website. Both entities make a call to the CORE ID service when a person visits their site to check whether the user has a CORE ID. 
• If yes, the email address is hashed and shared with the service, which connects it with offline deterministic data and adds other personally identifiable information (PII)-based elements, phone numbers and other email addresses. It connects this data at a user level and anonymizes it. This helps establish the user’s base identity. 
• In stage two, digital identity such as device usage and cookie-based data is connected to the base identity information to enable activation. 
• Pseudonymization of user data and matching occurs through Epsilon’s data processing product Agility and its DSP. If both publisher and advertiser are using CORE ID, matching can occur across the internet. And advertisers can also target prospective customers. 

Who are the partners? 

Publishers: Native integrations with over 8,000 publishers

Technical: LiveRamp and The Trade Desk

DSPs: Native direct integrations with The Trade Desk, Yahoo (previously Verizon), Google Display and Video 360, Facebook

Adoption: According to Epsilon, on average amongst those who implement PubCommon ID (which reads to CORE ID) with Publisher Link see 50% increase in publisher revenue and 60% increase in filled impressions

What kind of data does it use to identify users?

Core deterministic data: Name, email address, postal address

Other deterministic data: Phone number, first-party cookies

Probabilistic data: Device data, browser activity, IP address, third-party cookies

Does this solution use third-party cookie data?

Yes, on Chrome, but not on Safari. 

How does this ID solution address consent and user privacy?

• Consent: Digital opt-out signals are part of Epsilon’s Agility process. In the United States, Agility receives opt-out flags from the client side when a user does not want to see advertisements, and these flags are honored in both publisher and advertiser channels. For Safari browser, Epsilon follows the IDFA, the opt-in service for Apple app-based advertising. In Europe, Epsilon offers a free consent tool widget for clients to help them manage cookie-related messages.
• Transparency: Epsilon relies on transparency mechanisms, like opt-out options, provided by publishers and advertisers.
• Data protection: Epsilon uses Agility to pseudonymize PII data and collapse those signals into a generic ID, such as a random string of numbers like 48232. This generic ID resides in the ad server and is sent to the DSP — it has no PII attached to it. 

Is it interoperable? 

Yes. CORE ID can be mapped to LiveRamp’s universal connector and is integrated with The Trade Desk’s UID 2.0.

About Epsilon

Epsilon is a global data tech platform owned by Publicis Groupe. Publicis acquired Epsilon, which has more than 8,000 employees in over 40 offices worldwide, in 2019. Epsilon designed CORE ID in 2007 on a privacy-by-design basis and has been building its identity graph of more than 200 million people through direct publisher relationships since 2012. In 2021, Epsilon united CORE ID with The Trade Desk’s Unified ID 2.0 to create interoperability between the IDs, allowing Pubicis clients to activate CORE ID on The Trade Desk’s DSP; and allowing The Trade Desk to become the exclusive DSP partner for CORE ID. 

The multi-ID solution

Based on an interview with Steve Silvers, Neustar’s svp and gm of marketing solutions – identity

What is Fabrick ID?

Fabrick ID is a programmatic token that is made up of a variety of publisher-provided PII and is designed as a cookie replacement. Clients can use Fabrick ID to build marketing programs, either at the household level or the individual level. Once a campaign is executed, Neustar performs measurement using Fabrick ID and other IDs.

Who should use it?

Publishers who use multiple IDs and want to connect those data sources across one platform for transactions and measurement.

What does it do?

Neustar turns publisher-provided user information into a token in the form of a Fabrick ID and sends it back to the publisher. The publisher-specific token can be used to communicate with Neustar’s connectivity platform, also called “Fabrick,” and to sell its media programmatically. The platform can connect any other IDs the publisher is using with Fabrick ID and provide measurement. Neustar does not build or allow customers to build mapping tables.

Why is it unique?

Fabrick ID is one piece of a connectivity platform, which is Neustar’s main product. Fabrick ID can be used with multiple other IDs to create a publisher-specific ID to run campaigns and/or measure their effectiveness. The Fabrick ID token does not transfer or translate into another ID.

How does it work? 

• The publisher calls Neustar’s API, either on a page as a tag or via a backend process. The call passes user-related information, typically in some combination of a hashed email, phone number, first-party cookie and/or an IP address, to the Neustar platform. 
• Neustar turns that information into a token, which is the Fabrick ID, and sends it back to the publisher. The publisher uses the syndicated ID to sell its media programmatically. If the publisher is targeting households, Neustar will create one Fabrick ID for the entire household. If the publisher is targeting individuals, Neustar will create a Fabrick ID for each individual in the household..
• Neustar sends the IDs to publishers or to advertisers to launch the campaigns. In some cases, Neustar builds audiences in an SSP and this ad inventory is purchased via a private marketplace deal. In other cases, the transaction occurs through a DSP.
• Once a campaign is executed, Neustar receives logs for the IDs used and it performs campaign measurements using the IDs.

Who are the partners? 

Publishers: Several 100s of publishers

Advertisers: 400+ advertisers, 70% of which represent the top 100 globally

Adoption: Neustar has run nearly 400 campaigns since Fabrick ID launched in July 2020. 

What kind of data does it use to identify users?

Core deterministic data: Publisher-provided hashed email

Other deterministic data: Phone number, first-party cookies

Probabilistic data: IP address

Does this solution use third-party cookie data?

No. Neustar does not use third-party cookies for the Fabrick ID token, nor does it require them for transactions. 

How does this ID solution address consent and user privacy?

• Consent: Users give consent on a publisher’s privacy page.
• Transparency: The Fabrick ID requires clear language on the privacy pages of all  publishers that use it for user opt-out and consent to sell user data
• Data protection: The Fabrick ID token is reset every seven days. The IDs are designed to expire quickly, reducing the lag time between when a user opts out and when the opt-out takes effect. 

Is it interoperable? 

Yes. Neustar’s connectivity platform supports multiple identifiers. In addition to supporting Fabrick ID, it also supports Ramp ID and UID 2.0.

About Neustar

Neustar is an information services and technology and identity resolution company that provides real-time data and analytics for the marketing, risk, communications and security industries. It was founded in 1996 as a division of Lockheed Martin. TransUnion acquired Neustar in December 2021. Neustar is headquartered in Reston, Virginia.

The device-level ID solution

Based on an interview with Mathieu Roche, ID5’s CEO 

What is ID5 ID?

ID5 ID is an encrypted first-party data ID that gives publishers an individual device ID to share with their partners. The ID provides the infrastructure that enables ID matching for publishers. The ID is resolved cross-site and cross-device to allow for better measurement and attribution. 

Who should use it?

Publishers with more resources to outsource ID creation and privacy compliance in order to run campaigns while keeping user data safe.

What does it do?

This ID gives publishers encryption and decryption capabilities to protect user data when it enters the bid stream and to remain privacy compliant. ID5 also provides access to update requests so publishers can build audience segments, monetize ads and buy or sell campaigns. 

ID5 does not provide a mapping service or match with ads in DSPs on behalf of publishers; the latter send ID5 IDs into SSPs themselves. It does not run campaigns, build segments or collect or create user profiles. It can handle identification signals based on consent because these signals are considered personal data in some jurisdictions.

Why is it unique?

The ID is built using a privacy-by-design approach, meaning that privacy implications and concerns are addressed at the core of product, services and system designs development. Sites and applications that work with ID5 have an obligation to disclose that ID5 is collecting user data and what type of data is being collected. The sites pass consent, opt-out and do-not-sell signals to ID5, which only executes its services when it has the transparency and control required by law.

How does it work? 

• A type of API integration is enabled via the publisher site (ID5 has direct relationships with 100s of publishers) or through technology partners that call ID5 on behalf of the publisher site. 
• The site authorizes ID5 to retrieve the data and to create an ID5 ID for that particular user. 
• The ID is reconciled across sites or applications using a combination of probabilistic and deterministic approaches to make sure the ID is consistent. 
• Publisher partners then can run cross-site data collection, implement profiling and measurements, and share the ID with partners for ad targeting and to sell ads for higher prices. 

Who are the partners? 

Publishers: Direct relationships with 400+ publishers, including Complex Networks and NDTV

Brands and agencies: Who need user-level identification, the likes of Scream Malmo

Technical partners: 100s of data companies, SSPs and DSPs, including Amazon, Prebid and PubMatic

Adoption: ID5 ID is active on more than 70,000 websites and mobile applications, mostly reached through supply side/publisher integrations. According to ID5, between 10% and 50% of bid requests globally contain an ID5 ID, and it reaches 4 billion devices per month.

What kind of data does it use to identify users?

Core deterministic data: Email addresses (to tie information across domains and sites)

Other deterministic data: Phone number

Probabilistic data: IP address user agents, browser activity including page URLs and timestamps during a visit (an algorithmic/probabilistic approach is used to guess that the same device is interacting repeatedly across sites)

Does this solution use third-party cookie data?

No. It only uses first-party data and can match with third-party IDs if consent is present.

How does this ID solution address consent and user privacy?

• Consent: ID uses consent strings. 
• Transparency: Publisher partners are required to inform users that ID5 is collecting data.
• Data protection: ID is encrypted. Data is turned into a random alphanumeric string of characters or hash.

Is it interoperable? 

No. Currently, it does not match with other alternative IDs. 

About ID5

ID5 launched in 2017 as shared identity infrastructure for ad tech platforms and premium publishers. It is a privacy-compliant ID solution founded by ad tech executives Mathieu Roche, Pierre-Antoine Durgeat and Scott Menzer. In April 2022, data-certification company Neutronian named ID5 the first Neutronian Quality Index certified identity solution, indicating that ID5 “meets or exceeds industry standards in the areas of data quality and privacy compliance.”

The publisher newsletter ID solution

Based on an interview with Mano Pillai, LiveIntent’s chief product officer

What is nonID?

NonID is an email-based encrypted identifier token for publishers. NonID’s parent company LiveIntent places ads within publisher newsletters and therefore has access to large amounts of subscriber email address or “zero-party” data on which it builds an identity graph. LiveIntent is a full-stack platform with an SSP, an exchange and a DSP. Third-party DSPs also integrate into its exchange, where nonIDs can be matched with newsletter ads and other IDs securely and at scale.

Who should use it?

Publishers with newsletters who want to outsource ID creation and matching and want to generate revenue by placing ads in newsletters.

What does it do?

NonID helps publishers unify user identities and bridge with other IDs. It also provides publishers with user data to help them effectively engage with customers and place ads in their newsletters. Publishers can access LiveIntent’s identity graph to create private customer graphs, which are completely first-party in nature. 

Why is it unique?

LiveIntent primarily serves ads within newsletter inventory so that publishers can generate revenue from the ads.

How does it work? 

• When a user subscribes to a publisher newsletter, the consumer gives consent for their data to be used and it is extended in an authenticated environment to the publisher’s website. Once the consumer provides consent, LiveIntent can retrieve the first-party email address data from the publisher. 
• Publisher partners can also put LiveIntent’s JavaScript tags on their pages. That allows LiveIntent to make deterministic connections between the email channel and a publisher’s inventory, in a completely authenticated environment.
• LiveIntent turns an email address into a token/hashed email, creating a nonID.
• LiveIntent has a module in Prebid through which it passes nonIDs into the bid stream for the buy side to transact on on the web.

Who are the partners? 

Publishers: over 700 publishers have JavaScript on their page which enables nonID

Adoption: 200 million unique email addresses covering the US addressable audience. 8.6+ billion records are tied to LiveIntent’s identifiers, 60% of these are tied to an anonymized email address. In the LiveIntent Exchange, 100% of impressions have nonID associated with them. 

What kind of data does it use to identify users?

Core deterministic data: Email address (It does not utilize user registration data other than email addresses to build a nonID. For example, it does not use consumer names and addresses.)

Other deterministic data: N/A

Probabilistic data: N/A

Does this solution use third-party cookie data?

No. NonID does not use third-party cookie data, but it can connect with other IDs which may use third-party cookie data in LiveIntent’s ad exchange.

How does this ID solution address consent and user privacy?

• Consent: LiveIntent relies on publisher-provided consent. Publishers get consent when users register to receive their newsletters.
• Transparency: LiveIntent relies on publisher-provided transparency within the consent messages they serve to users when users register to receive newsletters.
• Data protection: Email addresses provided by publishers are hashed and encrypted. 

Is it interoperable? 

Yes. NonID identifies logged in email users across websites and apps via their hashed email addresses and bridges them with other IDs, publishers and advertisers through LiveIntent’s API or “Authenticated Bridge” framework.  

About LiveIntent

LiveIntent is an email ad monetization platform headquartered in New York. CEO Matthew Keiser and Dave Hendricks founded LiveIntent in 2009. LiveIntent uses tags embedded in publisher newsletters to serve ads to readers when they initially open an emailed newsletter. The company says it runs an exchange of more than 2,000 newsletters reaching more than 200 million readers per month. 

The universal user consent ID solution

Based on an interview with Pierre Diennet, Lotame’s product leader and chief evangelist

What is Panorama ID?

Panorama ID is a data-minimized predictive identifier that requires active user consent obtained from publishers and the Prebid privacy module. It can be used by first-party marketers and publisher clients to place ads in a privacy friendly manner. Panorama ID utilizes multiple user data points and can be used across SSPs and DSPs to match with ads and other IDs. It does not track a user across multiple publisher websites to build a match. Panorama ID enhances a cookie’s function because it’s privacy compliant and works cross-domain and cross-platform at an individual level. 

Who should use it?

Publishers who are committed to obtaining user consent; and publishers who have a large user base willing to provide active consent to be tracked and shown personalized advertisements.

What does it do?

Panorama ID uses predictive signals to build a single Panorama ID for a user only if active consent has been given. It works across various publisher domains, data points related to browser activity, and devices to build an ID that can be matched with other IDs in the bid stream and used to place targeted ads in real-time.

Why is it unique?

If a user provides active consent for their data to be used and to receive personalized advertising on one publisher website or one device, but opts out on another publisher domain or device, Lotame will not use that user’s data or track them for any reason. Lotame will opt the user out at a cluster level from all devices and publishers and will not link that data with the ID. Panorama ID is not encrypted.

How does it work? 

Panorama ID works in three ways:

1) Direct Link: When a user visits a publisher page and provides active consent, the publisher ID module makes an impression slot available for bidding with the Panorama ID. Lotame sends the first-party marketer, audience or publisher data into the DSP to  activate and meet the bids requests on the Panorama ID.

2) ID Translation: Lotame sends user data via the Panorama ID to another ID solution’s translation layer. The translation layer renders the Panorama ID data onto its ID, where it  makes a match.

3) SSP Route: A Panorama ID is included in a bid delivered to the SSP. The SSP stops the ID there and creates a deal ID, including the user data attached to the Panorama ID. The SSP passes only the deal ID through to the DSP.

Who are the partners? 

Publishers: 10,000+ 

Brands and partners: Dr. Martens, Omnicom Group, Advance Local, Rush Street Interactive, Digo Hispanic Media, MediaMath, PubMatic, and more

Adoption: Has run nearly 400 campaigns in the first 12 months after its launch in October 2020. Panorama ID results vs cookies include:

• 9.43X lift in CTR / 107% more viewable impressions
• 3X cheaper than cookies / 2X scaled delivery
• 8X CPM for publisher, lift in overall yield / 2X previously unaddressable inventory
• 31% impression lift in all browsers / 2.5X more efficient delivery than cookies

What kind of data does it use to identify users?

Core deterministic data: N/A

Other deterministic data: First-party cookies

Probabilistic data: IP address, browser activity, device data, third-party cookies, large data sets of consented traffic, timestamps and, in some cases, user agents (optional), mobile ad IDs (if available in-app) and CTV device identifiers (if available)

Does this solution use third-party cookie data?

Yes, if a third-party cookie is present on the browser when the user consents.

How does this ID solution address consent and user privacy?

• Consent: Lotame requires active user consent and reactive opt-out, and only uses a consumer’s data when they agree to be shown personalized advertisements based on browser history, etc. Lotame requires active consent on every publisher domain. It does not automatically assume if a user gives consent on one publisher domain that consent is also given on another publisher domain. 
• Transparency: When a user goes on a publisher’s page, they are notified of Lotame’s data usage and tracking in a publisher consent management system message to the user.
• Data protection: Panorama ID is not encrypted. It is derived from a privacy API, which only shares user data if consent is present.

Is it interoperable? 

Yes. Panorama ID syncs with Ramp ID currently.

About Lotame

Lotame Solutions is a data management company founded in 2006 by former advertising executive Andrew Monfried. Lotame works with publishers, marketers and agencies to collect customer data for audience segmentation and ad targeting. It is headquartered in Columbia, Maryland, with global clients. Lotame launched Panorama ID in October 2020 and it became available for use in January 2021.

The interoperable ID

Based on an interview with Travis Clinger, LiveRamp’s svp and head of addressability and ecosystem

What is Ramp ID?

Ramp ID is an anonymized people-based ID rooted in deterministic offline data, such as email and postal addresses, names and phone numbers. It can connect with IDs stored by premium publishers (Facebook and Google, for example) through integrations, and can be used for direct open internet deals and private marketplace activations. Once a RampID is created, LiveRamp provides cookie syncing across the industry using standard technology to match in DSPs, for example matching to The Trade Desk’s cookies or MediaMath’s cookies.

Who should use it?

Publishers and advertisers with more resources who want to outsource ID creation and matching, and who want greater interoperability.

What does it do?

Publishers and advertisers can use LiveRamp’s authenticated traffic solutions (ATS) service to connect with a user’s offline identity to enhance and anonymize it, and match at scale. It does not collect, store or enhance publisher-provided email addresses.

Why is it unique?

Ramp ID is built to be interoperable with other IDs across the internet. It does not connect with IDs based on fingerprinting.

How does it work? 

• LiveRamp’s ATS runs on a publisher website. When a user logs onto the site their email address is shared with the publisher in exchange for content. That email address is passed through to an API via LiveRamp’s Safe Haven platform, a neutral third-party data clean room.
• The email address is connected to a Ramp ID specific to that user and is passed back to the publisher, all in real-time. 
• The ID connects the publisher’s first-party inventory to a marketer’s database of first-, second- and third-party data. The latter’s data are linked to the same anonymous Ramp ID. 
• Once the publisher’s and marketer’s Ramp IDs are linked, the marketer can buy an impression. 

Who are the partners? 

Publishers: 500+ publishers representing 11,000+ domains worldwide including Amazon, Microsoft, CafeMedia, Leaf Group, Prisma Media and Burda

SSPs: 60 SSPs 

DSPs: Live on 67 DSPs, like The Trade Desk, Amobee, Criteo, Dataxu and MediaMath

Adoption: Connected to over 70% of consumer time spent online either via ATS or via direct integration, reaching 250 million+ consumers in the US

What kind of data does it use to identify users?

Core deterministic data: Offline name and postal address history, email address

Other deterministic data: Phone number

Probabilistic data: Third-party cookie data is used for matching at scale

Does this solution use third-party cookie data?

No. Third-party cookie data is not used to build Ramp ID, but in the US and in some limited international locations, third-party cookies are used to connect the ID to publisher inventory for it to function at scale. This capability is being rolled down and is expected to be replaced with ATS in the future.

How does this ID solution address consent and user privacy?

• Consent: LiveRamp works with publisher partners who are contractually required to give consumers proper notice and choice about how their information will be used, and further provide the consumer the option to opt out of data collection. Consumers can opt out at the publisher level or from all personalized advertising. LiveRamp also runs its own CMP, a privacy management system it gives to publishers at no cost.
• Transparency: LiveRamp’s ATS requires that the consumer shares their identity with the publisher, and publishers must give consumers a link to LiveRamp’s opt-out site. The consumer can opt-out at the publisher level or they can opt-out at the LiveRamp level. This enables users to opt-out at the person-level from ATS and RampID, whereas a user opting out at the publisher level would still allow them to participate in ATS on another publisher site. 
• Data protection: A Ramp ID is created through a one-way hash and encryption process to make it an anonymous ID. The ID cannot be unencrypted after it has been created. So, while data can be turned into a Ramp ID, a Ramp ID cannot be turned back into data. Consumer identity is matched anonymously to the Ramp ID and then to third-party cookie data.

Is it interoperable? 

Yes. Ramp ID is interoperable with any number of “privacy-first” IDs, including: UID 2.0; Fabrick ID; Facebook ID; Google Ad ID; Twitter ID; Snapchat ID; and a number of agency IDs.

About LiveRamp?

LiveRamp is a data enablement platform headquartered in San Francisco. Acxiom Corp., a legacy data analytics, and software service company founded in 1969, acquired LiveRamp in 2014. Four years later, Acxiom sold the Acxiom Marketing Services portion of its business to agency company Interpublic Group and rebranded the remaining portion of its business under the existing LiveRamp moniker. LiveRamp’s Ramp ID has access to Acxiom’s nearly 50-year reserve of data collected from its data management and direct mail customers.

The basic first-party-cookie ID solution

Based on an interview with Garrett McGrath, Prebid’s chairperson

What is SharedID?

SharedID is an open source ID-generating service for publishers, which uses a first-party cookie with no probabilistic features or background functions. The ID serves as a storage mechanism for the site’s first-party data. It does not allow for cross-site tracking, except for within the publisher’s own domain. (Epsilon made its PubCommon ID, also a first-party cookie, available to Prebid in 2020. Prebid merged SharedID and PubCommon ID to create one SharedID.)

Who should use it?

Small to large tech-savvy publishers with fewer resources who want to share their first-party data with DSPs via an ID solution.

What does it do?

It takes first-party user data collected by a publisher and generates a globally unique ID that publishers can use to identify individual users and to attach interest attributes to users. Once SharedID is implemented on a publisher’s page, it creates the user ID and stores it on the publisher’s own domain. The ID is sharable and can be used with SSPs or with other IDs.

Why is it unique?

SharedID is owned and operated by Prebid.org, an open source organization. It is not an authenticated ID tied to a piece of registered information on an external server and hidden from the user’s or publisher’s view. It is, very simply, a first-party cookie that stays within the publisher’s domain and is a submodule in the Prebid user ID module. The Prebid user ID module is a container of sorts for universal IDs in which different ID vendors can create submodules. (There are about 30 submodules in Prebid.) SharedID does not synchronize with external parties like some other IDs. 

How does it work? 

• Publishers put code on a page for the purpose of creating a wrapper for header bidding, which enables SharedID creation. 
• Once a publisher enables SharedID, the SharedID value is written to the page in a first-party cookie. 
• SharedID remains within the publisher domain and the publisher can choose to share it with an SSP or DSP. 
• The ID is subsequently made available to the programmatic bid stream through open RTB and it arrives at the front door of the SSP, and then at the DSPs, alongside all the other user IDs the publisher has elected to send.

Who are the partners? 

Publishers: 30,000+ publisher domains

Technical: Submodules in Prebid

Adoption: 30,000 domains have deployed the SharedID user module

What kind of data does it use to identify users?

Core deterministic data: N/A
Other deterministic data: First-party cookie data, like where a user is positioned on a web page or a user’s bank login information
Probabilistic data: N/A

Does this solution use third-party cookie data?

No. It is a first-party-cookie-based ID.

How does this ID solution address consent and user privacy?

• Consent: The publisher is responsible for getting consent for first-party data use. First-party cookies are considered to be strictly necessary cookies and are not restricted by privacy laws, nor are they likely to be in the future. However, they still require consent under the EU’s GDPR. Prebid’s code has features and functionalities written into it that require EU publishers to have consent strings in order to maintain control of user data.
• Transparency: All websites collect first-party cookies and SharedID is controlled by the publisher. Only the publisher, the content consumer and whoever is bidding on the right to serve the consumer an impression can see the SharedID.
• Data protection: SharedID is not encrypted. Not many third-party vendors or companies can see it as it is not sent to a third-party vendor, unless sent out to the bid stream. 

Is it interoperable? 

No. SharedID is a standalone ID.

About Prebid 

Prebid.js launched in 2015 as an open-source header bidding platform to give publishers the ability to handle header bidding on their own websites and apps. According to the company, Prebid.js is the mostly widely used header bidding wrapper on the web and includes  “ … more than 300 demand sources and 50 analytics adapters. It supports currency conversion, GDPR, common ID systems, and multiple ad servers.” Parent company Prebid.org was formed in September 2017 to manage Prebid.js and other products. 

The user-first ID solution

Based on an interview with SWAN’s James Rosewell, 51Degrees’ CEO

What is SWID?

Secure Web ID (SWID) is a resettable, pseudo-anonymous ID stewarded by a network of operators called Secure Web Addressability Network (SWAN). The operators include publishers, advertisers, CMPs and other companies interested in transparency. SWAN requires all participants adhere to a binding contractual agreement and follow SWAN’s standardized model terms. Operators execute the SWID ID on behalf of consumers, based on their expressed preferences for personalized or non-personalized marketing. For the latter, SWID enables use cases like reporting and attribution for advertisers. 

Who should use it?

Publishers and advertisers of any size that are interested in a highly transparent decentralized ad tech system that puts consent in the users’ hands. 

What does it do?

SWID works like other ID solutions in that it allows publishers to build profiles from user data and to sell ads in the open marketplace. However, a SWID is stored in a browser cookie file and works only for a single browser. Users can provide an optional email to continue their preferences across additional browsers and devices.

Why is it unique?

Consumers have complete control over opt-in, opt-out and use of their personal information. A user can access and change their consent preferences at any time through the SWAN portal. SWID also does not require a user to provide an email address or a phone number at sign up. And it does not use Javascript.

SWAN is a community project. It is open to all and is based on the founding principles of a decentralized digital ecosystem. It is free and mainly requires participants to adhere to its model terms. For instance, if data is sent outside of the European Economic Area, there are standard contractual clauses that govern that data transfer. Small to large publishers can take part in it and as more publishers, advertisers, ad tech orgs and companies participate, and adhere to standardized SWAN governance, the ecosystem grows. It is not a blockchain-based platform.

How does it work? 

• When a user visits a publisher page that uses SWAN, a pop-up window gives them the option to opt into personalized advertising and share their email address. A new identifier is created. This provides consent across the board to publishers and advertisers within SWAN’s ecosystem. 
• The SWID is then assigned to that user to provide a transparent and consensual targeting method. It is stored as a cookie in a single browser. Users can see and change their preferences at any time, and both sender and receiver of ad transactions are signed in to increase transparency within the ad supply chain. 
• SWAN operators cannot buy or sell profile or media data. Publishers can build personalized profiles for users who provide consent.
• Publishers and SSPs have a direct relationship with SWAN operators. They retrieve and sign the data to acknowledge receipt. The Publisher or SSP then sends the data to the SWAN exchange, which also signs it. The data can be used by publishers to build user profiles and sell ads via SSPs and DSPs.

Who are the partners? 

Publishers: 10s of publishers

Adoption: SWAN participants include some top 20 publishers and advertisers, but current adoption rates are lower than for other solutions.

What kind of data does it use to identify users?

Core deterministic data: Email address (SWID is based on a user’s single browser activity and does not require a user to provide specific data. A user has the option to provide an email address if they so choose. In that case, the user only provides an email address and a four-icon code to the User Interface Provider [UIP], commonly a CMP. The SWAN operator then returns a hash of the email address using the four icons as the salt for the hash.)

Other deterministic data: First-party cookies

Probabilistic data: Browser activity, third-party cookies 

Does this solution use third-party cookie data?

Yes. SWAN uses first-party and third-party cookies.

How does this ID solution address consent and user privacy?

• Consent: SWID requires users to provide consent for data use and users can opt-out via the SWAN portal at any time. Publishers that use SWAN data are required to provide a link to a UIP on every web page, typically displayed in the footer of every web page.
• Transparency: SWAN’s entire code is open source on GitHub. A user can access the opt-in portal whenever they want and can see all the companies and publishers with whom they are sharing data. All operators that receive user data have to comply with contractual rules requiring them to meet clearly defined standards for transparency in data processing. For example, participants must cryptographically verify that they received and processed user data and sign an audit trail. 
• Data protection: SWID is not encrypted. It assigns random unique alphanumeric characters to each user but it does not tie back to the user’s identity. The ID resets whenever a user wants or when a user enters a private browsing session. (SWAN governance is still considering whether there should be a set number of days after which the ID would automatically reset.)

Is it interoperable? 

Yes. SWAN does not currently integrate with UID or Prebid, but it is capable of doing so.

About SWAN

Secure Web Addressability Network (SWAN) is a community operated, open-source, cross-domain identity network focused on consent-based privacy. 51Degrees, a UK-based data services company, launched SWAN in early 2021. It was the brainchild of 51Degrees’ CEO James Rosewell. 

The industry-wide ID solution

Based on an interview with Kanishk Prasad, The Trade Desk’s senior product manager

What is Unified ID 2.0?

Unified ID 2.0 (UID 2.0) is an encryption and decryption system for both publishers and advertisers, which is based on a user’s email address. It is a decentralized open source, industry-wide project that is not proprietary to The Trade Desk and provides a lightweight way to match IDs securely. There are two types of UID 2.0. One is the UID 2.0 token which converts an email address into a UID 2.0 token through cryptography; the other UID 2.0 is its decrypted version, which is the actual UID 2.0. It is the identifier that the publisher and an advertiser transact upon. 

What does it do?

UID 2.0 provides publishers and advertisers a secure way to target ads to users by providing both sides with an encrypted ID that can be matched in the bid stream. Publishers and advertisers must have the same user email address in order to match IDs. While the ID itself does not contain data and is shared as a hash, data (such as which site the ID is coming from) is transferred in the regular bid request. UID 2.0 is not an ID resolution system. It does not use fingerprinting or behind-the-scenes tracking.

Why is it unique?

UID 2.0 is a decentralized system that can be operated by multiple independent and private entities, like different publishers and organizations. It is also interoperable with other IDs.

It is managed by an administrator, currently The Trade Desk, to ensure partners using the service meet privacy compliance standards. (UID 2.0 is expected to be handed off to an independent entity for administration, but a recent deal to have Prebid handle administration fell through.)

UID 2.0 has two types of operator participants: open and private operators. Open operators, like Prebid for example, tend to be used by publishers who don’t have the bandwidth to host the service in-house. Most publisher partners, like The Washington Post, are private operators. UID 2.0’s administrative body provides private operators with an algorithm to generate a UID 2.0 within their environment, so a user’s personally identifiable information does not leave the publisher’s or advertiser’s walls. 

Who should use it?

Small to large publishers and advertisers who want to use encrypted IDs for matching and have large reserves of user email addresses. 

How does it work? 

• When a user visits a website and explicitly provides an email address to a publisher or to an advertiser, that email address is shared with the operator/service.
• A publisher sends a request to an operator to generate a UID 2.0 token using a user’s email address. The processing or conversion to a UID token works on a publisher’s or advertiser’s domain, if they are private operators, or through open operators like Prebid. An advertiser with the same email address on its side also has the email address converted to a UID 2.0.
• The operator generates the constantly changing token ID, which is essentially a hash, for the publisher by running it through an algorithm. This can be shared with DSPs.
• Once the token reaches the DSP, the DSP sends a decryption key request to the administrator (currently The Trade Desk) so the publisher and advertiser UIDs can be matched in the bid stream.

Who are the partners? 

Publishers: 100+ publishers, such as BBC and Business Insider

SSPs: PubMatic and Magnite, among others

Data partners: Neustar and Nielsen, among others

Industry partners: Ad Council, IAB and Trustworthy Accountability Group (TAG), among others

Adoption: 250 million people are reachable via UID 2.0 in combination with The Trade Desk

What kind of data does it use to identify users?

Core deterministic data: Email address

Other deterministic data: N/A

Probabilistic data: N/A

Does this solution use third-party cookie data?

No.

How does this ID solution address consent and user privacy?

• Consent: A user has to provide an email address to the publisher or advertiser and take explicit action before a UID 2.0 can be generated. 
• Transparency: The Trade Desk is working on creating a user-friendly opt-out portal and a system to give users clear notice that the email addresses they’re providing will be converted into advertising IDs. They are also implementing audit mechanisms, which allow administrators to “kick out” non-compliant companies from the UID 2.0 system.  The audit mechanisms will be administered by independent entities instead of private companies in the future. The entire code base is already open source through the IAB Tech Lab on GitHub.
• Data protection: A user’s email address is hashed, and cryptographic noise and a  “secret salt” is added to it, so it cannot be leaked or traced back to the user. This process turns publisher-shared user data into a UID 2.0 token. The token ID changes every hour or so. The administrator receives token decryption key requests from the buy-side. The token is only decrypted if the requestor is compliant with all UID 2.0 rules and has passed all audits. The ID cannot be traced back to the user, nor can it be broken back down to the email address.

Is it interoperable? 

Yes. It is currently interoperable with LiveRamp’s Ramp ID.

About The Trade Desk

The Trade Desk is an ad tech company that specializes in programmatic media buying. It operates a self-service, cloud-based platform through which ad buyers can create, manage and optimize digital advertising campaigns across ad formats and devices. The Trade Desk says it is “the fastest growing demand-side platform in the industry.” It was co-founded in 2009 by Jeff Green, who previously co-founded DSP AdECN, and David Pickles, who joined AdECN in 2007.

Consent Strings

A consent string, also referred to as a “daisybit,” is a series of numbers added to an ad bid request which identifies the consent status of an ad tech vendor — whether or not they have a user’s consent to use their data in order to serve them personalized advertising — a stipulation now needed under the General Data Protection Regulation. The Interactive Advertising Bureau Europe has assigned a consent string to every vendor that has signed up to its global vendor list, a step any vendor needs to take if it wants to be part of the IAB Transparency and Consent framework. Google also has its own consent string version for companies that use its Funding Choices consent management platform. Read more here.

Hash

A hash or a “cryptographic hash function” is a mathematical function which uses an input value to produce a randomized output value, generally in the form of an alphanumeric string. The same input always yields the same output. Hashing is a one-way function, essentially irreversible; whereas encryption is a two-way function so data can be decrypted using a key. Hashing is a method used for anonymizing user data before sending it into the bid stream for matching. 

IDFA

IDFA (Identifier for Advertisers) is the mobile identifier companies use to track Apple device users without revealing personal information. Companies will have less access to the IDFA once apps are required to ask people for permission to collect and share them. Read more here. 

PII 

PII stands for personally identifiable information. PII is any information that can identify a person either directly or indirectly, or any information that can be linked to a person to infer their identity. Privacy regulations lay out the distinctions between types of personally identifiable information that is deemed problematic. In the case of cookies, it is “persistent” cookies that store personal user information post-session that present the larger threat. Other types of cookies, like those necessary to help a site remember what’s in your shopping cart, “load balancing” cookies or an information service requested by a user (like in the case of online banking), fall under a “strictly necessary exemption” that allows sites to continue to use them largely unimpeded. Read more on its use here.

Token

A token protects sensitive data by replacing it with an algorithmically generated number or index. Unlike encryption, it does not require a decryption key or alter the original data. A token cannot be turned back into sensitive data and is separated from that data. It can be sent out in external environments without a risk of linkage or leakage of the original data. Unlike a hash, a token does not have to be reproducible from the same input and cannot be “joined” or used with the original data or its characteristics. A token can be hashed for an extra layer of security. 

Zero-party data

This is the data a person intentionally shares with an advertiser, as in the case when a person knowingly gives their consent for an advertiser to use their data in exchange for offers that are individually relevant to them. Zero-party data was coined by research firm Forrester last November and has begun to get more traction. It subscribes to the notion that as much as people like to protect their privacy, they also like the brands they buy from to understand them. In reality, there is very little difference between zero-party data and authenticated first-party data other than the term. Read more here.