Using Predictions

Common queries

Confirm the event exists with posthog:read-data-schema first. It appears only after the first scoring run.

Both queries read the newest prediction date only, so a manual score and the daily run do not mix, and a model that scores every few days still returns rows. On a large population that scores in rolling batches, the newest date holds only that day’s batch.

Top people from the newest prediction date:

Score spread on the newest prediction date, one score per person:

On a rare target, healthy scores sit close together near zero, so look at the quantiles rather than equal-width buckets. Quantiles that are all the same value point to an identifier problem. See troubleshooting-and-steering.md.

Acting on the scores

• Cohort. A dynamic cohort on the output property, for example <output property> >= 0.6. It updates as scores change.
• Feature flag. Target the flag with the same person property condition to show something only to the Likely group.
• Workflow. A batch workflow with the property as its audience filter, for example an email to people at risk of going inactive (low activity score).
• Insight. Break down the target event by the output property to show that higher scores really do the target more often.

The model page has shortcuts for these on the Predictions tab. They build the same filters.

Points worth telling the user:

• For at_risk_of_inactivity, the at-risk group is a low score, because the model predicts activity.
• Pick a threshold from the segments or the score spread, not a round number. On a rare target, 0.6 can match almost nobody.
• People who were never scored have no property value. A filter like < 0.2 leaves them out, which is usually right, but check coverage on a large population.
• To measure the impact of acting on a score, hold back a random part of the targeted group. The prediction says who is likely; only a holdout shows that the action changed anything.