Getting Started With Analytics

Your Analytics Tool Should Get You to Product-Market Fit

Your analytics tool should enable you to get all the way from your first visits to product-market fit. If it can’t, you should change tools.

Easy Metrics may lead to Vanity Metrics

There’s a wave of tools being sold that are hitting the notes of “privacy-friendly” and “easy.”

Privacy-friendly is, in isolation, a good thing, but it can also lead you astray if your users care about privacy much less than you. Unfortunately, Privacy-friendly tools make design decisions that constrain what information they can give you.

As an analytics practitioner, I’m happy to be seeing interest in good UX for analytics. However, if all a tool shows you is visits and pages and referring domains, that’s not giving you sufficient wisdom to act. Without sufficient information, all you have as a result are vanity metrics.

You deserve more

You deserve to understand usage of each of your features. Specifically, you should be able to correlate them with customers at specific points in the lifecycle, which means your tool should be able to understand when your customer first arrived. Were they on your site yesterday? A week ago? A month ago? A year ago?

You deserve to know how well your messaging is working. For example, that means your tool should display to you conversions downstream of an acquisition channel or a landing page. (The “downstream” bit, which involves persisting values throughout sessions, can be a tricky point for privacy-forward tools.)

You deserve to know how well your marketing campaigns work, paid or non-paid. Put another way, your campaign parameter(s) should work all the way from the first arrival to the first payment.

You deserve to know when app failures get in the way of people giving you money (or causing them to churn). You should be able to send error events in a custom variable and respond to individual users with apologies or discount codes. Additionally, you should be able to read these error events from a very fast API, to know if errors are spiking.

You deserve power

The new wave of small, light, privacy-forward tools is very new, and some of them will continue to add to their feature sets (while prioritizing a pleasant UX). That’s great, but I believe they are not yet ready for prime time.

I have tools that I recommend. But, regardless of which tools you choose, consider prioritizing power as a key differentiator.

You will likely need it to reach product-market fit.

Interested in analyzing your way to product-market fit?

My book, Analytics for Indies, will show you how to set up three market-leading analytics tools just like they’re used by billion dollar e-commerce and SaaS companies. And it takes less than a day to set it all up, using the easy step-by-step guide in the book.

Sign up now for four free tips to get started. I’ll also throw in a free cheat sheet that tells you which tools to use.

Getting Started With Analytics

The 6 events that will complete your analytics

It’s a frequent question, asked in a variety of ways. Here are two:

  • How do you measure user engagement?
  • What user events should I be capturing?

I’ve been making events happen in large businesses like PlayStation and Rakuten since 2012. I estimate I’ve had a hand in over 1 trillion events being sent.

Even at high scale, events boil down into about 6 types. I’ll give a quick runthrough of each and a small taste of their benefits.

Let’s dive right in:

The Page View

The page view is the most basic unit of app analytics tracking. It’s incredibly versatile.

In almost every analytics tool, this is what you get by dropping in the standard snippet of code. The ROI of dropping in that code is huge given how many benefits there are and how little effort it takes.

Let me divide up some benefits into pre- and post-conversion.

Before conversion

Prior to conversion, when you’re looking at content viewed by prospective customers, you can see a few things quickly.

  • You can see where customers are landing, and where they most commonly navigate to next. That tells you what pages are valuable.
  • Even without any additional events, you can look at the number of people who reach your checkout/signup page, and even how many people have purchase confirmations or start using your app, and get a rough conversion rate with no additional effort.

After conversion

After signup, you want to focus on what your newly onboarding customers are doing.

  • What proportion of customers proceed to do something important right away to get value out of your product?
  • How many fall out of the funnel right there instead?
  • Do any customers come back later and do that important thing?
  • Are there patterns in where users navigate? Are they missing content that’s really important to their success with your product?

Just looking back up at those sets of bullets, that’s a lot of goodness to get out of the humble Page View.

The Purchase

As the wise Amy Hoy writes, “stay close to the money.”

The Purchase event lets you do that.

But wait, I hear you say. Can’t I get this from Stripe?

In some cases, yes. When you want to examine your MRR or ARPU, I definitely recommend looking at Stripe or Baremetrics. In fact, I’ve written before about the difference between Stripe/Baremetrics and Google Analytics for revenue metrics.

But there are a ton of other ways you need to examine your revenue. In those cases, you benefit from having (at least some) transactions in your analytics tools:

  • Which campaigns lead to trials/subscriptions more often?
  • What kind of feature usage correlates with converting from trial to paid?
  • Do users who churn have something in common?
  • What errors or app failures are costing me money?

These questions all have in common the need for analytics data, such as tagging marketing campaigns individually, capturing feature usage, or capturing errors.

The Campaign

A campaign code lets you organize all your inbound traffic, so that you can categorize (and understand) all your efforts to gain traffic.

Tiny technical sidebar: in code, campaigns don’t get their own event. They are properties added to existing events, particularly Page Views and purchase events.

Suppose you have four major ongoing efforts to gain traffic:

  • An email list
  • Facebook ads
  • Reddit non-paid posting (e.g. your own posts/comments, starting a community subreddit, etc.)
  • Reddit paid ads

If you use campaign codes on all of the links from those efforts back to your app, you can then slice and dice all of them to know what’s most valuable, and when and where.

It may seem like a lot of work, but it lets you answer really valuable questions like:

  • Which efforts drive the most eyeballs and awareness?
  • Which efforts drive conversion most effectively?
  • Among my paid ads, which service is more economical?

User Interactions

In the classical analytics world, lots of people call this “clicks” – what are people clicking on and interacting with on the screen?

At PlayStation we started calling them User Interactions because most of the time, our customers don’t use mice.

More importantly, this is a totally standard event that lets you see what happens on the page. If you have a submittable form and a video trailer, you can find out which one your users interact with more often.

And by combining this event with the Purchase event I from above, you can find out if one is more valuable to conversion than the other.


Error events can be a life-saver, even if you already have infrastructure monitoring in place.

If there’s an error that faces the user, that’s a great time to send an event with it.

This lets you do three super important things:

  • When a customer is logged in, you can know who is experiencing a problem, so you can proactively reach out to them.
  • If your visitor is a prospective customer, you can find out if/when there’s something blocking them from giving you money
  • If your tool has real-time support, you can monitor this metric and be aware of increasing problems. (Shout out to fellow indie creation GAInsights for linking that monitoring to your Slack instance!)

Everything else

I admit, it’s a bit of a cop-out to have a listicle of 6 event types and have the last one be a catchall.

But importantly, every app is different. Here’s a short preview of other things you might want to capture, if your app has them:

  • Have streaming video or audio? You can capture a heartbeat event every 30-60 seconds to know how much of your content is being consumed
  • Have social networking features? You can expand the definition of User Interaction to include adding friends, following people, publishing posts, or hitting the Share button
  • Is your app all about long-form text? Do you have those cool super-long, story-driven landing pages? You can capture scroll depth to know how much of a story is being read
  • Do you have an e-commerce app? You should absolutely capture the e-commerce classics: adding something to the cart, every checkout step, payment method management. Also, store searches and promo code usage will let you into people’s heads so that you know what they want and what triggers a buying decision.

Where might your app’s magic be? Use these events to find out.

How about a step-by-step walkthrough to go 0-to-100 in half a day?

My book, Analytics for Indies, is exactly that guide.

Each one of the event types I’ve written about in this post gets its own chapter, with code samples that can go straight into your app.

Sign up now for four free tips to get started. I’ll also throw in a free cheat sheet that tells you which tools to use.


Your users care less about privacy than you think

Content warning: This post is full of heresy.

The indie software community is marching off in the wrong direction about privacy.

On forum posts discussing analytics tools, the discussion invariably turns to privacy. One of two things happens, and the result is the same:

  • Someone asks for tool recommendations, while expressing a preference for privacy
  • Someone asks for tool recommendations, with no other opinions given, but commenters immediately reply recommending privacy-centric tools from small shops.

I think this is one of the biggest misconceptions when it comes to analytics on forums like Indie Hackers. That community loves privacy, which is great. But members of the community, who are business owners, also project personal preferences on to their users and on to consumers in general, which is a logical fallacy.

Your privacy preferences are not those of your users.

My day job, in which I see the opt-in rates for 100 million users, has convinced me of this. I am not at liberty to disclose precise numbers, but they are beyond sufficient to convince me in a personal capacity that most consumer bases are less concerned than you are.

You still have privacy obligations.

If I’m giving advice to aspiring entrepreneurs, I steadfastly maintain that you do have to comply with privacy regulations that apply where your customers are. The most famous is the European Union’s GDPR. California’s CCPA shows that more are on the horizon, and that this is a tide that can’t be turned back.

If I’m giving advice in my day job, I also steadfastly maintain that customer privacy cannot be compromised. We have tight controls on what information can go where, and who can access what. The reasons are various: regulatory compliance, security, keeping within vendors’ Terms of Service, and fuzzier ones like PR/image.

However, none of the above prevents me from counting a unique user by way of a cookie. But there are privacy-centric analytics tools out there that prevent that, by removing cookies from their design. I think it’s a step too far to be deprived of such a simple metric.

Privacy is a sliding scale, not a binary.

Analytics tools are not either inherently “private” or “not private.”

Analytics tools sit on a sliding scale of “more private” to “less private.”

How private is “insufficiently private”? Well, that’s up to your individual opinion.

Personally, I think tools that track user activity semi-anonymously (including Google Analytics, Adobe, and similar cookie-based systems) are fine.

I individually draw the line at:

  • User session recording without permission (because that tends to “feel creepy” to users)
  • DMP solutions, mainly used in the adtech world, which collect large amounts of traits about you expressly for commercial purposes.
  • Cat-and-mouse games of vendors trying to avoid privacy innovations. Apple’s Intelligent Tracking Prevention is a valid pro-privacy initiative that it sells to customers as a feature of Safari (and therefore, a feature of iOS and macOS). Meanwhile, large vendors like Adobe continue to work around new measures, resulting in a never-ending battle.

The company that gathers no data will be beat by the one that gathers some.

If you and I launch competing products, and you refuse to use analytics while I embrace them, I assure you that I will crush you in competition.

It’s certainly possible to gather too much data about customers. But it’s much more dangerous to your business not to gather enough.

Getting Started With Analytics

The Metrics You SHOULD NOT Use

Analytics systems make a delightful amount of data available quickly. Unfortunately, that may lead you astray and burn lots of your time as the owner of a small software business.

Here are some common issues I’ve seen among communities like Indie Hackers, and while onboarding users in my work at PlayStation, and how to handle them so they give you the insight you really need.

Don’t look at Total Visitors or Total Visits. Split them into New vs Customers Instead.

Let’s start with the biggest, highest-level, most visible, most KPI-able metric that you could see: your total visitors (or total sessions, for that matter).

Consider that your business gets some customers and starts making a little money. Your number of Total Visitors is steadily climbing. In this example, is your business healthy? 

I can tell you one thing for sure: you don’t know. 

Total Visitors could be capturing your increase in customers. Or it could also be capturing an increasing number of visitors who aren’t converting, which signals that you have problems with your landing pages and that this is bad for your business.

Put another way, the metric could be giving you good news or bad news, and you don’t know which.

That problem is worsened for Total Visits, because there’s one more variable in the equation: how frequently do your paying customers visit?

The one metric you are watching really should be separated into two

  • Your website’s new visitors
  • Visits by existing customers

Having those two numbers side by side is going to be more convenient for you to quickly get back to work on your business. Here’s why:

  • Looking at the number of new visitors will tell you at a glance how your traffic acquisition efforts are working. Is the number going up? Great! At any conversion rate above zero, that will probably equate to growth for you.
  • Looking at the number of visits by existing customers will tell you a sort of combination of how many customers you have, and how sticky your app is. Is the number going up? Great, you have growth! Is it going down? You probably have a churn issue.

The above samples explain the actual goal of analytics. It isn’t to make a dazzling amount of numbers or visualizations appear. It’s to get the information you need as quickly as possible to run your business. 

Don’t look at your conversion rate as a percentage of Total Visitors. Base it on Non-Customers Instead.

If we’re segmenting our visitors overall, we want to do the same for our conversion rate.

Too many people create a quick calculated metric that looks like:

Signups / Total Visits

But this is problematic, because if you have growth you’ll accidentally create the illusion that your conversion rate is falling.

Huh? Isn’t that crazy?

Another way to express the above metric would be:

Signups / (Visits by Non-Customers + Visits by Customers)

Note that “visits by customers” is in the denominator. When you gain more customers, overall denominator for your conversion gets bigger, and your conversion rate artificially falls.

We actually want to know how well your site is turning non-customers into customers. So let’s focus on them, and restate our conversion rate as:

Signups / Visits by Non-Customers

This is a number that you can watch over time. Even when your customer base grows over time, your conversion rate can be used to look specifically at how well your introductory content is creating new customers out of new visitors.

Don’t Monitor Page Views as a KPI

In the early days of the Internet, we counted “hits” to a page or site as a sign of its popularity. We intuitively knew that more hits was better.

Back when the Internet was almost entirely static HTML content, that was fine.

Now that we have SaaS apps, it’s hard to draw meaning from Page Views going up.

Let’s play a tiny game. Any of the following scenarios could result in Page Views increasing. As you read through the list, sort each scenario into “good news” or “bad news”:

  • You’re on the front page of Hacker News
  • Users are encountering a fatal error and they’re refreshing the page repeatedly
  • You acquired 100 customers this week
  • Your ads started running
  • You rolled out a new feature that is a multi-page process

Did that get tougher as it went on? Perhaps you answered a couple with “I don’t know” or “it depends”?

That ambiguity is exactly why you shouldn’t use Page Views in isolation.

There could be a case where looking at page views of a certain subset of your content may make sense. But the lesson here is that as a rule, you should start from the broad question of “what do you want to know?”. From there, you can back your way into a metric that specifically illustrates the case in question.

Don’t monitor Bounce Rate as a KPI

Bounce Rate is another metric that hasn’t aged well.

If you’re unfamiliar, Bounce Rate is the percentage of people who leave after a single page view.

This was fine back in Web 1.0 when pages weren’t super interactive.

Google Analytics’s bounce rate documentation explains the problem. As soon as your page sends a second call to the tracking server for any reason, the visit is no longer a bounce.

As a result, for most people Bounce Rate is perpetually deflated.

For example, any of these things could quickly send a second call, if they’re instrumented:

  • Page scroll depth plugins
  • Video playback
  • A form submission or button click
  • Moving to another section of a single-page application (SPA)

In short, the technology isn’t doing what we intuitively think it should do.

(Side note: Google Analytics isn’t the only tool that has this tricky definition.)

There is one place where it’s OK to use Bounce Rate: you might consider monitoring the bounce rate strictly from your landing pages.

Bounce Rate is, by its definition, a metric that leans toward being used at the “top of the funnel” – that is, when someone is a new potential customer and doesn’t deeply know you or your product yet. (It wouldn’t make sense to look at the bounce rate from your loyal customers, right?)

So you could use Bounce Rate when looking just at the content that’s used as your landing pages. That gives you a reliable number to watch over time and try to improve.

Look at this instead

It’s my book, Analytics for Indies.

(Real subtle plug there, right? Hey – you’ve read this far – I’m optimistic this book will be of interest to you.)

Your business deserves clear and consistent metrics that are quick and easy to check, so you can get back to running your business.

Each chapter has one event of tracking that you can install to take you all the way to tracking that’s on par with billion-dollar e-commerce sites. With each chapter you’ll get one key metric to watch in your dashboards.

The goal for this book is to take you from “not sure what to do” to “done” in a couple hours, with future-friendly analytics data capture all set up.

Sign up now to be notified when the book releases, and get a free email course with four quick wins and a freebie cheat sheet that tells you what tools to use. The only way to get the cheat sheet is to sign up!

Getting Started With Analytics

Why You Should Use Multiple Analytics Tools

In my work at PlayStation, I frequently get asked why the same metric isn’t identical between two tools. 

There are always precise technical reasons why they aren’t – for example, revenue may not be the same in two systems because each one calculates exchange rates slightly differently. 

That’s not what this article is about.

More importantly, I don’t mind these differences and you shouldn’t either.

Instead, use multiple tools and leverage each one for what it’s best for.

For the purposes of this post, I’ll use a simple example. Let’s suppose I have an indie software business, and I currently have Google Analytics and Baremetrics hooked up.

Why you should care: seeing money from all angles

If I want to get a complete picture of my revenue, I should be using at least two tools. Maybe even more.

But getting back to our example…

Baremetrics shows me really big-picture metrics, like MRR (monthly recurring revenue).

My overall MRR metric is super important. It’s a single metric that shows the size and health of my business. You gain a lot of knowledge from the single number. It’s fitting that MRR is the headline number attached to any business on communities like Indie Hackers.

Google Analytics would struggle to show me MRR, because GA only gets data that’s sent from a user browsing my app. So if a subscription quietly renews and my user isn’t around to send me a “subscription renewed” event, GA can’t “see” that happen.

Kind of like a tree falling in the woods: GA can’t “hear” it, so it didn’t happen.

It’s possible to get GA to show this information, but it doesn’t make logical sense to put the time or effort in to do it when you already have a tool that can reflect the “primary source” data. (That would be all of the subscriptions and their individual charges, all sitting conveniently at Stripe, and fed in to Baremetrics.)

Google Analytics shows me unique things too, though.

Likewise, there are things that GA does see that Baremetrics doesn’t, because GA is measuring what your visitor is doing in their browser.

To turn the comparison around, Baremetrics could show me the conversion rate of each marketing channel. (For example, comparing the value of ads on each of Twitter, Instagram and Reddit.) But it would be a ton of extra work compared to GA. GA has that data on hand thanks to referring information, and a couple more bits of information that are easy to set in code to send.

So, it’s pretty easy to argue that I need both as an indie software business owner. 

This GA-vs-Baremetrics distinction can be generalized to a wide variety of the metrics you may want to see in your day to day operation.

When to use Google Analytics

Google Analytics is best suited to understanding users in aggregate, relating to their activity on your site or in your app. Use GA to answer questions like:

  • How many visitors does my site have?
  • What is the proportionality of visitors from the places where I’ve done marketing?
  • How many signups (or how much revenue) comes from each of my marketing channels? Are visits from one channel more valuable than others?
  • What patterns of navigating my site are the most common? From which pages do users leave more frequently?
  • From where in a funnel are users most likely to leave?
  • What is the device distribution of my visitors?

There’s a lot more that GA can answer, but I have to stop that bullet list somewhere.

When to use Baremetrics (or Stripe Dashboard)

Baremetrics (or, for a starter utility that’s free, the Stripe Dashboard) is well-suited for questions that look at your business’s money flows from a very high level (almost like a 21st-century version of business accounting):

  • What’s my MRR right now, and what was it last month?
  • How much is one user worth? (What’s my ARPU?)
  • What’s my churn right now, and what was it last month?

There are more tools and more use cases

In my upcoming e-book, Analytics for Indies, you’ll see more use cases. For example, still other tools aside from these two might let you:

  • See an individual user’s stream of events (useful for detecting technical problems, UX problems, or fraud)
  • Attach geography to the stream of events (useful for detecting account sharing)
  • Create a collection of users meeting a certain condition
  • Compare collections of users, or message one cohort with highly targeted information (such as pointing out an as-yet-unused feature during an onboarding period)

If you’re an independent software owner who wants to have well-rounded analytics and quickly, you’ll want the e-book.

The goal for this book is to take you from “not sure what to do” to “done” in a couple hours, with future-friendly analytics data capture all set up.

Sign up now to be notified when the book releases, and get a free email course with four quick wins and a freebie cheat sheet that tells you what tools to use. The only way to get the cheat sheet is to sign up!

Getting Started With Analytics

Lessons from Billion-Dollar Analytics that Indies Might Find Useful Too

Hey there. I’m Blake Ellison, and I’ve spent the last five years at PlayStation building a new analytics program there. In that time, we’ve found a number of patterns that we’ve turned into processes for our team.

I’m going to share some of those patterns and processes here and what they mean for indie software creators.

If you’re an indie, then chances are pretty good you’re not yet at that size. But there are lessons from these practices that you can start with now.

Measure Everything!

First and foremost, Measure Everything! Don’t release something without any tracking installed – it will be impossible to validate its success.

Even in big business, people like product managers make the mistake of shipping their feature without analytics, who then have nothing to show for their feature’s success in front of executives. Like it or not, business decisions (that make or break careers) are made from the cold numbers, not the glowing Reddit comments.

Lesson for Indies: You should commit to basic analytics for whatever you release. There are great tools with free tiers.

If need be, explicitly budget in time for analytics as a component of whatever feature you’re working on.

Get the low-hanging fruit

There’s so much you could track: page views, interactions on page, form completions, e-commerce actions, video playback, user identities… there’s a lot.

But you don’t need every single thing for Launch Day.

Lesson for Indies: You can logically put these tracked elements in a priority order and add to your tracking over time.

You need to know some things more than others. For example, you need to know how much revenue you earned much more than how much of your promo video was played. Likewise, you should track which page the user is on, before starting to do additional work to track what interactions users had on each page.

Most analytics tools will by default send a page view event when the standard cut-and-paste JavaScript snippet is fired, which means you get that “for free” (in the technical sense, meaning you don’t have to go to additional work). It’s a great place to start.

Want a complete guide to what to install and in what order? The Analytics for Indies E-book has it. Sign up to be notified the instant it’s published.

Test Your Analytics Too

Data quality matters massively when your app is going out to tens of millions of users.

Our nightmare scenario is that an app goes out with a bug and then millions of users start sending in junk data. Worse than just shipping a bug, that junk data gets commingled with our existing high-quality data. And it’s nearly impossible to remove the junk data – once something is sent in to your analytics tools, it’s in there.

So, our team performs manual QA for every feature that goes out, because we’re highly incentivized to avoid failure.

Lesson for Indies: Test your analytics capture just like you would test your app’s core functionality. If your analytics were to fail, you’d be getting misinformed about the health of your product and what is most popular/successful. Most analytics tools offer debuggers to ensure you’re sending what you expect to. Test this in your dev or staging environment. Just like your core functionality, if you ship something with broken analytics, don’t be afraid to roll back.

Define Your Data

At scale, we operate a “self-serve” model. That means that hundreds of users throughout the company log in to our analytics systems to find out what it is they uniquely want to know. Whether someone is looking for their pet feature’s MAUs or load time performance, everyone wants to clearly understand the specific meaning of the metrics they’re seeing.

Here’s a practical example: most tools have varying definitions for what sequence of events constitutes a “visit”. Did you know that Google Analytics increments a visit when the clock strikes midnight, even if it’s just really one physical visit spanning across midnight?

At PlayStation, we put more and more time into creating data dictionaries that explain data with human-friendly language.

Lesson for Indies: You have so much going on that you shouldn’t have to keep all the ins-and-outs of your analytics tool in your head. Explore your tool’s definitions in the documentation and bookmark them for reference.

Make a Playbook from Your Process

As part of BigCo life, we had to fit into the Agile-like framework used company-wide.

After much negotiation, we settled on a workflow that broke up our work into discrete phases. This workflow had the benefit of being easily understood by all, and could be reflected in JIRA.

The details of that playbook are too boring to put here. But the point is that the process of adding analytics to a feature has a few building-block steps of work. Those steps can be documented, tracked, and taught to new employees.

Lesson for Indies: If you’re the kind of person who has an organized workflow, or finds checklists productive, you can templatize the addition of analytics to your new feature. This makes the work more predictable and controllable.

There’s An E-Book Coming

I’m writing an E-book to walk you step-by-step through setting up flexible, future-ready analytics for your project. Sign up now for four free tips to get started. I’ll also throw in a free cheat sheet that tells you which tools to use.

This E-book will show you, step-by-step, how to set up great analytics for your project. My experience with billion-dollar apps will ensure that your setup is stable and ready for the future.

The book is in progress, and here’s a preview of the chapters planned:

  • Which tools to use, and how to set up the accounts
  • Setting up basic code
  • Tracking revenue and why you should do it
  • Tracking unique users (in a way that respects privacy)
  • Connecting marketing campaigns and traffic sources to Revenue
  • Tracking errors, so that you know what blocks users from paying you
  • Tracking other interactions – is that video trailer valuable?

In all, you can accomplish in a couple hours what an analytics engineer would charge tens of thousands of dollars for.