Analytics Engineer

With one analyst, however revenue gets calculated, the company has exactly one revenue number. The trouble starts at three.

Pagedeck had that meeting. Two people brought last month's paid revenue: one said $215,000, the other said $238,000. One had excluded refunded charges, the other had counted everything at the moment of payment. Neither was wrong, an hour went into reconciling the two figures, and nobody got to the question of why revenue was at that level at all.

The cause wasn't the people, it was a missing seat. Data engineers build the data pipeline that pulls raw records together in one place, but raw records aren't shaped for a person to read. A single purchase is spread across several rows and refunds live in a separate table. Reshaping that into something usable happened over and over, once per analyst per question. So the same calculation existed as many times as there were people writing it.

The role exists to hold that middle ground. Do the calculation once, get everyone to use it, and that's the whole job.

The day usually opens by checking whether last night's transformation jobs finished. They're scheduled to read the raw records overnight and rebuild the tables, and a single renamed column upstream stops them. If they're still stopped in the morning, yesterday's figures are missing from the dashboards. Actual work moves between five things.

1. Fix the broken run. Find where it stopped, absorb whatever changed upstream, rerun. On some days this takes half the day.
2. Build new tables. A request like "one row per account with signup date, first payment date and last login" becomes a table, and every later version of that question is answered by reading it.
3. Settle definitions. Counting active users as anyone who logged in versus anyone who created a document splits the same month into 120,000 and 40,000. Which one is right isn't decided in this seat — it's agreed with the people who use the metric and then written into the code once.
4. Add checks. Rows with an empty payment amount, or one account arriving as two rows, skew every calculation sitting above them by a little. Data quality checks are attached so those rows halt the job and raise an alert instead of passing through.
5. Write it down. Each table gets notes on what its columns mean and when it refreshes. Without them, even the author can't say six months later why a condition is there.

The working style is closer to software engineering than to analysis. Calculations live in code, changes get reviewed by someone else, and the history is kept so any earlier state can be restored.

Other roles sit on both sides, so much of the day goes into other people's requests and other people's changes.

Upstream is the data engineer, who carries raw records as far as the analytical data store. When structures change on that side, the tables here collapse with them, which is why the two sides agree to announce changes before making them.

Downstream are the data analyst and the product analyst. They're the ones actually querying the tables, and requests for new ones come from them. Dashboards built by the BI analyst — the BI dashboard everyone opens on Monday — usually sit on the same tables, and the data scientist pulls training material from them too.

Alongside are the people building the product. Theo and the analytics engineer decide together what a new feature should record. Records can't be created retroactively: knowing how many people pressed the share button last month requires that the logging already existed last month. With Mia, the shared work is metric definitions, since how to count active users is a product question rather than a technical one and doesn't get answered from this seat.

"Which table did that number come from? The same calculation is already in the shared one."

Stop rewriting the same logic and read it from one place.

"Tell me before the payments table changes shape — it stops the nightly jobs."

A change upstream takes down every table built on top of it.

"Give me the definition of active user and I'll pin it in the code."

The counting rule is the product's call; holding it in one place is this role's.

Since that meeting, Pagedeck keeps revenue in a single table. The figure excluding refunds and the figure including them are separate columns, and whoever reads it chooses. The two numbers still differ, but now a meeting can see in one line where the difference comes from.

New metrics follow a set order. Mia writes down what she wants to count, the definition gets sharpened together, and once it's in code it runs alongside the old method for a week to see whether the values diverge. If they do, the definition isn't settled yet and the two sit down again.

The most common misreading is that this is the same job as data engineering. Both build tables and both write code, so from outside they look alike. What differs is the subject. A data engineer builds the path data travels — what moves from where to where and how often — and keeps that path from stopping. An analytics engineer works on the meaning of what arrives. How revenue should be counted is a question at the far end of the path, and the near end can't answer it. Without that distinction, nobody in the organization owns definitions and tables simply multiply.

The other misread is treating it as an analyst who writes good SQL. Plenty of people arrive in the seat from analysis, which makes the assumption easy. But a calculation written once and thrown away and a calculation that runs unattended every night demand different things. The second has to stop on its own when the source changes, keep a record of every edit, and be readable enough that someone else can tell six months later why it was written that way. Staff the seat without understanding that difference and the tables pile up in a state nobody can touch, until the analysts go back to calculating separately.