A short guide to analytics engineering

We end up explaining this on discovery calls often enough that it deserved writing down. Everything we would tell a client about analytics engineering in the time it takes to drink a coffee.

Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What is actually at stake

Transformations belong in version control like any other code. The reasoning matters more than the rule, because the rule has exceptions. Check it against what you would want a competitor's site to get wrong.

What good looks like

Tested, documented models stop every report disagreeing. There is a version of this that is over-engineered, and it is worth avoiding. Check it against what you would want a competitor's site to get wrong.

Where it usually goes wrong

One definition of a metric, used everywhere. Where this goes wrong is almost never a lack of knowledge. It is the sort of thing that looks like polish right up until it costs you an enquiry.

How to tell if yours is fine

Most data problems are ownership problems that turned into technical ones. Three things worth confirming about analytics engineering before you move on:

• Someone can say what the current setup is without going to look
• One definition of a metric, used everywhere — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.