How to get analytics engineering right
We end up explaining this on discovery calls often enough that it deserved writing down. The short answer to analytics engineering is that it is mostly a sequence of small decisions, not one big one.
Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What is actually at stake
Transformations belong in version control like any other code. The teams that handle this well are rarely the ones with the biggest budgets. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
The steps
- Establish what you have today before changing anything
- Tested, documented models stop every report disagreeing
- One definition of a metric, used everywhere
- Write down the decision so the next person does not re-litigate it
One definition of a metric, used everywhere. The reasoning matters more than the rule, because the rule has exceptions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Where to go from here
The short version
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
Worth checking on your own setup before it becomes someone else's problem to fix.