A practical checklist for analytics engineering

The advice here is unglamorous, which is probably why it gets skipped. Run through this the next time analytics engineering comes up.

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.

The checklist

• Transformations belong in version control like any other code
• Tested, documented models stop every report disagreeing
• One definition of a metric, used everywhere
• Someone is named as the owner
• There is a date to review it again

Why it matters

Transformations belong in version control like any other code. That sounds obvious written down. It is still the thing most often skipped. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

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

Pick the one that would hurt most if it failed, and start there.