Ryan Yu.

DoorDash – Promotion Suppression

Never contradicting yourself

What this proves: at agent scale, one contradiction breaks the relationship. Consistency has to be enforced by the architecture, not promised by the copy.

The trust problem

Analytics identified roughly 1.4M negative-lifetime-value customers whose promotional spend was not changing their behavior. Suppressing them is easy to describe; the hard part is that the customer must never notice.

Offers reach people through five independent systems - email, push and in-app, the promotions service, growth surfaces, the habituation service.

If any leaks an offer the customer can't redeem, the company has promised something and refused it at checkout - and a broken promise costs more than the promotion would have.

This is not a filter - it is a distributed consistency problem.

What the customer sees - a hypothetical mock

The same storefront, rendered two ways - a mock, but faithful to the experience the system controls.

Promotions as usual

Home
Search DoorDash

Recommended for you

Temakase

4.4 ★ (50+) · 0.5 mi · 27 min

$3.99 delivery fee

Buy 1, get 1 free$5 off on $30+

La Dong

4.8 ★ (1k+) · 1.4 mi · 22 min

$0 delivery fee

$9 off on $70+

Verde Taqueria

4.6 ★ (300+) · 0.4 mi · 18 min

$1.99 delivery fee

Free delivery on $20+
homegroceryshoppingbrowseme

With suppression active

Home
Search DoorDash

Recommended for you

Temakase

4.4 ★ (50+) · 0.5 mi · 27 min

$3.99 delivery fee

La Dong

4.8 ★ (1k+) · 1.4 mi · 22 min

$2.99 delivery fee

Verde Taqueria

4.6 ★ (300+) · 0.4 mi · 18 min

$1.99 delivery fee

homegroceryshoppingbrowseme

The same store, simply silent about offers this customer cannot redeem. Fees revert to their real prices.

Operating principles

Safety first

At the margin, err toward not suppressing - a wrong suppression costs more than the savings.

Honor your word

If we told a customer they were eligible, they are eligible. Regardless of what the model says.

The prototype – the decision engine

Four preset scenarios. Tap one - the engine walks the customer through the gates and lights the path.

Campaign management systemCarries the Do Not Suppress flag.Suppression list from AnalyticsRefreshed on a cadence; ingestion failure has a defined fallback.Campaign flaggedDo Not Suppress?Customer on thesuppression list?Already told abouta live offer?Falls throughALLOWexemptDEFERwindow closesSUPPRESSALLOWfail-openyesnonoyesyesnoENFORCEMENT SURFACESEmailPush and in-appPromotions serviceGrowth surfacesHabituation serviceAll five must agree, or the customer sees a contradiction.

Two evaluation moments

Audience build time. Static campaigns filter when the audience is assembled.

Trigger time. Dynamic and evergreen campaigns re-check at the moment of send: a customer suppressed on Tuesday can still be sitting in an audience assembled on Monday.

The metrics, written down first

MetricHypothesisExpected
Variable profitReducing spend on low-return customers increases savingsUp
iROASFewer low-return redemptions raises average return on spendUp
Customer savingsHigher effective minimums reduce redemptionsDown
Order volumeHigher effective minimums reduce redemptions and ordersDown
Support contactsChanged promotion logic may generate questionsNeutral to slight increase

The metrics were written down before anything was built, on a team goaled on order volume. When volume fell, it fell as predicted rather than as a surprise.

Priority order

P0

Ingestion and exemption checking

The list has to load, and Do Not Suppress has to hold.

P1

Live-campaign safeguards and marketing suppression

The gates that keep promises already made.

P2

Single source of truth and audit logging

One place that answers, and a record of every answer.

P3

Scale and latency

Fast enough to check at send time without slowing the send.

Why this matters for an agent

An agent acts across many surfaces on someone's behalf; the moment one says something the others do not honor, the person stops trusting all of it. If we said you were eligible, you were. That consistency is the trust product, not an infrastructure detail.

The promise also runs the other way, to the merchants whose systems an agent enters. Consistency used to be internal - the system says what it does. For agents it is also external: the agent does what it says, to systems built for humans, the same at the 9am drop as at 2am. Consumers extend money. Merchants extend access. The failure mode is already here: agents that hammered a booking endpoint got their users banned from it, and agent-driven accounts have been locked at Uber and Amazon.

Architecture generalized; internal system names and identifying details removed.

The tradeoff accepted

Fail-open leaks spend by design: some negative-LTV customers keep getting promotions. We sized that leak and accepted it as the cost of never breaking a promise.

Back to all three