Three myths about analytics engineering

Teams tend to reach for this after something has already gone wrong. A few things about analytics engineering that get repeated more often than they get checked.

Most data problems are ownership problems that turned into technical ones. Write the reasoning down alongside the decision, because the reasoning is what changes first.

“It only matters for big sites”

Transformations belong in version control like any other code. In practice this is a scheduling problem more than a technical one. If two people in the business would answer this differently, that gap is the actual problem.

“We can deal with it after launch”

Sometimes true, usually expensive. The cost of getting this wrong is rarely visible on the day it happens.

“Our platform handles it”

One definition of a metric, used everywhere. None of that requires a large budget, only a decision and someone to own it. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

Numbers get quoted in meetings long after anyone remembers how they were calculated. 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

If any of that sounds like a description of your current setup, it is fixable.