No send in this journey is fired natively by the app itself, so there is no native-to-Braze migration roster here: everything that sends today already lives in the messaging platform or an external one, and each row’s call sits on the As-is tab.
5 rows: 2 data points and 3 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.
This journey asks for no new events or feeds: entry, exits and the save's figures all run on data that exists or that Analytics computes and pipes themselves. The two rows here are stated so the picture is complete, not because they carry engineering hours.
| The data point | What exists today | The work | What it must carry | Phase · status · depends on |
|---|---|---|---|---|
D7The transaction events that end the episodebid_add · purchase events, real timeNothing: live and verified. Named so the exit contract is stated once. | LIVE IN BRAZE Live in the sender, verified. | No work | Any bid or purchase, on any product, ends the save episode the moment it happens; the growth journeys own what comes next. This is the journey's only real-time dependency and it already runs. Used where: The instant saved exit | PHASE 1 ships now Live Nothing. |
D6Lifecycle stage, and the ownership flagACTIVE_USER_LABEL · journey_state, campaign-writtenNothing to build for entry; the stand-down wiring above makes the flag readable by broadcast segments. | CAMPAIGN-OWNED The stage label is live in the sender; the ownership flag is written by the canvas. | Braze configuration | The lifecycle stage gates entry and the day-60 hand-off to win-back; the ownership flag enforces one lapse owner per customer. The flag is campaign-written, so batch sends cannot exclude on it until the stand-down segment is wired. Used where: Entry, the arbitration against win-back, and the broadcast stand-down | PHASE 1 ships now Wiring at build The stand-down segment above. |
Named here so the full picture is one table. The contract is the row: what each trait computes, what the Braze CDI holds today, and what remains to build.
| The computed trait | What exists today | The work | What it must carry | Phase · status · depends on |
|---|---|---|---|---|
D1The entry cohort: the slip boundarypersonal_median_inter_txn_gap, nightly · interim: the daily state changeBuild the cadence trait once, shared with Journey 6: it times that journey's nudge at about 1.0x and opens this journey's slip window at about 1.5x. | DOES NOT EXIST YET The state-change entry attributes are live in the Braze CDI (verified 31 Aug): churn_risk_band, previous_churn_risk_band, churn_risk_band_shift_date, daily refresh. The cadence trait is the remaining build. | One computed trait, two journeys | Entry fires when a customer passes about 1.5x their own median purchase gap. Until the trait ships, the daily active-status state change is the buildable interim, one day of latency, already in the sender. The churn score refines entry later; it is not a launch gate. Used where: Entry, the save message | PHASE 1 ships now With Analytics The shared-trait build, commissioned once with Journey 6. |
D3The usual route and the from-priceusual_route · from_price, nightly computedAdd both attributes to the daily sync payload; Analytics compute and pipe them from their side. | LIVE IN BRAZE Verified live in the Braze CDI, 31 Aug: usual_route and usual_route_bidding_from_price reach Braze (about 39 percent coverage, fluctuating weekly). | Sync payload extension, Analytics-owned | The line that makes the save concrete: their most-travelled route over twelve months (ties to most recent) and a from-price computed nightly from what actually sold on the route, never a live lookup and never an up-to claim. A missing figure falls to the designed fallback. Used where: The save message and the second knock | PHASE 1 ships now Delivered; coverage fluctuates with the auction calendar The CDI question above. |
D4The savings figure, for power userstotal_saved, in the Braze CDIDelivered: the figure is in the Braze CDI for every user; the power-only cut and the low-value guardrail apply at selection. Phase 2, so it is not missed: the proper full-history rebuild that makes the figure genuinely lifetime, one build shared with the post-trip journey's savings traits. | LIVE IN BRAZE total_saved landed in the Braze CDI on 27 Aug. | Sync payload extension, Analytics-owned | The recognition line: power users open on what they have saved with us. The figure counts upgrade savings since January 2026, not lifetime; below the guardrail the designed no-figure fallback renders instead. Used where: The save message, the recognition register | PHASE 1 ships now Delivered; floor and cap to confirm The CDI question above. |
Not listed because there is nothing to build: the transaction events that end the episode (live, verified); the daily active-status label the interim entry rides (already in the sender); and the ownership flag the campaign writes and reads itself.
Four 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.
None of the three is a new event or feed: one is a verification question, two are configuration and wiring on systems that already run.
| 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 writes the save episode, hands it to win-back at day 60, and stands the seasonal weekly down: a gate on the 7 September go-live. |
| The one open question: new attributes into the Snowflake-to-Braze pipe | Ivi answers the CDI question; if Engineering is needed it is one small pipeline change, and it becomes this journey's only engineering ask. | BACKEND ENG | PHASE 1 ships now ▸ The problem today, and why it sits hereThe problem today Analytics can compute the from-price, the lifetime saving and the cadence trait, and pipe them from their side. What nobody has confirmed is whether ADDING new attributes to the pipe needs anything from Engineering, for example registering them in a CDI mapping, and who sizes them against the platform's attribute rate limits before cutover.Why it sits in this journey Every personalised figure in the save rides this pipe. If the answer is no, Engineering's involvement in this journey is zero. |
| Payload extensions: the churn score and journey_state, cost-sized against the quota | Cost-size both extensions against the data-point quota before they ship; they queue behind the launch set. | BACKEND ENG | PHASE 2 gated ▸ The problem today, and why it sits hereThe problem today The daily sync carries a bounded data-point budget. The churn-score and journey-state payload extensions refine the entry and the arbitration but are not launch gates.Why it sits in this journey Engineering's 29 July quota concern stands and is scoped: it binds the refinements, never the launch. |
One front-end instrumentation gap. It does not block launch; it blocks reading the one in-app surface the journey borrows.
| The defect | The fix we are asking for |
|---|---|
| The in-app banner's impressions and clicks do not register | Fix the in-app message instrumentation so impressions and clicks register.▸ The problem today, and why it matters hereThe problem today The Braze instrumentation gap on the mid-Home slot: impressions and clicks from the in-app banner do not reach analytics, so the opt-in banner's two-ask rest rule cannot be verified from data.Why it matters here The no-marketing-channel cohort is about 830 a month; the banner is the only way this journey ever reaches them, and today its performance is unreadable. |
Source: the 29 to 31 July scoping round, the 20 August data-availability sweep, and the comms estate record. The CDI question is with Ivi; nothing here is on the sprint board because nothing needs sprint hours until it is answered.