‍
"How many of you are using Google Analytics as your primary metrics product? You are doing it wrong."

• Michael Seibel, Building Product 

I started thinking about this a while back but never really fleshed it out; why are most product teams dogmatically defaulting to Google Analytics as their primary metrics tool while there are so many better and more appropriate tools out there. It's become this ridiculous standard where Google Analytics code is just thrown into a product with the assumption that there is someone somewhere that is looking at the data and producing valuable insights.

Ever since Github posted their No Cookie For You post the absurdity really made itself clear to me. We're blindly using tools that offer way too much complexity than is needed or is usable and not provide any meaningful insights on how the product is actually doing. This becomes even more prominent when working on early stage products, where the metrics are essentially the lifeblood of the product. 

How can we improve the early stage validation process by giving more consideration to the tools we use and decisions we make? 

Tools of the trade

In their post The Best Web Analytics Tool, Satchel categorizes web analytics tools into pageview-based analytics tools and event-based analytics tools. Google Analytics falls under the former meaning its primary tracking units are page views. There should be no surprise here as Google Analytics has been around longer and page views were once the hot and only web metric from which to gain insights. The latter event-based tools focus on tracking what the users are actually doing on your web app; a trait that can prove invaluable in early stages. Google Analytics does provide a custom events component but falls short in this context as it requires a lot more setup and pipelining which adds rigidity, something early stage products should try to avoid as much as possible. 

Technically there is no substantial difference in how these tools work once integrated. They all send tracking data back home in the same way. The difference is only when they send it and what they include with the message. So a page view is a message sent when a page loads and a button click is a message sent when a user clicks a button. The messages contain metadata that help the tool determine more insights. 

These insights are the real differentiators of these tools. 

Pageview-based tools, like Google Analytics, Fathom or Plausible, provide information from a visiting context e.g. where are people coming from, what demographic are they etc. while event-based tools, like Heap, PostHog or Mixpanel, give information from a usability context on how they use your app and whether they're actually using it. Being able to measure whether your solution is solving the particular problem is beyond crucial in the early stages and relying solely on page views is probably closer to detrimental than suboptimal. 

There is a point to be made when choosing analytics tools; it pays off to research and demo the tools thoroughly, as once you integrate it's not very cost effective to be changing them. Although very similar, each of these tools have some specifics in implementation and changes will most likely require development work. Make sure you commit to it. However there is another category of tools that give you this ability by acting as a middleman between your application and analytics tools. Tools such as Segment or Freshpaint allow you to send your tracking data to them and then pipe the data forward to any analytics tools you want via a graphical user interface. This gives you a lot of flexibility as the underlying integration code remains the same in your application while you can safely reroute the data to a different analytics tool if you decide to change it. It's common for these tools to also offer data warehousing and re-playability of all tracking events to a new analytics tool.

Regardless of your chosen setup make sure your analytics tools bring you meaningful insight. Just like your boards and tracking tools give you clarity on time and resources, so should your analytics give you clarity on your product performance and direction.

Death by a thousand metrics

In my experience the analytics approach to early stage products tends to fall on either end of the spectrum between doing almost nothing to doing too much. Both usually produce zero meaningful insights. 

Commonly, the analytics strategy - which consists of solely implementing Google Analytics - comes somewhere close to public release in form of a checkbox from a pre-launch checklist. This is the low end of the spectrum where nothing is really being learned or validated. Building a product this way is equivalent to stumbling in the dark and guessing which way something is. 

On the other end, there's the approach of implementing a lot of different analytical tools and pipelines while tracking everything. This produces two significant problems; a rigid analytical infrastructure that requires time and effort to update and a lot of redundant unusable data. Something to be aware of and is rarely talked about: your early stage data will probably be very limited. This is another reason as to why splurging on grand analytics infrastructure doesn't make sense. Instead, focus those resources on talking with the customers you get as that's where the knowledge you are looking for is. 

Starting out, your metrics should clearly tell you whether your product is developing in the right direction. In this sense they should be few and clear. 

Mixpanel's Suhail Doshi in his talk How to Measure Your Product suggests having no more than 3 to 5 when starting out. There's a good chance the initial metrics won't be the right ones so keep in mind that you should keep an iteration cycle going. Which metrics you are going to use and the frequency of their review heavily depends on the industry the product is in, so there is no absolute answer to this but there are references you can use. 

Your metrics should be available and easily readable by the whole team and should not require a data scientist at this point to interpret them. On this note it's good to choose a tool that provides this clarity out of the box i.e. both Fathom and Plausible give you a one page, no fuss dashboard of your page view data that anyone can read, making them a far better alternative for early stage work than the complexity of Google Analytics. 

The no cookie diet

This is somewhat astray but does touch on some relevant points. 

The user experience of the web has greatly suffered under the explicit cookie consent banners that have rendered some pages almost unusable, especially when browsing them on a mobile device. Most of these required banners come from the fact that third party analytics tools, that use cookies, are implemented e.g. Google Analytics. 

Most of the alternative analytics tools work cookie-less, meaning that if you don't have any other cookie-placing third party integration, you can safely ditch the cookie consent banner and score a lot of UX brownie points.

Expending on this, adding your own simple tracking system to your product shouldn't be ignored as an early stage solution. People are doing it. There are some caveats to consider though, like when dealing with page views you need to filter out the plethora of bots, something that the analytical tools already do well. 

If you find your metrics to be more easily available through a custom tracking solution or are running on a very tight budget, don't shy away from considering it as an approach. Just make sure you commit to it and foresee the potential (and likely) future migration that will be needed.

Take home notes

• Google Analytics is a great tool that can complement your metrics toolset, but stop blindly defaulting to it as your primary measurement tool. If you're actually going to be validating your product and its features - and you should - consider more appropriate tools. 
• If you're serious about your validation process consider a middleware tool so you can pipe your analytics data wherever you want without extra development costs.
• Choose 3-5 metrics that everyone in the team can understand and see. Consider the tool as well. Find the correct ones through iteration e.g. review them every 6 months. 
• Plan the metrics in the product or product feature spec. You need a valid way of knowing when something is successful or not. 
• Favour UX brownie points instead of third party analytics cookies. 

At d.labs we specialise in working with early stage founders, so if you need help investigating, validating, and building your idea, make sure to get in touch!