Who Should Really Own Your Tracking Plan?

Editor’s note: this article was originally published on the Iteratively blog on January 11, 2021.

“Data is a team sport” is something we believe strongly in and talk about often at Amplitude. Analytics tracking plans are no different—tracking plans (and the instrumentation of them) are collaborative by nature. They work best when the relevant teams come together.

Let’s take the example of a new feature release. The product team has defined the goals and metrics for this new feature and will have a view of what event tracking is needed to measure those metrics. The iOS, Android, and web development teams are responsible for instrumenting (and ideally testing) those events in the code and will have an opinion on what’s feasible. An analyst or analytics engineer is responsible for modeling the data and will care about its structure, and you might have several teams responsible for building reports and analyzing the data in several tools. In short, in data-led company analytics involves almost everyone.

The example speaks to how complex analytics tracking really is and it also speaks to the importance of collaboration when defining and capturing the right events, implementing those accurately and making it easy for data consumers to explore the data. That said, with so many people involved, analytics tracking easily becomes a hot potato.

If it’s owned by everybody, it’s owned by nobody

With that many stakeholders involved, the tracking plan often becomes a shared responsibility, without a clear owner. And with shared responsibility comes little accountability.

We’ve talked to a lot of companies who want to (re)create processes around analytics tracking. It usually revolves around a spreadsheet or a Confluence or Notion page. While it’s mostly manual and there’s no way to enforce the tracking plan in code, it proves useful in the beginning and forces teams to think more about event tracking.

However, a few months in, the Notion page or Google Spreadsheet becomes outdated: tracking for the latest release was only documented in a Jira story and for a few other feature releases it’s now unclear whether tracking was implemented or not. No one is making it their responsibility to keep the tracking plan up-to-date.

So, how do you change this for the better and who’s best placed to own your analytics tracking?

Start by putting analytics front and center

Before we dive into the question of ownership, we have to mention the foundation required for analytics tracking success: event tracking matters and without it you’re left in the dark. The reality is that for most teams analytics is an afterthought. Here’s an example we see all the time:

• PM works on a release
• Release happens
• CEO asks the PM how it’s performing
• PM: “Let me ask data team”
• Data team: “You never brought us in—there is no data on this feature.”
• PM goes back to the CEO with no answers
• Data team and PM are distraught

If analytics does not become an integral part of every release, this will happen over and over again and it does not matter if your tracking plan is looking really slick and up to date. You need buy-in from all stakeholders (as well as from your leadership teams) that analytics tracking is just as important as the feature itself. No tracking, no release.

You need clear accountability, time and resources to empower the relevant teams and then you need to embed event tracking and success metrics down to the Jira ticket level (done is only done when tracking code is shipped along with the rest of the code).

What we’ve learned from over 400 interviews with data and product professionals

In two years we interviewed over 400 product managers, data teams, and engineers. We’ve seen some things.

Of course, your tracking plan and the process around it is unique to your business, team structure, and vertical (and that’s probably why it’s so hard to get right). A tracking plan for an ecommerce company will look very different from a tracking plan for a B2B SaaS company. They have different stakeholders involved and solve for entirely separate realities. Most commonly, we can break down what we’ve seen by company size.

Startups

For small companies, the process around tracking is usually ad hoc. It’s natural as very few people are involved and makes the complexity easy(ish) to manage. Most often, we see a head of product or a head of growth take ownership at this stage in a company’s journey.

SMEs

In a medium-sized company, the process typically falls on the head of data/analytics. There are more stakeholders involved now, and the complexity can easily become an issue. At this stage there is a definite need for ownership to limit damage and usually that falls on someone in the data team.

Enterprises

In larger companies, the person ultimately owning the tracking plan will usually be the head of product analytics. For ecommerce companies, it will often be the head of ecommerce. Oftentimes they won’t be the actual day-to-day person maintaining the plan or enforcing the process, it will be someone within their team who’s responsible.

We’ve seen various degrees of success from these types of setups. So, what do we think works best?

What works: The product team is the ultimate owner

This is what we know: The best ownership process happens when the product team acts as the ultimate owner. Product managers should be the main driver and ensure analytics tracking is part of every feature release. Depending on your team size, this could be one or more product managers or a dedicated product analyst. They should be held accountable for analytics tracking as a part of their role and OKRs.

But as we mentioned earlier, data is a team sport and we recommend teams come together to define things like event naming and taxonomy. Engineers and data teams will have important perspectives as this influences their day-to-day too. While the product team is the enforcer and ultimate owner, they should never work in a silo or make important decisions without involving the right stakeholders.

Setting up an advisory board that represents all the relevant stakeholders has worked well for companies we’ve worked with. Not every decision goes to the advisory board but they should be the driver at the beginning, defining your taxonomy and process and meeting regularly depending on how many breaking changes happen over time.

For product teams to successfully own this you need a clear process in place:

• Have clear success criteria for both qualitative and quantitative metrics as a part of every user story. These should be defined by the PM and sparred with the data team or analysts.
• Missing tracking? Fail the build. The notion of done needs to evolve to include analytics tracking as a part of every release. This doesn’t mean blocking releases right before launch, it means implementing a process that includes tracking considerations from the start.
• Collaboration is key. While the PM will own the event tracking spec, the data team or analysts should be available to step in and help define the detail of what should be tracked.

Empower your product managers to take ownership

For some PMs, owning the tracking plan comes as natural to them. They want the control and have the experience. And they’re also not afraid to ask for help when they need it. But it doesn’t come naturally to all PMs.

First, a culture change needs to happen: celebrate the performance and success of a new feature or product release, not the fact that it shipped! Surprisingly, for many it’s still the shipping that gets praise, not whether the product is performing or not.

So how do you empower your product team to own the tracking plan? This is not an exhaustive list but hopefully a place for folks to get started:

• Regular training: Getting event tracking right is as much an art as it is a science (i.e. it’s not easy), so ensure your team is empowered with the knowledge needed to comfortably take ownership. Training could be lunch & learn style, workshops or one-to-one sessions (remember to record your sessions for future hires).
• Office hours: We’ve seen great success when data teams host regular office hours for other teams to leverage the data team’s expertise and knowledge. Ensure teams come prepared with an agenda or specific questions to avoid it turning into a “support desk style” meeting.
• Clear process and check-points: We can’t stress the importance of a defined process enough. Make sure you have a clear process everyone knows about, understands and follows, and include regular review points to ensure quality, much like code reviews and merge requests in software development.
• Embed an analyst: This is not always an option, of course, but we’ve seen successful teams embed a data analyst in a product team either part or full time to own analytics tracking and help PMs with data exploration and analysis.
• Self-serve analytics: We think it’s best practice to empower PMs and everyone else in the organization to easily explore datasets and get answers to questions quickly. Amplitude is great for that and ensures high levels of data literacy across your company.

A reminder: good PMs don’t need to know SQL

Why care about event tracking if you’re not able to explore the data yourself anyways? To expand on the last point above, we’ve seen companies with central data teams who own all reporting and data analysis. It has its pros, but from our experience it can limit PMs and others and they will care less about analytics tracking or data quality.

Remember, giving PMs and others access to Redash or other SQL-based tools is not equal to empowering PMs to self-serve. Don’t expect your PMs to know (or learn) SQL. That’s not their job.Instead empower them with an easy-to-use UI and lots of training to go along with the tool and the datasets. Of course, SQL knowledge has its obvious advantages and if you’re able to find or train talent across the company (think product, marketing, customer success, etc.) you can make it work, but it has its obvious downsides and limitations.

If PMs are able to self-serve, they’re more likely to explore data from, say, a recent release. As they explore the data, they’re more likely to care about its quality, richness, and availability. Create a culture of empowerment and build a solid process around analytics tracking and you’ll have happy PMs, happy analysts, a happy data team and even happy developers.

Amplitude is here to help you

Amplitude helps data teams, product managers, and engineers define, instrument, verify and collaborate on analytics tracking. We proactively solve the data quality issues that arise from inconsistent event naming and missing tracking and provide a workflow for managing the evolution of your tracking.

We empower product managers to take ownership of the tracking plan and level up collaboration between teams. If you’re interested in trying out Amplitude for your company, create an account today or book a demo with our team to learn more.