18 Jan 2026
When to split an event
A single button_clicked with forty properties is not elegant restraint. It is a junk drawer. Splitting is sometimes the honest move.
Use a property when the action is the same and the variation is a dimension you will filter: method, plan, source. checkout_started with entry_point is usually correct.
Split the event when the user intent is different, when downstream owners differ, or when allowed values for the “type” property would exceed what a human can remember. message_sent and message_scheduled are different acts. Cramming them under message_action with a type enum helps no one in a review.
Another split signal: identity rules diverge. If one path must not fire until the user is known and the other may fire anonymously, they are not the same event with a flag. They will be double-counted by someone who forgets the flag.
Do not split because two squads do not want to share a name. That is politics. Keep one event and assign a joint owner in the dictionary. The Atelier’s review ritual exists partly to stop taxonomy from becoming a map of the org chart.
When you do split, write the deprecation or the coexistence rule on day one. Two overlapping names without a window is how dashboards quietly diverge.
If you are unsure, inventory the object again. Most false splits come from naming screens. Most false merges come from fear of “too many events.” Count intents, not taps.