ChurnaheadSign in

Product usage events

Last updated 1 November 2026

Billing data shows a customer who is about to stop paying. Usage data shows a customer who has already stopped using the product and hasn’t got round to cancelling. Send Churnahead a stream of simple events and three more signals join the score: nobody active for 21 days, activity down by half over two weeks, and a feature used every week gone quiet.

This is optional. Everything else works without it.

Sending events

Under Settings, Product usage, make an ingest key. It starts with chk_, only its hash is stored, and making a new key replaces the old one. The key can only write events; it cannot read anything.

curl https://api.churnahead.com/api/events \
  -H "Authorization: Bearer chk_…" -H "Content-Type: application/json" \
  -d '{"customer": "cus_123", "user": "user_42", "event": "login"}'
  • Shapes: one event, a list of events, or {"events": [...]}, up to 1,000 per request.
  • Fields: customer (Stripe customer id or the customer’s email), event (any name), optional user (any id for the person), optional at (RFC 3339) to backdate an event by up to 460 days.
  • Matching: an event names its customer by billing customer id or by email. Events that match no customer are counted in the response and dropped.
  • Rate limit: 600 requests a minute per key. Past that the API answers 429 with a Retry-After header. Batch events to stay under it.

Segment and PostHog

Point a Segment webhook destination or a PostHog webhook at the same endpoint with the same key. Their payloads work unchanged. Segment track, page and screen calls count, matched by a stripe_customer_id property or the user’s email trait. PostHog events are matched by the person’s email.

What is stored

Daily counts per account and event name, with up to 200 user ids per day so the account page can show people active against seats. Event properties are dropped. Nothing about what a user did is kept beyond the event’s name and the day.

The signals

The usage rules wait for four weeks of events per account before they score anything, so a customer who hasn’t been wired up yet isn’t flagged for silence.

Signal Points Fires when
Usage stopped 30 No event for 21 days or more.
Usage drop 20 Events in the last 14 days are half or less of the 14 before, from at least 20.
Feature dropped 15 An event used in at least 3 of the 4 weeks before the last 14 days, and not once since.

They replay in the backtest and the risk timeline like the billing rules, so you can see what they would have caught. The account page shows the last active day, the last 14 days against the 14 before, people active against seats, and eight weeks of daily events.