DEV Community: Avo

How to Get Everyone in Your Organization on Board with Your Tracking Plan

Avo — Fri, 07 May 2021 14:12:47 +0000

Data-driven business leaders know data is their company’s—and their product’s—most valuable asset. But many of them don't know how this data is generated—and can't help improve how it's collected—because they don't understand the role tracking plans play in overall data governance.

A good tracking plan can mean the difference between unwieldy, hard-to-use data (too much or too little; inconsistent; full of repetitions or errors) and data that helps your organization steamroll its objectives. But you already know that. So let’s talk about how to help your stakeholders understand that, too.

A good tracking plan needs the input and buy-in from everyone in your organization in order to fully align with organizational goals and ensure data design matches them. To get your stakeholders bought into your tracking plan, you need to connect with them early and highlight how your tracking plan will help you collect data to improve your performance and product.

Don't treat your stakeholders as mere bystanders in this quest for good data. Instead, treat them as your teammates, as the supporting cast, and help them understand how and why they should participate in your data plot.

How to shape your tracking plan with your stakeholders

Reach out to your stakeholders early on in the development of your tracking plan to give them a chance to weigh in and influence the plan. A new tracking plan means change, and whatever its nature, no one likes to have change happen to them. Meet for 30 minutes with the owner of each business objective on which you’re basing your tracking plan. The point is to understand the motivation behind the objectives they care about.

One owner might be a CMO motivated by how your product is helping fulfill wider company KPIs relative to adoption rates or churn. Another owner might be a product manager looking to better understand how the feature they’re responsible for is (or is not) driving adoption rates. Other stakeholders may include product leads, engineers, and designers, as well as analytics, marketing, and sales professionals.

Focus on scheduling in-person (or, as is more advisable in present circumstances, virtual) meetings to explain how the tracking plan fits into your company’s data governance. For example, let's say one of your business objectives is to increase average session time in your product. In that case, meet with the product development lead associated with your product.

From there, don't just tell them what preconceived metrics will go into your tracking plan. Find out what data your product development stakeholder would most like to see. What data would best help them solve that recurring issue that gives their team headaches and reduces the quality of their output? Do they need more behavioral data? More qualitative data? Do they need to know more about feature usage or more about bounce rates in certain product areas?

The conversation should be open and two-way. Valuing your stakeholders' ideas and taking their concerns seriously is vital to building a high-functioning tracking plan and building trust in that plan. Trust, needless to say, is an essential component of buy-in.

One-third of the American workforce feels that management officials don’t value their ideas. Your stakeholders should not figure among that number.

The plot treatment: Connect the dots between tracking and objectives

During the early stages of your tracking plan, it's vital that you're demonstrating how that plan will help fulfill stakeholder objectives.

The first step is to be honest about the impacts of inaccurate data. “But,” we hear you say, “isn't inaccurate data what happens when there's no tracking plan in place at all? Stakeholders will be free of having to worry about inaccurate data with this shiny new tracking plan, won't they?”

That's mostly right, and that’s the point you need to convince your stakeholders of. Remember that bad data costs US companies between $9.7 million and $14.2 million annually. It also costs stakeholders gray hairs and sleepless nights. Along with your tracking plan, you’ll also need some way to enforce data governance after its original implementation. But that’s another story for another time.

Once they understand the importance of their stake in your tracking plan, you can discuss how the data you collect will help inform better business decisions to align with these goals.

During your first meeting, identify which business objectives each stakeholder cares about and explain how your tracking plan's events and properties provide support. For example, if you're meeting with product designers, they might identify their principal business objective as “creating a UX that drives more conversions to our premium subscription tier.” An engineering lead might have an objective like “better understanding patterns of search within the product interface.”

Then, with that knowledge, you can demonstrate how your tracking plan will help your designer achieve their objective. It might help them spot premium-ready user types better. You can show your engineers how your tracking plan could help them develop an inventory of search requests and understand which proportion of users is finding the answers to their queries, and which proportion isn’t.

The build-up: Writing the first chapters of your data story

Now that you know what motivates your stakeholders, the fun can begin. To get stakeholders to buy into your tracking plan and feel like it's not just another box to tick on the journey to deployment, you need to set the stage for the kind of story that your new, clean, well-sourced data lets you tell.

Crafting this data story makes it clear to stakeholders how they stand to benefit from maintaining your tracking plan. All of a sudden, helping to develop and use a tracking plan is no longer something stakeholders simply "have to do." It’s something that directly and obviously benefits them.

Once you've identified which business objectives your stakeholder cares most about, work through an example scenario that shows the stakeholder how they might use data to uncover product changes that support better performance post-deployment.

For example, you may have data demonstrating a high bounce rate between your dashboard and your secondary features. This will allow your product development and design stakeholders to streamline their UX. They might implement clearer labeling or redesign on-page buttons to ease passage down the activation funnel. They might go further, reassessing how attractive those secondary features are to your users.

The adventure: Keep engaging stakeholders as your data plot develops

Getting your stakeholders on board is half the battle. The other half is keeping them there. To keep your stakeholders on board with your tracking plan, you need to continue to engage them after the first meeting by giving them updates on your product's performance and letting them know how you're using data to improve it. After all, the thing that will guarantee your team stays onboard with your tracking plan is evidence that it works.

Schedule two or three follow-up meetings with each of your stakeholders, at regular intervals, after deployment. These could fall at time intervals (e.g., a week, 30 days, 90 days) or relative to project milestones (e.g., go live, first product update, second product update, etc.).

For instance, you may wish to meet with your marketing stakeholders at 30, 60, and 90 days following deployment to consider how your tracking plan helped them target and convert the correct buyer personas. You could meet with your engineers and designers a week after each successive product update to review how your tracking plan's information positively impacted their previous round of development choices. This provides an excellent opportunity for stakeholders to add new knowledge and perspective to your tracking plan after your product release.

There are bound to be twists in your data plot; you may not get everything right in the first pass at a tracking plan. (Hint: you definitely won’t, and that’s why version control and branched workflows are important to consider.) Staying dynamic and receptive to stakeholder feedback is crucial for an optimized tracking plan and stable buy-in.

Support your data characters (and tracking plan) better with Avo

Your stakeholders aren’t just non-playable characters in your quest for good data; they’re your comrades in the data battle. To get them excited about the adventure, you need to make it clear how your tracking plan maps to their goals and objectives.

The first step in doing so is good communication. Almost a third of all projects fail because of poor communication: misalignment of objectives, bad or nonexistent knowledge-sharing, and an inability of stakeholders to raise concerns or contribute ideas. Build your tracking plan from stakeholder objectives. Continually feed back the results of your tracking plan to them. It’s all fundamental to gaining and keeping stakeholder buy-in.

You need tools to help make that good communication happen. One of the best ways to collaborate on your tracking plan and make sure everyone is up to date on it is to use a tool like Avo. Avo helps you seamlessly share your data best practices, events, and properties with your team by creating a single source of data truth. With it, your team can look forward to more consistent tracking of manageable volumes of data and an easier route to making better product decisions.

Find out more and try Avo today.

Data Best Practices to Make Your Datasets More Convincing and Less Confusing

Avo — Fri, 07 May 2021 14:12:26 +0000

We all have that one friend who loves to tell stories that seem interesting enough but just don't go anywhere. And we all have that other friend who has the party eating out of their hand with their stories. There's an approach that convinces and an approach that confuses. It's the same for managing your company's approach to data best practices.

Data is the most influential factor in your company's operational efficiency. Robust, precise data, collected diligently and with purpose, can improve team performances across the board and allow you to put out better products. Flawed data, haphazardly collected, can mire your business' day-to-day in confusion. Doubling down on data best practices will help you get on the right side of the convincing data/confusing data divide.

We spoke to Paul Joyce, CEO of Geckoboard, to figure out how his company goes about maximizing the value of its data.

Data That Convinces Is Free from Potential Stakeholder Bias

The most common cause of confusing data is a stakeholder’s bias for their own data needs in collecting or interpreting data. Data best practices for warding against this involve building a data strategy optimized for your entire company’s needs.

All data has to pass through someone’s hands before it can be used. As a result, there’s no such thing as entirely “neutral” data. Paul explains that "[in data], there is an editorial process. There's a curation that happens. Somebody in the middle there is deciding what to [include] and what not to." Unless you have a robust approach to data strategy, centered around defined questions, you can end up with confusing data that has been shaped (either in how it's collected or how it's interpreted) by individual stakeholder bias.

There’s no such thing as entirely “neutral” data.

Your organization has an overall “intention” with data. This intention is led by the answers to questions relating to specific KPIs, like “What product factors are leading to churn rate increase?” However, this intention can get muddled when individual stakeholders — devs, product managers, marketing leads, etc. — are handling the data. Each one will have their own questions they need answered and may collect or interpret data differently according to these biases.

This is a sure-fire recipe for confusing data that makes sense to one stakeholder but is hard to use or unclear for the rest.

You can flood your organization with convincing data, reflective of whole-company intent, and avoid the pitfalls of stakeholder bias by building a multi-perspective data strategy. Your data management architecture and tracking plan should involve input from all your stakeholders.

A given data strategy and tracking plan might be geared around answering as many of your stakeholders' questions as possible. These might include things like:

What's our overall adoption rate?
How often are users on subscription plan x churning?
How often are users clicking on in-app upgrade prompts?
How often are prospects finding our product through voice or natural language searches?
What's our mean customer support response time?

By consulting with each of your stakeholders and figuring out what questions each of them needs to see answered by an ideal data strategy, you can create a convincing data plan that satisfies everyone’s data needs.

Data That Convinces Requires Clear Data Ownership

Ownership involves one person or a small number of people in your company taking responsibility for data storage and data quality management. It’s a direct route to convincing data. We've already noted the risk posed by misinterpretation, and for that reason, giving one person or a few people responsibility for data and data quality is high among data best practices.

Ownership does not mean limiting access to your data or confining its benefits to a few administrators. Your data should be accessible and of use to everyone in your organization, from your C-suite down to your junior sales reps. However, the more people responsible for handling your data, the more likely it is that mistakes will result in the form of unintended add-ins or redactions.

Paul sees clear data ownership as tied to data quality, as well as clarity. "[Ownership is] to ensure that the data quality is good...that the devs don't send the wrong events or the wrong properties or the wrong data types."

To ensure that your data is of the convincing kind, elect one or more people in your organization to have responsibility for data-based decision-making. Small businesses can afford to have one person with ownership of the data management process. Larger organizations with a higher number of stakeholder types or ones dealing with big data may wish to appoint multiple people.

Whatever configuration you go with, ensure your choices have high individual data literacy. They'll be handling things like standardizing file formats and file naming conventions for your data assets. They may also take care of data collection, data validation, and data protection.

“[Ownership is] to ensure that the data quality is good...that the devs don't send the wrong events or the wrong properties or the wrong data types.”

These will be the people in your organization with ownership of your datasets. This will allow you to engage stakeholders on their preferred input while keeping your data coherent and convincing.

Paul elaborated on Geckoboard's approach to data ownership, "For us, data is owned by a product and ultimately our VP of product. And so we sat down, and we discussed what the problems with our current data ingestion was, our event tracking and all of that kind of stuff...Unless [ownership and] communication is totally in sync there, there is sufficient room for interpretation and misinterpretation to come in."

Data That Confuses Comes from Inflexible Data Strategies

Data best practices call for continually reassessing your data management plan for flaws and areas for improvement. Best practices don’t stay still, and neither should you when it comes to your approach to maintaining data strategy.

Data that confuses results from an over-commitment to particular KPIs or metrics. The importance of your starting metrics may vary over time. For example, click-through rates from launch-period marketing material or seasonal ad banners will only be useful as KPIs some of the time.

As well as KPIs shifting, your target audience's behaviors and needs will change. You must prepare to amend and alter your approach accordingly. Paul loves this philosophy. "[I] think [this] is a more pragmatic, probably more realistic approach to getting useful data. I think embracing the chaos and the messiness is an important thing. We can't have this idea that all of our data is as pure as the driven snow; we should have reasonable skepticism around some of this kind of stuff."

To guard against inflexibility in your data strategy, re-evaluate it at regular junctures with your stakeholders and restructure accordingly. For instance, get together with your marketing personnel at 30, 60, and 90 days after a product launch and assess whether the data they're getting helps them make the process improvements they want to. They may be finding that your initially agreed-upon KPI (e.g., age and location of your prospects) is not giving them much to go on, and a change (e.g., to the professional profile of your prospects) is required.

“We can't have this idea that all of our data is as pure as the driven snow; we should have reasonable skepticism around some of this kind of stuff.”

Similarly, meet with your devs and engineers at regular intervals and analyze whether your existing North Star metrics are allowing them to gain a firm grasp of how well your product is working for your users. Let's say you're running a marketplace for sellers of bespoke goods. You may have started with "Monthly Listings per User" as your North Star only to find that "Time-to-Sell from First Listing" might prove a better bet. Time for a change in data strategy!

You can't chart a forward course with a rigid data plan. Stay flexible, and your data will prove more relevant and more convincing.

Gearing Up for Data Best Practices

One of the main things differentiating data that convinces from data that confuses is where that data lives and the tools used to handle it. You need to establish a single source of truth for your data.

Your data will come from various sources. Each stakeholder group may well have their separate tech stacks for gathering the data they need. Some of it might be in batch, some of it in real-time. To that end, tools like Salesforce CRM or Zendesk are great for acquiring specific data, but you then need a tool to act as a centralized knowledge store.

Avo can fulfill this role for your business. It offers seamless data integration and all kinds of elite data governance functions, from version history for your tracking plan to standardized events across platforms. It contains an automation for validating metric data, and it also comes with in-built solutions for tracking and maintaining your data quality.

Find out more and try Avo today.

3 Myths and a Truth from our CEO: What it Takes to be a Successful Tech Founder

Avo — Tue, 04 May 2021 15:26:20 +0000

We all know the conventional wisdom about founding a startup. If you're a tech founder, you must be working 100-hour weeks. You must be living a penthouse lifestyle and racking up Virgil Abloh-grade air miles. You must be looking to change the world (and change it now). And should be doing all of this as the solo, genius trailblazer.

But that’s the old way of doing things. While there’s certainly something to be learned from these myths of tech founder success, the future calls us to think more holistically, sustainably, collaboratively, and quantitatively.

No one embodies this new way of thinking more than our inspiring Co-founder and CEO Stefania Olafsdottir. So we wanted to share some of the advice she shared for tech founders on Mat Sherman’s at the Forward Thinking Founders Podcast, as well as the insights she regularly surfaces with our own team.

Stef has learned a lot of lessons in her time as a founder: How to prioritize user needs over world-changing ambition, achieve steady pacing over hyperintense work, network over going it alone, and, above all, drive your business to new heights with the help of good data.

Here, we’re featuring Stef’s thoughts around three myths of tech founder success and one core truth that drives her forward each day. And we won’t even make you guess which is which.

Let’s dive in.

Myth: Tech founders should focus all their day-to-day work developing their company’s product

Beneath the world-beating enthusiasm founders have about their companies, their primary job isn’t to solve the core problem that originally inspired their company’s creation. Rather, their job centers around solving all the problems that surround the mission of their company, so that their company’s vision can move forward unhindered (or, as unhindered as possible).

“You never really go home feeling 'I'm done for the day!'”

It’s probably obvious to folks that know Avo, but Stef is extremely passionate about self-serve analytics culture, data quality, data structures, and working with product people to turn insights into action items. But this isn’t what her day to day work is about anymore.

It’s mostly about all the other stuff: Making sure we don’t run out of money, making sure the people on the team don’t burn out, mapping out go-to-market strategies, and a lot more. There's always a fire somewhere. As she confessed on Mat Sherman’s Forward Thinking Founders Podcast, "You never really go home feeling 'I'm done for the day!'"

Stef believes that if you're going to spend your days fighting those fires, you need three things:

A versatile imagination
Conscientiousness in how you approach problem-solving
The ability to keep your head and help your team keep theirs too

As she said on the Forward Thinking Founders Podcast about the importance of a versatile imagination: "[To] help so many people solve the problem that you're trying to solve for them. . . . That involves a lot of different things." You need to raise money for your MVP. You need to gather a great team around you (more on that later).

On the conscientiousness side, you can't hope to solve your customers' problems unless you've taken the time to understand their needs. Stef emphasizes the importance of keeping communication channels with current customers open to make sure you’re satisfying their needs and that they're happy with the product you're building.

That conscientiousness should extend to things like data strategy, too; it pays to be careful. Being conscientious about communication with customers and the quality of your data strategy can fast-track you to success. It can also save you potentially crippling corrective expenditure. "Fixing terrible data will cost hundreds of thousands of dollars. . . . Communicating and quality assurance [before shipping] is key," she said on the Mat’s podcast.

Finally, when you're fighting all those fires, you need to be able to keep your head and help your team keep theirs too. Stef observed that a happy startup environment involves "everyone on the team being happy that . . . the list [of outstanding tasks and issues] is endless." Stef's own ability to keep calm under pressure has impressed everyone around her. "My husband . . . said to me, 'If I were dealing with this, I would be so much more upset than you are right now.' I think that sums it up; just keeping calm while the fires are going on."

Myth: The 100-hour work week is something to aspire to for the sake of success

(Almost) all founders have been there: Working 100 hour weeks to get the project you care about up and running. The 100-hour work week has become something of a tech mythos, but, as Stef can warn from personal experience, it’s not something we should aspire to.

Now, sometimes you can’t escape it, and there’s no choice but to buckle down and push through (if so, here’s a good guide to surviving it). However, backing off from glamorizing overworking is something that all founders should aspire to.

Stef is an apostle of "slow living" and remote working for lifestyle, productivity, and even environmental benefits. These things are crucial to clear thinking, balanced perspective, and being less wasteful in living.

Stef is intrigued by the slower, more mindful alternative. Many of us were brought up to value constant productivity and to enjoy the material benefits of a work-intensive outlook on life. However, the psychological and even ecological impacts of that lifestyle are becoming better and better understood.

Slower living, as an alternative, roots in remote work. As Stef observed, "The fastest-growing commute to work currently is actually not commuting." This is particularly true in the post-COVID-19 remote landscape, but the appetite for working remotely was growing even before the pandemic. There had been 400% growth in remote working between January 2010 and January 2020.

“The fastest-growing commute to work currently is actually not commuting.”

For Stef and Avo, that embrace of remote working is essential, even before the global shift to distributed work in 2020. "My cofounder and I work over a seven- to eight-hour time-zone difference," she said. "We are making the decision [to] create a fully remote company. And a lot of companies are doing that today."

For maximum benefit, Stef suggested that this new approach to thinking about work be combined with a new approach to thinking about life. "I think it's interesting to take that direction [of] remote culture and combine it with a slow-living culture," she said. With a slower pace of life, you "don't have to work as much also, and that fuels a slower lifestyle. As a result, you don't have to be as extremely wasteful in living."

Myth: Tech founders can continue to achieve great things alone on the mountain top

Being a solo founder can be great, but Stef is a firm proponent of the school of cofounders: “I don't know where I would be if I didn't have my cofounder.”

This is because, no matter how inspired you are alone, your ideas and vision can’t exist in a vacuum forever. Rather, your goals are made stronger--and more diverse--when they’re supported and improved upon by talented people.

This network of inspiring people offers you greatness. Stef quoted the adage: "You are the average of the five people you spend the most time with." The cultivation of a great network is something that Stef is passionate about and is an essential aspect of success, whatever your aims. You might have talent to spare, but you still can't succeed without other people's input, advice, and cooperation.

Stef emphasized that “greatness” is not related just to technical skill or business acumen, but to personality. Whether you're building a business, a house, or a relationship, the foundational ingredient of any grand plan is optimism. You can't do it unless you think you can do it. Surround yourself (and fill your operations) with people who have a can-do, helpful, and conscientious approach to their lives and work.

This is Stef's advice whether you are living in an existing startup hub, like San Francisco, or are thousands of miles away from one. Sure, it's easier to get started if you live in San Francisco, Boston, London, Berlin, or any other major startup hotspot. But there are a lot of professional social networks out there, allowing any aspiring founder to do the thing Stef thinks is most important: "Talk to another entrepreneur. . . . Surround yourself with people who are optimistic and people who are interested in taking part in such a journey."

“I don't know where I would be if I didn't have my cofounders.”

From there, build your network of collaborators and advisers to reflect your goals.

Truth: Tech founders should establish a single source of data truth for their companies

Your insights about your customers and product are only as good as your data. Tech founders, and their teams, need to invest in good data practices in order to get the insight they need to build great things. But, if your data is bad (or confusing), it unfortunately won’t fix itself.

Stef learned this lesson many times in the early years of her career as a founder. At QuizUp, she found herself having to choose between product delivery speed and data quality. This trade off wasn’t sustainable because as more features were shipped her team’s ability to gain insight into their performance got foggier and foggier with bad data.

To remedy this, the QuizUp team hacked together internal tooling to improve data quality and reduce engineering friction. These early solutions ended up saving the day (and the product) countless times down the road. But Stef wrestled with the same parable of data quality at her next company, Viska.

"I'll never forget the day when [at my previous startup QuizUp] I discovered our first data bug for our new product," she said. The data was incomplete and impossible to use. It was a devastating realization after so much work. "I was so, so disappointed; I would sort of say that I rage-quit the day. I just had to go home."

These data bug issues pointed back to the broader problem: The consequences of bad data never go away, but only get worse (until you deal with them). Building a digital product means always generating more and more data, which requires a proactive approach to data management.

"I [thought] this will never be okay; as long as I'm building a digital product, I will always be dealing with this," Stef said on the podcast.

In Stef's view, the key to eliminating the possibility of bad data is through the creation of a single source of truth on the subject. That's precisely why she and the team decided to create Avo. Suddenly, all those persistent issues with poor data, slow analytics, and tough collaboration were gone. Stef explained that, with Avo, "developers can implement their analytics faster because they get custom-generated and type-safe SDKs (bundles of software development tools) based on pre-agreed events."

She also emphasized the benefits for the customer. "Using this combination of tools, we are helping our customers keep up their product delivery speed while maintaining reliability in their data and insights."

And when it comes to facilitating productive remote work, Avo delivers the goods, too. It includes many collaborative features — branched workflows for parallel work, features for peer-reviewing, an implementation status feature — which facilitate collaboration and help make Avo that single source of truth.

“Using this combination of tools, we are helping our customers keep up their product delivery speed while maintaining reliability in their data and insights.”

Perhaps that was Stef’s most important piece of advice to tech founders. If you can’t find the solution to your problem, build your own!

Find out more and try Avo today.

A Developer’s Guide to Analytics Implementation & Testing

Avo — Tue, 13 Apr 2021 18:31:02 +0000

When working with data teams, spending chunks of our time chasing and squashing data bugs is no one's idea of a good time. Those bugs can have a huge impact on the whole product, even if they often seem insignificant, from a development perspective.

We spend so much time bug-squashing because we often find ourselves put in a reactive position by mediocre data management practices. It would remove huge time-wasters for everyone if we could proactively act on data quality. One way to achieve that is becoming a data stakeholder, a role that guides better workflows from the outset. Eradicating trivial data-quality issues allows all engineers on the team to spend less time chasing frustrating bugs and more time building worthwhile code.

We should follow implementation best practices; test and validate our implementation to make sure our code functions correctly, and our data is clean. This helps avoid rework down the road. So, if we’d rather create exciting new features than spend our time dealing with bad data and do-overs, here are the best practices for analytics implementation and testing to follow.

Caring about data analytics implementation and testing best practices saves developers time and frustration

When we care about analytics implementation and validation best practices, it prevents bad-data-mitigating rework later on. This saves a huge number of engineering hours that get wasted tracking down the error later — not to mention the frustration in trying to find what went wrong. Other parts of the company might also be waiting for corrected insights to make clear decisions, and they’re getting held up as well.

One of Avo’s customers is realistically expecting to cut engineering hours spent on implementing analytics by 80%, and that time-saving largely comes from not having to chase down these bad data-bugs anymore. This makes everyone happier — from the developer implementing tracking code to the product manager analyzing the data to the CEO making data based decisions.

Reworking represents a huge waste of time. Kirill Yakovenko, product manager at Termius, knows this well. Termius’ process for dealing with bad data was laborious and frustrating, before they started using Avo, of course.

“The problem with tracking mistakes,” says Yakovenko,“is that each fix takes time. It might take a month to roll out a fix for a single issue to all our applications and users.”

Fixing analytics issues didn’t just waste developer hours on the fix itself; it also delayed product decisions because insights are crucial to making the right product decisions.

Caring about data analytics implementation and testing best >practices help prevent bad data and rework later on.

Analytics implementation and validation processes often aren’t something we consider when we think of testing code because it hasn’t traditionally been a part of our main codebase, nor is it part of our job to design. But caring about data analytics implementation and testing best practices helps prevent bad data and rework later on. As more businesses recognize the importance of online business as a primary revenue source, data insights are important as ever, and product analytics solutions like Amplitude and Mixpanel are becoming more critical.

When trying to implement analytics, many developers report:

Incomplete implementation instructions
Systems that were designed with data as an afterthought
Long feedback loops of the correctness of their implementation
Multiple streams of feedback from different stakeholders

On the testing side, we, and data teams, often don’t prioritize testing our code to make sure we’re not putting garbage into our data systems. Testing is time-expensive, complicated, and easy to get wrong — making it low priority. Low priority generally translates to no testing at all, which means that code either ships broken, breaks during a later update, or ships without analytics altogether 💀.

However, it’s important that we take an active role in analytics implementation and testing best practices to help make our data teams and our own workdays more efficient. After all, it’s much easier for us to fix data through testing these best practices at the source than it is to make corrections downstream, especially if we’ve already shipped.

Removing the frustration around data tasks, and recouping development time by tweaking these processes is valuable. Fixing bugs can take us as much as 30x the amount of time to fix later on, if not caught early. Developers within our own network report that up to 30% of issues for a single team are analytics bugs. We can slash that number down to size with these best practices in the bag.

Here’s how.

Five best practices for analytics implementation and testing

These five practices make your analytics tests and implementation more efficient and consistent. Your code can be implemented quickly, without taking shortcuts or trading accuracy for convenience. In other words, you’re beating the builder’s paradox. Think of the efficiency as the “human” process side to data testing and implementation. Easier replication of the same process or request while having clean code on the other side of that replication creates consistency. Think of the consistency as the “code” process side to analytics testing and implementation. Breaking best practices down into matters of efficiency and consistency means you’ll be able to reap the benefits of attending to analytics implementation and testing — less time spent on frustrating re-work and bugs, and more time spent on your regular development workflow.

1. Request full implementation specs every time

Request full implementation specs from your data team or product manager every time, so you know where the code goes in your codebase and what the goal of implementing it is.

The main obstacle to straightforward implementation is that we often get ill-defined data from our product managers. Sometimes, this results in stop-gap solutions that work “well enough” but require rework later on. Other times, it generates a lot of tiresome back and forth on how to implement:

The devs handle implementation as they think it should be done.
The PM comes back to the devs with something else that they’d prefer.
The dev redoes the same work.
The cycle repeats until mutual satisfaction/breakdown.

Holistic specs makes implementation and testing more efficient by preventing confusion around necessary actions. Everyone is clear from the jump, and no back-and-forth is needed.

Additionally, these guidelines for implementing your code help ensure that all tracking is consistent between multiple platforms each time.

2. Consolidate feedback into a single source of truth

Consolidate feedback into a single source of data truth that the data team can comment on and answer questions around before the code goes to production. This involves the creation of a draft branch — or a draft version for JSON lovers — of your changes in your event analytics software or your tracking plan.

Consolidate feedback to ensure that it remains directed and issue-oriented. This also allows you to gather feedback in the specific context of the suggested changes. That way, everyone can see exactly what will be changed and can give feedback on it.

Feedback can come from anyone, other developers, data analysts, and product managers who all have something to say about your approach to data analytics implementation. This feedback is often ad hoc, making it difficult to track the narrative of the changes needed or questions asked. This is especially true if you don’t have a solid tracking plan and your teams are siloed.

When you consolidate feedback into a single source of truth it increases implementation and testing efficiency by creating a single environment (e.g., a shared doc or an easy-to-use tool like Avo 🙌) in which you can surface questions. Not only is it easier to have the relevant context then and there with descriptions, but your data team can be pulled in to answer any questions that might come up. When your data includes all relevant information that’s accessible to all stakeholders at any time, you can expect to see rapid turnaround on required changes and track any conversations about the particular changes made and the conversation about those changes.

Maintaining a single source of truth also helps consistency by giving you a chance to flag issues that arise during testing. Your data team, meanwhile, gets an equal chance to flag an issue with downstream data if/when they come across it.

3. Embrace versioning and test environments

Embrace versioning and test environments so you can test for analytics implementation errors before that code causes problems in your codebase out in the real world. Faulty code during the product cycle is bad enough, but faulty code in your released product can negatively affect customer success and, by extension, your business’ credibility. For example, if you’re in a commerce business, I can tell you that you will not want to be the developer on call (or on the hook!) for an analytics break during the Black Friday rush.😬

Development moves fast, and in the interest of time, testing environments and versioning for analytics specs are either non-existent or weak. Instead, the focus is squarely on getting to market in good time, i.e shipping fast. As a result, plenty of teams ship a product only to find out downstream that there’s an issue.

Devoting attention to versioning and test environments increases the efficiency of your implementation and testing by solving problems at the source. When you scan for errors at the source by using versioning and test environments that work by comparing your product against a golden/ideal dataset and a copy of your production dataset, you can clearly see where improvements are needed. You can make them in real time and then press on with development. So long, rework! 🐬

Following versioning and test environment best practices also helps with consistency by incorporating them into your standard product development cycle. It becomes the default. Having a set process for testing your code before it goes to production will help you avoid inconsistencies in implementation before it’s out in the real world. Or, as an Avo user puts it, “Fewer stupid errors with analytics.” As a result, you will consistently be able to release bug-free products that perform better, rather than chasing errors down the road.

4. Map data dependencies and lineages

Create an ecosystem for mapping downstream dependencies. Knowing how updates or changes will affect dependencies ensures fewer breaking changes are made. It will also create an environment that fosters communication between teams responsible for dependencies throughout the project.

You’ll gain a better understanding of why you’re implementing specific data, and you’ll have a higher stake in the success of capturing and maintaining that data. You’ll also know who to contact if any changes you make cause issues in an important metric or campaign.

Data implementation is often carried out by devs who have a lot of other demands on their time, so they optimize for getting it done. Code goes to production without checks. This is not only a problem in and of itself — as analytics tracking builds on inconsistent implementation, the quality of the data suffers.

When you have a better understanding of why data is being implemented, you can see how the work you’re doing is integral to heading off instances of bugs and misaligned code down the road. Not only will this cause less frustration for you, but your data team will thank you, as well as anyone who depends on the insights produced. This is anyone from marketing, product, even up to VP or executive level.

Mapping dependencies and lineages ahead of time cuts down on rework and headaches that are inevitable down the line when data quality practices are poor. You can paint a representative, upfront picture of what dependencies exist in your code. Testing will then reveal any issues arising as a result of those dependencies before you’re in production. Data produced this way is tracked and tested, and therefore correct, and uniform downstream.

5. Use the right tools to make your life easier

There’s a reason the next big thing in analytics is data governance. What has been a frustrating and error-prone process is now being solved with made-for-purpose analytics governance solutions. Instead of just using manual tests, finding the right data analytics tool can streamline your testing and data management and increase your data quality. This allows you to spend more time on the code you enjoy building, and less time squashing analytics bugs.

Avo is made so your data implementation is seamless. Your whole team has access to a single source of truth where data specialists can send clear, explicit implementation instructions to developers for each platform. Developers love it, as what that means in practice is: “Goodbye guesswork when implementing code!”

Using a type-safe tool like Avo increases your efficiency as you no longer need to write explicit data tests every time. Instead, you immediately see if the app is getting the expected data or not. Avo can be used in unit testing as part of your full test suite. This makes it easy for you to test analytics functionality without going too far out of your way. Here you can see an example of how to initialize Avo in a jest test environment with JavaScript.

Tools like Avo are great for your operation’s consistency. Avo’s type-safety means that, unlike a lot of other data analytics tools, you won’t have to troubleshoot your event names and metadata based on syntax. With Avo, you can trust that it’s right every time.

Data analytics implementation and testing best practices are important— and they don’t have to suck

Without any kind of optimization, analytics implementation and testing is a laborious and unappetizing process. By following implementation and testing best practices you’re saving yourself from a magnitude of data bugs and unexpected code re-work. Good news! There’s a tool to help you with this. 🥑

Having Avo in your tool stack minimizes the amount of valuable time required for implementation and testing episodes. It can eliminate the need for manual testing entirely. In a time when both quality and speed to market are more important than ever, trust you’re building a better product. Try Avo today to make analytics implementation a breeze for you and your team.

How Avo Does Tracking Plans: We Pull Back the Curtain

Avo — Tue, 23 Mar 2021 14:11:22 +0000

OK, we’re going to get a little (or a lot) meta with this one. We’re going to pull the curtain back and tear down how we do tracking plans.We help you create great tracking plans, but our own process around them is a healthy mix of best practices and practical improvisation.

But before we dive in, let’s a look at the tour de tracking plans we’ve rolled out in the last month.

Hint: If you’re new to tracking plans, we recommend checking out our foundational pieces and then coming back to this article.

So far, we’ve looked at:

Why tracking plans are important (Who can forget the Bad Data Day?)
Who should be involved in tracking plan dev
A worksheet on tracking plans
Essential tracking plan events and properties
The official Avo template for tracking plans
A roundup of our favorite tracking plan templates

You ready? Let’s get started: Here’s how we (ideally) create Avo’s tracking plans.

Full disclaimer: We don’t always practice what we preach, and, truthfully, there are times that you shouldn’t either. As the old adage goes, you have to know the rules in order to break them (and anticipate the impact of doing so). Once you dial in the practices that we outline below, you can start bending the rules a bit to find the right mix to create the best data possible for your use case.

We kick off with a purpose meeting

Pre-release purpose meetings ensure that everyone’s on the same page. They’re kind of like meal planning for your data. Imagine trying to plan dinner with a group when nobody can agree on an entrée. If you just wing it, you end up with duplicate dishes, too much of one ingredient, or too little of another.

But if you consider these 30-minute meetings your chance to meal prep, you can sort out all your priorities and needs to have a hearty data feast, with none of the drama.

Like all good recipes, these meetings come down to a few main ingredients. Each of which builds on the last.

Topics are the main course of your purpose meeting 🥘

The key to a successful purpose meeting lies in establishing the topic your meeting will be about. If you don’t have common topics identified for the team to focus on, you won’t have a foundation to build your goals and metrics on.

Instead, by defining topics early on, you anchor your purpose meeting behind a common vision.

Let’s look at, for instance, our purpose meeting for our Publishing functionality, which lets you configure Avo to automatically publish your tracking plan to your analytics platform of choice. When we did our initial purpose meeting for this feature, we established three topics:

Making Publishing available to the public (it was previously behind a feature flag and wasn’t super easy to find)
Making Publishing hackable (so that you could use webhook functionality to post to your own end point)
Automating the publishing of tracking plan changes to integration so that your plan was updated via the merging of a new branch

Our three topics were the main dish of our tracking plan, which would be complemented by all future additions. After we set them, we were able to create context around our OKR of helping companies keep their ingestion time validation tool (e.g. Lexicon) up to date and drive more relevant goals later on.

Before you can get to your delicious data dessert (goals), you have to make it through your vegetables (problems).

Problems are your hearty side dishes 🥗

The second part of your purpose meeting should focus on identifying the problems that you and your product are solving for. After all, if the data you’re measuring isn’t focused on the challenges your users face it’s difficult to know whether or not you’re actually delivering value and making their lives easier.

To use our Publishing example, during our purpose meeting, we identified the following key problems our users faced with the existing integrations functionality:

People forgot to manually publish existing functionality because it wasn’t automatic (this meant data was out of sync).
People had a hard time finding the functionality because it wasn’t visible, and they had to manually request it from the Avo team.
Tracking plans stayed stuck in Avo if customers weren’t using Segment, Amplitude, or Mixpanel.

Once we understood these three problems, we could start setting goals around what “success” looked like.

Now, after we’ve devoured your topics and wrestled with our problems, our team gets to tackle our favorite part of the data feast: dessert (aka goal-setting, for you less-food-minded folks).

Goals are your delicious data desserts 🍰

The goals we set during our purpose meetings help us define success throughout future iterations of our tracking plan. They’re unique to the features and product we’re working on and always map back to the problems we’re trying to solve.

Our goals are typically focused on how we can reduce friction to help customers better understand and leverage their event data. For our Publishing example, this translated to goals that looked like the following:

Making Publishing discoverable and easy to set up
Making Publishing feel safe and secure
Ensuring that tracking plan dependencies were always up to date
Allowing developers to build custom services on top of their tracking in Avo

After we identified these goals, we got to work on designing our data. We always recommend identifying metrics during those purpose meetings and even the events and properties needed to construct the metrics. This is where we sometimes break from our own sage wisdom. 🧙

We sometimes don’t go into metrics in this meeting and usually don’t get to the events; instead, our developers take the insights from our purpose meeting and collaborate to design data with data experts post-meeting (but pre-release). This approach lets us focus our purpose meetings on big-picture goal-setting (and helps our devs avoid sitting through meetings they don’t necessarily need to attend).

We design events for the start and end points of a user’s journey

To capture the entire user journey for our features, we start by identifying the first touchpoint a user will have with our feature, as well as their final “completed” action.

It’s tempting when tracking user actions to focus on the final conversion that shows you whether or not someone has successfully completed their journey. But this doesn’t give you all that much insight into everything that happened leading up to their conversion (or what happened to the folks that fell off before they finished).

Clearly identifying both the start and the finish of the user journey for each feature lets us compare how many folks entered from the front door, how many left through the back, and how many got stuck wandering in the UX house.

Instead of lumping events together, we focus on creating starts and ends of user actions so we frame the user journey and can get a clear picture of how folks move from point A to point B. This is especially important for flows like sign-ups, logins, games, and checkouts.

For example, in the case of the Publishing flow we outlined above, we could have just created an event for “integration published,” right? Well, yeah. But it doesn’t tell us how a user got there, or if folks might be dropping off. So, instead, we created two events that show us how the user is progressing: one for when they initially click “Add Integration” and one for when they hit “Publish to Lexicon/Govern/Protocols/Webhook” and get value out of the feature.

By clearly defining the start and the end of the user flow for our Publishing feature, we can begin to see how folks interact with our funnel, and how many are falling out of it in the process.

We fill out our user journey with the events and properties that matter most

Users do a lot in our product. They can create new tracking plans, change configurations, add comments to branches, change individual values. All are important for the user experience, but we don’t necessarily want to track all this data all the time. As we’ve said in the past, more data isn’t necessarily best.

Instead, each time we design data for a new tracking plan, we identify which user actions matter most in the user journey and then track those. The process of designing this data starts with the beginning and the end of the funnel, as we talked about above. Then, we walk through our feature as if we were using it and pinpoint which actions most impact our progress.

For instance, in our Publishing tracking plan, we knew that our users started their journey with the “Add Integration” tab and ended with the “Publish to Lexicon” button.

Between these two points, users entered a lot of information. They selected which integration type they were adding—Segment Protocols, Amplitude Taxonomy, Mixpanel Lexicon, or Webhooks—and gave the integration a name before hitting the “Create Integration” button. Now, while the Integration Type and name is important info for the functionality of the feature, which option they select doesn’t tell us they’re moving down their journey. So, we focused an event on the “Create Integration” action.

After they hit “Create Integration,” our users land on the main form, where they can enter their project ID, account username, account secret, and events filter. This is also the spot where they can toggle on or off the “Auto Publishing” feature that automatically pushes tracking plan updates whenever changes are made (pretty sweet, huh? 😉).

Again, while the information that users add is valuable, we don’t need to track every nuance. Instead, we focused on creating events on the “Auto Publishing” toggle and the final step, “Publish to Lexicon.”

This intentional event tracking doesn’t just make our data designing easier (in fact, it actually takes more forethought than just casting a wide data net). By limiting the events and properties we track to only those that most directly reflect our user journeys and goals, we avoid unnecessary data noise.

We build fat events

When we say we build “fat” events, we mean that we design events with a number of related properties that give deeper information about the action the user made.

Think of these fat events like a deep well: It’s really easy to pull water (insights) out of the well (data) because it’s all captured in one place, and you can dip your bucket (query) into the well and easily find what you need. The alternative to the data well is a shallow data pool, where the water is spread out over a mile of concrete but is only an inch deep. To get the same amount of water, you have to drag your bucket across the surface of it multiple times before you get what you need.

If we don’t build fat events, we have to do a lot of work to gather data from a bunch of different sources and collect it into something useful.

By building fat events, data teams can segment events based on properties to compare different flavors of the same user action, rather than having to pull together multiple events to analyze them. This allows teams to keep the number of events down to a manageable level, which makes it easier to find what they’re looking for and more easily onboard new data consumers to the existing analytics.

We also make sure to name these fat events in a way that is clear and communicates what product and funnel the event corresponds to (e.g., not just “source” or “plan” but “[Product] Plan” and “[Product] Source”).

In our Publishing tracking plan, an example of a fat event is our Integration Configured event, which, you guessed it, tells us when someone makes a change to their integration setup. Now, we could set up individual events for Integration Type Updated, Integration Name Updated, Downstream Project Name Updated, etc. But that would get messy, fast. Instead, we create one main fat event (Integration Configured) and then properties underneath it that capture all the kinds of types of integrations that you might update.

Fat events make it easy for us to see, at a glance, what kinds of actions are possible for integration configuration and keep the tracking of those changes easy to understand and analyze.

We (try to) avoid using Boolean properties

Boolean values are fundamental for functional programming, but they aren’t the best option for reflecting human behaviors (after all, people’s choices are rarely binary). We don’t simply log into an app or not.

For example, if your app uses only one authentication method (let’s say email, for instance) you don’t really need a property to track authentication method. But down the line you’ll probably want to add more methods, like Facebook or Google authentication. Bad Boolean practices would be to create a property for “Facebook” or “Is Facebook Authenticated,” as well as a property for “Is Google Authenticated.” All of which gets messy, and makes it difficult to compare how many authentications are happening via email, Google, or Facebook.

In short, we try to avoid using Boolean properties because they don’t scale as our products and features become more complex.

If we do use Booleans (or when we have in the past) our features and products quickly outgrow the data that our analytics can collect. This makes it difficult (read: nearly impossible) to compare data between eras of our product.

Using Boolean values for seemingly binary actions is a trap that so many early data teams often fall into. They start with exactly the use case being built right now. And then, later, they have to add a bunch more Boolean properties (or revamp their data design). It’s hard to segment on all the possibilities.

Instead, we design our data types for events and properties as strings or other more open-ended data types from the beginning so we’re not limited to whether a functionality is just “on” or “off.”

For instance, in our Publishing feature example, we have a property called Integration Stage. Now, there’s only two options—"Created" and "Published"—so we could just use a Boolean value. However, we know that down the road we’ll probably add more stages, such as "Published to Staging" or "Draft Stage" or something, and we don’t want to limit ourselves.

Boolean values might seem easier to implement at first, but you’re setting yourself up for heartbreak down the road.

We use constraints when defining properties

It’s not enough to say that you want to collect data from your users and your product. You need to explicitly outline for developers what kind of data you’ll accept (communicate your needs, basically).

If you don’t, you’ll end up with folks telling you that their age is 178,000 years, or that they live on Mars. Or you’ll end up with data that you can’t compare because you took in apples when you really needed oranges.

We use constraints when defining data values so that we have a contract about the kind of data we receive (and so that we know it’s useful). These constraints also help us ensure the data is consistent, so it can be compared and analyzed downstream.

In our Publishing tracking plan, for example, we have an event called Integration Configured with a property called Integration Item Type that tells us what part of the integration you’re interacting with. To ensure that these item types are correctly tracked by developers implemented, we explicitly outline the string values, and their formatting, that we’ll accept (e.g., Integration Type not integration type or integration typo).

We do something similar for numerical values by setting a min of 0 to prevent erroneous negative values (or the 1,000-year-old vampire customer from signing up for a service).

It may take a while, but it does pay off to list all of the options a property can take if those options are finite (obviously, you can’t know every URL in existence, so some things should be left open).

We improve and revise our tracking plans when it makes sense

We’re always learning and improving. As a result, our tracking plans improve, too. We revise our tracking plans when product changes call for it or if we come into contact with out-of-date best practices.

If we don’t improve our best practices, we leave our old data and tracking plans frozen in time. This creates unnecessary confusion for whoever interacts with that old data (and more bad data as time goes on). Instead, when we come across an inconsistency that makes sense to correct, we update the tracking plan element so it’s more in line with our current best practices.

Tracking plans are a living document. If your data needs change or your product functionality shifts, it’s important that you have a system for documenting how your tracking plan evolves alongside it.

At Avo, we’re diligent notetakers. We maintain, as comments on our branches, a record of the changes (or change requests) that take place. This helps us understand how our plan evolved over time, or if certain parts of our tracking plan had to be sliced out in order to ship code on time (as was the case with some of our Publishing tracking plan).

Sometimes, after we launch a new feature, we discover that we need to add an event to better understand why our users are dropping off between the main user actions we’ve already identified, or we find that we need to add a new property to segment on a flavor of event we didn’t think of at the start.

For example, we recently started noticing that people were creating integrations, but not publishing them. We weren’t sure why that was, however, because we didn’t have events and properties that showed if they were trying to publish something, or just testing out the product. So, we added an “Integration Archived” event to see if folks were just creating events to archive them, or if they were getting stuck publishing.

However, while we’re all for a data ✨ glow-up ✨, it’s important to remember that data is permanent. We don’t want to change too much, because then we lose context by completing deleting those shallow events. Instead, we can preserve context and improve tracking by consolidating these shallow events into fat events.

We use Avo to help us build better, collaborative tracking plans

Collaborative data management at Avo is rooted in collaborating, in communicating, and in dogfooding our own product so that we can capture all of the ideas and expertise of our team and product design. This helps us avoid conflicts, keeps our plan up to date, and ensures that we design good data.

If we didn’t leverage Avo as a single source of data truth that’s directly connected to the implementation, our data experts, developers, and product managers would exist in silos. We’d run the risk of our tracking plan not being in sync with the implementation, constantly making changes to our source of truth that conflict with each other, and designing our data in an unideal way (because experts in different areas are not collaborating). Remember that imaginary dinner, where we didn’t plan what ingredients we needed? Now imagine we’re putting together a potluck, where everybody has to make their own dish, but nobody knows what anyone else is making, or even where the event is being held. That would just multiply the number of duplicate and downright disgusting dish combinations that made it to our table.

We avoid a similar data disaster by dogfooding Avo as our main source of data truth, which includes those in-app comments and suggestions between the team on different branches of our tracking plan we mentioned earlier. Rather than spending our time getting lost in our tracking plan (and finding our way out), we can focus conversation around the changes needed. This comment log and versioning is the functional group text that the disaster potluck needs.

Avo lets our developers flag data experts to review new features before merging changes with the main branch. All of this is coupled with Avo’s built-in branching mechanism that allows data teams to make changes to tracking safely in isolation without impacting the core source of truth for the worse.

If there’s one thing you take away from all of this, let it be this: communication is the key to collaborative success. Avo simply makes that communication much, much easier.

Be More Like Avo: Use Avo

As long as you’re generally adhering to these best practices—and using a tool like Avo to make following those rules easier—you, too, can have an efficient, collaborative tracking plan process.

Avo lets you combine all the data best practices we’ve outlined in our tracking plan series (and all the tips and tricks we’ve outlined right here) into one collaborative, single source of data truth.

Check out Avo today to level up your tracking plan and be more like Avo. (We promise, we’re pretty awesome.) 🥑

How to Reduce Back-and-Forth with Data Teams in Developer Workflows

Avo — Thu, 04 Feb 2021 19:56:44 +0000

It starts with one clarifying email. Then a follow-up Slack message turns into a cascade of notifications that completely dissolve your productivity.

Nothing throws a wrench into a spinning product development cycle like multiple rounds of ineffective feedback because of confusing or incomplete information. Unclear expectations and poor communication during the design stage of a project are the two most common reasons for the mass of emails, Slack messages, and Jira tickets that can bring a developer workflow to a crawl.

By tackling these two leading causes of miscommunication between teams, developers can cut down on the unnecessary back-and-forth and keep projects moving.

Put Project Expectations in Writing

One of the best ways to stem unnecessary messages around a developer workflow is to establish clear expectations at the beginning. This starts with a Purpose Meeting: a 30-minute gathering of stakeholders, including engineers, developers, data specialists, and the PM, to make sure everyone understands not only the “what” of the project but also the “why.” Consider creating an agenda so all the stakeholders understand their role in the meeting.

During the Purpose Meeting, create a tracking plan that clearly outlines the project’s purpose and the best way to fulfill that purpose. There should be no doubt among the stakeholders what the end product should look like. This document should explain the goals, metrics, and data needed so everyone knows the final destination before a single line of code is written. Keep it simple and only focus on the data that aligns most closely to your goals.

‍

The three primary goals of a Purpose Meeting

This meeting and the resulting document will ensure everyone involved understands the success metrics for a project. Keeping the document in a central place such as Avo, Notion or GitHub, where everyone can refer back to it at any point in the development process, will eliminate unnecessary confusion.

Communicate in Context With the Data

When you have data in a Google Sheet and communication in Slack, miscommunication is bound to happen. An update won’t get documented, or the PM will ask for a change to one piece of the project, but the developer will think they’re referring to a different piece. Cue notifications.

A simple way to avoid this type of confusion is to communicate in context with the data. Using the same platform to discuss and manage the data helps make sure all teams are discussing the same issue. Tools such as Branch Collaborators remove both knowledge silos and barriers to collaboration while eliminating miscommunication between iterations. These tools allow you to have a focused conversation around the changes made. They also provide a living record of incremental changes, which makes it much simpler to onboard new developers to a project.

Branch Collaborator example in Avo

Before adopting Avo, Patreon was struggling with an inefficient developer workflow. The teams behind the international membership platform faced rounds of ineffective feedback around every launch. Unsurprisingly, this slowed down launches and kept teams from getting the data they needed.

But by switching to a platform where the feedback can happen alongside the data, Patreon’s data and development teams could both work in a specific branch for changes and QA. Working in context with the data helped the teams replace an error-prone process with an alignment that allows them to ship faster and move on to new projects.

"Instrumentation process used to take 1-4 days but now take 30-120 minutes." -- Maura Church, Director of Data Science

Integrate Validation Tools to Catch Problems Before the Analytics Destination

Even with a clear design scope, updating complicated code can cause tracking to break or unexpected problems between platforms or code paths. These types of problems can take months to identify, let alone fix, and become a huge drain on developer resources. Not to mention that this can cause the longest-running email threads.

By incorporating tools with type safety that validate implementation, the development team can catch missing data or discrepancies in code paths before the product is released. This not only improves the data quality of the product, but it also eliminates a huge source of frustration for many teams.

The challenge for Secure Shell (SSH) client Termius was keeping analytics consistent across the multiple platforms they serve. This involved a number of applications and codebases, and the added complexity increased the probability of errors significantly. Minor issues would cascade into a mountain of data debt. Each fix slowed the developer workflow, kept projects from moving forward, and delayed decisions that hinged on the insights from the analytics.

Using a system that helps remove data debt, standardize boilerplate code, and validate updates not only gave time back to Termius’s developers, but it also provided trust in the data.

“Avo’s biggest impact was in reduced overheads on analytics. We’re not only saving time for developers and product managers on designing, implementing, and verifying analytics, but developers are also relieved that they no longer have to monitor the analytics after every release, to make sure the tracking didn’t break,” said Kirill Yakovenko, a product manager at Termius who heads up analytics quality.

Get Developer Workflows Moving Again

The typical development workflow is ripe for miscommunication and the resulting flood of notifications across teams. One Avo client reported that 25% of their Jira tickets were associated with the back-and-forth confusion that comes from incomplete information. A solid process for validation and clear channels for communicating around the data keeps projects moving smoothly so developers can get back to building and shipping great products.

Looking for a tool that can help your teams communicate effectively around analytics management? See how Avo can get your developer workflows moving again.

6 Tracking Plan Best Practices to Guarantee Good Data

Avo — Wed, 27 Jan 2021 17:04:51 +0000

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.

An easy way to collect crash reports in our Android libraries

Avo — Wed, 20 Jan 2021 14:44:32 +0000

Being an app developer I always liked how easy it is to add crash collection to my apps, but after switching to library development I’ve found myself in an opposite situation. How do I track and analyze crashes in my library?

Here at Avo we have a couple of open source libraries for mobile. We have part of one of our main products distributed as a library, the Avo Inspector SDK, and we have our mobile debugger.

At one point we realized that there is a problem, we don’t have access to crash reports from the libraries. When the library is integrated to a third party app and crashes, that crash is collected by the app and it actually crashes the whole app, which is really bad. At the beginning we were in a situation where we relied on the crash information we get from our clients. We also lacked a good tool to organize the reports, something similar to what you get in Crashlytics for example.

Our library, Avo Inspector, monitors tracking and collects metadata about it, it's not the core functionality of the app, so we decided that failure of the library should not be terminal to the app. We will collect the crashes when they happen and let the app do it's main job undistracted.

As with all problems we face in software development, there are multiple possible solutions here with their own drawbacks.

Most companies solve this problem by having their app with a decent amount of users where they use their sdk and monitor crash reports. Unfortunately it's not our case, since our product is a web app and a set of developer tools.

Being a seed stage startup with a very small engineering team and huge list of product opportunities we try to utilise existing software as much as possible and invest as much time as we can in development of our product, so the first thing we did to figure out this problem was to look for a well built existing solution. To our great surprise we have not found any. There are quite a few different crash management tools for apps, but nothing dedicated for libraries.

Technically we can use an app-based solution, but then the dependencies and library initialization may collide if the integrating app uses the same tool for crash reporting internally. Actually duplicate dependencies is not a huge issue and gradle would take care of it for us (read more about how gradle resolves dependencies here and in the worst case will fail the build, while the initialization is trickier. Most of the libraries do not allow having 2 instances sending crashes to 2 different destinations. Another complication is that those app specific crash reporting tools usually collect a lot of additional app data by default that we don't really want to collect as a library, like sessions or user identifiers.

At that point building our own proxy to collect the crash reports seemed like the only option. We are using Sentry.io in our web app and decided to look into sending crashes there through our own endpoint. But then, when reading the docs, we got another idea. The thing is that alongside an app-specific Android SDK they provide a generic Java SDK that can be used in an Android app.

This Java SDK actually automatically checked out most of our concerns about using a crash reporting SDK in our library.

Chances that there would be a conflict are very low, and for those who use Sentry Java SDK we provide a version of our library without the dependency. The Java SDK is not sending additional app-related information. And integration is just a couple of lines of code. And since we are already using Sentry it was just perfect in our case!

Here is how the code looks in our repo.

The Sentry Java SDK dependency:

Raw code
‍

One thing we had to do is disable uncaught exception handling. By default Sentry, like most other crash reporting tools, registers a global uncaught exceptions handler that reports errors coming from any part of the application. In case of a library, we don’t want to be notified about exceptions that were thrown outside of our own code, so we disabled the global handler like this:

Raw code

Then we initialize the library:

Raw code
‍

And finally we wrapped all public methods in a try-catch and added this handler:

‍

Raw code
‍

That’s it!

We love this solution for the simplicity and the amount of value we get per unit of effort, it's exactly what we need. You can utilize the same approach, improve the stability and quality of your library and make your clients happier, never worrying about crashes from that 3rd party code they pull in!

P.S.

In addition to Sentry, Bugsnag and Raygun have Java SDKs and can likely be used in the same way. We haven't tried them though, please let us know if you are using one of them in an Android app by sending an email to dev@avo.app.

P.P.S

Another great option which is more universal is using the new crash reporting API from AppCenter. It's quite new and was not present when we did initial research.

We have considered using it since then and were quite intrigued, but are still staying with Sentry on Android because of the implementation simplicity and the fact that we are using Sentry for our other products.

In your case utilizing the AppCenter API might be a better option, check it out! Moreover, stay tuned for the news about our iOS crash reporting. They might be posting about AppCenter at some point. 😉

Your Guide to Updating Your Tracking Plan (Without Breaking Everything)

Avo — Fri, 15 Jan 2021 00:56:21 +0000

Your product is out. Your tracking plan is in place. Now the work really begins, at least as far as your tracking plan is concerned.

But just because a tracking plan was great pre-launch doesn't guarantee it'll stay that way on its own. Even the best and most thoughtfully laid-out courses need correction from time to time. Your tracking plan is no different.

No matter how well you design your tracking plan pre-release, chances are, new questions about your users and product will arise after things go live. Here's how to adapt your tracking plan without breaking your analytics—or undoing your sanity—in the process.

Look at your data (nearly) every day

The first step in adjusting your tracking plan is knowing whether you need to in the first place. Look at your data every day for the first few weeks that your product is live. Be sensitive to any technical flaws. Is your analytics platform accurately collecting info? Is the data you're gathering answering the questions you set out to find answers to during that initial purpose meeting? You don’t have any follow-up questions from the ones you have already answered?

By looking at your data daily, you may find that the answer to all those questions is: "Well, yes!" In such an instance: congratulations! You've built the perfect tracking plan, and you are in no need of the remainder of this article. Have a cookie. 🍪

More likely, though, you'll walk away from checking your data with even more questions about your users and how they're leveraging your product. In which case, there's work to do. It's OK, it happens to the best of data teams (even ours).

After one of our launches, we realized our tracking plan was designed such that we had to dig into our raw data to know how long branches had been open. We revised our tracking plan and added a new property to allow us to measure the number of hours and days that branches had been open.

For the first few weeks after your launch, look at your data daily. Then, once you’ve built a good baseline of metric performance you can shift to a weekly data review cadence to review your short-term KPIs. Once upon a time, it was acceptable to consult data monthly, quarterly, even yearly. Now, as we're deep in COVID-19 country and the new, fast-paced normal that came with it, markets and customer needs shift on a dime, so frequent consultation of data is advisable.

For the first few weeks after your launch, look at your data daily.

Speaking at Amplitude's recent Amplify conference, executives from elite companies unanimously agreed about a need to be more agile and responsive with data. Shipt's VP of data science, Vinay Bhat, suggested that looking at data every day and "using shorter-term trends to quickly iterate off of" allowed Shipt to be more diligent about responding to new customer trends.

Along similar lines, Shopify's director of data science, Philip Rossi, explained that daily data checks gave his team the ability to show people a snapshot of their performance at any given time.

“On any given day . . . we could give people the [data] insights we had at that particular time, knowing we'd be looking for new ones the next day,” he said.

Whatever the nature of your business, those are good precedents to follow.

Listen to your product manager's suggestions

Your product manager is the one closest to the KPIs and goals for your product. They may or may not be data-savvy, but that doesn't necessarily matter. The questions they have post-release can help improve your tracking plan and bring it more in line with the business's goals. They'll also be getting feedback from other team members about potential areas of improvement in your tracking plan and new questions to be answered.

For instance, say you wanted to figure out where in the user journey your users were dropping off. You start out by measuring, with your tracking plan, an event for overall adoption rates. A few days after your launch, one of your product managers comes to you and suggests that you make a change to help your designers better understand which features need improving (rather than just measuring adoption generally). After collaborating with your product manager, you decide to track adoption-rate data per feature that lets your design team see where they can make improvements to individual features to remove friction from your UX.

Regularly check in with your product manager after their first round of revisions to ensure that your data feeds into the future of the product. If they’re missing a particular kind of needed data — “Why aren't we getting info about follow-through from feature-set a to feature-set b?” — you can make that integration or add a new event to capture that information. Alternatively, if there's a metric they no longer need — “We're a month in; we don't need to still be checking how many users are coming in from our launch-day content” — you can streamline your plan.

Run any changes by your developers and data experts

All potential adjustments to your tracking plan should be gut-checked by your developers and data experts. This ensures the tracking plan is designed well and that it's possible to track the data being requested.

For instance, let's say you have two stakeholder requests: one from your product manager and one from your sales department. Your product manager wants to add information to your tracking plan about how many users are going from your “Start trial” page, through your “Demo,” to your “Premium Landing Page.” Your sales department wants to know how many users use your product after visiting a particular other site.

Discipline and care make your tracking plan work.

Once you know the data they want tracked, check with your developers that it's possible to collect that data. It's likely that your developers could very easily implement your product manager's request, given the right analytics tool. However, your sales department's request may be more difficult. That information may not be available at the moment when the event should be sent or be better served by a qualitative approach to collecting it.

Finally, once you've settled on what can and will be added to your tracking plan, have your data experts come in. Their job will be to review the new structure to ensure that it meets your data governance standards in security, cleanliness of data, and usability.

Refer back to your established naming conventions

When updating your tracking plan, refer back to your original tracking document and established naming conventions to avoid duplication errors and casing inconsistencies. You created your initial tracking plan for a reason, and that reason was ensuring data continuity post release. Tracking plans are useful only if the data they include is usable. The organization and communication of those insights are imperative.

Naming conventions are crucial for maintaining that continuity. However, enforcing consistent naming conventions is one of the biggest challenges for companies because errors are often small and seemingly innocuous. But all it takes is for one stakeholder to refer to “customers” as “clients” during input for that potentially vital data to become siloed and inaccessible in an extensive database. For that reason, the most powerful tool to maintain data continuity is a naming convention that's well defined and available to everyone to prevent these problems.

Enforcing consistent naming conventions is one of the biggest challenges for companies.

Developers (and anyone creating new events and properties in tools like Avo) should pay particular attention to the casing of names, order of objects and actions (e.g. Button Clicked vs Clicked Button), and the tense to avoid creating messy duplicates or confusing names. A good example of a naming convention will have the following features:

A settled practice for cases (e.g., everything in “UPPERCASE,” everything in “lowercase,” everything in “camelCase”)
A unified approach to articulating spaces between separate words (e.g., use of underscores, use of spaces, use of hyphens/em dashes, use of camelCase)
IDs that include the data type expected for each variable
Human-readable data that clearly and concisely communicates what each event and property measures (e.g., Adoption Rate, Conversion Rate, etc.)

Remember, duplicates or erroneous values can lead to adverse consequences for people using your data.

Your tracking plan is a little like a language of its own. Consistency and continuity are vital to maintaining ease of understanding between your stakeholders. Discipline and care make it all work.

Establish a system for version control

Without an established system for version control, tracking plan management can get messy, and updates between different versions, made by different teams, can cause conflicts within your code and schema. Having an established VCS (version control system) and process helps you avoid these disconnects.

This is particularly important in the context of team collaboration. The point of your tracking plan is to de-silo teams and improve knowledge-sharing. For that reason, multiple teams will be working on the same tracking plan. You may find mistakes are made, particularly in the first month or two of using your plan, when everyone is getting used to the standardized procedure.
‍

Teams traditionally feel the pain of poor version control when they’re over-reliant on Google Sheets.

Teams traditionally feel the pain of poor version control when they’re over-reliant on Google Sheets (bad doc history features have a lot to answer for). Worse still, they might be trying to manage tracking plan versions through multiple files (e.g., Data Plan v23). What your team needs instead is a single source of truth, like Avo or a similar tool.

Beyond updating your tech stack, you can improve version control by implementing branched workflows and version control systems. This is easy if you’re keeping your tracking plan in JSON documents and collaborating in git, which allows you to bump a version every time you update your plan. This gives you the ability to check for conflicts and dependencies within your codebase, as you would during regular QA checks of code pre-deployment.

Make tracking plan management (and revising) easier with Avo

There's nothing wrong with changing your tracking plan design post release. In fact, it's a great thing to do. Acknowledging that your tracking plan is a little off somewhere—or that more data would help you build a better product--is the first step to improvement. Once you've established that you need more — or different — data than you originally planned, it's time to get to work adding new events and properties so that you can get better answers down the road.

Nevertheless, tracking plans can be demanding, even with the most disciplined stakeholders in the world. That's why it comes in handy to use a tool like Avo. With Avo, you can keep track of all your events and properties easily in one place. It helps you enforce best practices, like standardizing casing and preventing duplicate events and properties from occurring. Avo also lets you seamlessly push updates to developers for every platform from a single, accessible source of data truth.

Try Avo today for better product decision-making and a cleaner tracking plan.

How Rappi Developers use Avo to build better product analytics

Avo — Mon, 11 Jan 2021 21:22:18 +0000

guest post by Juan Jose Villegas, Engineering Manager at Rappi

The power of Avo is this: what is designed is what is implemented.
– Juan Jose Villegas
Engineering Manager

‍
As an Engineering Manager at Rappi, I’m in charge of managing a cross-functional team made up of Android, iOS and backend engineers that are focused on developing and maintaining features that our end user perceives. My role is to take them from ideation and concept phases to testing and production, while remaining involved form a hands-on technical perspective.

We found Avo when searching for a solution to the problems that plague many engineering teams. Rappi develops new features and ships weekly, and each new feature requires analytics. Then, all those features require cross-platform implementation, so we are working on at least 3 different codebases at any given time. Each team had their own interpretation of what should be implemented. We’re only human, so there were typos and different types of events and properties scattered throughout the code. Once the feature went into production, the BI team started to track activity and realized what was defined didn't match what was implemented. Tickets bounced back to the engineering team, and the cycle started all over again.

All of this boils down to developers' time wasted in implementing analytics and fixing bugs - 25% of tickets in engineering were analytics related. We also saw the BI team wasting time on clean up projects and regression testing when critical events break. QA teams were stretched trying to catch every bug before it hit production. Even then, our VPs worried that the data presented to the CEO was inaccurate, leading to large-scale decisions in the wrong direction. I’m willing to bet you’ve found similar inefficiencies in your organization, and it was these recurring issues that led us to implement Avo.

Align Cross-Platform and Cross-Functionally

Avo helps developers communicate with each other better, as well as come to a clear understanding of our requirements and deliverables with data science, business intelligence, and product teams.

Global naming conventions

Discrepancies in event and property names––seemingly minor (order_submitted and orderSubmitted) as well as major (order_submitted and orderButtonPress)––are a surprisingly central pain point in data analytics, particularly when aiming for self-serve analytics culture.

Issues with event names and property names do not only arise from the implementation step (which is mostly prevented with type-safe analytics code generated from a central source of truth for all platforms); they also arise from the data-design step: when multiple teams work on a product, it typically also means that multiple humans work on the tracking plan. It's difficult enough to remember all the events you yourself created, let alone be aware of the events other people have created.

Avo has a global namespace to ensure that all events and properties in the tracking plan have unique names so that they can be easily identified. This significantly reduces duplicate event definitions for the same user action. A global namespace for events ensures that whoever is defining events is aware of events that have similar names. Furthermore, they won't even be able to create an event or property where the only difference is casing (a source of surprisingly many frustrating data issues).

Having a global namespace for all properties ensures you won't create properties with slightly different meanings depending on which event they are sent from – a source of many confusions for the data consumers. For example, the data consumer may be used to user_id meaning "id of the user ordering something", but then all of a sudden a new event gets created with user_id referring to the user delivering an order.

Descriptions

Descriptions aren’t new for us, and I’m sure they aren’t new to you either. Whether we work in Excel, Miro, Amplitude, or Avo, there is some version of event and property descriptions that tell us basic information about how and why a data point is instrumented. What separates Avo from the rest is how it communicates this rich information across the workflow. Descriptions don’t just die in Avo. They’re presented in the generated code, so developers have easy access to them while they’re implementing. They can also get published into your other schema sources, via a Webhook or Avo’s auto-publishing into Amplitude, Mixpanel and Segment. Avo also keeps a log of all changes and comments made, so the descriptions become an ever-evolving and well-documented source of truth.

To make it absolutely clear when an event should get triggered, our event and property descriptions follow a standard template including a Miro link to planning exercises and a link to an image that shows how and where the event is triggered. Avo also recommends having the purpose of your events clear, and allows you to link your events directly to the metrics they should be used for – which adds further clarity and context for your future self or coworkers, who might be wondering why an event exists.

Review workflows

Self-serve analytics and an open data democracy are tenets most product orgs aspire to in the age of rapid product development with an expectation for fast learning. However, I’ve found it to be unsustainable without some type of changelog and review system in place. We can define our analytics events as flawlessly as possible, but it’s meaningless if someone can come in and accidentally delete them.

We utilize Avo’s review workflows. The main branch is protected against direct changes, and every other branch has to be reviewed by someone before it is merged. Having another set of eyes on all changes means the probability of damaging events or designing incorrect data is slim.

It’s also worth noting that each change is logged in Avo, and displayed to the end user in a diff log. The Avo log is particularly designed for reviewing changes to analytics objects, which is better than a git-hosted .json file, where you can’t reliably trace changes to specific events or properties, because git is limited to line-changed of a file. With Avo, it’s easy to trace which developer or analyst made which change, and we can always do a rollback if an error does occur.

Implement faster and better

Type-safe code

When you use Avo to generate code via the CLI or the UI, it’s type-safe and generated the same event and property names across all platforms. We can only implement data in well-defined and reliable ways.

For example, we have an event property called “category”, and we want the values to be either “market” or “restaurant”. That’s how it’s defined in our tracking plan. When we go to generate code, we see that the “category” is implemented as an enum where the cases are exactly what is available in the tracking plan, “market” or restaurant”.

Inspector and Debugger prevent implementation errors

Even with the above processes in place, there could theoretically be errors. For example, we’re still responsible for correctly implementing the timing and triggers for how each event fires. However, the mobile debugger and the Inspector help QA teams to find and eliminate errors before we ship that version. These QA tools make it nearly impossible to ship bad analytics, and eliminate the feedback loop wherein our BI team would find errors and be forced to log Jira tickets to have them resolved.

The power of Avo is this: what is designed is what is implemented.

As an added bonus, Inspector tracks our legacy code before Avo. The Inspector is like a map of what’s happening with our data, what is being sent. What previously was taking weeks of BI time auditing and cleaning up our existing code is now automated. Avo has given us a clearer picture of what inconsistencies our tracking has, and the power to know exactly what issues to fix, so we can work towards prioritizing and resolving them.

Dedupe your workflow

Property Groups

Let me walk through an example I’m sure will resonate with you. You have a widget to sell, and you want to track the ecommerce funnel for how a user buys that widget. You have events like view_item, add_to_cart, and purchase and each of those events will have properties that tell you more about the event. You usually want to know things like item_name or item_price, so you send that along with each of the three events above. Each event can be triggered in multiple places, so you have to type item_name at least a dozen times already. Multiply that by the number of platforms your team serves. Bored yet? Oh, and Android decided to call it itemName instead because they didn’t know we were using snake casing for analytics.

Can we even be surprised that there is human error, then, when we are implementing the same thing over and over, by hand, with several different teams?

Instead, we’ve adopted Property Groups in Avo. We define and design groups of similar properties when we design the tracking plan and assign those Property Groups to relevant events. Then, not only are we only defining the properties once, we’re also ensuring that all necessary metadata is included with each event.

Use default destinations

As mentioned previously, we have quite a few tools in our marketing stack. Downstream from Avo, we have Amplitude, AppsFlyer, Braze, Firebase, Rakam, Split.io and Facebook. Our events could go to one of these sources or they could go to all of these sources. It can be challenging for our developers to know what goes where, and this results in a lot of guesswork that has to be corrected at some point in the future.

When you configure sources in Avo, you have the option of defining defaults for given source-destination pairs. For example, if I know I always want to send Android and iOS events to Firebase, but never web, I can automate that for all events. It is possible to change defaults at the time of event creation, but having defaults in place addresses the vast majority of cases.

Publishing

At Rappi, we use Amplitude for most product and marketing insights and visualizations. If you’ve worked in Amplitude previously, you’ll know that when an external event is sent into the platform, there is a review and acceptance process in Amplitude Govern. Without Avo, this is a valuable check in the system to make sure bad data doesn’t end up flooding our analytics tool. However, we’ve already done the work of describing and verifying all data points so this extra check becomes a timesuck with no added benefit to the process.

Avo integrates directly with Amplitude’s Govern tool and bypasses this process. Instead, all descriptions and contextual meta-data are sent to Govern each time a branch is merged. I don’t have to remember to update Govern, and our analysts always have the most up-to-date version of analytics.

‍

Where We’re At Today

We’re making great strides in improving our analytics implementations and making our developers more efficient in the process. We are working towards an overall goal of having our engineers use only 5% of their time implementing analytics. That represents an 80% reduction in their current use of time. While we’re working towards our metric goals, we’re happy with our developer and data scientist feedback so far. Here is what my co-worker had to say:

“Developer adoption of Avo has been great. In a matter of weeks, multiple teams are implementing analytics with Avo, with developers adopting the tool seamlessly and without conflict, even if they are developers that don’t work together day-to-day. I’ve seen very good feedback from devs. It’s easier to make changes and maintain events, because they are well defined in advance.”
- Henry Martinez
Android lead

With Avo we create analytics schemas upfront, identify analytics issues fast, add consistency over time and ensure data reliability as we help customers serve the 12+ million monthly users their businesses attract. Overall, the power in Avo is that it frees my team up to build the experiences and features that really matter for our users.

Publish your tracking plan into Amplitude, Mixpanel, Segment or with a Webhook

Avo — Mon, 14 Dec 2020 20:04:23 +0000

Tracking plans can't live in isolation. Once a tracking plan has been defined in Avo it needs to be utilized in multiple places, not only to generate type safe tracking code, but also to...

feed the rich context of the tracking plan (think event descriptions, property types etc) into analytics platforms Example: I want to see the Avo description when hovering over an event in Amplitude
update ingestion time validation tooling that blocks things that are not defined in the tracking plan from entering our datastore
build or update SQL tables based on the latest tracking plan, to receive and store the data

Basically, the limit does not exist. 🚀

Publish Your Avo Tracking Plan:

We’re excited to announce the following Publishing destinations are now available in Avo:

Segment Protocols: You can push the Avo tracking plan to Segment Protocols with a click of a button in the Avo dashboard.
Amplitude Govern: API pending update from Amplitude, coming soon! You'll be able to push your Avo tracking plan with a click of a button in the Avo dashboard.
Mixpanel Lexicon: You can push the Avo tracking plan to Mixpanel Lexicon with a click of a button in the Avo dashboard.
Webhooks: To access your tracking plan data in thousands of other platforms, or in your own in-house tools, use Avo Webhooks. It’s as easy as adding a URL.

The feature we’re most excited about, however, is auto-publishing to all of these destinations. You can now configure these integrations so that each time a new branch is merged, your new and updated tracking plan is automatically sent to your downstream tools of choice! We’re taking the guesswork out of event metadata.

With auto-publishing, you can rest assured that every team member has the insights needed for analysis and activation, right where they need them.

This helps you seamlessly create a single source of data truth and foster better collaboration across teams in your product organization. If you need help along the way, know Avo is ready to partner with you on your journey to good analytics governance.

9 Free Tracking Plan Templates from Mixpanel, Amplitude, Segment, and More

Avo — Mon, 23 Nov 2020 14:39:08 +0000

At Avo, we’re all about working smarter, not harder. That’s why we rounded up some of the best tracking plan templates: so you can spend less time planning your data management, and more time enjoying the fruits of your labor.

Sure, you could build your tracking plan completely from scratch using a Google Sheet or Excel, but why make your life harder than it needs to be. Building a good tracking plan can take a lot of work and trial and error.

When you start with a tracking plan template, you reduce some of the friction between your data-driven vision and your data-admin reality. This helps you get your data management off the ground faster, with less of a headache.

Why you should use a tracking plan template

There’s a lot that goes into building a great tracking plan, and, thankfully, some of the best leaders in the analytics industry have done the legwork for you.

You can definitely blaze your own trail and create a tracking plan yourself, but you’ll inflate the amount of time going back and forth with your product and sales teams to establish key events and KPIs. You also run the risk of forgetting about a key field your tracking plan needs, requiring you to go back and correct both your plan and your analytics down the road.

Why work harder when you can work smarter and faster?

But before we get going too fast, let’s review a quick definition of what we mean by “tracking plan”:

A tracking plan is a centralized document that everyone on your team refers to when setting up and implementing tracking analytics at your company. It outlines what metrics you care about, and why.

Now that you know why you should use a tracking plan template and what a tracking plan is, we can move on to the best part: our favorite tracking plan templates. 🥑

A breakdown of our favorite tracking plan templates 😍

The tracking plan templates we’ve included below will streamline many of the steps of building this centralized document to keep everyone on the same page.

These templates help you avoid all that mess and help you get your tracking plan best practices up and running, and each of the templates below from companies such as Amplitude, Segment, and Mixpanel will make it easier for you to implement your plan into popular analytics tools.

1. Avo’s Ultimate tracking plan template 🎉

We’re a little biased, but this is our favorite. We created an ultimate, universal tracking plan template that outlines everything you need to think about when creating a tracking plan, all in one Google Sheet doc.

‍

What we like: This tracking plan template takes our favorite elements from our customers’ tracking plans and puts them into an understandable template format that companies can use to break down the metrics they most care about. Then, once it’s filled out, tracking plan champions can use this document to seamlessly implement their plans into their analytics tool of choice.

What we don’t like: Your information isn’t already in it. 😉

Best for: The Avo template is made for any company that wants to be data-driven and develop a killer tracking plan.

2. Segment’s basic tracking plan template

Segment is an industry leader when it comes to product analytics. In addition to their specs for mobile, video, SaaS, and ecommerce tracking, they’ve developed a number of tracking plan templates to get you started, but this basic template is one of our favorites.

‍

What we like: You can use Segment’s template for a variety of industries, and the Google Sheet format makes it easy for you to keep track of implementation notes, tracked events, and user IDs and traits.

What we don't like: In our opinion, this template could be improved with an additional column (or stand-alone tab) for overall business objectives and key performance indicators (KPIs).

Best for: This template is best suited to any company looking to improve their data management practices (bonus if you already use Segment).

3. Amplitude’s basic event taxonomy template

This template is an oldie but a goodie. Amplitude created a basic template for event taxonomy (a fancy way of saying tracking plan) for companies in any industry.

‍

What we like: Amplitude’s tracking plan template includes clear instructions on how to get started, as well as answers to common questions companies may have while building their template. This ensures that you (or whoever is in charge of developing your 1.0 tracking plan) can easily get started without having to do a bunch of Googling.

What we don't like: This template doesn’t feature a tab for implementation notes, but you can always add another to your local copy.

Best for: Amplitude’s template is best suited to companies in any industry that already use—or plan to use—Amplitude to manage their analytics.

4. Practico Analytics’ basic tracking template

Practico Analytics has created some awesome resources around tracking plan development and management, not least of which is this basic tracking plan template.

‍

What we like: Practico Analytics added some extra fields to their template for implementation status, spots to specify where in the life cycle the event fits, and a field for what app section your events sit within. This extra detail is an awesome way to ensure that your events match up with your user journey.

What we don't like: This tracking plan is technically behind a sign-up gate (though the link we provided up top gets you around that), and their implementation checklist doesn’t include any sample information.

Best for: This tracking plan template is best for companies that have some tracking plan experience and that appreciate, but don’t need, example data to show them what to include.

5. Mixpanel’s Tracking plan Template for SaaS companies

Mixpanel created a great simple template for SaaS companies that breaks down how to think about business objectives, analytics strategy, and tracking plan elements such as event names, triggers, and definitions. If you’re in the SaaS space, this is a great resource to get you started.

What we like: This Mixpanel tracking plan template is great for SaaS companies looking to pull all their tracking and sales KPIs into one place (there are three sheets: one for your tracking plan, one for your analytics strategy, and one for your business objectives).

What we don't like: The design is a bit old school and may take a bit longer to figure out than others on this list. Also, there are some redundant fields (trigger and event definition, for instance), so the layout could be simplified.

Best for: The Mixpanel SaaS tracking plan template is best for—you guessed it—SaaS companies that are putting together their first tracking plan.

6. Mixpanel’s Template for Retail and eCommerce companies

Mixpanel has created a great simple template for retail and ecommerce companies that breaks down how to think about business objectives, analytics strategy, and tracking plan elements and includes some sample data for each area to help you get started.

What we like: The Mixpanel tracking plan template for ecommerce and retail companies includes some awesome example data for your tracking plan to help you get an idea of what to start off with. And, like the SaaS template, it features tabs for your overall KPIs, your analytics strategy, and your tracking plan, so everything is in one place.

What we don't like: Like the SaaS template, this one’s design is a little clunky, and some fields are redundant.

Best for: This template was specifically put together for ecommerce and retail companies.

7. Amplitude’s tracking plan template for ecommerce companies

This template is nearly the same as Amplitude’s basic template but includes some suggested events and properties for the ecommerce industry, which can be used as a jumping-off point.

What we like: Amplitude’s tracking plan template for ecommerce companies includes sample event and property names, as well as detailed instructions on how to think about each field of the plan. They also have included links to sample taxonomies that you can check out for more inspiration.

What we don't like: This is the same as their basic template, and it doesn’t include that much space for adding notes for developers.

Best for: This template is best for companies within the ecommerce space that are completely new to tracking and in need of some extra detail.

8. Mixpanel’s Tracking plan template for Media companies

Continuing on their industry-themed templates, Mixpanel created a great, simple template for media companies. Like the templates before it, this one breaks down business objectives, analytics strategy, and tracking plan fields.

What we like: The Mixpanel tracking plan template for media companies includes a great breakdown of the different elements you need to identify—everything from KPIs to events to implementation notes—to create a great tracking plan.

What we don't like: Some of the fields provided are redundant, like previous templates. Additionally, their provided KPIs and properties include some examples that aren’t actually relevant to the industry and can’t be implemented 1:1 into their platform.

Best for: This template is best for media companies that have already put some thought into their tracking plans and don’t necessarily need a bunch of examples.

9. Mixpanel’s Tracking plan template for financial service companies

Closing out both our list and our collection of Mixpanel tracking templates is this great template for financial services companies. Like previous examples from Mixpanel, this template breaks down info into KPIs and analytics strategy, as well as your tracking plan.

What we like: Like other tracking plan templates from Mixpanel, this one includes a good amount of detail to ensure that companies using it are breaking down their tracking plans to the right level.

What we don't like: Unfortunately, also like other tracking templates from Mixpanel, the information isn’t presented in the prettiest way, and some fields are redundant.

Who this template is best for: This template—as you probably guessed from the name—is best for financial services companies.

Now that you’ve got your tracking plan template, meet your best tracking analytics tool: Avo

There are lots of awesome templates out there to help you get started in creating your tracking plan. But no matter which one you go with, you can level up your tracking (and make the management of it easier) with Avo.

Avo works with nearly all of the analytics tools that developed templates on this list (sans Practico Analytics). So, no matter what template you choose, you can add your tracking plan to Avo and manage analytics implementation across all platforms.

Basically, we’re your source of data truth.

Create a free account today, or sign up for a demo to learn more.