4 November 2025
The quiet cost of too many events
An SDK that fires on every tap feels thorough. It is often a way of postponing the decision about what the product is.
Volume invoices arrive first: warehouse scan time, vendor MAU bands, the analyst who now spends Thursday deduplicating button_click. Trust arrives later, as a rumour: “we don’t use that dashboard.” By then the catalogue has three hundred names and four owners, which is to say no owner.
Auto-track is not immoral. It is a first draft. Teams get into trouble when the first draft is promoted to the constitution. Every screen view becomes a fact, including screens that are loading states, error toasts, and the paywall shown to a user who is already billed.
What we cut in critique
Events that describe UI chrome rather than objects. Properties that dump the entire user record on every fire “in case we need it”. Duplicate completes from retry buttons. Marketing pixels that re-implement the same purchase with a different spelling.
Students are often relieved when we delete. The fear is that a future question will be unanswerable. That fear is correct, and it is still cheaper than a stream nobody believes. The withholding list — questions we will not answer — is part of Signal Studio for this reason.
A practical ceiling
We do not publish a magic number. We do ask that a new hire can read the catalogue in an afternoon and find the core object in under ten minutes. If that test fails, you do not need more events. You need fewer, with owners, and a retirement date for the rest.