Name your analytics events before they hit PostHog.
A structured catalogue of the named events your product emits. Module, event name, CRUD verb, source, trigger, status. Tied to PD controllers and to the emails those events fire. The event-storming layer that survives the workshop.
Every team has the Notion page nobody updates.
"Analytics events we should be tracking" is a Notion page in every startup we've worked at. It was created in month one with grand intentions. By month six it's stale. By month twelve the actual events in PostHog and the catalogue in Notion have diverged so much that nobody trusts either.
m18t's event registry is the catalogue with teeth. Each event has a structured record (name, module, CRUD verb, source, trigger), a status (planning → in-production), and links to the PD controllers that emit it and the emails those events fire. When a developer adds the instrumentation, they read the catalogue here. When a PM plans a new feature, they add the events here first.
A catalogue that's connected to the work doesn't drift from the work.
Capabilities
Structured event records
Slug, module, event name, CRUD verb (Create/Read/Update/Delete), source (User/System), trigger, status, brand scope. The shape forces clarity.
Status workflow
Planning → To Do → Doing → Testing → Production. Same status set as the rest of m18t. See at a glance which events are live and which are pending instrumentation.
Linked to PD controllers
Each event ties to the PD controllers that emit it (via event_controllers junction). Useful for engineers — they see which controllers need to fire which events.
Linked to emails
Each event ties to the transactional emails it should fire (via email_events junction). Marketing and engineering see the same chain.
Brand-scoped
Each brand maintains its own event registry. Multi-product founders track each product's events separately.
Scheduled and published dates
Track when an event is planned to ship vs. when it actually went live. Useful for release planning.
The feature → event → email chain.
m18t lets you trace the full chain from a feature in PD to the controller that emits an event, to the analytics event registered here, to the email that should fire when the event happens — all in one workspace.
Events link to the PD controllers that emit them. The plan is to fold events into PD as pd_events on the roadmap.
Events link to the transactional emails they fire. Two-way visibility.
Drop your registered events onto a whiteboard for event-storming. The board stays in sync with the registry.