Predicting journey outcomes from timed behaviour in C#
Part 3 of Scott Galloway's series builds a temporal predictor in C#. It tracks a journey's centroid, velocity and acceleration in real time, then forecasts whether it ends in purchase, cancellation or departure within 60 seconds. The engine learns only from actual endpoints and abstains when evidence is thin, which makes it a concrete example for teams building SQLite-backed behavioural or service-health models.
Key points
- Track each journey with a centroid whose adaptation depends on elapsed time (2-second half-life in the demo).
- Derive velocity and acceleration from timestamps; equal or out-of-order timestamps are rejected in temporal mode.
- Forecast purchase, cancel or leave within a 60-second horizon; abstain with stale_trajectory once the window has passed.
- Train only on actual endpoints; predicted outcomes never count as labels.
- Keep healthy reference data separate from incidents so outages do not become the new normal.
- Compare Brier scores against a training-only prior before trusting any forecast.
The third part of Scott Galloway's series moves from ranking products to predicting where a journey is heading. The engine estimates likely endpoints for shopping sessions and service incidents, so a team can spot where a change might help before the outcome arrives. The sample starts from an empty SQLite database and learns from synthetic episodes.
It tracks a time-weighted behavioural centroid and derives velocity and acceleration from actual timestamps, so irregular sampling keeps correct units. Forecasts use destination frequencies from comparable past contexts. Only observed endpoints train the model, and an unresolved visit adds no invented label. On a later population the reported Brier scores beat training-only priors, but these are simulator results, not production uplift.
Real-world use
- A shopping checkout flow that checks whether a shopper is likely to convert within the next minute before showing an offer.
- A service health monitor that flags latency rising toward failure while there is still time to scale out.
- A support or onboarding flow that decides when a reassurance message could change a stalled session.
Why it matters
Position alone cannot separate a recovering service from a deteriorating one, so models that ignore motion and time will mislead. This pattern gives .NET teams a testable baseline with explicit abstention before they add experiments in Part 4.