Nobody can say whether the campaign moved the number or the product changed underneath it. You re-litigate the same numbers at the next QBR, and at the one after that.
Prove what worked.
Every play you ship is a bet. Skene names the evidence it needs before launch, computes the verdict from your own database after, and keeps that answer true as the code changes.
Free to start and no card. You sign in, and connecting one source takes about five minutes.
The bet, before launch
How do we make time to value shorter?
Compiled to: signups reaching a first project inside seven days, up 3 points.
Skene checks the signals exist
3 of 3 ready- signup_completed
- project_created
- public.projects
The verdict
Goal met+6.7 points31.5% to 38.2%
Next: the accounts that stalled never reached project_created. Measure the invite step to see what holds them there.
SupabasePostHogMixpanelBigQueryResend
The weekly problem
Nothing breaks. The number just stops being true.
The numbers your team runs on come out of product code your team never sees, and when that code changes, nobody tells you.
Say a release ships on Thursday and stops recording which plan a customer upgraded to. Nothing errors, so nothing reaches you. On Monday the funnel still shows 1,097 upgrades started, and the paid conversion rate still shows a number for every tier. It just stopped counting those 1,097 into any of them.
Evidence
metricPaid conversion rate
flowUpgrade started
What the step feeds: the number it reports into, and the flow it sits in.
Journey step
Upgrade started
activation · First ValueDetected · 100%1 property missing: plan
FeedsPaid conversion rate
Flows
Pricing viewed4,182
Upgrade started1,097
Upgrade completed863
How users actually move, captured by one script tag.
The same step, seen from both sides. What changed is written down in engineering's record, and the people reading the number never open it.
Every value shown above is an example.
Every quarter
By the time you can answer, the quarter is over.
Someone asks whether last quarter's campaign worked. Answering means the product has to have recorded the right thing while it was running, and that is engineering's code, not your dashboard.
So you file a request, and it waits. The quarter closes with no answer on it, and the next one gets planned on the plays that felt like they worked.
The outcome you asked about has to become something the product records, and the result has to come back the other way. Both directions lose something, and it waits behind the work engineering does feel.
It matches the product on the day you write it and is stale two sprints later. It is a standing request that engineering be careful, and it has to cross the same boundary the ticket does.
Each of these is what is left when the answer lives in another team's queue.
The mechanism
Grading a change takes three things. They have to hold at once.
Skene holds all three together. What the answer needs is agreed before you ship, and it still means the same thing on the day you read the result.
The bet turns into a list of what has to be recorded.
You state the change you are about to ship and what would count as it working. Skene turns that into the events and fields the answer will need, before the change ships rather than after it launches.
That list is checked against the code that actually ships.
Skene reads your repository and your database schema, then names which of those events your code already records and which are missing. It reviews every pull request for removed or broken tracking, so the answer does not quietly stop being true while the product changes.
The verdict is computed from your own database.
After launch, Skene reads the numbers where they already live and grades the change against what you said would count as it working. The measurement returns a number, not your rows.
How it works
Four steps, and the bet comes back graded.
You connect one source, say what the next change has to prove, ship it, and read the number back. Steps two and four carry the same tag because they are the same job: make the change measurable before launch, then grade it after.
Every plan, number and screen in this section is an example.
See the evidence
Connect one source and see what you actually collect.
Sign in, create a workspace, and connect the GitHub App on a repository or your Supabase project. Skene reads the code and the schema and returns what your product collects today, and which steps in the journey have nothing behind them.
- Two sources today: a GitHub repository, or a Supabase project.
- The GitHub App reads your code, and everything it proposes arrives as a pull request you review. It never pushes to your default branch.
- The Supabase grant starts read-only: it reads the schema, not the rows. Upgrade it to read-write and Skene can also count what is in each table.
Step one is the free audit: one audit per workspace, once, with no card. Pro adds continuous monitoring and recommendations.
Discovery/skene-dashboard
1 signal missing, 1 table not counted
| Signal or table | Kind | Where | Status |
|---|---|---|---|
| signup_completed | analytics | signup.ts:44 | verified |
| workspace_opened | analytics | page.tsx:61 | verified |
| invite_accepted | analytics | not found | |
| public.subscriptions | database | your database | not counted |
Grade what you shipped
Say what the next change has to prove.
You write the bet in a sentence. Skene turns it into the signals the answer needs, checks each one against your code and your arriving events, and marks the plan launch ready once every required signal is confirmed, or once you accept a limitation on the record.
- Each required signal comes back ready or missing, with a count of what is confirmed.
- The plan names the metric and the goal before launch, not after the result is in.
Skene / ActivationVerifying
Activation: first project in seven days
Draft reviewed. Gathering evidence from code and events.
- Plan
- Verify
- Launch ready
Protect the evidence
Ship it. The check holds.
Skene requests changes on a pull request that removes or breaks a signal your collection plan needs, and names the event, the file and the line. It never pushes to your default branch.
- A release fails when a table the plan needs is missing from your database.
- A table that is there with no sample is reported and blocks nothing.
SkeneTechnologies/skene-dashboard #312changes requested
Sskene-aibot
Skene Analytics Drift Review
This pull request has 1 tracking issue (1 fires early). See inline comments.
What breaks
Warn:
upgrade_started fires earlier at billing.ts:31src/billing/billing.ts1 comment
Grade what you shipped
Read the verdict, then the one after that.
After launch Skene computes the number the plan named, from your own database, and returns current, previous and change against the goal you set. Every prior check stays on the record with the verdict it returned, so a bet made this quarter is still graded next quarter.
- Say the goal was three points. In the panel the rate is up 7.2 points at thirty days and 2.1 by ninety.
- Skene shows the numbers behind the movement. A change is evidence, not proof of cause.
Check history / Activation3 checks
| Check | Change | Verdict |
|---|---|---|
| 30 days after launch | +7.2 points | Goal met |
| 60 days after launch | +6.4 points | Goal met |
| 90 days after launch | +2.1 points | Below goal |
Pricing
Start free. Pay when the check runs on every release.
Product data your GTM team can trust. Skene doesn't replace your analytics. It watches the code that records the events PostHog, Mixpanel and the rest read, and it does not keep or chart those events itself.
Free
$0
One audit of what you collect
- One audit per workspace, once, and no card
- Sign in, create a workspace, connect a source
ProMost teams
$249/ month
Continuous monitoring
- Continuous monitoring on every pull request
- Recommendations as new gaps appear
Enterprise
Contact us
Adapted to your systems
- Expert-curated rules and guidance
- A shared GTM and engineering operating model
FAQ
Common questions
The questions worth settling before you connect a source.
You sign in, connect one source, and Skene starts the analysis as soon as setup is done. Setup takes about five minutes. The free audit is behind sign-in, not an anonymous scan.
No. Skene protects the collection layer feeding whichever of those you already run; it never becomes the place your event data lives.
It reads the repository you link and posts its reviews on your pull requests. The Contents, Pull requests and Issues permissions are read and write, so when someone on the repo comments /skene fix, it can open a follow-up pull request restoring the tracking that was deleted. It never pushes to your default branch, so every change it proposes arrives as a pull request you review and merge.
Disconnecting happens in your own Skene settings: one control unlinks the repository, another deletes the Supabase connection and the OAuth tokens Skene stored. To revoke the App's permissions at GitHub itself, uninstall the Skene GitHub App there. If you had upgraded Supabase to read-write, the triggers Skene deployed stay in your database until you drop them.
Your next decision deserves better evidence
Ship the next play with an answer, not a caveat.
Start with the free audit of the product data your GTM team relies on. It maps what your product collects and names the gaps, while there is still time to add what is missing.The free audit costs USD 0 and needs a sign-in and one connected source, not a card. It returns one audit of what your product collects, once.