Data is a core part of more than 80% of companies’ business strategy, according to a report commissioned by Experian. But 69% of the organizations surveyed believe their inaccurate data is holding back their ability to provide the best customer experience possible.

Many of their bad-data issues boil down to how data is tracked and how companies design and manage their tracking plans.

It’s not enough to simply take the first tracking plan template you see and run with it—even if it’s the world’s best template. You need to establish some best practices to avoid bad data (and see a return on investment).

The six following best practices will help you and your team hone in on the events and properties you need to measure success—and ensure your data is designed well enough to tell you exactly what you need to know about your customers and your product.

1. Elect tracking plan champions

Elect tracking plan champions to ensure there are dedicated experts on your team to pay attention to the design, enforcement, and improvement of your tracking plan.

These tracking plan champions—likely your product managers or data experts, for example—help ensure your tracking plan is well designed and complete from the beginning (pre-release). They will also work with each team to educate them on how to use your tracking plan to maintain good data and make sure these teams follow best practices over time.

It’s likely that, when you first start designing your tracking plan, you'll have a singular champion. But, as you aim to democratize your data and create self-serve analytics, you should expand your roster of tracking plan champions so multiple people can take on reviewing and approval tracking plan suggestions.

For example, while your pre-release tracking plan meeting should include a developer for each of your product’s platforms, other developers working on your project will need to know how to use and adhere to your tracking plan. Your initial champion will be responsible for going to each of your dev teams to make sure they understand how to use the plan to create good data.

Then, as your dev teams feel more empowered to make suggestions on how to improve your tracking plan, the leads of each dev team can step into the role of tracking plan champion to advocate for the ideas of their cohort moving forward.

In their final forms, these tracking plan champions will stay up-to-date on the business goals related to each product release and update your tracking plan as needed to keep it in line with company-wide OKRs.

To elect your first tracking plan champion, discuss early on who will be using your data most and who has the bandwidth to take on these responsibilities. This should be decided before or during your pre-release purpose meeting. Then, you can add on new champions as your plan progresses and team members feel more empowered.

2. Look for templates for your industry

We know we warned against just using a tracking plan template and calling it a day, but don’t let that turn you off of using a tracking plan template at all. They can be incredibly useful tools (and save you a ton of time up front).

Dozens of awesome data analytics companies have developed tracking plan templates that can help you out, especially if you’re early in your data analytics journey.

Tracking plan templates provide a sample of events and properties other companies in your industry often track, and give you a framework you can fill in to save time.

For example, let’s say you’re releasing a new line of products at an eCommerce company. The events and properties you’re interested in tracking—most related to how often users buy your new items—are different from those a SaaS company would be interested in. If you use a tracking plan template for eCommerce companies off the bat, you’ll have a head start on creating great data.

You can find most tracking plan templates for your industry by searching “[industry] tracking plan template” in your favorite search engine, or you can check out this roundup of our favorite tracking plan templates.

3. Establish naming conventions for events and properties from the beginning

Establish naming conventions for events so you can accurately compile and compare your data. This enables your developers to integrate tracking analytics consistently between platforms.

Naming conventions for events and properties are guidelines that you set in your tracking plan to standardize how developers and product managers refer to user actions and triggers. They’re important to both how your analytics are set up by developers and how your product managers read and interpret data on the other side.

In general, there are three components to event naming conventions that you should pay particular attention to:

• Casing
• Object and action order
• Tense

For example, if you’re tracking new user sign-ups, you would want all instances of analytics to track an event called either new_user_sign_up or user_sign_up or newSignUp. If any of those were mixed, it would cause compilation errors down the line (meaning more work for your data specialists).

When it comes to property naming, however, things aren’t always as straightforward. Property names describe deeper information on the action that was taken, which means there’s more opportunity for variance. To avoid confusion, make sure to continue to emphasize casing and stick to agreed-upon words to describe the most important things. From there, make sure your team is explicit in what each property is describing. For example: instead of naming a property simply “Product”, clearly label each property so that each person looking at it can see without a doubt what they refer to (e.g. “Product ID”, “Product Type” and “Product Name.”)

When you establish naming conventions for events and properties, you avoid having to manually match data points between platforms down the road. We also recommend sticking to the same kinds of words commonly used by your company throughout your plan to avoid duplicates.

To make sure you’re using standardized naming conventions for events and properties early on, sit down with your shareholders during your pre-release purpose meeting, and explicitly outline the language you’ll use in your tracking plan. During this meeting, confirm what the name for each event and property should be on every platform to prevent collection errors.

4. Track the most important steps of your most important funnels

You have an entire world of data at your fingertips, but, as tempting as it is, you shouldn’t collect it all. Instead, focus only on tracking the macro and micro conversions that matter most to the key funnels you care about. These are the ones that will tell you directly whether or not your customers find your product useful.

When you track only the data that matters most--that is, the conversions that directly map to the key actions your customers must take to convert--you save your product managers, developers, and data specialists time by reducing the number of metrics they need to pay attention to post-release.

These macro and micro conversions are the events that most directly tie into your organization’s overall KPIs. It’s important that they not be clouded in your analytics by unrelated user data. This is particularly true if you’re looking into why users aren’t converting (e.g. tracking signup and purchase funnels).

For example, if you're tracking customer sign-ups for a free trial of a music streaming service, you don’t need to track all of your customers’ listening histories at the same time. Instead, you’d just set up events and properties around plan upgrades, payment types, and successful status changes.

To ensure you’re tracking only the conversions that matter within your key funnels, talk with your data shareholders and map out your user journey to determine the key actions that customers must take to move from point A to point B.

5. Design action-based events and specific, consistent properties

Your events and properties should help you quickly and easily gain context on your data, no matter the platform your data is coming from. To accomplish this state of data bliss, you need to design your events to describe the action performed and your properties to be specific and consistent to what they’re describing across platforms.

This ensures that no matter who is looking at your data, they can understand the necessary context of what’s being measured across each facet of your product and your event tracking.
‍

For example, let’s say you want to track when your users complete signup. You should design your events to describe the action the user is performing by naming your event “Signup Completed” rather than “Complete Signup Button Clicked.” The former is much clearer, and helps the consumer of your data pinpoint the action that you care about: User signups. However, there’s a high probability that the copy of the button will change at some point. A better practice would be adding properties to the “Signup Complete” event that describes what the user interacted with to complete the signup, for example “Button Copy” and “Button Location.”
‍

Additionally, while you want to track similar properties across all products so you can compare user actions, you should consistently design your properties to be specific to the product they’re happening within. Taking another example, if you’re tracking certain IDs and categories across products, your properties should be named “[Product] ID” and “[Product] Category” instead of just “ID” and “Category.” This helps your future data consumers better parse your data when looking at information across platforms and products.
‍

When you keep your properties specific and consistent between platforms and products, you help your product managers—or anyone else looking at your data—gain and keep context about where in the user journey each event and property takes place. This makes it easier to understand the data.
‍

To design easily-understood properties for your product, sit down with your team for a pre-release purpose meeting--which should include developers from each platform--and map out the user actions that support each event and identify the commonalities between each. These are the properties that you should track.

6. Use a tool like Avo to manage your tracking plan

You could create your tracking plan as a Google spreadsheet, throw all your code into one of the columns for each event and property that needs tracking, and manually link all your shareholders to it as needed. But that sounds like a lot of (unnecessary) work to do every time your analytics needs implementing.

Instead, use a tool like Avo to manage your tracking plan.

While a spreadsheet is a great place to start, smart tracking plans like Avo make your data quality much more scalable. Avo helps you create a single source of data tracking truth. With it, you can use a central app to track events and properties and send implementation instructions to developers.

This makes it easy for you to quickly create and update your tracking plan, collaborate with team members, and give developers the instructions they need to keep tracking consistent and data helpful.

To get started, check out Avo today.