The workflow before
PENN's teams saw declining guests in after-the-fact reports, once spend had already dropped. Hypotheses about what changed guest behavior after specific events were argued, not tested. Data science work ran without a structured cadence, so model experiments and tuning were hard to track and hard to trust.
What we built
We built decliner models that score guests on their likelihood of reducing spend, using engineered features such as the percentile of a guest's last actual loss and time-series features of visit and play patterns.
Every prediction ships with an explanation, so marketing can see why a guest was flagged and choose the right offer instead of acting on a black box.
We ran the work inside PENN's Jira sprints, with hypothesis tests on guest behavior after specific events and model tuning by cross-validation and Bayesian hyperparameter search.
Before and after
| Measure | Before | After |
|---|---|---|
| When a decliner is found | After spend has dropped | Scored ahead of the drop |
| At-risk guests identified | Rules and reports | 2x more, from the model |
| Why a guest was flagged | Not shown | Explanation on every score |
What's next
Scores are the input for an L3 workflow: an agent that drafts the retention offer for each flagged guest and sends it to a host for approval.
