Playable‑Demo Instrumentation Cookbook: 12 Events, Naming Conventions, and Dashboards That Prove a Demo Moves MRR

Start by defining the causal claim you want to test. Typical claims are: “Watching the playable increases trial starts by X%” or “Interacting with feature X inside the demo improves trial→paid conversion.” The instrumentation below is designed so every experiment produces the three observation layers you need: demo engagement, downstream micro-conversion (signup/trial), and revenue/paid conversion.

Minimum telemetry: record demo lifecycle events, a small set of micro-conversions, and revenue events. Keep the taxonomy lean—only track events that answer the business question for your experiment. Over-instrumentation creates noise and increases the maintenance burden.

Instrument twelve events grouped by purpose so you can run funnels and attribution without having to join raw logs. Use simple, high-signal events; avoid capturing every click inside the player unless you need to diagnose UX.

Below are the events and the minimal properties each should carry. These names follow the object-action pattern so they’re portable across analytics stacks and warehouse pipelines.

Pick a single naming convention and treat event names as immutable once live. Use a consistent object-action style (e.g., demo.start, demo.feature.use). Keep event names stable to preserve historical comparisons; add new events for new behavior instead of renaming old ones.

Standardize property prefixes and types (strings, booleans, numbers), and document them in a single source of truth. Use demo_variant and demo_source consistently so A/B analysis and UTM attribution are straightforward.

Installless demos often start anonymous and only later connect to accounts. Emit an anonymous_id for every session and capture an eventual user_id when the visitor signs up or authenticates. Record consent decisions (analytics_allowed true/false) and implement server-side guardrails so revenue events are always tied to a verified user_id.

When you A/B test variants, ensure equal sampling at the demo variant assignment point (server-side or globally seeded client-side) and log variant assignment as a persistent property so downstream joins and cohorting are deterministic.

Build three dashboards for every experiment: (1) Demo engagement funnel (demo.start → demo.feature.use → demo.complete), (2) Demo-to-trial funnel (demo.start → signup_after_demo → trial_start), and (3) Revenue attribution (trial_start → subscription_start → revenue). Use the demo_variant property to split by variant and compute lift in each funnel step.

Add a lightweight acceptance test suite: synthetic events that assert the event pipeline preserves insert_id/unique ids, variant is recorded, timestamps are monotonic, and revenue events are tied to user_id. Run these tests on deploy and before launching an experiment to avoid noisy, unusable data.