They decide how to turn available data into reliable analytical models, which definitions can become shared, and what trade-off to accept between accuracy, freshness, readability and speed of use.
The Analytics Engineer works in the zone where technically available data becomes genuinely usable data. Their scope covers the grain of the models, historisation, metric definitions, consistency across domains, traceability of the rules, and the way analysts, product teams and business teams will reuse these objects rather than rebuilding their own version of the truth.
The difference between someone executing and someone genuinely holding the role shows up when a simple request hides a semantic decision. Summing a column is easy; determining what each row represents, which date an event should be attached to, or which definition must stay stable over time takes reasoning that goes well beyond SQL. A model can be elegant, well controlled and fast while still producing a misleading picture of the business.
The job runs on permanent tensions: ship a metric quickly or settle its definition, share a model across domains or preserve a domain's specifics, correct history or keep it comparable. The assessment looks at the ability to make those tensions explicit and to build an analytical layer that accelerates usage without industrialising ambiguity.
Market benchmarks
The title Analytics Engineer is gradually taking hold on the French market, but its boundaries remain fluid. The role may sit within a data platform team, in analytics, in finance or in product, and may hide behind titles such as BI Engineer, technical Data Analyst or transformation-oriented Data Engineer.
Demand is growing as cloud warehouses, version-controlled transformations and self-service become the norm. Genuinely senior profiles remain hard to identify: many can produce models and dashboards, far fewer can settle a definition and get a shared language adopted without becoming a bottleneck themselves.
Context
In an IT services firm, the assessment focuses on the ability to grasp an inherited analytical estate quickly, to tell genuinely contractual rules from local habits, and to deliver within a bounded scope without freezing the client's ambiguities in place. The Analytics Engineer has to map consumers they have never met and prepare a handover someone else can work with.
Level 1
Junior
A Junior can build a bounded transformation, apply existing conventions, add simple checks and document a model whose grain and business rule have already been established. When several definitions contradict each other, or when the requirement leaves it unclear what a row represents, they still need someone to frame it.
Click to read
Level 2
Mid-level
A Mid-level engineer is autonomous on a common analytical domain. They can choose a grain, structure maintainable transformations, reconcile a result with its source, diagnose a break and measure the impact of a change on known consumers. Their usual limit: they solve the model as requested without always questioning the metric or the underlying business definition.
Click to read
Level 3
Senior
A Senior engineer links the transformation to the decision it feeds. They tell a data discrepancy from a definitional conflict, identify implicit rules, surface assumptions, and organise compatibility when things change. They treat documentation, lineage and adoption as parts of the analytical product itself.
Click to read
Level 4
Expert
An Expert is not the person writing more sophisticated transformations. It is the person who settles a semantic or organisational trade-off while owning what the decision costs: delaying the publication of a metric, temporarily maintaining two incompatible readings, or retiring a heavily used model. They name the business, technical and political price of their choice.
Click to read
Grain, historisation, dimensions, calculation rules and the stability of definitions determine what users will understand about reality. A mistake here spreads into every downstream analysis.
A metric has to be explainable, traceable back to its sources, monitored and correctable without losing the trust of the people using it. The analytical layer is worth only the evidence it can offer for its own results.
Transformations have to be readable, modular, versioned, deployable and able to evolve. Industrialisation matters, but it stays in service of meaning and never compensates for a wrong definition.
The role sits at the interface of analysts, product, finance and the data teams. A definition that is technically correct but not shared immediately produces local workarounds and rival versions of the truth.
Materialisation, incremental computation, access, sensitive data and cost control determine whether analytical usage can last without the platform becoming unmanageable.
The method in action
The scorecard at a glance — hover an axis
Data & artificial intelligence