How To Build a Customer Data Tracking Plan

To reduce common data errors such as duplication, misnamed events, incorrect property values, or incomplete user aliasing, a strong analytics strategy starts with a tracking plan. Many users jump into customer data analytics without first taking the time to create a plan. A hasty integration can cause data quality problems and reduce end user confidence in their results. It can also cost valuable time and effort trying to fix problems after integrating or trying to rewrite historical data. Just as an ounce of prevention is worth a pound of cure, time invested in planning your event pipeline will yield greater returns later on.

What is a Tracking Plan?

A tracking plan is a document that describes which user behaviors to track, why they are important, and how they are defined. When creating your tracking plan, you should keep in mind the developer who has to implement tracking and the end user who needs to answer questions from the data. You should include representation from various departments at your company in the process of creating a tracking plan so that they can document a comprehensive understanding of which user behaviors influence which business and performance metrics.

The following recommendations will help you define a consistent and trustworthy data model to measure your business and analytics goals.

  • Assemble a Team -- Websites and digital products are rarely developed by a single creator, so you should include a variety of perspectives in the creation of your tracking plan. A single event, such as a user registration, may appear in multiple customer journeys or impact cross-department KPIs across your business. 
  • Identify Key Use Cases -- What about your product or your customers do you want to better understand or improve? For example, your marketing team might be focused on improving the product's user acquisition and sign up conversion. Perhaps your engineering team is most interested in identifying and investigating points of friction in the checkout process. Your customer service team might use event data to investigate common errors or complaints. Once you've prioritized your business goals, you can define the data or events required to measure performance.
  • Identify User Actions -- You’ll want to begin thinking about the different steps in your expected customer journeys or user flows and how a customer may progress through them. Mapping out this progression- and its varieties- is important because you are able to visualize what your customer must do to reach the goal event or conversion event.
  • Standardize Event Names -- It’s very common for different teams to track events differently, or to use different formal and informal terms to explain user behaviors. For example, the iOS team might track “Purchase” and the Android team tracks “Click Checkout.” A “Registration” event might alternatively be called a “Sign up,” “Enrollment,” “Submission,” or “Application.” Incorporating input from different teams will help you to identify differences and work toward an agreed upon naming convention.
  • Build a Data Tracking Model -- A data tracking plan lays out which events to track, where those events go in the code base, and why those events are important to your business. Having a tracking plan benefits all members of your team because it builds consistency and provides a single source of truth. Our basic data model includes the use case event, key properties, source, table, mapping, unique identifier, timestamp, notes, and status. By documenting this information, any user can review the tracking plan to identify the information that they need. For a tracking plan template, reference our article Build a Customer Data Tracking Plan in 3 Easy Steps, available here.

Best Practices

Here are some best practices and suggested considerations when setting up your tracking plan...

  • Start Small -- A common mistake is to track everything- every swipe, screen view, click, submit, and subscribe along the entire customer journey. This will produce a lot of data, but it can also produce a lot of noise and it can be difficult to validate. New users might find themselves lost in an overly complex data model or confused about which events can be used to answer their particular questions. We recommend starting with the essentials- a well-defined subset of your total data to answer your top questions as defined in Step 2 above. Once your users are comfortable using Indicative to ask and answer questions using this data, you can add more events later on.
  • Identity Management -- in addition to events, it’s important to properly track your users. Read more about how Indicative identifies and aliases unique users here.

Common Questions

  • How many events should I track?

The basic Indicative SDK tracks two basic events to get you started: Page Views and Web Sessions. Our most successful customers will build additional events for developing deeper insights. We typically recommend anywhere between 20 to 300 events, depending on the complexity of your product and the number of users on your team. That said, we also recommend that keep it simple- at least when first starting out- so that end users are not overwhelmed by an overly complex data model.

  • What events should I track?

You should track any action that is important for completing a process with a measurable outcome, such as signing up for a newsletter or processing an in app purchase. If your team has a documented expected user flow, like a user acquisition funnel, then you should track each step along that customer journey. 

  • How many properties should I track?

Event properties describe the context of an event. User properties describe the user who performs an event. In both cases, too many properties can become unintelligible and are often unused. Events are capped at 500 properties, but we typically see no more than 100 properties per event. 

  • Should I collect data on the client or server?

User-initiated actions like page views, button clicks, social shares, and email opens are all typical client-side events. Things like UTM tags, operating system, device type, or cookie data are also easiest to track client-side. Alternatively, because it is more controlled, server-side tracking tends to be more accurate, so it’s best for events that contain sensitive information, such as payment data or personally identifiable information. Generally, client-side data is best used for understanding general trends, while server-side data is best for precise counts and calculations.

6 users found this helpful