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 trivial to describe.
The hard part is that the customer must never notice. Promotional offers reach people through at least five independent systems: email, push and in-app notifications, the promotions service, growth surfaces, and the habituation service. Some evaluate audiences when a campaign is built. Some evaluate at the moment of send. Some cache. One is a third-party vendor.
If any one of them leaks an offer the customer cannot redeem, the company has told someone they can have something and then refused it at checkout. That is not an efficiency loss. That is a broken promise, and it costs more than the promotion would have.
So this is not a filter. It is a distributed consistency problem where the failure mode is a broken promise.
The prototype — the decision engine
Four preset scenarios. Tap one - the engine walks the customer through the gates and lights the path.
Two evaluation moments
Audience build time. Static campaigns filter against the suppression list when the audience is assembled.
Trigger time. Dynamic and evergreen campaigns must re-check at the moment of send, because status may have changed since the audience was built.
A customer suppressed on Tuesday can still be sitting in an audience assembled on Monday. Evergreen campaigns have to re-ask.
What keeps it honest
Single source of truth. Downstream systems query rather than cache, because stale suppression state is how a contradiction reaches a customer.
Audit log. Captures customer, campaign, decision, timestamp, and reason for every evaluation.
Fail-open. Any ingestion failure, latency miss, or system error defaults to not suppressing.
The metrics, written down first
| Metric | Hypothesis | Expected |
|---|---|---|
| Variable profit | Reducing spend on low-return customers increases savings | Up |
| iROAS | Fewer low-return redemptions raises average return on spend | Up |
| Customer savings | Higher effective minimums reduce redemptions | Down |
| Order volume | Higher effective minimums reduce redemptions and orders | Down |
| Support contacts | Changed promotion logic may generate questions | Neutral to slight increase |
These two 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
Ingestion and exemption checking
Before any execution. The list has to load, and Do Not Suppress has to hold.
Live-campaign safeguards and marketing suppression
The gates that keep promises already made.
Single source of truth and audit logging
One place that answers, and a record of every answer.
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 surface says something the others do not honor, the person stops trusting all of it. Consistency across systems that do not know about each other is not an infrastructure detail. It is the trust product.
Architecture generalized; internal system names and identifying details removed.
The tradeoff accepted
Fail-open leaks spend by design: every error, miss, and ambiguity defaults to not suppressing, and some negative-LTV customers keep getting promotions. We sized that leak and accepted it as the cost of never breaking a promise.