Challenge
Retired nationwide seasonal weigh-in events and replaced them with a program that issues its own rewards, in seconds.
An evergreen body-transformation program run entirely off device measurements: a scan opens a 28-day window, a second scan closes it, and the reward is computed and issued in seconds.
Context & Goal
The predecessor was a seasonal challenge: fixed cohorts, signup lists, nationwide weigh-in and weigh-out events, and results tabulated by hand in a weekly batch. It ran twice a year, it consumed store labor at both ends, and a participant's reward arrived days after the measurement that earned it.
The goal was to make it always-on and self-running instead: every customer on their own private 28-day clock, every number taken from an in-store body scanner rather than self-reported, and the reward computed and delivered while the customer is still in the store. Built and operated by one engineer across ingestion, the engine, both enrollment surfaces, and the models.
The loop, end to end
From the scan that sets a baseline to the text message carrying the reward. No human approves anything along this path.
A free in-store body scan sets the baseline. Enrollment has to happen within 7 days of it, at a corporate store.
A webhook lands the scan and publishes. A subscriber pulls the full body-composition panel back from the vendor API. Both hops write raw to BigQuery.
Any scan inside the window returns running progress and the store credit currently on the table.
A scan on days 29 through 35 closes the challenge. A guard rejects the pair if age or height moved between the two scans.
The engine computes the reward, mints a real single-use POS code in the same request, and that code rides out on the message reporting the result.
Results
In production since February 2025.
- 1.2M+ body scans ingested and 54k+ enrollments, running roughly 2,000 to 4,800 new enrollments a month across ~37 corporate stores.
- 12.3k rewards issued automatically and $137k+ in store credit, with no manual tabulation, no approval queue, and no human in the issuance path.
- Time to reward cut from days to seconds. The coupon code arrives by SMS while the customer is still standing at the scanner.
- 40k+ lbs of verified body-composition improvement, measured by device rather than claimed by the participant.
- Retired nationwide seasonal weigh-in and weigh-out operations entirely. No cohorts, no signup lists, no roster to manage: each participant's window starts the day they enroll.
- ~96.5% of enrollments happen at the register inside a minute of associate time; the rest self-serve on the storefront.
- 30% of issued coupons come back as in-store redemptions, which is the point of paying in store credit rather than cash.
How the Program Works
The rules the engine enforces, as the customer experiences them.
- A free in-store body scan sets the baseline. Enrollment has to happen within 7 days of that scan, at a corporate store.
- The challenge runs 28 days from enrollment. Any scan inside the window returns running progress and the store credit currently on the table.
- The weigh-out window is days 29 through 35. A scan inside it closes the challenge and computes the reward.
- Reward: $5 per point of body fat percentage lost, plus $5 per pound of skeletal muscle gained, floored at $5 and capped at $25.
- A guard rejects the pair outright if age or height moved between the two scans, which is the signal that two different people used one phone number.
- Coupons are single-use in-store codes valid 31 days, with a three-day expiring notice and a one-time seven-day extension the customer requests by replying to the SMS.
- Roughly a quarter of starters come back for the second scan. The rest are closed out by an overnight sweep, so an abandoned challenge never needs a person to reconcile it.
What I built
Ingestion, the engine, both enrollment surfaces, and the models.
Event-driven scanner ingestion
For the in-store scanner fleet: a webhook lands each scan, a subscriber pulls the full body-composition panel back from the vendor API, and both hops write raw to BigQuery before anything interprets them.
A single engine that owns the program
One Cloud Run service handling eligibility, the 28-day clock, per-scan progress evaluation, the reward math, and coupon issuance, with challenge state in Cloud SQL Postgres.
Two enrollment surfaces
At the register through Associate App webviews behind a trusted proxy, plus a self-serve path on the Shopify storefront with an SMS one-time-code bridge from phone number to store account.
Automated reward issuance
The weigh-out scan computes the reward and mints a real single-use POS promotion code in the same request, and that code rides out on the message that tells the customer their result.
A full coupon lifecycle
31-day expiry, a three-day notice, a customer-initiated extension handled as an inbound SMS-reply webhook, next-day redemption reconciliation from the warehouse, and deactivation of the code in the POS on expiry.
Week-by-week nurture
Fanned out through Cloud Tasks rather than sent in a loop, one task per participant, scheduled around midday and spread across an hour.
Four self-closing scheduled jobs
Queue the nurture batch, sweep missed weigh-outs, reconcile and expire coupons, send expiring notices. Together they keep the program running without anyone tending it.
Reporting marts in dbt
At a date by store by signup associate grain, with store attribution inferred from the same-day scan, surfaced on the internal retail KPI report next to sales.
Key decisions & tradeoffs
Each of these bought something and cost something. The cost is the interesting half.
Evergreen and solo instead of seasonal cohorts.
Removing the roster removed the operational cost of the program.
TradeoffNo two participants are ever on the same schedule, so every deadline has to be computed per person off their own baseline scan.
The truth lives in the application tier, the opposite of the loyalty program on the same stack.
A reward is computed once, at a single moment, from exactly two scans, so an append-only ledger would buy nothing.
TradeoffThe warehouse is a read-only reporting mirror rather than the system of record.
Rewards are floored and capped.
The floor guarantees anyone who comes back for the second scan gets paid something, and the cap keeps one outlier result from writing an unbounded check.
TradeoffHalf of all coupons land on the floor, which is the price of that guarantee.
Device measurement instead of self-reported progress.
It removes the entire class of disputes the manual challenge generated.
TradeoffStore hardware and a vendor API sit in the critical path of the reward.
Coupons are real POS promotion codes rather than an internal balance.
Redemption is a one-tap apply at the register with no custom checkout work.
TradeoffThe platform only learns a coupon was used from the next morning's model build.
Ingest is a fan-out, not a chain.
The webhook lands the scan and publishes rather than calling the engine directly, so a slow vendor response or a bad deploy on the engine can never cost the business a measurement it can only take once.
Reporting is deliberately a day behind.
Operational state replicates to the warehouse once a night, which keeps the register off the warehouse path entirely.
TradeoffEvery number on the dashboard is as of yesterday.
Corporate stores only.
The reward is corporate store credit.
TradeoffFranchise scans flow through the same ingestion and land in the same warehouse, but cannot enroll.
Architecture in detail
The program is one loop around a single service: a scan lands on the event bus, the bus carries every later scan back to the engine, the engine decides at day 29 what the customer earned, and the coupon goes out on the same message that reports the result. Hover a node to trace its connections; click a node for details. The diagram scrolls sideways on smaller screens.