One Signal, Many Uses: Identity Intelligence for DoorDash Integrity

In a marketplace, risks inevitably converge on two key underlying questions: Who is this, and how confident are we that this action is legitimate? Some examples of what we mean by this: A support agent evaluating a refund request needs to know these answers. A promo engine deciding whether to extend an offer can’t go ahead without this information. A bot-mitigation system screening a login attempt for automated traffic is hamstrung without this data. The specifics differ — the channel, the signal, the threshold — but the core questions don’t change. 

While these questions aren’t new, AI increasingly has introduced new pressure from both sides of the equation; the same advances that make it easier to generate convincing fake behavior at scale also make it possible to identify the actors with richer signals than ever before.

Yet identity has never been treated as its own horizontal capability. Instead, most systems have been built product-first — a risk engine for orders, a model for promo targeting, or a rule for account-takeover detection. Each one implicitly answers a version of the who-is-this question for its own purposes, but none of them share that answer. This leaves a set of partial views of the same person, each accurate for its own purpose but walled off inside in its own system.

Identity intelligence starts from a different premise: If the question is shared, the signal that answers it should be, too.  That's a platform problem — solved once, centrally — that’s distinct from how any given system chooses to act on the answer, which looks different depending on where it's applied. Treated as a first-class, horizontal capability — not a byproduct of any one product — identity becomes a common thread running through nearly every integrity use case. That's our central thesis here; identity is one of the highest-leverage but least appreciated capabilities in integrity precisely because no one builds it as its own thing.

Identity comes into its own

If that who-is-this question is so universal, why hasn't identity been treated as core infrastructure from the start?

In the past, every integrity surface — order risk, account risk, or promo risk — has solved its own problem first and in its own way, with its own device signals, linkage logic, and working definition of "the same person." That's how specialized problems tend to be solved, with a rule here and a model there, each purpose-built and quick to ship. A shared identity layer is a different kind of investment: It doesn't belong to any single surface, so no one surface is naturally positioned to build it, even though every one of them would benefit.

The result to date has been an identity signal that isn’t reusable off the shelf. Every new team that wanted that answer had to onboard it from scratch with a bespoke, one-off integration instead of plugging into a standard interface. For years, identity signals have existed everywhere but were owned nowhere; each team paid to re-derive a partial answer while no one captured the compounding value of answering the question once and sharing it.

Building an identity intelligence platform

At DoorDash, we decided to close that gap by designing new infrastructure. Instead of each system building its own linkage logic on top of its own signals, we wanted identity to become something built once and consumed everywhere.

In practice, that meant building three layers on top of one shared signal store:

• First, identity resolution: An entity-resolution graph with 1B+ edges, built mostly with unsupervised clustering and link-prediction techniques, that investigates which accounts might be the same person. 
• Second, relationship intelligence: A related but different graph question: Which people, accounts, devices, and assets are associated with each other? This layer acknowledges that two accounts can be meaningfully connected without being the same human. 
• Third, decisioning models: Typically supervised learning models, such as gradient-boosted classifiers, trained on known outcomes for a specific use case. This layer consumes the first two layers to return a real-time answer to the question: Is this particular event, for this particular decision, legitimate?

We'll use one of the hardest cases for identity resolution as an example — a customer who just signed up, places a first order, and files a support request. There's no history to compare against, nor is there likely to be a strong match to an existing account; identity resolution alone doesn't have much to go on. What the account does have, from the moment it exists, is a handful of identity attributes, such as a device, a phone number, an address, or a card on file. The platform already tracks which accounts each of those attributes has appeared on, so an overlap on any of them is visible immediately, without waiting for a single order or support request. A shared address, for example, is a start, but a bare shared-or-not flag is too coarse to act on; it doesn't say whether that address sits under two accounts or 200, whether they all showed up on the same day or over years, or whether that pattern is even unusual. That's relationship intelligence's job: Not resolving who someone is, but characterizing how connected they are. It combs through more than 100 derived signals computed per account, each one capturing how many other accounts share a given attribute, how recently, and how anomalous that looks next to an ordinary customer.

But even all of this isn't a decision. A simple fact about the graph — such as, this address has 40 accounts attached to it, most created in the last week — is not a verdict on this particular support request. Turning one into the other is the decisioning model's job. It is trained on outcomes to know how much that pattern should matter for this specific kind of request; its conclusion is made available in real time so that it's ready the moment a request comes in.

That's why the platform needs all three layers, not just the first. Identity resolution answers whether two accounts are the same person, while relationship intelligence gives a useful answer even when resolution comes up empty; neither is a decision until a model built for that specific use case turns it into one.

The platform separates signal computation from scoring (Figure 2). Features are aggregated asynchronously and ready within minutes of whatever changed. A checkpoint retrieves what it needs in 10 to 15 milliseconds rather than waiting on any of the work that produced it. Scoring then sits wherever the surface's latency budget wants it; it’s called inline when there is room, or can be triggered as soon as the features land so that the score is stored and read at decision time.

One foundation, many use cases

Downstream systems — for instance, a support flow, a promo engine, or a checkout gate — don't all need the same layer. Some systems can get an answer straight from the identity and relationship graph; others need it distilled further through the appropriate decisioning model into a real-time score built for that specific decision. These never need to know what the graph underneath looks like.

Consumer identity clustering is the clearest example of that platform in action. Such accounts look like separate people but are actually the same person. This specifically is identity resolution, determining whether two accounts collapse into one human, not just whether they're somehow connected. Under the hood, the identity cluster weighs the reliability of each signal connecting two accounts and how unlikely it would be for two different people to share it by coincidence. The more improbable a shared signal is, the more weight it carries on its own; more common or easier-to-share signals only carry weight in combination, when several of them add up. Because it runs continuously against DoorDash's identity graph rather than as a periodic batch job, it can be checked the moment a login, checkout, or refund request comes in.

Once that cluster exists, the same underlying identity and relationship signal — reused rather than rebuilt — shows up across the rest of integrity's surface area. In support workflows, that same clustering helps discern a genuine service failure from one person filing similar-looking claims across several accounts. In promotions, it decides eligibility by discerning a new customer from a person who already claimed an offer under a different identity. In account security, it flags a login with the right password that doesn't behave like the account owner. Scaled up from one person to many, a related but distinct layer — relationship intelligence, not identity resolution — is what surfaces coordinated abuse; this may take the form of a ring of accounts that look independent individually but can be seen to move as a single operation after their connections are mapped. In bot mitigation, it distinguishes a human working through friction from a script working at scale. 

None of these needed a new kind of signal, just the same one, routed to a different decision each time. That's what a shared platform makes possible: One substrate, many decisions. And once that platform exists, it doesn’t have to stop at direct identifiers.

Identity is more than an identifier

Direct identifiers were the obvious place to start, of course — a device ID, a phone number, an email, or a card on file. These are powerful signals that are hard to fake and often enough on their own to confidently answer the who-is-this question. But a sufficiently determined bad actor can still work around them with a new device, a new number, a new email, or a new card — making the direct trail go cold.

Behavior helps close the gap. How someone moves through a marketplace — the rhythm of their actions, their browsing patterns, checkout actions, or interactions with support — also provides a form of identity, one that tends to persist even when the identifiers around it are swapped out. It doesn't replace direct signals; it's a complementary layer for the cases where direct signals alone fall short.

This reframe matters because it changes the definition of "the same person." Two accounts with completely different devices and payment methods can still be recognized as the same person if behavior enters the picture. Two accounts that look unrelated by every direct identifier can still warrant a closer look, if their behavior lines up too closely to be a coincidence.

Identity’s AI future

The clearest way to measure a platform like this isn't in any single win; it's in the customers who never notice anything happened, yet who benefit from a more streamlined experience. Identity intelligence removes friction that honest customers have been forced to absorb; a more confident system that moves more quickly to a conclusion about who it’s dealing with relieves them of that burden. 

This same idea can be applied to richer inputs. Today, our behavioral signals still rely heavily on numerical summaries. But LLM and generative AI models can enable us in future to absorb insights from unstructured text, images, and free-form conversations at much lower development costs than before. 

Unlike bootstrapping text and image sub-components from scratch in traditional neural network models, we can now either use readily available genAI endpoints or leverage the output layer of pretrained large models to generate text/image-related features such as issue description sentiment analysis or duplicate image checks. Additionally, we can explore transformer-based model architectures to curate user identity embeddings that could potentially revolutionize how we define clusters in the identity graph. In the architecture above, these show up as two separate paths (Figure 1): an LLM extracting features directly from free-form appeals, and text embeddings becoming a new kind of edge in the identity graph. 

That said, the same AI advances that make it easier to build a trustworthy identity signal also make it easier to fake one with more convincing synthetic behavior, automated variation across accounts, or faster adversarial response to our new policies. Treating identity as a platform rather than a patchwork of one-off checks makes it possible to keep pace by offering a single place to fold in a new kind of signal instead of relying on a dozen separate systems each waiting their turn to catch up.

Ultimately, we aim to benefit from fewer bespoke, one-off identity answers by developing one consistent identity and relationship substrate to serve every decision point that needs it.