Introducing Event Analytics: Funnels, Retention, Cohorts, and Alerts
Pilot LMS analytics now runs on events: everything that happens in your lab, recorded as it happens. On top of that come six new report types, cohorts, webhooks, email subscriptions, alerts, and 102 ready-made templates.
Your reports could tell you how much. Now they can tell you what happened next.
A while ago we shipped Power BI-like analytics: pick metrics, pick dimensions, get a table and a chart. Labs liked it, and then labs started asking questions it could not answer. “How many of my new customers place a second order?” “Which accounts used to order every week and stopped?” “Where do cases get stuck between going live and shipping?” Fair questions – and none of them is a metric grouped by a dimension.
So we rebuilt analytics from the ground up around one idea: record every meaningful thing that happens as an event, tie it to the customer and the billing account it concerns, and let every report be a question about those events.
How It Used to Work
The previous analytics was built on metrics and dimensions. Every night Pilot summarized your cases, invoices, payments, and tasks into reporting tables, and a report was an aggregation over those: revenue grouped by case type, finished tasks by user, receivables by aging bucket. You dropped reports onto a dashboard, and if you needed something unusual, you wrote SQL in Query Studio.
That is great for totals. It has three blind spots, though:
A total knows that 300 cases shipped. It does not know which customers shipped their first case and never sent a second.
You saw a number go down, and then you went digging through customer lists to work out whose number it was.
Nightly summaries mean yesterday’s picture. Fine for month-end, less fine for something that broke this morning.
Nothing you built is going away. Dashboards, the metric-and-dimension report builder, and SQL are all still here, and the new reports sit on the same dashboards next to the old ones.
Events: Everything That Happens, as It Happens
An event is one thing that happened: a case shipped, a customer placed an order, a payment was applied to an invoice. Pilot now records these on its own, appended once and never edited. Each event knows when it happened, which record it is about, and – whenever it can be known – which customer and which billing account it concerns.
Pilot ships with 117 built-in events. You don't set anything up; they are simply there:
Cases
created, went live, shipped, invoiced, put on hold, outsourced, became late
Financials
invoice issued, payment received, payment applied, credit issued, overdue balance above a threshold
Customers
created, put on hold, deactivated, stopped ordering, started ordering again
Conversations
started, customer wrote in, team replied, SLA missed, closed
Tasks
opened, assigned, state changed, closed, became overdue
Customer portal
what your customers do when they sign in
Orders
customer placed an order, product ordered
Shipping
shipment events
A few things about events that are worth knowing:
Events carry properties
A shipped case carries its case type, its turnaround, and whether it shipped late. A payment application carries the amount, the invoice type, and how many days it took to pay. Every one of those can be used to filter a report or break it down.
Two ways of being recorded
Most events are recorded the moment the record changes. Some can only be noticed over time – a case becoming late, a customer who has stopped ordering – so Pilot checks for those every hour.
Thresholds are yours
How many quiet days make a customer "stopped ordering"? What overdue balance is worth an event? 18 events fire on a number, and your lab can set that number for itself.
Nothing is counted twice
A customer has one billing account; an account can have many customers. A customer’s event counts for their account too, but an account’s event never fans out to each of its customers.
All of this lives in the new Events tab under Analytics. Every event has its own page: what it means, when your lab first and last saw it, how often it happens, what it carries, which of your reports use it, and the occurrences themselves.
Your Own Events
Pilot only sees what happens in Pilot. Your sales rep visited an office; a customer answered your NPS survey; your CRM marked an account as at-risk. Those matter too, so you can now define custom events and send them to us.
Give the event a name, say whether it happens to a customer or to a billing account, and list the properties it carries (text, number, or yes/no). The event's page then shows a How to send section: create a service key, put it in the request header, and send one POST per occurrence. We included ready-to-paste examples in Python, TypeScript, and the command line, already filled in with your event's name and properties.
Once a custom event arrives, it is a first-class citizen. It shows up in every report type and every cohort, right next to the built-in ones. “Did customers who got a sales visit order more in the following month?” is now a retention report.
Webhooks: Events Going Out
Custom events bring your data into Pilot. Webhooks are the other direction: Pilot tells your systems when something happens. Add an endpoint under Settings, pick exactly which events it should receive, and Pilot sends each one as it occurs – the event, the record it is about, the customer and billing account, and its properties.
Every request is signed with a secret that is shown once, when you create the endpoint, so your side can verify it really came from Pilot.
If your endpoint does not answer OK within 10 seconds, Pilot tries again after 1, 2, 4, 8, 16, 32, and 64 minutes before giving up.
Each endpoint has a delivery log: what was sent, what your server answered, and how many attempts it took.
Pause an endpoint without losing its setup. It keeps its subscription and is simply sent nothing until you turn it back on.
The New Report Types
Okay, we have events. Now the fun part. If you've ever used PostHog, Amplitude, or Mixpanel, the next section will feel familiar – these are the report types product companies use to understand their users, pointed at a dental lab instead. Each one answers a different question.
How it works: Pick one or more events and a way to count them: every occurrence, unique customers, unique billing accounts, the average per customer, first-time-ever, weekly or monthly active, or the sum / average / median of a number the event carries (an amount, a turnaround). Then filter and break it down by any property.
What it's for: Orders per month by case type, on-time shipping rate, amount collected by payment method, remakes by reason. This is also where Number, Table, and Pie chart reports live – they are the same report drawn differently.
How it works: Line up two to ten events as steps and set a conversion window (say, 14 days). Pilot counts who reached each step in order, how long each step took, and who dropped off. You choose what moves through the funnel: customers, billing accounts, or the record itself (a case, an invoice). An exclusion step removes anyone who did something in between, like cancelling.
What it's for: Case created → went live → shipped → invoiced. Invoice issued → paid. New customer → first order → second order. Click any bar to see exactly who converted and who did not.
How it works: Pick a start event and a return event. Everyone who did the start event in the same day, week, or month becomes a cohort, and Pilot shows what share of that cohort came back in each period after. You can require the return to happen "during the next N days", and count first-timers only or every recurrence.
What it's for: Do customers who order in January order again in February, March, April? Do accounts pay after being invoiced? Do customers reorder after a remake, or after a late shipment?
How it works: For one event and a date range, Pilot counts on how many separate days (or weeks, or months) each customer did it, and groups them: active once, twice, three times, and so on. You can raise the bar so a day only counts with at least N occurrences.
What it's for: Finding your power customers – the ones who send cases nearly every week – and, on the other side, the accounts that pay late again and again.
How it works: Every period, each customer lands in exactly one group: new (did it for the first time ever), returning (also did it last period), resurrecting (came back after a gap), or dormant (did it last period, not this one).
What it's for: One chart that tells you whether new and won-back customers outnumber the ones going quiet. If the dormant bars keep getting taller, you want to know now, not at year-end.
How it works: Instead of telling Pilot the steps, you let the data show them. Choose where paths start or end, and Pilot draws the most common routes from one event to the next, for customers, billing accounts, or records like cases.
What it's for: What a new customer does in their first weeks. What tends to happen right before a customer stops ordering. The real route of a case through your lab, not the one on the whiteboard.
How it works: Write a read-only query against your own data and choose how to draw the result.
What it's for: The questions that are about the state of things right now, not about events: A/R aging, late cases right now, throughput by workstation.
One Screen, No “Save and See”
Viewing a report and editing it are the same screen: settings on the left, the chart and the detailed table on the right. Change an event, a filter, or a breakdown, and the result redraws – no saving first. Everything is bucketed in your lab's time zone, so “last week” means your week.
Draw It However It Makes Sense
A trend can be drawn as a line, a cumulative line, an area, a stacked area, bars, stacked bars, 100% stacked bars, a slope graph, a pie, a donut, a proportions bar, a table, or one big number. You switch between them from a dropdown, and Pilot is honest about which ones make sense: a pie chart of averages is greyed out with the reason, because averages are not parts of a whole.
Who Is Behind the Number
This is the part we are most excited about. Every number in every report can be opened. Click a funnel bar, a retention cell, a point on a trend line, a lifecycle bar, or a step on a path, and you get the list behind it: the actual customers, billing accounts, or cases, by name, linked to their pages.
“12 customers dropped off between their first and second order” stops being a statistic and becomes twelve names your team can call this afternoon. The list exports to CSV, and – this leads us nicely into the next section – it can be saved as a cohort.
Cohorts
A cohort is a named group of customers or billing accounts: “Lapsed implant customers”, “Accounts that paid late three times this quarter”, “New this month”. Once a cohort exists, you can use it as a filter in every report type – in the group, or not in the group.
Cohorts come in two flavors:
A fixed list, saved as it is right now. Usually you make one straight from a report: open the list behind a funnel bar or a retention cell and save it. The members never change on their own.
A set of rules. Pilot works out who matches when you save it and again every hour, so the group keeps itself up to date as customers start, stop, and come back.
What a Cohort Can Be Built From
A dynamic cohort is made of criteria. Each one is a statement about what someone did, how their behavior changed, or who they are:
Completed event. Did it, ever or in the last N days, weeks, months, or years.
Did not complete event. Never did it, or not in that time.
Completed event multiple times. At least, exactly, or at most N times.
Completed a sequence of events. Did one event, then another within a set time of it.
Did not complete a sequence of events. Did the first event but the second never followed in time.
Completed an event for the first time. Their very first time was in the last N.
Completed an event regularly. At least N times per week (or day, or month) in at least X of the last Y periods.
Stopped doing an event. Did it in the period before, but not recently.
Started doing an event again. Did it recently, after a gap, having done it at some point before.
Has a property. Any customer or billing account property, your own metadata fields included.
In cohort / Not in cohort. Build one cohort out of others.
Conditions
Every criterion can be narrowed, and criteria combine:
Time windows
"In the last N" days, weeks, months, or years. For stopped and started-again, there is a second window for the period before.
Counts
At least, exactly, or at most N times.
Event property filters
Only count the event when its own properties match: shipped late, case type is Implant, amount over 500. Text properties take is / is not / contains / starts with / is any of / is empty; number properties take equals / greater than / less than / between.
Customer and account properties
The same operators against the record itself, read at its current value, your custom metadata included.
And / Or groups
Criteria sit in groups. Inside a group they combine one way and the groups combine the other, which is how you write "(ordered in the last 30 days AND is active) OR (is in the VIP cohort)".
Across customers and accounts
A customer counts as being in a cohort of billing accounts when their account is in it, and an account is in a cohort of customers when one of its customers is.
While you edit the criteria, Pilot shows how many match and the first few names, so you know the cohort means what you think it means before you save it. And if you want to freeze a dynamic cohort at a moment in time, you can duplicate it as a static one.
Subscriptions: Reports That Come to You
Okay, great, we have reports that answer real questions. However, a report is only useful if somebody looks at it, and nobody remembers to open the dashboard on Monday morning.
So now the report comes to you.
You can subscribe to any insight, any report from the report builder, or a whole dashboard. Pick who gets it (any email addresses, each sent their own copy), add an optional note, and set the schedule:
The email carries each report as a table, not as a chart, with a link back to the live version. Subscriptions can be paused without losing their settings, and if a delivery fails, the subscription tells you why.
Alerts: Only When Something Is Off
A subscription sends you the report no matter what it says. An alert watches one number and only writes to you when that number crosses a line you drew. You set a limit below, a limit above, or both, choose how often to check, and choose who to tell.
Watch the conversion rate between any two steps. “Tell me when fewer than 80% of invoiced cases are paid within the window.”
Watch a column of the result: the first row, the last row, or every row. “Tell me about any account whose overdue balance is above $5,000” – and the email names the accounts.
An alert emails at every scheduled check where the condition holds. So a weekly alert that stays quiet is good news: the number is back in range. Each alert shows its current state (OK, firing, or error), the last value it saw, and when it last fired.
Alerts are available on funnels and SQL insights for now, not on the other report types.
102 Templates to Start From
The one thing that may be going through your mind as you're reading this: “Okay, Nikita, this is neat and all, but I run a dental lab, I don't have time to learn what a retention cohort is.”
Fair. That's why every report type comes with templates: real questions labs ask, already set up. Pick one, look at your own data in it, and change whatever you like. Here is everything we included:
Phew, that was a long one. Events are the foundation here, and we will keep adding more of them. If there is something happening in your lab that you wish Pilot kept track of, tell us. There is a good chance it is one event away.