pixellint

Blog · UID2

UID2 inside a LiveRamp envelope still wants SHA-256. MD5 is how the token never appears.

· 10 min read

UID2 inside a LiveRamp envelope still wants SHA-256. MD5 is how the token never appears. Publishers using ATS can mint a UID2 token beside RampID only if Interoperable IDs is on, hashing is SHA-256, and Prebid storage.refreshInSeconds is 1800.

The first integration most stacks will ship is the ATS.js they already run. LiveRamp still accepts SHA-1, SHA-256, and MD5 for hashed email when it builds a RampID envelope. That array is in the ATS docs. UID2 is not RampID. Unified ID's LiveRamp tips page is three bullets: enable UID2 as an interoperable ID, implement the UID2 hashing methodology, set envelope refresh to 1800 seconds. Miss any one and the envelope can still look full. The UID2 token is what is missing.

Bidstream sharing must be tokens, never raw UID2s. Unified ID says it without a hedge: data in the bidstream can be accessed by unauthorized parties, so it is never acceptable to share raw UID2s in the bidstream. ATS putting a UID2 beside RampID does not change that. The thing that goes into Prebid and the bid request is a UID2 token. The DSP decrypts it. The publisher does not paste a raw UID2 into user.ext.

Interoperable IDs is a LiveRamp switch, not a UID2 default

LiveRamp ATS turns a consented email into an encrypted envelope that contains RampID. Depending on the integration, that envelope may also contain PAIR IDs, Facebook-scoped envelopes, and other identifiers. UID2 is one of those other identifiers only when Interoperable IDs is enabled for UID2. Unified ID: if UID2 is not enabled as an interoperable ID, UID2 tokens will not be appended to the envelope. Completing the step means talking to a LiveRamp representative. Flipping a Prebid config is not the switch.

LiveRamp has also described RideAlong as the feature that lets other identity providers embed identifiers in ATS envelopes. Unified ID's tips still use the Interoperable IDs name. Confirm UID2 is on for that configuration. An envelope that contains RampID is not proof UID2 is inside. The ATS Mobile SDK sunset on 30 September 2026 is a different product and a different post.

SHA-256 is the UID2 methodology. MD5 is a RampID habit.

To add a valid UID2 token to the ATS envelope, Unified ID says the publisher must provide plain text emails, indicate the SHA-256 hashing methodology, or supply an SHA-256 hashed version of the email directly into the LiveRamp library. You must use SHA-256, which both UID2 and LiveRamp support. Using any other hashing methodology, or missing any step, results in either no UID2 token added to the ATS envelope or an invalid token added. MD5 and SHA-1 can still feed RampID. They do not mint UID2.

UID2 hashing is not hex-only SHA-256 of the raw display string. Normalization comes first. Email: trim, lowercase, UTF-8. For gmail.com only, strip dots and strip plus-tags. Then SHA-256 the normalized string, then Base64-encode the raw hash bytes, not the hex string. The operator wants that 44-character Base64 value. Hashing JANESaoirse@gmail.com without normalizing produces a different UID2 than janesaoirse@gmail.com. Unified ID's own example: those two hashes do not match, so the publisher misses the join.

Phone is E.164 with a leading plus, then the same SHA-256 then Base64. LiveRamp ATS hashed-email arrays that mix MD5, SHA-1, and SHA-256 are a RampID match-rate tactic. For UID2, the SHA-256 slot is the one that matters, and the input to that slot still has to be the UID2-normalized email. Hashing the un-normalized address with SHA-256 is the other way the token is invalid: the algorithm looks right, the digest is for a string UID2 will never emit.

Refresh is 1800 seconds, and the bidstream gets a token

When enabling ATS inside Prebid.js, Unified ID says storage.refreshInSeconds must be 1800 (30 minutes). LiveRamp checks for a new ATS envelope containing the UID2 every 30 minutes so you do not send expired envelopes into the bidstream or pass envelopes after an opt-out. A Prebid storage TTL copied from another id module, 3600 or 86400, is how a stale envelope sits in the bid request. The RampID may still decrypt. The UID2 token may be expired or opted out.

Tokenized sharing in the bidstream is required. Publishers encrypt DII (email or phone) directly into a UID2 token, then put that token in the bidstream. Prebid.js, the JavaScript SDK, Java, Python, or POST /token/generate are the documented sender options. DSPs decrypt to a raw UID2, check opt-out, then bid. Account setup in the UID2 Portal is optional for publishers sending to all authorized DSPs. It is required if you want to limit who can decrypt. Receivers always need a Portal account and the sender's keys.

Pixels have the same rule. Unified ID: it is never acceptable to share raw UID2s in pixels. Tracking pixels and creative pixels take tokens. Raw UID2 sharing exists on a secure channel between participants, not in RTB and not in a fire-and-forget pixel query. If someone puts a raw UID2 on a bid request because ATS already hashed the email, that is the opposite of the ATS integration tips.

The ATS push that still skips UID2

An MD5 email hash. LiveRamp can still build a RampID envelope. UID2 wants SHA-256, or plaintext, or a SHA-256 hash of the normalized email.

ats.setAdditionalData({
  type: "emailHashes",
  id: ["5d41402abc4b2a76b9719d911017c592"]
});

That call can succeed. ATS.js will not throw because the array is missing SHA-256. LiveRamp's own hashed-email example is three slots: SHA-1, SHA-256, MD5. One MD5 is enough for an envelope that contains RampID. It is not the UID2 hashing methodology. Indicate SHA-256, pass plaintext and let the library hash, or pass the SHA-256 of the normalized email. Then confirm Interoperable IDs is on so the token is appended.

Do not Base64-encode the hex string. Do not SHA-256 the MD5. Do not skip gmail dot-stripping because RampID did not require it. UID2's hashing tool exists to catch those misses before they become empty tokens in Prebid.

Names that do not translate

The envelope can be non-empty and still miss UID2

LiveRamp FAQs note that a RampID envelope is about 139 bytes and may grow if a ride-along ID such as UID2 is present. Size is not a test. The test is whether a UID2 token is present where your bid adapter expects it, after SHA-256 and a 1800-second refresh.

Expired tokens and opt-outs are why the refresh exists. ATS-plus-Prebid is explicit: 1800 seconds. Do not refresh RampID on ATS's clock and UID2 on a daily timer. Normalization mismatches are silent: hashing My.Email@gmail.com without UID2's gmail rules produces a token that will not match the advertiser's list.

Using any other hashing methodology, or missing any step, results in either no UID2 token added to the ATS envelope or an invalid token added.

UID2: LiveRamp integration tips

What to do

Ask LiveRamp to enable UID2 as an interoperable ID on the ATS configuration you actually serve. Pass plaintext email, or SHA-256 of the UID2-normalized email, into the LiveRamp library. Set Prebid storage.refreshInSeconds to 1800. Put UID2 tokens in the bidstream, never raw UID2s. Put tokens in pixels too.

Normalize before hash: lowercase, trim, gmail dot and plus rules, E.164 phones, UTF-8, SHA-256, Base64 of the hash bytes. Confirm with Unified ID's hashing tool. Do not treat an ATS envelope that already contains RampID as a completed UID2 integration.

The contract for graphs versus hashes is the identity graphs page. This post is the market fact: ATS will mint RampID on MD5, and UID2 still wants SHA-256 plus a switch plus a 30-minute refresh. Pixellint is not affiliated with Unified ID or LiveRamp. Passing a linter means the artifact matches a published envelope. It does not mean a DSP decrypted a UID2 token, and it does not detect fraud.

Checklist

Sources

Contract pages

The dated argument is above. These pages are the field lists.

Read identity graphs Docs