What a data analyst does

One task — three professions

On Monday Kotomarket's product owner brings the data team a single sentence:

"Buyers are coming back less often. Look into it."

Then three people do three different jobs.

The data analyst answers "what exactly is happening, and why". They slice retention (the share of returning buyers) by cuts — month of first purchase, acquisition channel, platform, city — hunting for where the drop is concentrated and which date it lines up with. Two days later: "Repeat purchases fell only in cohorts acquired through the 'food for a rouble' promo from June 1; everyone else's retention is unchanged." Tools: SQL, Python/pandas, metrics, dashboards, common sense.

The data scientist answers "who leaves next". They build a model that scores, from a user's behaviour, the probability they will not return within 30 days — so the retention team emails three thousand riskiest users instead of everyone. Tools: the same SQL and Python plus statistics and machine learning.

The data engineer answers "where do these numbers come from at all". They build the daily load: every night the app's events flow from the stream into the warehouse, get deduplicated and laid out into tables — so that by nine in the morning retention has recomputed itself and has not drifted. Tools: SQL, Python, orchestrators, warehouses.

In a small company one person does all three; in a large one, three departments. But the questions differ, and confusing them is expensive: a churn model built before anyone looked at the slices usually struggles to predict what was plainly visible anyway.

The analyst's loop

Every task travels the same circle. Each step in one sentence:

1. Question. Turn a request ("take a look at what is going on with refunds") into a question with a checkable answer and a clear cost of being wrong.
2. Data. Find the tables where the answer may live, and make sure they can be trusted.
3. Computation. Compute the metric by an explicitly written rule and break it down by slices.
4. Conclusion. State what the numbers prove — and what they do not.
5. Recommendation. Propose an action with a price and a deadline.
6. Follow-up. See what changed after the action — and go back to step 1.

What "check the data" means

This is the one step beginners skip — and the one that separates an analyst from a person with a calculator. It is five questions to the table.

• Completeness. Are all the days there? Any days with suspiciously few rows, or none? A hole in the data looks on a chart exactly like a catastrophe in the business.
• Freshness. When was the table refreshed? The last, incomplete day almost always lies downward — it simply has not ended yet.
• Duplicates. Did an event arrive twice? Did rows double after a join? Duplicates always push a metric up — which is why they feel pleasant until you check.
• Grain: what is one row. An order, an order line, or a delivery? Get it wrong and revenue triples while nobody notices, because the number "looks plausible".
• Consistency. Does the number match a neighbouring source? Orders in events versus orders in the production DB: a 1% gap is fine, a 40% gap means stop — first work out which of the two is lying.

L., entry #11: "Until you know what one row equals, you are not computing a metric. You are adding up something you do not understand."

The ladder: from observation to decision

In conversation "observation", "conclusion" and "decision" melt into one word. At work they are separate floors, and confusing them means either panicking early or taking on somebody else's responsibility. Let us walk a case from L.'s journal.

Floor 1. Observation — what you see, no explanations.

DAU: 4,200 → 2,950 overnight   (−30%)

This is not yet a problem, nor a finding — it is a fact that demands an explanation. Here you may neither panic nor reassure.

Floor 2. Finding — where the drop actually sits. Slice by platform:

platform    before     after   change
iOS          1,000       980     −2%
Web            560       566     +1%
Android      2,640     1,404    −47%   ← almost the entire drop is here

Slice Android further — by app version:

version     before     after   change
4.11           920       920      0%
4.12         1,720       484    −72%   ← and here

The finding: the drop is entirely inside Android, and entirely inside version 4.12. Note this: the overall metric fell 30%, yet nowhere is there a 30% drop. Part of the audience did not move at all, part collapsed by nearly three quarters. An average always hides exactly the thing you need to find.

Floor 3. Interpretation — a version of events tied to an external fact. Release 4.12 shipped the previous evening; it rewrote the launch screen. There are exactly two explanations: either the app became so bad people stopped opening it, or the new version stopped sending app_open. The second is testable with a neighbouring metric:

purchases from Android 4.12:  124 → 121   (−2%)

The people are in the app, buying like yesterday. It is the event that is not arriving.

Floor 4. Conclusion — what is proven, with its limits.

"The 30% DAU drop is fully explained by Android 4.12 users. Purchases in that same group are unchanged — so the audience was not lost; app_open tracking broke in release 4.12. DAU figures from March 12 onward are unreliable."

A conclusion always states what it does not claim: we have not proven that 4.12 did no harm to the product at all — we proved the DAU collapse is not about the audience.

Floor 5. Recommendation — what you propose to do, with a price and a deadline.

"Do not roll back the release for the sake of a metric: the product works. Ship a tracking hotfix — engineering estimate one day. Recompute DAU for March 12–14 from purchases and flag those days in reports as incomplete."

And only then — the decision. It is made by the product owner, not the analyst: they hold the resources, the priorities and the responsibility for the outcome. They may agree, may choose a rollback to calm the board, may push the hotfix to the next sprint.

The analyst is accountable not for the decision but for it being made in full knowledge of the facts. The flip side is nicer than it sounds: you do not need to know "what the company should do" to be useful. You need to know what is actually happening — and say it so that people hear it.

What interviews ask about

Requirements vary from posting to posting, but the set of topics for a junior role is nearly the same everywhere.

A take-home assignment is almost always a separate stage. The typical wording:

"Attached are two files: 90 days of app events and a user directory. Compute daily DAU and weekly-cohort retention, then find and describe an anomaly. We expect a notebook with the code and 3–5 slides of findings for the product team. Deadline: 3 days."

They are not measuring coding speed but three things: whether you spot the anomaly, whether you think to sanity-check the data before computing, and whether you can compress the result into five slides a person without SQL can follow. That is exactly what the rest of this course is built from — and by the final chapter you will have your own solved case.