[FEATURE] Opt-in anonymous usage telemetry for product insight

Problem

OpenCut has 69k+ stars and opencut.app has real users — but the team currently has no signal on how the product is actually being used. Without this, every architectural and prioritisation decision in the rewrite is made blind:

• Which features do users actually reach (vs. which do they open and never touch)?
• Where do sessions drop off?
• What export formats and resolutions are most common?
• Are users hitting errors silently and churning without filing issues?
• Is the editor being used for short-form (15s) or long-form (5min+) content?
  This matters most right now, during the rewrite, while architectural decisions are still open. Building the new Editor API and plugin system without usage data means optimising for assumptions, not reality.

Solution

Add opt-in, anonymous, aggregated telemetry — off by default, with a clear prompt on first load and a permanent toggle in settings.

What to track (events only, no content)

Event	Why it matters
Session start / duration	Active usage vs. install-and-abandon
Feature touched (timeline, trim, audio, captions, effects)	Which features have real adoption
Export triggered + format + resolution	What output workflows matter
Export success / failure + error type	Silent failure rate
Number of clips on timeline	Simple vs. complex edit patterns
Plugin installed (once plugin system ships)	Which plugin categories drive adoption

What to explicitly NOT track

• Video content, file names, or any media metadata
• User identifiers, IPs, or anything linkable to an individual
• Keystroke or mouse patterns

Privacy constraints (non-negotiable)

Given that privacy is a stated reason OpenCut exists ("your videos stay on your device"), this must be:

• Off by default. Opt-in only, surfaced once on first launch with a plain-language explanation.
• Self-hostable. Enterprise/self-hosted users should be able to route telemetry to their own collector or disable entirely via config flag.
• Auditable. The full event schema should be documented in /docs and kept in sync with the code. No dark patterns.
• Killable at runtime. A single env var (OPENCUT_TELEMETRY=false) should fully disable all collection.

Acceptance criteria

• Telemetry is off by default; user is prompted once on first load
• Settings panel shows current state with one-click toggle
• Collected event schema is documented in /docs and kept in sync
• OPENCUT_TELEMETRY=false fully disables all collection
• No PII or media metadata is ever transmitted
• A public dashboard or periodic report is shared with the community

---

Alternative

Alternative

Do nothing and rely on GitHub issues + Discord signals.
The downside: issues are filed by the vocal minority. Most users who hit a bug or find a feature confusing just leave. Passive telemetry is the only way to see what the silent majority is actually doing.

Periodic opt-in surveys instead of telemetry.
Lower engineering lift, but surveys capture stated preference, not actual behaviour. A user might say captions are important but never use them. Event data shows the truth.

Wait until after the rewrite to add this.
The worst option. The rewrite's biggest decisions — what goes into core vs. plugins, which features need to be first-class — are being made now. Telemetry added after the architecture locks in can inform iteration but can't shape the foundation.

---

Anything else?

Why this timing matters: The rewrite introduces a plugin-first architecture. If the team doesn't know which core features are actually used, they risk moving things into plugins that should stay in core (and vice versa). Usage data collected even from the classic version at opencut.app would directly inform these decisions while there's still time to act.

Suggested implementation: PostHog has an open-source self-hosted option used by several OS projects for exactly this pattern. Alternatively, a simple HTTP beacon to a maintainer-controlled endpoint avoids any third-party dependency entirely. Events should be batched and sent on session end — not in real-time — to avoid any inference of live activity.

Related: This pairs well with the planned headless/batch rendering mode — distinguishing interactive sessions from automated ones would itself be valuable signal for understanding how the Editor API gets used once it ships.

Start by mapping the first-load prompt, settings toggle, runtime configuration, and event-producing entry points, then review the event schema requirements and the /docs location mentioned in the issue. Compare a self-hosted collector with the suggested HTTP beacon, and verify that opt-in defaults, OPENCUT_TELEMETRY=false, PII restrictions, schema documentation, and community reporting are all covered when the work is complete.