Objective & prerequisites
Validate identities, timestamps, repeated deliveries and event meaning. Prerequisites: percentages, basic tables, Python lists/dictionaries and the earlier analysis foundations. Download and extract the full kit, then open a terminal in product-analytics-kit. Python 3.10+ and the standard library are sufficient. Spreadsheet users can inspect the CSVs and reproduce the small controls manually. All people, events and experiment outcomes are invented teaching data. No live tracking, public experiment, payment or registration is activated. These free companion lessons use the existing studio without changing paid access or course progress.
python3 analysis.py
python3 -m unittest discover -s tests -vUnderstand the concept
An event table usually has event grain: one record describes one recorded action. It is not a user table. Stable event IDs can reveal delivery retries. Remove an exact repeated event_id only when all fields agree; a repeated ID with conflicting fields is an error requiring investigation. Different IDs from the same user may be genuine repeated actions and should not be dropped merely to simplify totals. Validate known user references, allowed event names and explicit UTC timestamps. Event time and ingestion time are different concepts; this kit has only event time and an explicit completeness assumption, so it cannot diagnose late-arriving ingestion. Never copy personal details into event payloads for a teaching exercise.
Worked example
The source contains 45 CSV event rows. One exact delivery retry is removed. One event from the internal user is excluded, and two records at or after the watermark are withheld. This leaves 41 accepted event records. A lesson before the user’s first start remains valid event evidence but does not advance the ordered funnel. An exercise before its lesson is similarly retained and evaluated against the sequence rule. The validator rejects unknown users, conflicting IDs and pre-signup events instead of silently publishing a partial answer.
from analysis import read_csv, product_data
raw = read_csv("events.csv")
people, accepted, audit = product_data(read_csv("users.csv"), raw)
assert len(raw) == 45 and len(accepted) == 41
print(audit)Try it yourself
Reconcile the 45 raw rows to 41 accepted rows. Locate the repeated event ID in a spreadsheet or with collections.Counter. In a copy, change the time on its repeated row and predict what the validator should do. Add an unknown user ID to a separate copy and explain why a join that silently drops it could hide instrumentation failure. State your denominator, time window and expected result before running the reference. Use a copy for changes and keep the original evidence intact.
Worked solution
The reconciliation is 45 minus 1 exact retry minus 1 internal event minus 2 out-of-snapshot events = 41. The supplied audit reports each exclusion separately. A conflicting duplicate raises ValueError and no report is produced. An unknown user also fails. If a real operating policy instead quarantines records, it must publish the rejected population and completeness implications; the current reference deliberately fails closed for these contract defects.
Knowledge check
Can you infer that tracking is complete because the maximum event time looks recent?
Check and explain
No. Absence of events can mean inactivity or collection failure. Completeness needs an independent collection/watermark contract and operational checks.
Evidence, mistakes & handover
Keep a metric definition and an auditable count beside every percentage. Distinguish a measured zero, missing telemetry and an incomplete observation window. Record exact commands, actual outputs, assumptions and one failed case. Do not describe an observational association or a manufactured experiment fixture as proof of real business impact. The kit includes separate exercises, worked solutions, a metric contract, an experiment plan template, a decision memo template, tests and a visual worked report. Credit the supplied starting point and explain your own contribution.
Authoritative reference
— reference for the underlying concept; vendor defaults can differ from this lesson’s explicit definitions. Lesson prose, case data and exercises are original. No analytics vendor installation, live user telemetry or production experimentation is claimed.
Try the activity before reading its reference. Keep your sources, commands and assumptions with your work. Companion activities are unsaved self-practice and do not award a certificate or change lesson progress.