All 3 sends the app fires itself, out of the app, each with its call: 0 move to Braze, 3 stay native, the rest retire, need a decision or belong to another journey. These calls are this pack’s proposals, to be agreed with Engineering.
| The send | When in the journey | The call | Who does the work |
|---|---|---|---|
| Auction ended, winner (native push) Native Push | STAYS NATIVE | BACKEND ENG▸ What fires it, and whyWhat fires it The winner outcome at the close, and instant wins mid-auction once the upgrade charge succeeds.Why, in one line Reworked in place, not moved: the same push, enriched to carry the realised saving and a first-win copy branch, celebrate-and-reassure only, no marketing call to action.What decides or enables it The Android deep-link defect fixed so the tap lands on the won upgrade; the first-versus-repeat split needs the win-type attribute. | |
| Auction opened, milestone winner (native push) Native Push | STAYS NATIVE | BACKEND ENG▸ What fires it, and whyWhat fires it The winner outcome at auction open, for auto-win and milestone winners.Why, in one line Reworked in place.What decides or enables it The same Android deep-link fix; the iPhone type-name fix is a one-line correction already on the defect list. | |
| The win reveal (in-app surface) In-App | STAYS NATIVE | No work▸ What fires it, and whyWhat fires it Live. The app's win reveal shows the won upgrade. The savings modal this record first listed is not in the current code (Engineering's read, confirmed in her answer to Dirk of 29 Sep). The designed celebration screen was never rolled out.Why, in one line The interim anchor for the win celebration: the modal exists and works, so Phase 1 celebrates on it with copy and sequencing changes only.What decides or enables it Honesty in the pack: what the customer feels at the win in Phase 1 is better copy on an existing surface, not a new one. |
One rule across the moved sends: a trigger that fires in the final minutes before a close is sent by the app, not Braze, so a delayed message can never land after the auction has closed. The release work sits on the switch-off row below.
14 rows: 9 data points and 5 computed traits (Analytics builds, no engineering hours). The D badge is the walkthrough pin number. Delivery fixes and app defects follow in their own sections.
The events and payloads the journey fires on. Each row is the contract; the board carries the sized asks.
| The data point | What exists today | The work | What it must carry | Phase · status · depends on |
|---|---|---|---|---|
D1The win eventauction_won, at close and fulfilmentNothing new: the entry trigger already reaches Braze, once per win, all four entry views. | LIVE IN BRAZE Live and console-confirmed. | Existing event | The whole journey enters on it. Used where: Entry, every view | PHASE 1 ships now Nothing to build Nothing. |
D2The instant-win emissioninstant_win to auction_wonClose the event audit: does an instant win emit a distinct enterable event, and does it partition buy-now from bid wins? | VERIFY FIRST The push half is resolved; the Braze-event half is not. | Event audit | The instant winners' entry to the practice-bid arc and the shared dedupe partition hang on the answer; Buy Now buyers enter the arc at launch without it (29 Sep 2026). Used where: Entry partition | PHASE 1 ships now Open, with the app team Nothing: an audit, not a build. |
D4The realised saving in the push payloadsaved_amount, per winCarry the realised saving (and coach data) in the win-push payload. | DOES NOT EXIST YET Not in the payload. | Payload extension | The enriched win push's headline line; Phase 1 ships the copy without it where absent. Used where: The win push | PHASE 2 gated With Backend Engineering The copy release lands first either way. |
D7The episode flagjourney_state, canvas-writtenThe canvas writes it at entry and clears it at exit; every recurring batch audience filters on it. | BUILDABLE TODAY The shared convention exists; this journey's wiring lands with the build. | Braze configuration | One owner per customer, made real in audiences; the seasonal weekly is the first proof case. Used where: The batch stand-down and the day-30 hand-off | PHASE 1 ships now With the Braze developer Nothing new. |
D8The capture-ladder stateask_declined + timestampInstrument the capture events and hold the decline state per surface. | DOES NOT EXIST YET The events do not exist. | New events | The one-ask rule and its cooldowns; the shared counter across surfaces is designed here, ladder-wide with the master record. Used where: The capture ask | PHASE 2 gated With App Engineering Instrumented before the holdout starts. |
D10The consent write-backpush permission and marketing-subscription state, on acceptWrite the consent state back in real time when the one push ask is accepted: the offers subscription for everyone who says yes, and the phone permission where the phone's own prompt was shown and accepted (her ruling, 15 Oct 2026: one push opt-in covers alerts and offers, in every journey). | DOES NOT EXIST YET Not written back in real time. | Live event | Day-1 habit touches route by armed channel; a stale consent read mis-routes them. Used where: Channel routing at day 1 | PHASE 2 gated With App Engineering The capture events. |
D11The pacing timergrow_canvas_wait_elapsedThe canvas's mid-window pacing timer for the day-15 beat. | BUILDABLE TODAY Canvas configuration, not an app build. | Braze configuration | The arc's mid-window beat fires on the clock, not on a schedule guess. Used where: The canvas family | PHASE 1 ships now With the Braze developer Nothing. |
D12The measurement fixescorrelation token + the reporting opt-in feedThe priority measurement pair: the correlation token, and the opt-in state feed to reporting. | DOES NOT EXIST YET Neither exists. | Instrumentation | Until the token lands, every results claim stays attributed, not incremental, and is labelled so. Used where: Every results claim | PHASE 1 ships now The standing estate fix, already raised Nothing in this journey. |
D13The lifetime upgrade count in the win push payloadlifetime_upgrades (won or bought) in the native win push payloadEnrich the service-layer win push payload with the customer's lifetime upgrade count, won or bought, so the push can carry the milestone register at the third, fifth, tenth and twentieth upgrade ("Upgrade number twenty"), no ask, no discount. The push stays native (rule 48: reliability at the payment moment); only the payload grows. | DOES NOT EXIST YET The payload carries the class and the route; no count. Auction wins emit no client event, so the count must come from the backend sale record, not the app. | Payload enrichment | Until it lands the win push keeps today's copy; the milestone register is a phase-2 view. Journey 6 owns the day-after milestone email on the warehouse count; this is only the recognition inside the win moment. Used where: The win push, milestone register (power band and any customer reaching a rung) | PHASE 2 gated On the engineering board The backend sale count per customer at event time, won or bought; Journey 6's D13 is the same count in the nightly sync. |
Named here so the full picture is one table. All follow the standing pattern: computed nightly, synced as traits, never live lookups at send time.
| The computed trait | What exists today | The work | What it must carry | Phase · status · depends on |
|---|---|---|---|---|
D3The win typewin_type, nightlyBid, buy-now or instant win: the standing pattern, computed nightly. | BUILDABLE TODAY Derivable from the warehouse. | Computed trait | Routes the win-beat copy variants and the first-timer against practice-bid arcs. Used where: Entry partition and copy branch | PHASE 1 ships now With Analytics The nightly sync. |
D5First win against repeatprior_wins, nightlyThe win count: first-time winners get the first-win branch, repeat winners the light arc. | BUILDABLE TODAY Derivable from the warehouse. | Computed trait | The first-win copy branch and the repeat-arc routing. Used where: Copy branch and arc routing | PHASE 1 ships now With Analytics The nightly sync. |
D6The power bandrfm_segment = "Power user", nightly syncNone outstanding: the Analytics recency, frequency and value segmentation is live in Braze as rfm_segment (delivered 27 Aug 2026, verified in production 31 Aug). | LIVE IN BRAZE Live in Braze. The legacy £500 flag matched roughly a tenth of the band and is retired. | Computed trait | The power-band suppression: the one cohort where messaging is proven to destroy value. Used where: Entry eligibility | PHASE 1 ships now Done (Analytics) Nothing. |
D9The travel-completion floorscheduled arrival per trip, plus one day for the floorA trip completes at its scheduled arrival (ruled 31 Aug 2026, restated to Dirk 29 Sep, answer 24: it replaces departure plus one day everywhere; the brief's older proxy corrected 15 Oct); the floor is arrival plus one day. The real-time trip-completed event (SOL144) is phase 2 and replaces the schedule when a live feed exists. | BUILDABLE TODAY Scheduled arrival derives per trip from the booking and timetable data we hold; the live-feed arrival is a later enrichment. | Computed trait | Rebook touches wait for it; education touches are exempt by ruling. Used where: The canvas-family rebook touches | PHASE 1 ships now With Analytics The nightly sync. |
D14The lifetime saving, for the power bandlifetime_saving (total_saved in the Braze CDI today; the walk-up basis when the savings feed ships)Journey 1 row 3's celebration carries the power band's lifetime saving under the confirmation line, recognition only (Sheran, 6 Sep 2026). Phase 1 is possible on today's total_saved for power users (Journey 8's floor and its no-figure fallback apply); the walk-up basis replaces it when the savings feed lands. Board row: Braze savings feed. | PARTLY LIVE IN BRAZE total_saved exists in the sync for power users on today's calculation. | Existing trait for power users; the feed later | Row 3's power-band line; Journey 6's value proof and anniversary share the trait Used where: Row 3 | PHASE 1 ships now Ruled 6 Sep 2026 Journey 8's floor and fallback; the savings feed for the walk-up basis. |
Not listed because there is nothing to build: the win and purchase events the canvas enters on (auction_won and the purchase model) already reach Braze, and the receipt rework rides the transactional migration into Braze (Harrison builds it; engineering switches the existing API call; the barcode needs a third-party integration).
Eight changes the customer never sees: what is broken today, the fix we are asking Engineering for, and why it belongs in this journey rather than a general engineering backlog. None is a comm and none needs a decision from Marketing. Each one either loses a message this journey depends on, or decides whether something else can be built at all.
The launch-blocking pair and the release-riders: what must land before the holdout starts, and what rides the copy release.
| The delivery fix | The fix we are asking for | Who does it | Phase |
|---|---|---|---|
| The journey ownership flag (journey_state): the shared build | Build journey_state once, estate-wide: one attribute carrying the owning journey, the episode id and the entry time. Every owning canvas writes it at entry and clears it at exit; every broadcast and wave segment excludes on it; it is mirrored nightly to the warehouse and readable at render by the home surface. The Braze developer wires the canvases and the exclusion segments, Engineering mirrors it to the warehouse and exposes the render read, Analytics keeps the state history. One board row carries it for all ten journeys. | BACKEND ENG | PHASE 1 ships now ▸ The problem today, and why it sits hereThe problem today Every journey's stand-down and hand-off assumes one owner per customer, and the flag those rules read is campaign-written today: invisible to broadcast segments, the warehouse and the app, so the rule cannot be enforced. Two live journeys can reach one customer in one week with clashing messages.Why it sits in this journey Here it carries the day-30 hand-off and stands the broadcasts down during the habit window. |
| The content-card placement and its measurement fix | Ship the placement and the impression-and-click instrumentation together, and verify events land in the warehouse before the holdout starts. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today The habit window's not-armed arc has no placement to render in, and card impressions and clicks register zero in the warehouse.Why it sits in this journey Launch-blocking for the not-armed arc: without it the journey's core promise excludes the majority of instant-win first-winners. |
| The capture-ladder events | Instrument the capture events before the first send. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today The decline counter's events (ask shown, ask declined, timestamp) do not exist today.Why it sits in this journey Without them the capture read is fiction and the ladder cannot enforce its own cooldowns. |
| The refund check on the celebration | Check refund and cancellation state when the celebration card opens and when the app returns to the foreground; no live update this quarter. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today The celebration surface cannot see a refund today.Why it sits in this journey Or the app congratulates a dead win; a refund in the seconds a card is open is rare, and the refund notification follows anyway. |
| The win-push release riders | Fix both in the copy-release window. | BACKEND ENG | PHASE 1 ships now ▸ The problem today, and why it sits hereThe problem today Two defects ride the same release as the copy rework: the Android tap lands on the home screen rather than the won upgrade, and the iPhone app misspells the milestone message type so its per-type handler never runs.Why it sits in this journey The Android defect bites at the exact moment the customer wants to see what they won. |
Live defects at the journey's peak moment: two deep-link and handler defects on the win pushes, and the card surface that cannot be measured.
| The defect | The fix we are asking for |
|---|---|
| The Android win-push deep link | Fix rides the win-push copy release.▸ The problem today, and why it matters hereThe problem today The tap lands on the home screen rather than the won upgrade.Why it matters here The worst message type for that defect, at the journey's peak moment. |
| The iPhone milestone type-name | A one-line correction, already on the defect list.▸ The problem today, and why it matters hereThe problem today The app misspells the message type, so its per-type handler never runs; the banner and tap still work.Why it matters here Silent handler failure on the surprise-charge cohort's push. |
| The card surface is unreadable | The instrumentation half of the launch-blocking pair.▸ The problem today, and why it matters hereThe problem today Impression and click measurement registers zero: the shared estate gap.Why it matters here Nothing on the not-armed arc can be measured until it lands. |
Source: the code audit of 12 August 2026, the console trigger pass of 14 to 16 August 2026, and the matrix spec. Board rows are the system of record for the sized asks.