Skip to main content

What it is

Measured. The figures on the Usage intelligence page are counts and sums of what your product analytics and billing record, worked out every morning by fixed, written rules. Nothing on the page today is a score or an estimate: usage health, its parts, tiers and patterns are not calculated yet, and the page says so. The same usage rows always give the same figures. This article is the one the page’s how it is calculated link opens. It sets out each rule in turn. The shape of a customer’s use over six months is a published value with its own definition — usage pattern — and it is not calculated yet.

Which customers count

A customer sends usage when Beacon holds it as one of your customers and it has at least one usage row from your product analytics. Usage for an account in your product analytics that does not match one of your customers is not written. The morning run counts how many such accounts there were, without naming them. Each product analytics account is matched to a customer by the field you confirm when you connect PostHog: which PostHog group is your customer, and which field it shares with Stripe. For each customer that sends usage, the morning run notes:
  • its size group — such as Enterprise, Mid-market or Small business, or Unsegmented when none is held;
  • its industry, where one is held;
  • its segment — its confirmed segment once your segments are confirmed; until then, its size group and industry together, or its size group alone when no industry is held;
  • customer since — the earliest start date of its subscriptions in your billing.
The page also shows how many customers Beacon holds for you in all, so it can say how many of them send usage.

The last day the data reaches

Every figure is anchored to the last day your usage data reaches — the latest day on which any customer used the product, as your product analytics has delivered it. It is not the day of the run. If your usage data stops on 3 October, the figures are as of 3 October, whatever day it is, and the page says the data reaches 3 October.

Last full month

The last full month is the month before the one the next day falls in. If the data reaches 3 October, the last full month is September; if it reaches 31 October, it is October. For each customer, the last full month’s figures are taken exactly as your product analytics records them for that month: A customer with no usage row for that month has no figures for it — never zero. Zero would say it did not use the product; no row says nothing was delivered.

The last two weeks

Two windows, both ending on the last day the data reaches:
  • Recent — the 14 days up to and including that day.
  • Before — the 14 days before those.
Each is the sum of the customer’s daily events inside the window. A day with no usage row is a day with no use: your product analytics only delivers a day when there was some. From the two sums, your data store works out the change, as a whole percent: recent minus before, divided by before. Then: A customer is counted as halved when it had use in the two weeks before and its events fell by 50% or more. This direction is shown on the page only. It is not a published value. Beacon publishes the usage pattern instead — eight shapes over six months, because a three-way trend loses the distinctions that matter.

Last use

Last active day is the latest day with any use for the customer.

Monthly revenue

Each customer’s monthly revenue is its recurring revenue for the last full month, from your billing, in your reporting currency. A customer with none that month has none on the page.

Active days in bands

Your data store places each customer with last-month figures in one of four bands of active days: under 10, 10 to 19, 20 to 25, and 26 or more. A customer with no row for the last full month is in none.

The groups

Every customer that sends usage counts in three groups at once: For each group, the data store counts the customers in it, how many have last-month figures, how many are rising, about the same, falling and halved, how many sit in each band of active days, the fewest and the most active days, how many are in their first 12 months, and adds up their monthly revenue. Every count, direction, band and sum here is your data store’s own formula or roll-up. Beacon’s code never divides or adds them. The morning run writes each customer’s figures and which groups it is in; the store does the arithmetic, where it can be reproduced. The one figure the morning run works out itself is each group’s middle number of active days — the median of its customers’ last-month active days. With an even number of customers, it is the average of the two in the middle. The data store has no median, so it is declared, versioned and reproducible like every other rule.

How many full months are held

The run also counts how many full months of usage your data holds, up to the last full month. The check of each month against the month before needs two; until then the page says when the first check can run.

Customers that stop sending usage

When a customer no longer sends usage, or a group no longer applies, its record is marked as no longer current and taken out of every group. It is kept, never deleted, so the totals count only today’s customers while yesterday’s can still be reproduced.

When it runs, and when it does not

The run needs billing connected and working — without billing no module runs — and a product analytics tool connected and working. If either is not, the run does not write. If no usage has been delivered yet, the page reads Coming.

Not yet calculated

How the following are worked out is not yet written down, or waits for data Beacon does not read yet, so the page says Not yet calculated rather than showing a number:
  • Usage health — how each of its five parts (activation milestones, feature adoption, usage intensity, teams using it, recency) turns what Beacon reads into a score from 0 to 100 is not written down. Milestones and features also need picking from your events in Setup, teams need a team property in your usage data, and paid seats are not read.
  • The tiers, revenue in healthy usage by segment and customers on track at month 6, which come from usage health and milestones.
  • Usage patterns — how a shape of use is matched to one of the eight is not written down, and a pattern needs six months of history.
  • Each month against the month before, which needs two full months of usage.
  • Every alert.
Until those exist, no score or pattern is written anywhere, and Beacon does not invent one.

Where it comes from

How fresh it is

Once a day at 08:00 UTC, after the morning load from your billing (05:00 UTC) and from your product analytics (06:00 UTC). The page shows when it last ran and the last day the data reaches. Use during the day shows after the next morning’s load and run. Every figure carries the run it came from, the version of the rules it was worked out under, and what was read — so it can be reproduced from the same inputs.

Currency and rounding

Monthly revenue is stated in your single reporting currency. The change over two weeks is a whole percent. The middle number of active days is shown as a whole day. Events, active days and active users are whole numbers, as your product analytics records them.

What it is not

  • Not usage health. Every figure on the page today is a count of what your product analytics recorded. Usage health is Beacon’s score, and it is not calculated yet.
  • Not the usage pattern. The change over two weeks is a short reading shown on the page. The pattern is the published shape over six months.
  • Not a churn prediction. Falling use is one of the things Churn risk reads; it is not the risk itself.
  • Not about people. Beacon reads usage per customer and shows counts, never lists of the people using it. No event or person-level row leaves Beacon — see Boundaries.
  • Not a change to your tools. Beacon reads your product analytics and billing and writes nothing back.