PR #1148 · Practical value
No sample rates · questions before answers

Turn activity into decisions.

The events do not improve the product by themselves. They locate the next problem worth solving—and show whether the fix worked.

Where do new users stop?
Can creators reach an export?
Why does revenue leak?
Which save offers work?
Companion to the implementation explainer · use ← →, Space, or swipe
Diagnostic route
Measure step-to-step conversion · no values until data lands

Find the first broken handoff.

The funnel shows which transition loses people. That turns “growth feels slow” into a bounded product question.

Sign upsignup_completed
Createtask_created
Exportexport_completed
Checkoutcheckout_started
Activatesubscription_active
Observe

Locate the largest loss

Compare adjacent steps for identified users.

Baseline first
Explain

Break down the transition

Check platform, tier, task kind, and export mode.

One hypothesis
Act

Fix that handoff

Ship one targeted change, then compare the same transition.

Decision enabled
Hatching means unmeasured—not poor performance. Real rates begin only after instrumentation ships.
Illustrative example
Hypothetical numbers · not production data

A concrete example points to Mac export.

Sign up1,000base
Create70070%
Export21030%
Checkout8038%
Activate7290%
30%

task → export conversion is the weakest handoff: 490 of 700 creators stop before an observed export.

Mac · local
12%
Web · local
41%
Web · cloud
44%
Decision

Investigate Mac export reliability first. Ship the fix, then compare the next Mac cohort against the same 12% boundary.

Illustration only · a move from 12% toward the other observed modes would support the fix; exact task and revenue totals still come from product systems.
Use case 01 · Activation
signup_completed → task_created

Diagnose onboarding before redesigning it.

Signal

Signed up, but created no task

Measure time and conversion from first sign-in to accepted work.

PostHog funnel
What it narrows

Intent, setup, or platform friction?

Split by auth method, web vs Mac, and the task kind eventually chosen.

Segment the loss
Decision

Change the first-run path

Improve import guidance, empty states, sample media, or the failing platform—not all onboarding at once.

Targeted onboarding
Success measure · the same signup→task transition improves without increasing failed or abandoned jobs.
Use case 02 · Product value
task_created → export_completed

Show whether creation reaches a usable result.

A task is intent. An export is realized value. The gap between them is where editor and renderer friction lives.

Start with the gap

People create accepted work but the current client never observes an output.

  • Time to export
  • Task → export rate

Locate the friction

Compare transcription, translation, VTT, and dubbing; then local vs cloud export and web vs Mac.

  • Discoverability
  • Reliability
  • Performance

Choose the fix

Prioritize the mode and platform with the clearest loss, then verify that completed exports rise.

  • Editor guidance
  • Exporter hardening
Known limit · cloud completion is recorded only when the initiating client observes it; operational task data remains authoritative.
Use case 03 · Monetization
task_created → checkout_started → subscription_active

Separate pricing friction from payment failure.

No checkout

Value or offer problem

Creators use the product but do not begin checkout. Test packaging, limits, price framing, and upgrade timing.

Checkout, no activation

Payment or plumbing problem

Stripe handoff happened, but no verified paid-tier transition followed. Inspect abandonment, payment failure, or webhook state.

Verified activation

Revenue path completed

Compare tier, interval, promotion, activation path, and source page to learn what converts.

Stripe remains the source of truth for money. These events explain the journey around the transaction.
Use case 04 · Segmentation
Same funnel · different operating conditions

Segments tell you where to work.

Activation
Value reached
Monetization
Platform
Does Mac or web lose more new users?
Which platform reaches export reliably?
Does either platform under-convert?
Task kind
Which intent reaches accepted work?
Do dubbing or VTT users export?
Which workloads create paid intent?
Tier
Are unknown/free users activating?
Do paid users reach output faster?
Which upgrade path changes tier?
Offer
Which source starts the journey?
Does promo traffic reach value?
Monthly vs annual; promo vs standard?
Use breakdowns to bound investigation—not to manufacture conclusions from tiny cohorts.
Use case 05 · Retention
Reason → offer → observed outcome

Cancellation becomes a retention experiment.

Reason

Why are they leaving?

Use survey reason and detail presence to identify product, price, timing, or fit problems.

Offer shown

What intervention matched?

Pause, downgrade, or listen—measured against the reason that selected it.

Saved or confirmed

Did it change the outcome?

Compare save rate by reason and offer. Remove weak interventions; improve the ones that retain the right users.

Cancellation records remain authoritative for totals; events support funnel ratios and cohort comparisons.
Operating cadence
Saved insights · stable event vocabulary

A weekly dashboard answers five questions.

Acquisition

Signup → first task → first export

Where does activation break?

Monetization

Task → checkout → active subscription

Offer issue or payment issue?

Retention

First task → returning weekly task

Does value become habit?

Experience

Task → export by kind, mode, platform

Which workflow needs work?

Cancellation

Saved / (saved + confirmed), by reason

Which save offer earns its place?

PostHog · identified funnels and retention · Plausible · aggregate top-of-funnel ratios.
Decision hygiene
Best-effort telemetry · authoritative business state

Use signals for direction. Use records for totals.

Analytics answers

Where, when, and for whom does the journey break?

Use events for ratios, funnels, cohorts, comparisons, and before/after movement.

Systems of record answer

How many tasks, cancellations, and paid subscriptions actually exist?

Use Firestore cancellation records, task state, and Stripe webhooks for exact business counts.

Events can be absent before consent, after teardown, or when a sink is blocked. That limitation is explicit.
What happens next
Instrument → learn → change → verify

Every event should close a decision loop.

Establish baseline

Configure PostHog, register Plausible Goals, and let normal product traffic accumulate.

Name one loss

Choose the largest useful transition—not the most dramatic-looking chart.

Ship one change

Annotate the release and preserve the same event definitions.

Compare again

Keep, iterate, or revert based on movement plus the authoritative product outcome.

The practical payoff · fewer roadmap arguments based on anecdotes, and faster feedback on the changes that matter.