The purpose of a tracking plan is to define the key stages of your lifecycle, and make sure that tracking is consistent in all your tools.
A quality tracking plan will give you useful, quality data to work with. A crap tracking plan will give you useless, crap data to work with.
The key part of a tracking plan is don’t measure everything - you want to build a high level overview and drill down from there.
By “measuring everything” it creates a lot of noise and detail for analysing and driving decision making. The events you track have a hierarchy of importance. Don't cloud that hierarchy - start by plotting your key events.
Low level events and “micro-conversions” have their place in optimising your lifecycle and narrowing your questions, but still in the context of the macro-conversions - the big events that result in progress down the lifecycle. It’s the macro-conversions that describe the key steps that move people down the lifecycle.
- Micro-conversion: "Completed email address field in Demo Request Form"
- Macro-conversion: "Requested Demo"
Since you’ve done the legwork of mapping out your lifecycle already, the output of this is the outline of your tracking plan.
- The key events (that matter most)
- The purpose of the event (and how it progresses through the lifecycle)
- Event properties
You’ve also paid some attention to your naming conventions for events. Don’t have different methods of naming different things - have one method, so it’s easier to sort, segment and analyse by later.
A recommended standard is “object + action” where the object is a noun, and the action is a verb - always in the past tense.
- Blog Post Viewed
- Email Subscribed
- Demo Requested
- Account Created
- Order Completed
Following Segment.com’s tracking plan guide, the next steps are to outline the event properties and their values, together with their location and code. This becomes much more about implementation.
Since this tends to sit within your website, CMS, e-Commerce engine or within your product, you may be quite restricted in what you can manipulate and setup yourself without diving into your own code. Two more sets of things need defining -
- Event property values
Again, less is more. Don’t track everything in your properties. Once you define a need for a specific set of properties across your events, then it makes sense to add it. Common types of properties are people, products, places and times which are groupable - these make them useful for segmentation later.
As with the full event names, event properties need to be clear and descriptive. Properties ought to be complete (always having a value) and discrete - only one value makes sense to enter at any one time.
For the purpose of personalisation, it’s critical that you include one set of properties across every event - an identifier. This allows you to track individuals actions, and then analyse actions and trigger personalised messages based on that individuals actions.
Implementing your tracking plan
With your spreadsheet defining event names, properties, values and code, you need to implement it within your tools.
We love Segment.com for making it easy to add and maintain a tracking plan across multiple tools. Instead of writing implementations for every single tool, you write it and implement it once within Segment.
Then, within the Segment interface, you connect it to other tools (analytics and otherwise - including Hull) so it’ll track the data asynchronously under the same format there. Segment makes it really easy to maintain a consistent tracking plan everywhere.
With your tracking plan implemented, you’ll start getting structured event data through to your tracking tools. You’ll be able to use this data to analyse your key events and manage your segmentation.
It’s your event names and properties which give one set of the options for creating segments within Hull - make them useful!
And remember - KISS: Keep It Simple, Stupid!