SkeneProductDevelopersUse casesMeasurePricingEventsAbout
Skene
Start free
Before you ship

Know whether you can measure it, before you ship it.

Every growth lead knows the feeling. You ship the thing, you wait three weeks, and then you find out the one event you needed to judge it was never added. There is no way to go back and collect it.

The loop

Four steps, and the useful one happens before launch.

You find out a required signal is missing while you can still add it, and Skene names which one.

01

Describe what you are shipping

In plain language: who it is for, what problem it solves, what you expect to change. Skene turns that into a plan with an outcome, the questions the data has to answer, and the signals that must exist to answer them. You review the draft before it goes to verification.
02

Verify you can measure it

Skene gathers evidence from your code and from the events actually arriving, then works out whether the plan is measurable as written. If something required is missing, it says which one.
03

Ready to launch, or not yet

A plan reaches launch ready only when everything it needs exists. If you want to ship anyway, the workspace owner can accept the limitation explicitly rather than discover it later.
04

Check it afterwards

The plan carries a success formula. After launch it runs against real data, records what it found, and keeps every prior run.
Evaluator/Activation

Activation: first order within seven days of signup

Draft reviewed. Gathering evidence from code and arriving events.

  1. ✓Plan
  2. Verify
  3. Launch ready
  4. Check
What step 02 actually returns

It names the signal, not a score.

Three evaluations, each described in a sentence and then verified against the code and the events actually arriving. None of the three reached launch ready, and the screen says why rather than rounding it up. The last one needs a checkout_abandoned signal that is not being recorded anywhere, so the metric it is built on cannot be computed at all.

Evaluator/skene-dashboard
38 signals missing
EvaluationStatus checkMetricConfirmed
Activation: first order within seven days of signupverifyingFirst-week first-order activation rate0 / 10
Flag customers that have gone quiet for thirty daysverifyingQuiet customers resuming orders within thirty days0 / 13
Recover an abandoned checkout by emailverifyingAbandoned checkout recovery rate within seven days0 / 15
Recover an abandoned checkout by emailVerify · 0 of 15 requirements confirmed
checkout_abandoned
The event was not found in code or runtime evidence.formula input
missing
timestamp
Required event field was not observed.
missing
customer_id
Required property was not observed.
missing
checkout_id
Required property was not observed.
missing
cart_value
Required property was not observed.
missing
checkout_reached_at
Required property was not observed.
missing
checkout_recovery_email_sent
The event was not found in code or runtime evidence.
missing
checkout_recovered
The event was not found in code or runtime evidence.formula input
missing
Nothing here was set by hand. The workspace records public.customers, public.orders and public.invoices, and an abandoned checkout writes no row in any of them, so the denominator cannot be built at all. The evaluation names the signal it is missing rather than returning a number that would look fine.
The part most tools skip

Two data points are two data points.

Every verdict shows the previous number and reads up to ten prior runs, and says so when that history is too short to trust.

When the Check runs, it does not just hand you a number. It reads the hypothesis you wrote, what the formula returned this time and last time, and up to the last ten runs with their own verdicts, then says what it thinks happened.

A short history is treated as weak evidence and labelled that way. If your plan has no target, it does not invent a pass or fail: it judges movement and the quality of the evidence behind it.

What you get back

A verdict you can take to a review

The number, the previous number, the change, and every operand that went into it. Not a score with nothing underneath.

Where the evidence is thin, it says the evidence is thin.

Who does what

Nobody is asked to write event names.

What reaches engineering is a named signal and the place it is missing, or nothing at all when the tracking is already there.

You describe the change in the language you would use in a planning meeting. Skene works out which signals that implies and whether they exist. Engineering gets a specific missing event or field, or nothing at all if the tracking is already there.

That is the same split as the release check, moved one step earlier: you decide what has to be answerable, Skene turns it into something checkable.

Evaluator/Verify
1 missing
What engineering is actually handedA named signal and where it is missing. No naming decisions.
checkout_abandoned
Not found in code or in arriving events
cart_value
Required by the success formula
What the Check needsRunning the success formula against real data reads from a connected warehouse: a BigQuery dataset fed from your database, read-only to Skene, with you choosing which tables are published. Without one, Skene falls back to querying your database directly. Steps 01 to 03 run on your repository and your events. Worth knowing before you plan around step 04.
Start freeThe same problem, after launch →
Skene

Product

How it worksMeasure what you shipFeaturesIntegrationsSecuritySupabasePricing

Developers

Developersvs coding agentsOpen sourceDocs

Resources

ResourcesGlossaryPlaybooksBlogReleases

Company

AboutCommunityEventsContactPrivacyTerms
© 2026 Skene Technologies. All rights reserved.
Skene