How to Turn Your Analytics Tracking into an Ongoing Collaborative Process

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

We all know that any organization building digital products and services will collect data. We also know that just collecting data is not the same as actually using it effectively. Even if you have an amazing tracking plan in place, supported by a strong toolkit, your strategy will fail if you don’t take the time to engage in one key thing: collaboration.

Analytics touch everyone in a data-led company

Think about building a new feature for your product. There are two main considerations at play here: what new data points will this feature bring in, and who are the audiences for those data points? Well, if you truly want to make data-driven decisions, more or less everyone will be an audience for your customer data.

The key stakeholders involved in analytics tracking will all bring their unique ideas and expertise to the story—a healthy mixture of domain knowledge and technical know-how. We’ve got:

• Executives/leadership
• Product managers
• Analysts/data teams
• Developers

Each of these teams will have their own distinct tasks and goals, but ultimately they will be working from the same tracking plan.

Tip: Having too many cooks can be a nightmare—read this post to learn more about who should own the tracking plan.

How these teams (should) collaborate with each other on analytics.

Executives/leadership

Let’s start with the team(s) who will want the most high-level view of event tracking. When building a new feature, the executive will care most about what the goals of this new feature are, and what metrics will be used to measure success.

That means teams working beneath the leadership need to be equipped to do some high-quality reporting. A good leadership team won’t want to make important decisions about the future of the company based on hunches—they’ll want hard proof of what works and what doesn’t.

Key collaborative behaviors of this team:

• Leadership should be working the hardest to inspire collaboration throughout the organization, and fostering a culture that understands the value of data-driven decision making.
• Celebrate successes that were born out of making decisions based on data.
• Crudely, if your manager doesn’t care about good analytics tracking, then why should you?‍

Product managers

Product managers know your product intimately, and how it sits in the market/industry. They are responsible for shipping this new feature, and as such will be looking to turn those metrics that the leadership cares about into actual events that they want tracked. In order to build reliable reports on this new feature, event tracking needs to be built in from the beginning.

While a product manager is armed with a great deal of domain expertise, they may not have the technical skills needed to define the tracking plan themselves. This means they have to collaborate with other teams to get the job done. A good product manager is less likely to dictate a list of events they want tracked, and expect perfect reporting to result from that. Instead they might discuss and agree on what’s possible with analysts and developers, as these are the teams that will be implementing the tracking plan and building the reports.

So product managers will know what metrics are important, but may rely on others to turn those into trackable events. They will be instrumental in asking the right questions of the data, deciding when to A/B test, and creating appropriate feedback loops: looking at the performance of prior decisions, and iterating on those.

Key collaborative behaviors of this team:

• Regular check-ins with analysts covering what events are being tracked and why, and keeping everyone on the same page with taxonomies and naming conventions
• Working with developers to determine what changes to the tracking plan need implementing, and if those changes are possible given the infrastructure and how long it would take to do it
• Making sure they provide feedback to leadership with high quality reports

Analysts

Your team of data analysts are like the company’s central hub for reporting. They are most likely the ones who get their hands on raw data first (possibly the only ones). They will work to join, model, and visualize the data. They help turn the data into insight.

An important note on the analyst team: they should not be seen as an organizational resource, i.e. the “people to ask” when you need something data related. If this is the case, analysts may find their capacity is taken up with fulfilling daily requests from other teams, as opposed to actually building insights and generating meaningful reports.

Part of the analyst’s collaborative process is to enable other teams to self-serve as much as possible. A basic example of this might be working with product managers and marketers to build predefined queries into a tool like Tableau, so that the most-asked questions can be answered at the click of a button. Product and marketing teams can also use a self-service digital analytics platform like Amplitude to build charts and analyze customer behavior on their own.

Key collaborative behaviors of this team:

• Working with product managers to understand more about the people behind the data: they can work with abstract data, without knowing much about end users, but will be all the more effective if they have a greater understanding of why this data is important
• Facilitating challenging conversations about what questions are most helpful to ask of the data, and what other teams want tracked (e.g. know when to push back if teams are asking to gather more data than is needed)

Developers

Of course, the developers are the ones that are actually building the product, and thus implementing your tracking plan. Technically speaking, a software engineer doesn’t have to know much about the industry you’re operating in, or about end user behavior. This isn’t true across the board, and has led to the assumption that developers don’t care about analytics.

In actuality, an engineering team may struggle to get on board with analytics in a meaningful way if there is no systemized collaborative process in place. When building a new feature, receiving a spreadsheet of which events to track can be frustrating because it’s a huge disruption to workflow. Switching back and forth between an IDE, a spreadsheet, and a Jira ticket is cumbersome, and very easily leads to errors and inconsistencies.

Good developers are much more likely to care about how the products they build are performing—they also know more than anyone how the product actually works, so are best equipped to implement the tracking plan in the most effective way.

Key collaborative behaviors of this team:

• Making sure product managers understand the limitations of their products’ infrastructure, when and where tracking is appropriate, and how long implementation might take
• Working closely with analysts to build data and analytics pipelines, and making sure everything is going where it’s meant to go
• Helping all other teams understand that to track events effectively, they need the time to build tracking into features right from the beginning, not as an afterthought

Fostering collaboration around analytics tracking

With this broad understanding of how teams can work together on analytics tracking, it should hopefully be easier to start developing a collaborative process. It’s quite clear that if everyone is working towards building and maintaining the same product, cross-team communication is going to be extremely important.

Start thinking about your analytics as a key design point in the backend of your product. It’s not just something you tack on once you’ve shipped a feature, but an integral part of the SDLC.

Many companies, especially in the tech industry, will already be comfortable with using collaboration and knowledge sharing tools like Jira, Slack, and of course, Amplitude. If you’re passionate about adopting stronger collaborative processes in your organization, we advise that you build your case to the willing. Getting buy-in for new processes is often the hardest part.

There’s no need to reinvent the wheel. Apply existing processes that already work.

Quite often, adopting new processes (such as collaborating effectively on analytics) has almost nothing to do with technology and everything to do with culture. When it comes to analytics, knowledge will not exist in a single person or team—everyone needs to work together to get the most out of your data.

It’s important to note that no one will adopt a new process (no matter how good it is) unless they see the point of it. Practically speaking, a great way to get company-wide buy-in on a new process is to demonstrate the value of that process, by comparing it to other pre-existing ones. A couple of examples:

GitHub: I don’t think I’d be overstating anything if I said that practically every person/company/organization that is building software, uses GitHub. It’s a very elegant, but hard-coded, process: every piece of code written is subject to branch, commit, and merge. So Github is actually less like a tool and more like a process: it simply wouldn’t work if everyone didn’t use it.

Figma: a tool which perfectly demonstrates seamless cross-team collaboration; Figma enables product designers to hand off prototypes to developers that clearly show how all the elements fit together. Tip: Use the Amplitude Event Planner in Figma.

Amplitude is here to help you collaborate

It’s useful to think of Amplitude’s data governance features as GitHub for your analytics. Amplitude facilitates a transparent, auditable process around event planning that every key stakeholder can be involved in regardless of technical ability.

The best processes are the ones you don’t even notice: we have developer tooling so that no one’s workflow is disrupted, allowing engineers to easily and accurately implement analytics tracking with type-safe, open-source SDKs, a CLI and CI/CD integration.

Amplitude is first and foremost a collaborative platform, enforcing a reliable source of truth for analytics. This means that those who consume the data know that they can trust it. If you’ve achieved significant buy-in for new collaborative processes, Amplitude can certainly play a part in supporting that. Request a free demo and start your exploration today.