The Analytics Event Registry

What you'll learn

• What the Events Manager is: a registry where you name and design analytics events before you instrument them in PostHog or GA.
• The fields that describe an event — module, name, CRUD verb, source, trigger, status, payload contract.
• Why this is event-storming discipline, not a marketing-campaign tool.

Why name events before you write the tracking code

Analytics instrumentation usually happens backwards. A developer sprinkles track('button_clicked') calls through the code, a second developer adds track('Button Clicked'), and six months later the analytics dashboard is a graveyard of near-duplicate event names nobody agreed on. The vocabulary was never designed; it accreted.

The Events Manager flips that order. It's a registry where you decide what events your product emits — their names, their shapes, what triggers them — and only then go instrument them in PostHog or Google Analytics. The registry is the source of truth for the event vocabulary; the tracking code conforms to it. This is the event-storming practice made into a real table you can query.

One thing to clear up immediately, because the URL is misleading: the page lives under /studio/martech/events, but these are not marketing campaigns. There's no email blast, no audience, no campaign timeline. (The old "Campaign Timeline" label is gone — the page is titled "Events Manager".) An "event" here means a named thing your software does — user.registered, content.published, subscription.renewed — the kind of event you'd send to a product-analytics tool.

Events are strictly brand-scoped. Every event belongs to a real brand; there's no workspace-wide "all-brands" event. Switch brands in the sidebar and the registry re-shards.

The shape of an event record

• Slug in a dotted convention — auth.user.login, content.post.published. Reads like a path; uniqueness is per brand.
• Module — the functional area (auth, billing, content, ai, onboarding, …), colour-coded in the list.
• Event name — the human-readable name ("User Registered").
• CRUD verb — Create, Read, Update, or Delete, the kind of operation the event represents.
• Source — who or what causes it: User, Visitor, Platform, or Admin.
• Trigger key — an identifier for the logic that fires it (e.g. USER_REGISTERED).
• Status from the shared status set, so you can track which events are still planned versus instrumented and live.
• Payload contract — a small JSON object describing the event's data shape, e.g. { "email": "string", "brand": "string" }. This is the load-bearing contract that downstream consumers (emails, automation, your analytics tool) reference. The form validates it as JSON and pretty-prints it. Keep it small and free of personal data.
• Related product model — an optional link to a Product Manager model the event concerns.
• Linked controllers and emails — see Tying Events to Emails & Code.

How to add an event

1. Open Events Manager (/studio/martech/events).
2. Click Add Event.
3. Pick the brand — events must belong to a real brand, so this gates the form.
4. Fill in the slug (dotted), module, and event name (these three are required).
5. Set the CRUD verb, source, and an optional trigger key.
6. Define the payload contract as JSON — what data the event carries. The editor flags invalid JSON before you save.
7. Set the status to reflect where the event is: planning while you're designing it, advancing as you instrument and ship it.
8. Save.

Variations

• Filtering and reading the table. Filter by module and status in the bar; Advanced Filters adds CRUD-type and source. The footer tallies events by CRUD verb and by source, so you can sanity-check coverage at a glance.
• Linking to your product spec. If you maintain a Product Manager spec, attach the relevant model and the controllers that emit the event. That turns the registry into part of your living architecture, not a side list.
• Folding into PD. There's an active plan to fold events into the Product Manager workspace as a native PD entity. Until that lands, the registry stays at /studio/martech/events for historical reasons. Nothing you enter is lost in that move.

FAQ

Are these marketing campaigns or email campaigns? No. Despite the martech in the URL, an event here is a named action your software performs — the kind you'd track in PostHog or GA. There's no audience, blast, or campaign timeline.

Does adding an event here start tracking it automatically? No. The registry is the design surface — it names and documents the event. You still instrument the actual tracking in your analytics tool. The registry is what that code should conform to.

What is the payload contract for? It documents the event's data shape so every downstream consumer — an email that fires on it, an automation, your analytics schema — agrees on the fields. Keep it minimal and PII-free.

Why must an event belong to a specific brand? Events are strictly brand-scoped to avoid leaking one brand's event data into another under m18t's tenancy model. There's no "all-brands" event.

Can I connect an event to the code that emits it? Yes — link it to the Product Manager controllers that trigger it, and to the emails it should dispatch. See Tying Events to Emails & Code.

What's next

• Tying Events to Emails & Code — wire events to controllers and emails.
• The Email Repository — the emails events trigger.
• The Product Development Concept — the controllers and models events link to.
• The Status Set — the status vocabulary events share.
• Programmatic Read & Write — read and create events via the MCP endpoint.