Instrumentation: Event Tracking Plans (segment)

https://segment.com/academy/collecting-data/how-to-create-a-tracking-plan/

https://segment.com/docs/protocols/tracking-plan/best-practices/

https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/

https://segment.com/blog/what-is-a-tracking-plan/

Regardless of your approach, keep the following tips in mind:

• Pick a casing convention. Segment recommends Title Case for event names and snake_case for property names. Make sure you pick a casing standard and enforce it across your events and properties.
• Pick an event name structure. As you may have noticed from the Segment specs, Segment uses the Object (Blog Post) + Action (Read) framework for event names. Pick a convention and stick to it.
• Don’t create event names dynamically. Avoid creating events that pull a dynamic value into the event name (like User Signed Up (11-01-2019)).
• Don’t create events to track properties. Avoid adding values to event names that could be a property. Instead, add values a property (like "blog_post_title":"Best Tracking Plans Ever").
• Don’t create property keys dynamically. Avoid creating property names like "feature_1":"true","feature_2":"false", as these are ambiguous and difficult to analyze.

Resources:

Building a Model-Driven Enterprise

Data taxonomy playbook, part two: Events and properties

When should you create a new event or a new event property for similar user actions?

Suppose you have two user actions that could either be two separate events, or a single event with two separate event property values. Is the fundamental action the user is taking the same in both cases? If so, consider instrumenting them as one event separated by an event property.

Option 1

• Event: 'Purchase Coins'
• Event: 'Purchase Gems'

Option 2

• Event Property: 'Type' = {'Coins', 'Gems'}
• Event: 'Purchase'

How important is it to monitor the flow of events from 'Purchase Coins' to 'Purchase Gems'?

If it's important enough, it'll be easier to read as two separate events in Pathfinder, Pathfinder Users, Show Users Streams, and Show User Paths. On the other hand, if the purchase action is the same regardless of whether they purchase a coin or a gem, and you just want to occasionally filter on it, instrument it as one 'Purchase' event with an event property that accepts the values 'Coins' or 'Gems'.

Broadly speaking, the general rule of thumb is that if you want to see how users move between two critical actions, then create two separate events. Having one event is good for two similar user actions.