How To Pass Admiral-Collected Email Addresses To ID5 Using Prebid.Js

Overview

As third-party identifiers become less reliable across browsers and environments, publishers are increasingly looking for ways to strengthen their first-party identity strategies.

One opportunity is to connect email addresses collected through Admiral with the identity solutions publishers already use for programmatic advertising.

Admiral enables publishers to build direct relationships with their visitors through experiences such as newsletter registrations, account creation, and other email collection campaigns.

When properly normalized, hashed, and passed to an identity partner such as ID5, these email addresses can provide an additional deterministic signal that complements existing identity methods.

This guide explains how to connect Admiral-collected emails to ID5 through Prebid.js, using a lightweight client-side JavaScript implementation.

The benefit: Publishers can make more use of the first-party data they collect through Admiral without replacing their existing advertising technology or building a new identity infrastructure.

---

1. Why Connect Admiral Email Collection to Identity Partners?

Feature: First-party email collection through Admiral

Admiral enables publishers to collect email addresses directly from visitors through customizable on-site experiences.

These experiences can support newsletter acquisition, registration, audience engagement, and other visitor relationship strategies.

Function: Convert collected emails into identity signals

With a supplemental JavaScript implementation, an email collected through Admiral can be:

1. Captured when the visitor submits an Admiral email form.
2. Normalized according to the identity partner's requirements.
3. Hashed using SHA-256.
4. Stored temporarily in the browser.
5. Passed to an existing identity solution through Prebid.js.

The publisher's identity partner can then use this additional signal as part of its identity-resolution process, subject to its own policies and matching capabilities.

Benefit: Increase the utility of first-party audience data

Publishers can potentially:

• Improve addressability: Provide identity partners with an additional deterministic signal for eligible visitors.
• Support programmatic monetization: Give participating advertising partners more opportunities to recognize audiences where permitted.
• Increase the value of email acquisition: Extend the utility of collected email addresses beyond newsletters and direct communication.
• Preserve existing infrastructure: Continue using established Prebid.js and identity integrations.
• Reduce implementation complexity: Use lightweight client-side JavaScript instead of developing a custom server-side identity integration.

Actual improvements in match rates, addressability, or advertising revenue depend on the publisher's audience, consent configuration, identity partners, and demand relationships. They should be measured rather than assumed.

---

2. How the Integration Works

Feature: Client-side email hashing and identity integration

Admiral-collected emails can be transformed into the format expected by ID5 and made available to the publisher's existing Prebid.js User ID module.

Function: Connect the email capture event to Prebid

The integration follows this process:

Step 1 — Email collection

A visitor submits their email address through an Admiral experience.

Step 2 — Normalization

JavaScript normalizes the email address according to ID5's partner-data requirements.

Step 3 — SHA-256 hashing

The normalized email address is hashed in the browser using the Web Crypto API.

Step 4 — Temporary browser storage

The hash is stored in sessionStorage under a dedicated key.

Step 5 — Prebid.js integration

The publisher's existing ID5 configuration retrieves the hash and includes it in the partner-data payload.

Step 6 — ID5 request

When the ID5 User ID module initializes or refreshes, Prebid can transmit the partner data to ID5.

Benefit: Extend existing identity workflows

The publisher does not need to replace SharedID, ID5, or other identity providers already deployed through Prebid.

Instead, the hashed email becomes an additional signal within the existing identity workflow.

---

3. Implementation Requirements

Before beginning, confirm that:

• Admiral is deployed and collecting email addresses through an on-site experience.
• The publisher has an existing Prebid.js integration that includes the ID5 User ID module.
• The publisher can add supplemental JavaScript to the page.
• The publisher can modify the ID5 partner-data configuration.
• The publisher has reviewed applicable privacy, consent, and identity-partner requirements.

Important: SHA-256 hashing is a pseudonymization technique, not anonymization. Hashed email addresses may remain personal data under applicable privacy laws. Publishers should ensure that email collection, identity sharing, storage, and downstream processing are covered by appropriate notices, consent or other lawful bases, and contractual permissions.

The implementation described below is a technical example, not a substitute for those requirements.

---

4. Step One: Capture and Hash the Admiral-Collected Email

Feature: Supplemental client-side JavaScript

A JavaScript listener can detect a successful email collection event and prepare the email for identity use.

Function: Normalize and hash the email

For the tested ID5 implementation, email normalization included:

• Trimming leading and trailing whitespace.
• Converting the address to lowercase.
• Removing periods from the local portion of the email.
• Removing plus-addressing suffixes from the local portion.
• Generating a SHA-256 hash of the normalized value.

The exact normalization rules should be checked against the identity partner's current documentation before implementation.

The following example illustrates the normalization and hashing process:

function normalizeEmailForId5(email) {

const normalized = email.trim().toLowerCase();

const parts = normalized.split('@');

if (parts.length !== 2 || !parts[0] || !parts[1]) {

throw new Error('Invalid email address');

}

let local = parts[0];

local = local.split('+')[0];

local = local.replace(/\./g, '');

return `${local}@${parts[1]}`;

}

async function sha256Hex(value) {

const bytes = new TextEncoder().encode(value);

const digest = await crypto.subtle.digest(

'SHA-256',

bytes

);

return Array.from(new Uint8Array(digest))

.map(byte => byte.toString(16).padStart(2, '0'))

.join('');

}

async function storeAdmiralEmailHash(email) {

const normalized = normalizeEmailForId5(email);

const hash = await sha256Hex(normalized);

sessionStorage.setItem(

'admiral_id5_email_hash',

hash

);

return hash;

}

 

Connecting to Admiral: Call storeAdmiralEmailHash(email) from the appropriate Admiral email collection success event or an approved integration callback.

This example is the hashing and storage component, not a complete Admiral event listener. The tested proof of concept used a supplemental form-submission listener, but production implementations should use a reliable collection-success signal to avoid processing unsuccessful submissions or unrelated forms.

Benefit: Prepare email-derived identity data without exposing the raw address to ID5 through this integration

The raw email is converted into a hash before it is included in the ID5 partner-data payload.

The hash is then temporarily available to the publisher's Prebid configuration.

Using sessionStorage also limits persistence to the current browser tab's session, although the value can survive page reloads within that session.

Note: The browser still handles the raw email during collection and hashing. Hashing does not eliminate all privacy risks, and other storage or transmission mechanisms may exist independently of this integration.

---

5. Step Two: Add the Hashed Email to ID5 Partner Data

Feature: ID5 Partner Data support

ID5 supports partner data that can be supplied through the Prebid.js User ID module.

For this implementation, the relevant partner-data key is:

Key 1 — SHA-256 hashed email address

Additional partner-data keys may already be configured by the publisher.

Function: Extend the existing getId5Pd() function

A publisher might already have a function that prepares partner data for ID5.

For example:

const getId5Pd = () => {

const ua = window.navigator.userAgent;

const domain = document.location.hostname;

const url = document.location.href;

const pdKeys = {

12: encodeURIComponent(ua),

8: encodeURIComponent(url),

9: encodeURIComponent(domain)

};

const pdRaw = Object.keys(pdKeys)

.map(key => key + '=' + pdKeys[key])

.join('&');

return btoa(pdRaw);

};

 

To incorporate the Admiral-collected hash, add the following immediately after the pdKeys object is defined:

const emailHash = sessionStorage.getItem(

'admiral_id5_email_hash'

);

if (emailHash && /^[a-f0-9]{64}$/i.test(emailHash)) {

pdKeys[1] = encodeURIComponent(emailHash);

}

 

The function continues to generate its existing partner-data payload, but now includes the hashed email when an eligible value is available.

The resulting partner data can contain:

These keys reflect the tested configuration. Publishers should consult ID5's current documentation for supported partner-data fields and requirements.

Benefit: Add deterministic identity information without disrupting existing signals

The hashed email is additive.

Existing partner-data signals remain available, and the publisher can continue using its established ID5 integration.

This reduces the scope of changes required in the advertising stack.

---

6. Step Three: Confirm the Prebid.js Configuration

Feature: Existing Prebid User ID module

Publishers already using ID5 through Prebid.js can continue using their existing partner ID, storage configuration, and identity-module deployment.

Function: Include the updated partner-data function

An illustrative configuration is:

userSync: {

userIds: [

{

name: 'sharedId',

storage: {

type: 'cookie',

name: '_pubcid',

expires: 365

}

},

{

name: 'id5Id',

params: {

partner: 1532,

pd: getId5Pd()

},

storage: {

type: 'html5',

name: 'id5id',

expires: 90,

refreshInSeconds: 8 * 3600

}

}

]

}

 

The partner ID 1532 is an example from the tested publisher implementation. Each publisher must use its own ID5 partner ID and approved configuration.

Benefit: Preserve existing advertising infrastructure

Publishers can retain their current Prebid.js deployment while extending the data supplied to ID5.

This approach minimizes changes to existing advertising integrations and avoids introducing a separate identity management system solely for the email signal.

Important: Account for initialization timing

Prebid may initialize before a visitor submits an Admiral email form.

If that happens, the initial ID5 request will not contain the newly collected email hash.

In the proof of concept, the hash was stored and the page was reloaded in the same tab so that Prebid could initialize with the value available.

For production, publishers should establish a reliable mechanism to make the hash available before ID5 partner data is constructed, or trigger an appropriate identity refresh after collection.

The appropriate approach depends on the publisher's Prebid version, identity storage settings, and existing ad initialization workflow.

---

7. Step Four: Validate the Integration

Feature: Browser-based integration testing

Chrome DevTools can be used to verify that the hashed email moves from Admiral to Prebid and into the outgoing ID5 request.

Function: Verify each stage

Test A: Confirm the hash is stored

After submitting a test email through Admiral, open the browser console:

sessionStorage.getItem('admiral_id5_email_hash');

 

Expected result: a 64-character hexadecimal string.

Test B: Confirm Prebid includes the email hash

Reload the page in the same tab, then run:

(() => {

const hash = sessionStorage.getItem(

'admiral_id5_email_hash'

);

const id5 = pbjs.getConfig('userSync')?.userIds

?.find(x => x.name === 'id5Id');

const pd = id5?.params?.pd

? Object.fromEntries(

new URLSearchParams(atob(id5.params.pd))

)

: {};



console.table({

partner: id5?.params?.partner ?? null,

admiralHashStored: !!hash,

emailHashIncluded: !!pd['1'],

hashesMatch: !!hash && hash === pd['1']

});

})();

 

 

A successful result shows that the stored Admiral hash matches partner-data key 1 in the visible Prebid configuration.

Test C: Confirm the outgoing ID5 network request

1. Open Chrome DevTools → Network.
2. Enable Preserve log.
3. Filter for id5-sync.com/api/config/prebid.
4. Reload the page.
5. Find the request associated with the publisher's ID5 partner ID.
6. Open the Payload tab and locate the pd value.
7. Copy and decode the Base64-encoded partner data.

For example:

const networkPd = 'PASTE_PD_VALUE_HERE';

const decoded = Object.fromEntries(

new URLSearchParams(atob(networkPd))

);

const storedHash = sessionStorage.getItem(

'admiral_id5_email_hash'

);

console.table({

partnerDataKeys: Object.keys(decoded).join(', '),

networkEmailHashPresent: !!decoded['1'],

hashesMatch: !!storedHash &&

storedHash === decoded['1']

});

 

The expected result is:

• The outgoing request uses the publisher's correct ID5 partner ID.
• Partner-data key 1 is present.
• The value of key 1 exactly matches the hash stored by Admiral.

Testing consideration: Some websites contain multiple Prebid instances, including integrations from third-party video players or other advertising vendors. Make sure the inspected network request belongs to the publisher's intended ID5 integration.

Benefit: Validate data transmission before production rollout

These tests provide a repeatable way to verify that the publisher's identity integration is receiving and transmitting the expected email-derived signal.

A successful test confirms browser-side transmission. It does not, by itself, prove that ID5 has successfully resolved an identity or that the additional signal has improved advertising performance.

---

8. What Publishers Gain From This Integration

The technical implementation is relatively lightweight, but its potential value extends beyond the code itself.

From email acquisition to broader audience value

A publisher may initially collect an email address to grow a newsletter or encourage repeat visits.

By integrating that email-derived signal into an approved identity workflow, the publisher can potentially support another use case: improving recognition of eligible visitors in programmatic advertising.

This creates an opportunity to connect visitor relationship management with advertising identity strategy.

The key advantage is that the same first-party relationship can support multiple business objectives, provided each use is appropriately disclosed and permitted.

---

9. Production Considerations

Before deploying beyond a test page, publishers should review several areas.

Consent and privacy

Confirm that the relevant consent or other lawful basis permits the intended collection, hashing, storage, and sharing with ID5. Ensure the integration respects applicable consent-management signals and opt-outs.

Event handling

Use a reliable Admiral email collection success event or supported callback where available. Avoid capturing unrelated forms or processing an email before the collection action is completed.

Identity refresh timing

Ensure that Prebid can access the hash when preparing the ID5 request. Consider how the integration behaves when an email is collected after Prebid has already initialized.

Storage and persistence

The example uses sessionStorage, which is scoped to a browser tab session. Publishers should decide whether this persistence model meets their requirements and whether any alternative is appropriate under their privacy policies.

Multiple identity providers

The same first-party email collection strategy may be adaptable to other identity partners, but each provider can have different requirements for normalization, hashing, consent, APIs, and data formats.

Do not assume that ID5's partner-data configuration can be reused unchanged for another provider.

Performance measurement

After deployment, publishers can evaluate relevant outcomes such as identity availability, match rates, addressable impressions, and monetization performance, where those measurements are supported by their partners and reporting systems.

---

10. Frequently Asked Questions

Does this require replacing an existing ID5 integration?

No. This approach extends an existing ID5 integration through Prebid.js by adding a hashed email as partner data.

Does Admiral need to send raw email addresses to ID5?

No. In the implementation described here, the email is normalized and SHA-256 hashed in the browser before being included in the ID5 partner-data payload.

Does the integration require server-side development?

Not for the client-side approach demonstrated in this guide. The tested implementation used supplemental JavaScript, browser session storage, and the publisher's existing Prebid configuration.

Does a successful integration guarantee higher programmatic revenue?

No. The integration provides an additional identity signal. Whether that signal improves match rates, addressability, or revenue depends on the identity partner, eligible audience, demand partners, and other factors.

Can this work with other identity partners?

Potentially. Publishers using solutions such as IntentIQ or other Prebid-supported identity providers can evaluate similar integrations, but each provider's technical and privacy requirements must be reviewed independently.

How do I know the integration is working?

Confirm that the normalized email is hashed, the hash is available in browser storage, Prebid includes it in the intended partner-data field, and the outgoing identity-partner request contains the same value.

---

Conclusion: Make First-Party Relationships More Valuable

First-party email collection can serve more than one purpose.

With Admiral and an existing Prebid.js identity integration, publishers can explore using email addresses collected through visitor experiences as additional deterministic identity signals.

The approach demonstrated in this guide requires only a small amount of supplemental JavaScript and a modification to the publisher's existing ID5 partner-data function.

For publishers seeking to strengthen their identity strategy, this provides a practical starting point without replacing their existing advertising infrastructure.

Ready to explore this integration?

Contact your Admiral Customer Success representative to discuss your email collection experiences, current identity providers, and the implementation approach that best fits your advertising stack.

---

Additional resources

• ID5: Passing Partner Data to ID5
• Prebid.js Documentation
• MDN: Web Crypto API
• MDN: Window.sessionStorage