Project: reconcile Meridian's signup funnel

Last updated: 4 Oct 202618 min read

project

A product-analytics prompt should preserve metric definitions, event lineage, eligibility, identity, and time windows. It can explain a validated table and suggest checks. It cannot turn raw event volume into a user count or infer causation from a descriptive funnel. Meridian Parcel is a fictional product used throughout these lessons.

Review the packet

Meridian records 5,170 raw signup-start events. After removing 470 duplicate deliveries by event ID, 4,700 eligible unique users remain for the chosen window. Of those users, 2,820 complete signup within the defined period, giving a 60% funnel rate. The mobile group has 2,350 starts and 1,175 completions, or 50%; desktop also has 2,350 starts but 1,645 completions, or 70%. The prompt must preserve these denominators and show a product hypothesis as a hypothesis, not a causal verdict.

Raw start events: 5,170; duplicate event deliveries: 470
Eligible unique starts: 4,700
Mobile: 1,175 / 2,350 = 50%
Desktop: 1,645 / 2,350 = 70%
All: 2,820 / 4,700 = 60%
Cause of gap: unknown without further evidence

Performance and review cost

Deduplicating N events by stable event ID is O(N) expected time and O(N) memory; grouping U eligible users by platform is O(U) with a small number of counters. The expensive part is proving that the event contract and identity rules mean what the labels claim. Preserve a reproducible query and its input snapshot so the memo can be rerun after an instrumentation repair.

Common Mistakes

Do not use 5,170 raw event deliveries as the eligible-user denominator.
Do not average the two platform percentages when segment sizes differ.
Do not call a platform gap a proven design cause.

Related lessons

prompt engineering

product analytics