The RampID Your DSP Receives Expires on a Schedule Your Campaign Flight Does Not Match

When a media buyer activates a CRM-derived audience through a LiveRamp-style onboarding workflow, the output is a set of pseudonymous identity tokens that travel into a DSP and power both targeting and measurement. The assumption most buyers carry into that process is that the token connecting a person at the moment of audience build is the same token connecting that person when an impression is served two weeks later, and again when a conversion is logged three weeks after that. That assumption is worth examining carefully.

Identity tokens are not permanent. They are designed to rotate. The rotation serves legitimate purposes: it limits the ability of any third party to build a persistent surveillance profile on an individual, and it gives the identity provider a mechanism to re-resolve a person against fresher signal as their device environment changes. Those are reasonable engineering choices. But they create a timing problem for campaigns that span more than a few weeks, and the problem is largely invisible to the buyer during the flight.

What token expiration actually means for a running campaign

Imagine a hypothetical scenario. You onboard a CRM file in week one. The onboarding vendor resolves your records and returns a set of tokens to your DSP. Those tokens are valid at the moment of transfer. Your DSP begins bidding against them. By week four, some share of those tokens have cycled through a refresh, and the DSP's stored version no longer matches the current valid token for that individual. The DSP either stops serving to that person entirely, or it may attempt a re-resolution that produces a token pointing to a slightly different identity state than your original file described.

Neither outcome produces an error message. Delivery continues. Reporting shows impressions served and frequency accumulating. What changes silently is which specific people are receiving those impressions, and whether the measurement layer can still connect those impressions back to the original CRM record when you go to evaluate outcomes.

Where this compounds in measurement

The token expiration problem is not limited to the targeting side of a campaign. It extends into post-campaign measurement, and that is where the practical harm is often largest.

If you run a reach and frequency report at the end of a twelve-week flight, the identity layer that powers that report is resolving impressions against the current state of the graph, not the state that existed when the impressions were served. Records that resolved cleanly in week one may resolve to a different token cluster in week twelve. Some impressions will be orphaned entirely, attributed to a token the graph can no longer connect to a person or a CRM record.

This means your reach numbers can be understated relative to actual delivery, your frequency numbers can be overstated for the records that do resolve, and your conversion attribution can lose credit for outcomes that were genuinely influenced by your campaign but can no longer be linked through a chain of matching tokens.

The refresh cycle is not a published specification

One practical difficulty for buyers is that token refresh schedules are not standardized across identity providers, and they are rarely disclosed in a form that maps directly to campaign planning calendars. Different identity providers operate on different rotation logic. Some tie refresh to specific triggering events, such as a change in the device signals associated with a person. Others operate on time-based schedules. The details are treated as proprietary infrastructure rather than buyer-facing specifications.

This is not a reason to avoid identity-resolved activation. It is a reason to ask specific questions of your onboarding vendor and your DSP before a campaign goes live, particularly for flights longer than four weeks.

Questions worth asking before a long-flight campaign

A few practical lines of inquiry can help you understand your exposure before it affects a live buy.

First, ask your onboarding vendor what the expected token validity window is for the output file you receive, and whether that window is calendar-based or event-triggered. Even a rough answer tells you whether mid-flight re-onboarding is worth planning for.

Second, ask your DSP how it handles a token that fails validation mid-campaign. Does it stop serving? Does it attempt a re-resolution from its own graph? If re-resolution happens, is it using the same identity source your original onboarding relied on, or a different one? A re-resolution from a different graph can shift who you are reaching in ways that are not visible in standard delivery reports.

Third, ask your measurement partner whether the attribution report they deliver at campaign end is resolving impressions against the current graph state or against a snapshotted graph state captured at the time of delivery. Snapshotted resolution is more accurate for longer flights but less commonly offered as a default.

Mid-flight re-onboarding as a practical option

For campaigns that run more than six weeks, some buyers and their onboarding vendors work out a schedule for refreshing the token file mid-flight. This means re-submitting the CRM file partway through the campaign and pushing a refreshed token set to the DSP. The practical benefit is that the tokens active in the DSP remain closer to the current valid state of the identity graph, reducing the drift that accumulates over time.

Mid-flight re-onboarding introduces its own considerations. The refreshed token set may not be identical to the original, because the graph itself will have changed. Some records may resolve differently, and some records that resolved in the first pass may not resolve in the second. A suggested approach is to treat the re-onboarded file as an additive update rather than a wholesale replacement, and to flag the transition date in your delivery reporting so you can distinguish pre-refresh and post-refresh performance if the data warrants it.

The practical takeaway

Token-based identity activation is a durable and useful approach to CRM-connected media buying. The refresh cycle built into those tokens is a feature of how responsible identity systems manage privacy and data freshness, not a defect. But a campaign calendar and a token validity window are two separate schedules, and buyers benefit from knowing whether those schedules are likely to diverge during a flight. The cost of that divergence is not always visible in standard reporting, which makes it worth surfacing through direct conversation with vendors before the campaign starts rather than through a reconciliation exercise after it ends.