For the last while I've been the person who can tell you what happened on your website. Which campaign pulled its weight, where people dropped out of the funnel, which page quietly bleeds visitors every single day. I'm good at it, and I still think marketing analytics is more interesting than most people give it credit for — I've written before about reading web analytics for decisions rather than decoration, and I stand by all of it. But somewhere in the last few months I hit a ceiling, and I want to write down what it felt like — partly for me, partly in case you're standing where I was.

The ceiling looked like this: I could read the dials beautifully, but I didn't own the plumbing behind them.

Reading the dials vs. building the machine

When you do marketing analytics, you live downstream. Google Analytics hands you numbers, Hotjar hands you recordings, and your job is to turn all that into a story someone can act on. It's genuinely skilled work — a lot of it is knowing which questions are worth asking and which "insights" are noise dressed up as signal.

But you're always working with data someone else shaped. And the day I started asking where these numbers actually come from — how they're collected, where they're stored, what happens between a click and a chart — I realised I was standing at a locked door. I could describe the output all day. I couldn't fix the input.

The moment it became concrete: a figure on a dashboard didn't match a figure in the source system, and everyone looked at me because I was "the data person." I could see the two numbers disagreed. I could not tell you why, because the machinery in between was a black box to me. That's a bad feeling when your name is on the report.

What I found on the other side of the door

So I started teaching myself the layer underneath. Not the dashboards — the pipes. How data actually moves: extracted from a source, cleaned and reshaped, loaded somewhere it can be trusted. In a start-up you get to poke at all of it, which is a gift — a bit of Python here, a pandas script there, Docker so the thing runs the same on my laptop as on the server, the beginnings of understanding what a real data pipeline is.

And I noticed something about myself. The part I found most satisfying wasn't the clever analysis at the end. It was making the underlying data correct and dependable in the first place — so that when someone finally did read the dials, they could believe them. That's a different job. It's less glamorous and, I'm starting to think, more valuable.

Here's the thing my communications background keeps whispering, though: the plumbing is not the point either. A perfectly engineered pipeline that delivers a number nobody understands is just a faster way to be misunderstood. The goal is trustworthy data that a human can actually reason about. The engineering serves the meaning, not the other way round.

The first things I taught myself

If you're standing where I am and want to start, here's the order that's working for me — least glamorous first, because that's where the leverage is.

SQL before anything. Not the fancy parts — the everyday grammar of asking a database questions directly: SELECT, JOIN, GROUP BY, WHERE. This is the language the machinery actually speaks, and until you're comfortable in it you're forever one translation removed from your own data. I drilled it until writing a join stopped feeling like an event.

Then, what a pipeline actually is. Extract, transform, load — the idea that data is moved and reshaped on its way from where it's born to where it's used, and that each of those steps is a place things can go right or wrong. I'd been consuming the output of pipelines for years without a mental model of the thing itself. Getting that model changed how I read every number.

Then, read someone else's ETL. The fastest way to learn how this is really done is to open a working pipeline someone competent built and trace it end to end, asking "why did they do it that way?" at every step. You learn more from one well-built real example than from ten tutorials.

Then, the mindset shift that's hardest. Moving from "a script that runs once on my laptop and gives me an answer" to "a job that has to run every night, unattended, and be trusted." That last word is the whole difference between analysis and engineering, and it's the one I'm still growing into.

Where this is heading

I don't have a tidy conclusion, because I'm in the middle of the move rather than looking back on it. But the direction is clear to me now: I want to build the machine, not just read its output. I want to be the person who can follow a number all the way back to where it was born and tell you, with confidence, whether to trust it.

That means going properly into data engineering — SQL, ETL, the whole enterprise stack I've only glimpsed. It's a real step down the ladder in some ways; I'll be a beginner again at things. I've made my peace with that. Reading the dials was a good place to start a career. It's a worse place to spend one.

If you're a marketing analyst feeling that same itch — the one that says but where does this actually come from — take it seriously. It might be the most useful career signal you'll get.