Trial conversion as a hazard curve.
Your trial is decided on day 3 or on day 13. The conversion rate cannot tell you which.
One number at the end of fourteen days tells you nothing about when a trial user was won or lost, so the activation sequence goes out on a schedule someone copied from a blog post. The hazard curve tells you which day actually decides it.
A real 14-day trial book with two onboarding variants and 520 trials still running. Every hazard, curve, and p-value computed in your browser.
The problem
Conversion is an event with a time, and you are reporting it as a percentage.
Trial conversion gets reported the way a coin flip gets reported: one number, at the end. That number cannot distinguish a trial where users decide on day three from one where they decide the night the trial expires, and those two products need completely different onboarding. Worse, the calculation is quietly broken in whichever direction you pick. Divide by every trial started and the live number is dragged down by everyone still inside their fourteen days. Divide only by completed trials and you have thrown away every user your dashboard is actually about, which is the entire population of a variant you shipped last week.
The insight
The hazard curve tells you which day to intervene on. A percentage never can.
A conversion rate is a summary of an outcome. A hazard curve is a statement about mechanism: of the users still undecided at the start of day 3, this many decided during it. That is directly actionable in a way the summary is not, because it names a day and a population. It also changes what an onboarding experiment means. Two flows with the same fourteen-day conversion rate are not the same flow if one of them resolves on day three, because resolving early means you learn faster, you stop paying for trials that will never convert, and you have ten days left to rescue the ones that stalled. And because censoring is handled properly, you can compare two flows while trials are still in flight instead of waiting a full cycle for every cohort to complete.
Conversion modelled as time to event with a 14-day administrative horizon. Kaplan-Meier for cumulative conversion with Greenwood intervals, so in-flight trials are censored at their current day rather than counted as failures or dropped. Per-day hazard to locate the decisive day. Log-rank to compare onboarding variants on the full population including trials that have not finished.
How it works
Four steps, no data science team
Trial start timestamp, conversion timestamp if there is one, and the variant. That is it. Most teams already have this in the billing table.
Which day of the fourteen carries the conversion decision, how much of it, and how sharp the peak is. Broken out by plan, source, or company size if you want it.
Log-rank on every trial including the ones still running. A variant that shipped nine days ago is still evidence, because censoring is what the method is for.
The output is a schedule change: which day the activation nudge goes out, which day a stalled trial gets a human, which day an extension is worth offering.
Who it is for
Head of growth, or whoever owns the trial-to-paid number
PLG companies running a free trial with an email sequence attached to it. Usually the ones who have already A/B tested the subject lines and gotten nothing, because the send day was the variable that mattered.
Pricing
- –Per-day conversion hazard
- –Kaplan-Meier with intervals
- –Runs in the browser, no account
- –Warehouse or Stripe sync
- –Variant comparison on in-flight trials
- –Hazard shift alerts
- –Intervention day recommendations
- –Self-hosted or VPC
- –Segment-level hazard models
- –Webhooks into your messaging tool
- –SSO and audit log
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Amplitude, Mixpanel | Funnels and conversion reports over a chosen window. | A funnel is a step, not a clock. In-flight users are counted as drop-off or excluded depending on the window you pick, and neither choice is stated. There is no hazard view and no test. |
| Statsig, Eppo, GrowthBook | Experimentation platforms that will test trial conversion correctly. | They test a binary outcome at a fixed horizon, which means every cohort has to finish before it counts, and two flows with the same fourteen-day rate but a ten-day difference in timing look identical. |
| Customer.io, Braze, Vitally | The tools that actually send the trial emails. | They execute the schedule. They have no opinion about which day of the trial matters, so the schedule is a guess that nobody has ever tested against the timing of the decision. |
| A notebook with lifelines | The right method, and the real substitute at companies with a data team. | One chart, once, by someone with three other priorities. The value is in re-running it every week against a variant that shipped on Tuesday, which is exactly what a notebook does not do. |
The honest risk is that the decisive day turns out not to be movable. Knowing that your trial resolves on day 3 is only worth something if changing what happens on day 2 changes the outcome, and it is entirely possible that the day is set by the shape of the product rather than by anything a growth team controls. If that is true this sells one diagnosis and no subscription. The second risk is smaller but real: the buyer has to accept an estimate that uses unfinished trials, and "we included users who have not converted yet" sounds like cheating to anyone who has not seen why it is the opposite. Both risks are testable inside a two-week pilot, which is the only reason to build it this way.
Market
Attached to the PLG growth stack, alongside the experimentation and lifecycle messaging lines
Every company running a free trial has someone whose number this is, and they already pay $200 to $2,000 a month for experimentation and lifecycle tooling. The free hazard curve reaches every growth engineer with a CSV. Three thousand accounts at the Team tier is $12.6M ARR, and the Scale tier attaches to the same companies buying Statsig today.