Skip to content

Product Analytics

Events named for the named person's actionsteacher.submitted_grade, not form.submit. Subject.verb format. Feeds the signal reading. The prediction's measurement instrument.

Owners: PO, Developer, Data Phase it lives in: How We Build → After We Build The corpus principle this enacts: The check is observation — and analytics is what makes the observation honest.

Where it lives in the chain

How to do this

The naming convention is subject-dot-verb-past-tense:

  • teacher.submitted_grade — Gal's action.
  • student.viewed_grade — the student's action.
  • system.flagged_late_submission — the system's action, treated as a named actor.

For every event:

  1. The subject — the actor whose perspective the event takes.
  2. The verb — past tense, completed action. Submitted, not submitting.
  3. The propertieswhat was the grade, which exam, what time, with what shortcut.
  4. The session — a session ID groups events into a story.

What good practice looks like

The PO can answer, from analytics alone, the questions the brief is being checked on:

  • "What fraction of graders used the new shortcut?" — count teacher.submitted_grade with method: shortcut over total.
  • "How long does Gal's grading session take now?" — time between teacher.started_grading_session and teacher.finished_grading_session.
  • "Where do graders abandon?" — funnel from teacher.opened_exam to teacher.submitted_grade.

The events are wired before the flag is enabled — that was a release-gate condition. The dashboards are named, owned, rehearsed in staging. The brief's prediction names which events answer it.

A team that adds analytics after release is a team that predicts in vague terms because they have no instrument. The discipline is: analytics is part of shaping, not part of polish. Without it, the signal reading is reconstruction; with it, the signal reading is observation.

200apps · How We Work · NWIRE