Data Analyst

Product decisions used to come from whoever sounded most certain in the room. Someone says "people bail when the signup flow has too many steps," nobody has evidence to push back with, and that becomes the plan. Six months later nobody checks whether the call was right.

Looking at numbers didn't fix it on its own. It produced meetings with three different revenue figures in them. Sales counted signed contracts, finance counted money received, and the product team counted payment logs. None of the three was wrong, and because they disagreed the room went back to arguing from instinct.

The analyst role exists to carry both halves of that problem: answering questions with numbers, and settling once and for all what each number counts. A number defined in advance so the team can judge where things stand is a metric, and defining one comes before calculating it and is usually the harder half. Count active users as anyone who logged in and the month reads 120,000; count anyone who created a document and the same month reads 40,000.

What arrives is usually an unshaped question. "Churn went up last quarter, can you look into why" is the starting point, and five steps separate it from an answer.

1. Narrow the question. What does churn mean here, over what period, for which users. Some questions dissolve at this step, because the person asking already knew the answer and wanted confirmation.
2. Pull the data. This means writing queries against the warehouse, in practice a language called SQL. It takes the most time because the table you want rarely exists as such: if payments live in one place and session logs in another, joining them comes first.
3. Distrust the values. Look for rows with an empty payment amount, or the same user appearing twice. If sessions dropped 40 percent in March, the users may not have left — the tracking code may have fallen out that month. Skip this step and the analysis produces a wrong answer confidently.
4. Extract the meaning. Group users by the month they arrived and follow them over time, or count how many survive each step from signup to payment. The common patterns are collected under analysis method.
5. Deliver it. Hand over what to do about the number, not just the number. Not "week-two churn is 31 percent" but "churn doubles only for accounts that never created a document, so put guidance right after signup."

When the same question comes back every week, the answer stops being made by hand and moves into a dashboard that gathers the key metrics onto one screen. Whether one is any good is settled by whether people do something different after looking at it, not by how many numbers it holds.

Some questions analysis cannot answer. What already happened shows you which things moved together, not which one caused the other. Those questions turn into an experiment: split users at random, show the changed screen to one side only, and compare.

Most questions arrive from the product manager, who decides what gets built and why and owns it through release, and therefore needs evidence behind every call. The common way this goes wrong is the analyst becoming a service desk working through a request queue. When the reason behind a question never travels with it, answers get produced and then go unused.

The person who prepares data so it can be pulled straight off the shelf is the analytics engineer. Joining payments, signups, and session logs into one table keyed by account means nobody rewrites the same calculation each time, and where that seat doesn't exist the analyst does the work too. The flow that carries scattered sources into one place is a data pipeline, and when last night's run failed, this morning's numbers are all off.

Questions about what will happen — which accounts are likely to leave within three months — go to the data scientist. Getting that model into the live product and running daily belongs to the ML engineer, and turning the current state into recurring reports for the rest of the company belongs to the BI analyst.

At a company of around forty people all five of these are one person. The seat that splits off first as headcount grows is the analytics engineer, because once three analysts each calculate revenue their own way, the meeting is back to three revenue figures.

"How is that number counted? Your definition of active looks different from ours."

A sign that one metric name is circulating with two definitions behind it.

"Analysis won't answer this one. We need to run an experiment."

Declining a request to read causation out of historical data.

"Don't use the March figures as they are. The tracking code was missing that month."

A warning that part of the data can't be trusted at all.

When free-to-paid conversion at Pagedeck fell for a second month, the question Mia got was one line: why is conversion down. The first thing she did was ask back rather than write a query. Overall conversion or new signups only, and does the conversion date mean the payment date or the day the plan changed.

The numbers showed the overall rate falling while no single signup-month group fell at all. Ad spend had gone up, more people had signed up through that channel, and those people had always converted at a lower rate. Nothing about the product had gotten worse; the mix of people arriving had changed. Mia sent that back along with a proposal to track conversion per channel from then on.

The most common misreading is that the job is writing queries for other people. The visible output is tables and charts, so tool skill looks like the whole of it. The time actually goes into step 1, narrowing the question, and step 3, distrusting the values — and neither is a tool skill. Both require knowing how the product and its data behave. Leave the role as a place that returns exactly what was requested and meetings fill with numbers while the decisions stay the same.

The other one is expecting the analyst to make the decision. It's the seat that produces the evidence, so the answer seems like it should come with it, but a number usually just narrows the options. Finding that one acquisition channel converts poorly doesn't settle whether to keep spending there — that depends on what the company is going after. Push the decision onto the analyst and accountability moves without the authority to reverse it moving too.