Why it matters
Analytics is only as good as the events underneath it. Without a plan, the same action arrives under three names, a property is a number in one release and a string in the next, and an event fires on a screen nobody saw. Each of those is a chart that looks right and is wrong — a funnel that undercounts, a retention curve that splits one cohort in two, an answer you act on.
Governance is how you prevent that, once, instead of finding it later in a chart. In Togo it comes down to one habit — define every event before you ship it — and the controls that enforce the plan for you.
A defined event pays off three ways:
- Your numbers mean what they say. Every event has one name, one meaning and typed properties, so two people — or two agents — asking the same question get the same answer.
- Your agent answers better. A definition tells the AI what the event means, when it fires and when it does not — the difference between “people who saw pricing” and “people the pricing page rendered for”.
- Mistakes are caught before they reach your data. A misspelled name, a missing event or a property that would be dropped is flagged before you ship, not discovered a month later.
What a definition holds
| Part | Example for checkout_started |
|---|---|
| What it means | A person began paying for a plan |
| When it fires | The checkout page has loaded with a plan selected |
| When it does not | A plan is previewed from the pricing page; a checkout is retried |
| Its properties, typed | plan: one of starter, pro, team · seats: number |
The “does not fire” line matters most. It is what stops a conversion event quietly turning into a page-render event as the product changes around it.
The recommended setup
- Define every event before the code sends it. The agent install does this for you: it reads
your product’s flows and defines each event first
(Install Togo with your AI agent). Your agent can define or refine one at any
time with
update_event_definitions, and you can review them all in the dashboard’s Event registry. - Check every release against the plan. Before you ship, have your agent check its test run
with
verify_tracking: it shows each event the run sent with what is wrong with it and the fix, and counts the errors, the warnings and the expected events that never arrived (Check that events arrive). - Turn on strict event governance once your plan covers your traffic, so only defined events reach your reports (below).
What Togo enforces for you
| Control | What it does |
|---|---|
| Strict event governance | Keeps only events your plan defines; everything else is dropped as it is processed |
| Safe changes to live events | Once an event has traffic, a definition change that would break code already sending it — a narrower type, a removed allowed value — is refused, with the reason |
| Stable keys and merge suggestions | Every event keeps one key for life, and two names that look like one event are flagged to merge — never merged silently (Events) |
| Release checks | verify_tracking and Live View show, for every test event, whether production keeps it |
| Checks on arrival | Reserved $ names, oversized values, too many properties and implausible timestamps are refused before they are stored (Event diagnostics) |
Strict event governance
Turn it on in your project’s Settings, under Event governance → Only keep defined events. From then on, an event whose key has no definition is dropped when it is processed. Its name still appears in the Event registry, so you can see it and define it.
Turn it on when your plan covers your traffic. Before switching, check that every event you
rely on is defined: Live View marks any test event production would drop as Not defined,
and verify_tracking says the same. Define what it names, and switch on.
Drops are permanent. An event dropped while the setting is on is not stored, so turning it off later does not bring it back. That is why the switch belongs to a person: an owner or admin turns it on in the dashboard, and agents — which can define events — cannot change it.
Who can change the plan
| Change | Who |
|---|---|
| Define or refine an event | Your agent with a Read and change connection |
| Merge two events | Your agent, after asking you — a merge is permanent |
| Turn strict event governance on or off | An owner or admin, in the dashboard |
What a connection can see and do covers agent access in full.