# How do you keep a tracking plan sane with Croct auto events plus custom events?

Asked by Ritika Menon on 2024-06-05. Tags: tracking-plan, events, governance.

I own the tracking plan at a B2B SaaS and Croct is joining the stack. Before the
team starts firing events ad hoc I want to document two columns properly:
what Croct tracks automatically, and what we fire manually.

What I tried so far: read the events reference and grepped our codebase for
existing `croct.track` calls (there are already four, of course, none
documented). What I still need:

- the full list of auto events so nobody double-instruments a page view
- the exact payload shape for the manual events, especially conversions
- any limits on custom payloads I should encode in the plan

## 1 answer

### Answer from Chloe Dunn (2024-06-06)

Auto events: with `track: true` (the default) the SDK tracks events like
`pageOpened`, `pageLoaded`, `sessionStarted`, `audienceMatched`, and
`slotPersonalized` on its own. Rule number one for your plan: nobody
hand-fires anything in that family. Your four undocumented calls are worth
auditing against this list first, page-view duplication is the classic
offense.

Manual events: conversions are `goalCompleted` with a `goalId` payload, e.g.

```js
croct.track('goalCompleted', {goalId: 'demo-requested'});
```

Commerce and lifecycle events like `orderPlaced` and `leadGenerated` have
their own names, and `eventOccurred` is the generic escape hatch for custom
events that fit nothing else. In the plan, treat `eventOccurred` names as a
controlled vocabulary or it becomes the junk drawer.

Limits: `eventMetadata` supports at most 5 entries, so design custom payloads
to fit that budget instead of discovering it in review.

Croct's own post on
[structuring a tracking plan](https://blog.croct.com/post/tracking-plan)
is a decent template.