This journey’s strategy. An auction only works when losing feels fair. Give every loser a straight account of the close, then one reason to bid again, drawn from their own loss history. The full statement and the case: the campaign brief tab.
For the CRM team and the Braze developer. The journey as it runs today and as it should run by phase, then the Phase 1 build: one row per send Braze builds, with what starts it, what stops it and what it needs. The words per version are on the Design brief; the full logic per row, and the copy of record, sit on the Decisioning matrix.
Phase 1 ships on Braze and Analytics with no app release; Phase 2 is anything that needs engineering.
| The build | Fires on | Caps, and what stops it | What it needs, and what is open |
|---|---|---|---|
| The outbid moment · email Phase 1 | The real-time outbid event, once per state change. | The live auction owns this customer, from an active bid to two hours after the close. Operational class, so it always sends and is never capped; each send counts toward the six-send ceiling. Stops: Render guard: the price block renders only when the current bid is above the customer’s maximum. Any other state gets state-only copy, and a push firing there is reported as a possible defect, never papered over. | liquid Nothing. Both source blocks exist in live Braze campaigns and are ours to edit. Both outbid variants carry an undocumented control group.
|
| The outbid moment · Braze push Braze Push Phase 1 | The real-time outbid trigger, the API-triggered event the outbid email fires from today; a rejected bid on the newer system rides the same trigger until Phase 2 splits it. The auction-open outbid (the newer system's push at the open) rides the same send as a second trigger, so one Braze push covers both. | Operational class, so it always sends and is never capped; each send counts toward the six-send ceiling. The live auction owns this customer from an active bid to two hours after the close. Stops: Critical-only where the lock-screen status is active. | native send switch-off Engineering switch the native outbid push off in the same release, outside the final minutes before a close where the app keeps its own push. Both figures are on the trigger today: the live outbid email prints current_price as the current winning bid and current_bid as the customer's maximum. |
| No push permission, email held Phase 1 | The existing transactional triggers: the outbid event, and thirty minutes to close. | Service class: outside the marketing caps, bound by the auction-only copy rule. Stops: The opt-in is only ever re-asked at a post-intent moment, a re-search tap or a route watch (on hold), never cold on a loss screen. | The lock-screen build is the only thing that widens in-auction reach. The email fallback rides sends that already exist. |
| The close, off the app · email Phase 1 | The auction closing, any reason. | Transactional, so it always sends and is exempt from quiet hours. Sheran, 4 Sep: the buy-now email is not stopped before the party-size check exists. Stops: Phase 1: no you-lost wording for closes that never ran; the buy-now email unchanged. Phase 2: the buy-now branch renders only where the offer is confirmed open and an upgrade is confirmed available for the whole party, failing closed; never to a customer whose in-app offer converted, never an expired price. | prior-loss count, loss-cause counts Phase 1: nothing new; the live loss campaign carries a control group Analytics sizes before the template swap. Phase 2: the party-size availability signal (D10), then the merge in Braze.
|
| Day one after a loss Phase 1 | Day one after a competitive loss. | Marketing, never the same day as recovery. Stops: Its own holdout from day one: control customers get nothing. No other suppression; eligibility is the audience column. | late-bid flag Braze for the build. The bid-gap should be derivable from the highest-bid stream Braze already receives plus the customer's own maximum: confirm at build before commissioning any new feed. The survey answers must land as warehouse-visible custom attributes, with the sync path named before build. Analytics reconciles the twenty-against-forty-five-a-week volume conflict. The late-bidder lead needs a first-bid-to-close-minutes attribute computed from bid timestamps; the generic timing tip ships without it, and Analytics sizes late-bidder losers and their re-bid rate before the attribute is commissioned (the ask is on the analytics board).
|
| Day three after a loss Email, Braze Push Phase 1 | The day-three gate, with a send-time re-check because the nightly trait can miss a same-day return. | One recovery per auction, family cap of three. A cross-episode dial holds it to two recovery sends per customer per rolling thirty days, then in-app on next open only. Copy forks on prior loss count, so the identical message never sends twice. Send-priority, never eligibility: mid and low value ordered first under the daily cap. Sends inside the 08:00 to 22:00 optimised window. Stops: Out: anyone who has come back to the auction flow on their own before day three (a silent exit, no send), power users, failure closes, active disruption; and once the has-contacted-support flag exists, anyone who has contacted support since the close is left alone. If a live auction is running the send waits four hours and is then dropped rather than sent late. No second knock. | computed trait The day-three gate trait, the power-user suppression trait, the journey-state and cap counter, the nightly from-price attribute extended to the lost route, and the buy-now availability flag for the CTA fork. The return-leg variant needs the route-level return-window distribution and a return-search signal; the typical-price tip needs route-level winning-price statistics. The repeat-loser variant needs a prior-competitive-loss count from the warehouse, which the copy fork in the caps already assumes. Gated on the repeat-loser analysis; the first-timer and default variants ship without it.
|
| The abandonment pushes Braze Push Phase 1 | Drop-off from the auction flow. Four variants are live: five, ten and fifteen minutes, plus a control. | Suppressed the moment the auction closes for that auction. It also needs de-stacking against the Avanti cross-sell in the row below: see the go-live gates. Stops: Journey 3 owns the never-bid slice: replace, not stack. Boundary with the search-abandon recovery (Sheran, 6 Sep 2026, rulings J3-01 and J4-01): opened an auction, this journey owns them; searched only and never opened an auction, Journey 3's row 7b owns them, never this push. | liquid, catalogue Nothing. Liquid conditionals and a station catalogue lookup, both inside Braze. The timing test has run for over two years without a decision and still carries an undocumented control group.
|
| The Avanti class cross-sell Braze Push Phase 1 | Time since the trip was added. Three variants are live: one hour, two hours, and a control. | De-stacking against the abandonment nudge is a go-live gate, not a later refinement. Stops: Suppressed the moment the auction closes, on the same rule as the abandonment nudge. | Nothing. The timing test has run for over two years without a decision and still carries an undocumented control group.
|
Build paused until written sign-off. Every build carries its exit, cap and suppression; a control group is verified real, never assumed; Liquid never renders raw; a dependency that does not exist yet is flagged, not faked.
| The treatment | Who it reaches | Why it waits |
|---|---|---|
| Bid status off the app Live Activity (Ios) | Any bidder, from the later of the bid and 7h45m before the close, to the close | Waits on an app release. |
| The outbid moment · Braze push Braze Push | Bidder who has been outbid, and bidder whose own bid was rejected | Waits on a backend release. |
| The outbid moment · Braze push Braze Push | Bidder whose own bid was rejected for being below the current bid | Waits on a backend release. |
| Knocked out Braze Push, Braze In-App Message | Bidder knocked out while the auction is still running | Waits on a backend release. |
| Minutes to close, not in the lead · native push Native Push | Bidder not currently winning, minutes from the close | Waits on a backend release. |
| Minutes to close, in the lead Native Push | Bidder currently winning, minutes from the close | Waits on a backend release. |
| The close, in the app Native Screen Or Modal, Braze In-App Message | Everyone who bid and did not get the upgrade, whatever the reason, who is in the app at the close | Waits on a backend release, then an app release. |
| The close, off the app · Braze push Braze Push | Everyone who bid and did not get the upgrade, away from the app at the close | Waits on a backend release. |
| A failure on our side Braze Push, Email | Loser whose auction did not run as intended | Waits on a backend release. |