How Do You Analyze Product Data and Logs? Tracking Basics for PMs and Marketers

When you run a service, phrases like “can you pull some data?” and “what’s our conversion rate this month?” come up constantly. If you’re a PM or a marketer, you meet them every day. Yet where that data comes from, and how it differs from logs or metrics, is surprisingly easy to gloss over.

In this post, I’ll unpack, without any code, how the data and logs a service leaves behind pile up, and how they turn into metrics and analysis.

A log is the diary a service keeps #

While it runs, a service constantly leaves records. It writes down, in chronological order, who connected and when, what requests came in, and where errors occurred. This is a log. It’s much like a diary the service writes for itself.

A log is the first record you look at when something goes wrong. When there’s an outage, you trace back through the logs to find what error happened at what minute and pin down the cause. It usually goes unnoticed, but it’s the rawest data, holding what actually happened.

An event records what the user did #

If a log is a record the system leaves automatically, an event is a deliberately chosen record of a user’s action. It captures individual actions as data: pressed a button, finished signing up, added a product to the cart.

These records don’t accumulate on their own. They only gather if you’ve set up in advance, “when this button is pressed, leave a record.” A widely used tool like Google Analytics helps with this. So when a marketer asks you to “add an event to this button,” it means: get ready to count that action from now on. The important point is that an action you didn’t instrument can’t be counted retroactively.

A metric is a number that summarizes data #

If logs and events are individual records, a metric is what you get by gathering them and reducing them to a single number. The number of people who signed up in a day, the share of visitors who actually bought (the conversion rate), the count of users who stopped by at least once in a month — scattered records combined into a meaningful figure.

The reason metrics are needed is clear: you can’t pore over millions of lines of records as they are. Just as you gauge health with height and weight, you read a service’s state quickly through a few metrics. That’s why metrics like conversion rate and return rate come up daily in marketing and planning.

Analysis starts with a question #

Piling up lots of metrics doesn’t immediately amount to analysis. Analysis usually starts from a question. A question like “why do people drop off when they’re close to signing up?” comes first, and you dig into the data to find the answer.

For example, you split the signup process into steps and see at which step the most people drop off. This is often called a funnel, by analogy with the shape. You fix the step you found, then look at the metrics again to confirm whether it improved — that flow is analysis. A dashboard is a screen that gathers these metrics so you can see them at a glance.

Doubt the numbers once before you trust them #

Data is powerful, but it isn’t always right. If you instrument an event incorrectly, the wrong numbers pile up, and the decisions built on top of them go off course as well. So when a number looks odd, it’s safer to first check whether the data was collected properly before you revise any conclusion.

There are also numbers that look impressive but don’t connect to real results. For instance, even if total visitor count jumps, it means little if it doesn’t lead to purchases. Such numbers are often called vanity metrics. Deciding in advance which numbers really matter is where analysis begins.

Why this makes work easier for non-developers #

• You make precise requests. Instead of a vague “pull the data,” knowing which event must be instrumented to produce a given number makes the conversation with developers faster.
• You read metrics properly. Knowing what a conversion rate or return rate sums up keeps you from being swayed by a single number and lets you see the context too.
• You prepare ahead. Knowing that an action you don’t instrument now can’t be counted later, you can build measurement in alongside the feature.

Wrapping up #

Today we looked at how the logs and events a service leaves behind get summarized into metrics, and how that leads to analysis that starts from a question. The big picture is the distinction: a log is the diary the system keeps, an event is a chosen record of user behavior, and a metric is the number that summarizes them.

If you’re curious how logs are used in incident response, read Bugs, Hotfixes, and Rollbacks; if you want to know about validating hypotheses with metrics and shipping small, read Agile, Sprints, and MVP.