Analytics engineer role: tested models between raw data and dashboards

Why the role appeared

For years, analysts wrote their own SQL against raw tables. Each dashboard computed revenue slightly differently, and nobody could say which was right. Analytics engineering applies software practice to that layer: models live in version control, changes go through pull requests, tests run on every build, and documentation is generated from the code. The job title is newer in India than data engineer or BI developer, and is most common in product companies, startups and some GCCs with modern data stacks.

The artefact: one model and its tests

Here is a small dbt-style model that builds a customer-level table from raw orders, followed by the test definitions that guard it. Both are shown as plain text because the model contains dbt templating, so it will not run in a SQL console as written.

-- models/marts/dim_customers.sql
with orders as (
    select
        customer_id,
        order_id,
        order_date,
        net_amount
    from {{ ref('stg_orders') }}
    where order_status = 'delivered'
),

customer_orders as (
    select
        customer_id,
        min(order_date)          as first_order_date,
        max(order_date)          as last_order_date,
        count(order_id)          as delivered_orders,
        sum(net_amount)          as lifetime_net_revenue
    from orders
    group by customer_id
)

select
    c.customer_id,
    c.city,
    c.signup_date,
    co.first_order_date,
    co.last_order_date,
    coalesce(co.delivered_orders, 0)     as delivered_orders,
    coalesce(co.lifetime_net_revenue, 0) as lifetime_net_revenue
from {{ ref('stg_customers') }} c
left join customer_orders co on c.customer_id = co.customer_id

# models/marts/dim_customers.yml
version: 2
models:
  - name: dim_customers
    description: One row per registered customer. Revenue counts delivered orders only, net of discounts and returns.
    columns:
      - name: customer_id
        tests: [unique, not_null]
      - name: delivered_orders
        tests:
          - dbt_utils.accepted_range:
              min_value: 0
      - name: first_order_date
        description: Null if the customer has never had an order delivered.

The {{ ref() }} calls are dbt syntax that resolve to other models and let the tool build the dependency graph. The accepted_range test comes from the widely used dbt_utils package, which must be installed. The important parts are not syntax. The description says exactly what "revenue" means here. The left join keeps customers who never ordered, which a careless inner join would drop. And the uniqueness test on customer_id fails the build if a bad join in stg_orders ever duplicates customers, before a dashboard shows inflated counts.

How the work flows through a week

Most weeks mix three kinds of work. There are requests: marketing wants a new attribute on the customer table, finance wants refunds split out. There is maintenance: a test failed overnight because a source started sending a new order status, and the engineer decides whether the model should include it. And there is review: reading colleagues' pull requests, checking that a change to a shared model does not quietly alter numbers in 15 downstream dashboards. That last part is where analytics engineers add the most value and where new ones are least prepared.

Test coverage, trusted metrics and fewer ad hoc queries

Test coverage on important models, number of data incidents caused by modelling changes, build reliability and run time, adoption of shared models instead of ad hoc SQL, and the quality of documentation. A useful signal is how many dashboards read from certified models rather than raw tables.

Data engineers upstream, analysts downstream

Analytics engineers usually report to a head of analytics or data platform lead. They work with data engineers (who land raw data), analysts and BI developers (their main consumers), and business owners who must agree definitions.

Analytics engineer versus data engineer and BI developer

A data engineer gets data into the warehouse and runs the platform. An analytics engineer shapes data inside the warehouse for business use. A BI developer builds the semantic model and reports on top. In practice the boundaries move from company to company, and one person often covers two of the three.

dbt, semantic layers and metric definitions in postings

Document the models nobody owns

Month one: read the project's lineage graph and document the five most-used models. Month two: add tests where important models have none. Month three: consolidate one metric that is currently defined in several places into a single tested model.

Lead analytics engineer or data platform roles

Senior analytics engineer, data platform or data engineering roles, analytics lead, or data product manager. The Data Science programme includes the data engineering and data quality foundations, such as SQL modelling, validation and reproducibility, that analytics engineering depends on.