BI Analyst

Small companies don't need anyone to own the numbers. Curious about revenue, someone opens the billing system. Curious about signups, someone asks an engineer and has an answer before lunch. That arrangement breaks somewhere past forty people. Five teams show up to the weekly meeting each carrying their own figures, the same item calculated three different ways, and half the meeting goes to arguing about which one is real.

The title comes from business intelligence (BI), a term covering the work of turning accumulated data into a form the organization can act on. Did revenue grow since last week? Which pricing plan is losing customers fastest? A BI analyst prepares answers to questions like these in advance, because they get asked again and again.

Two problems pushed the role into existence. The first is repetition: whoever asked for last month's signup count asks again this month, and someone spends thirty minutes on it every time. The second is drift. The person handed a rush request calculates it whichever way is fastest that day, so the same month's signups come back as 4,200 once and 3,900 the next time.

A BI analyst removes both at once. Recurring questions get wired up to answer themselves, and those answers get pinned to one fixed calculation. Among the five roles in data and analytics, this one stands at the end of the line, where results are set down in front of the rest of the company.

The day opens with a look at the dashboards, and the point isn't to read the numbers. It's to confirm they arrived. Zero signups yesterday almost never means signups stopped; far more often the data didn't land. Before touching any formula, check whether the data pipeline failed overnight or an app release dropped some event tracking.

The rest of the time splits roughly four ways.

1. Publishing recurring reports — the same format goes out on a fixed weekly or monthly date. Not a wall of numbers: the two or three things that moved since last week each get a line of explanation. Without those lines, readers look at the table and decide nothing.
2. Building and maintaining dashboards — building the screens people ask for, then keeping the existing ones correct. Maintenance is the larger half. Change the pricing plans or adjust a metric definition and every screen that uses it has to be found and fixed.
3. Handling one-off requests — "can you pull just the teams that converted from free to paid last quarter?" arrives most weeks. When the same request comes in a third time, the answer stops being a pull and becomes a screen.
4. Documenting definitions — how an active user is counted, when a refund hits revenue. Written down and parked next to the screen. Most disputes about whose number is right end with that one page.

Upstream sit the people who prepare the data. An analytics engineer consolidates scattered records into account-level tables, and the BI analyst builds screens on top of those tables. Without that groundwork every screen carries its own formula and the numbers split apart again. At a 45-person company like Pagedeck, the two jobs often belong to one person.

Downstream sits everyone who uses the screens. The skill that matters here is not taking requests at face value. "Can you make me a churn chart" usually has another question hiding behind it. Asking what decision the chart is for is what settles whether it should be cut by pricing plan or grouped by signup month.

Mia checks the product metrics screen every week to decide what to dig into next. Ravi watches spend against performance daily. Sofia works from a list of accounts coming up for renewal. Three people, three different views, so the BI analyst slices the same data three ways.

The monthly report that goes to Grace is a different animal. Fewer items, longer trend lines. A chief executive isn't deciding what to do this week — they're reading which direction the last six months point.

"Where did you get that number? The dashboard is 300 lower."

Two sources are reporting the same metric differently, which means checking the definition or the data feed.

"That's the third time this has come up. Let me build it as a screen instead of pulling it each time."

A repeating question is getting moved into something that answers itself.

"That screen was built last quarter, so the new pricing plans aren't in it."

A warning that the dashboard has gone stale against the current setup.

Monday mornings are the busiest at Pagedeck. The weekly report has to go out before noon, and weekend data has a habit of arriving late. Last month the billing records came in a day behind and revenue landed 20 percent low; sending the report as it stood would have sent an hour of the meeting somewhere useless. The figure stayed as it was, with a note in the cell: "billing data delayed, updates Tuesday."

The job doesn't extend to judging the numbers. Working out why revenue dropped is Mia and Theo's work. What the BI analyst does is make sure that conversation starts from the same figures.

The most common assumption is that this is a job about making charts look good. The visible output is a screen, so the assumption is easy to arrive at. But drawing the screen is one slice of the work, and the rest goes into agreeing on what to count and pinning that calculation in one place. Counting an active user as anyone who logged in, versus anyone who created a document, is the difference between 120,000 and 40,000 in the same month. Skip that agreement and build the screens first, and you get five attractive screens pointing at five different values.

The other one is that more dashboards mean a more data-driven company. Screens are easy to count, which makes them look like output. But a screen is good or bad depending on whether anyone does something different after looking at it, not on how many numbers it holds. A screen nobody acts on takes up space, and fifty of them leave a new hire unable to tell which one to trust, reading none of them in the end.