The tracking plan, the event debugger, and why bots are stored rather than dropped.
Declare the events you expect and the type of each property. A violation is flagged and the event is stored anyway, because losing data due to a property type change is a worse failure than keeping it and saying so.
A project with no declared plan has nothing to violate. Validation is opt-in and does not punish anyone who has not written one.
| Undeclared event | Flagged. Usually a rename nobody told the analyst about. |
| Wrong property type | Flagged with the expected and received types. |
| Missing required property | Flagged. |
| Value outside an enum | Flagged with the allowed values. |
| Undeclared property | Reported, not treated as breakage. Adding a property is a normal change. |
A live view of every decision the pipeline made about an event in the last 30 minutes: the visitor hash, the session and whether it started, the resolved country and device, the consent state, the properties, and any validation errors.
Rejected events appear alongside accepted ones with the reason and what to do about it. Everything shown is post-sanitisation, so the debugger can never become a way to inspect the personal data the pipeline refused to keep.
Bots are detected, labelled, and stored. They are excluded from every report and never billed.
Storing them is the point: you can see what was filtered and disagree with it, and the filter can be improved retroactively without having lost the history. A product that silently drops traffic is asking you to trust a number you cannot check.