Add the properties an event needs before it can be segmented
An event that records that something happened and nothing about who or where.
The ticket
Add the properties an event needs to be segmentable.
Acceptance criteria
- Each property is present on a captured event
- Property names follow the existing convention
- No personal data is added without a stated basis
- The properties are documented in the tracking plan
What lands as proof
A captured event carrying every property, checked against the plan rather than the code.
Why teams defer it
- The event was added to answer one question and is now being asked a different one.
- Adding properties risks adding personal data, which pulls in a privacy review.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: add the properties an event needs to be segmentable. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means each property present on a captured event, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.