tracking-and-funnels

Tracking & Funnels

One skill for both directions of the same loop: what to instrument (so hypotheses become measurable) and how to read the funnel (so measurements become verdicts). Serves /brief (steps 4–5), /validate (step 6) and experiment-design (step 14/16).

Design tracking FROM the hypotheses

For every testing/draft hypothesis in output/hypotheses.json, name the event/metric that would confirm or refute it — that mapping IS the acceptance test of the schema. An event no hypothesis needs is noise; a hypothesis no event can test is a research gap → into the analytics brief.

Schema conventions:

• object_action naming (checkout_started, not click_btn_3), snake_case
• Properties over event proliferation: one order_completed with payment_method beats three payment events
• Every event: user id, timestamp, platform, session id; funnel events additionally carry the entry surface/source
• Define each metric once, in writing, with its window ("CTR" without a definition is how gate presentations die — see /challenge)

Read the funnel

• Sequential windows: a funnel is ordered events within a window per user — state the window and whether re-entry counts; unstated windows make numbers incomparable across sources (→ data_inconsistency).
• Segment before averaging: an aggregate drop-off hides opposite behaviors; split by the CONTEXT.md segments and by entry surface first.
• Cohorts for time effects: compare users by start week when the product changes underneath them.
• Skeleton (adapt to the PM's warehouse; pseudo-SQL is fine in briefs):

SELECT step, COUNT(DISTINCT user_id) AS users,
       ROUND(100.0 * COUNT(DISTINCT user_id) /
             FIRST_VALUE(COUNT(DISTINCT user_id)) OVER (ORDER BY step), 1) AS pct
FROM funnel_events           -- events pre-mapped to ordered steps
GROUP BY step ORDER BY step;
-- splitting by segment/platform? add PARTITION BY to the window fn,
-- or pct will be computed against the wrong base