Analytics Engineering: What is it and How the Role is Evolving

Everyone has a take on AI. Some see it as a threat to their jobs, while others see an opportunity. For data teams, the truth isn’t so black and white. 

In our survey, 86% of data leaders say AI has changed their team’s role and core responsibilities. Teams once focused mainly on analyzing data are now also on the hook for preparing it for agentic analytics. They’re expected to build the pipelines, definitions, and enterprise context needed to keep AI governed and reliable.

In other words, AI isn’t replacing your role so much as reshaping every part of it.

This growing need for AI-ready data is a big reason why the analytics engineer role has taken off. Analytics engineers bridge the gap between data engineers and analysts, using software engineering practices to turn raw data into clean, reliable datasets the business can use.

In this first post of our series on the evolving roles of the modern data team, we’ll take a closer look at the role of an analytics engineer, including what they do, how they differ from data engineers, and where they fit on the team. Later posts will explore the rise of the AI context engineer.

What is analytics engineering?

Analytics engineering is the practice of turning raw data into clean, well-documented data models business users and AI systems can trust and reuse. It sits between data engineering and data analysts, covering everything from cleaning and modeling data to defining the metrics your business relies on.

Typically, analytics engineering work spans 6 areas: 

• Data modeling: Reshaping raw tables from your source systems into business-ready models. Most teams work in layers, moving data from lightly cleaned staging tables into final tables your analysts can use.

• Metric definitions: Defining key metrics like product value, churn, or active users once in code, so every dashboard and team gets the same number. These definitions often live in a semantic layer.

• Testing and data quality: Writing automated checks to catch duplicated logs, missing values, broken joins, or stale data before they reach a report.

• Documentation and lineage: Explaining what each table and column means and tracing which sources feed which dashboards, letting anyone on your team see where a number came from.

• Software engineering practices: Using version control, code review, development environments, and automated deployment for analytics code.

• Cross-domain alignment: Partnering with business teams like finance, sales, and marketing to understand their domain knowledge, then turning it into clear, agreed-upon definitions.

With a shared, trusted dataset, analysts and business users no longer have to rewrite the same logic every time they build a report. They spend less time preparing data and more time answering the questions your business cares about.

Data engineer vs. analytics engineer vs. AI context engineer

These three roles are easy to mix up. The titles sound alike, the work overlaps, and companies often use the terms interchangeably in job postings. But each role has a distinct focus. Here’s what they do: 

What does a data engineer do?

A data engineer designs and maintains the pipelines built to move data from source systems, such as applications, databases, and third-party APIs, into a central data warehouse or lakehouse. They set up ETL or ELT workflows, orchestrate the jobs within each pipeline, and monitor the whole system to keep data fresh, complete, and reliable at scale.

More and more data engineers are also being asked to expand into the realm of AI context. In fact, in our survey of enterprise data executives, 56% said that data leaders are responsible for managing enterprise context. 

What does an AI context engineer do?

AI can read the data you’ve prepared, but on its own, it doesn’t know what any of it means. An AI context engineer closes this gap by building a context layer, which helps AI interpret your enterprise data correctly. They capture business knowledge, map everyday terms to the right data, and set the rules and guardrails AI should follow. 

Increasingly, they also help configure the agentic harness, the system around the AI model controlling how it plans an analysis, which of your data and tools it can use, and how it checks its work before answering. From there, they test AI responses against expected answers, refine the context, and work with your engineering teams to adjust the harness as needed, keeping results accurate and consistent over time.

The diagram below shows where each role fits in the journey from raw data to business value:

Let’s take a closer look at how each role differs: 

How did the role of an analytics engineer emerge?

Say your company is growing fast and decides to bring all its data together in one place. It invests in a cloud warehouse, and your data engineering team gets to work building pipelines to pull in everything from the CRM, the billing system, and the product database. Within a few weeks, data starts flowing into the warehouse on schedule, but it arrives raw, exactly as each source system stores it.

Soon after, leadership asks your team for an analysis of customer revenue trends.

Before your analysts can start, they first have to find the data. The warehouse holds hundreds of tables with cryptic names and duplicated records. Even once they find the right tables, the data is far from ready for analysis, leaving your analysts to spend the next two weeks cleaning, matching, and joining tables before running a single meaningful query.

The rise of the analytics engineer

Analytics engineers solve this problem. Instead of leaving each analyst to prepare raw data, they build clean, documented models once in the warehouse, such as a single customer table your analysts can use for the revenue analysis and every report after it. 

Today, your analysts aren’t the only ones using these models. AI agents can also query them directly to answer business questions, and unlike your analysts, they’ll use the data as is, even if it contains duplicates or errors. Given this risk, it’s no surprise 60% of data leaders in our report said clean data is important for AI analysis. 

AI readiness is not the same as clean data. Context management and harness engineering close the gap. Still, clean data helps speed the process along, which is why the analytics engineer still has a place on the data team.

Core responsibilities of an analytics engineer

Analytics engineers handle a wide range of tasks, but their work comes down to three core areas:

Cleaning, preparing, and standardizing data

Every reliable model starts with clean data, and analytics engineers begin by fixing quality and consistency issues. First, they remove duplicate transactions and values before they inflate your totals or skew results. Next, they convert inconsistent formats into proper data types, such as turning a date stored as text into a true date value.

From there, they standardize coded values and nulls, mapping different versions of the same value to one standard. These fixes may seem small, but they add up fast. A single duplicated order can overstate revenue, and a filter on “True” will silently miss every record marked “T.” Your analysts might catch some of these issues. Still, an AI agent won’t, which makes cleaning an important step in building AI analytics your business can trust.

Modeling and harmonizing data across domains

Raw data comes from many operational systems, each with its own schemas, naming conventions, and terminology. Because of this fragmentation, the same concept can mean different things depending on where it lives. 

In your CRM, a “customer” might be anyone with an open opportunity. Meanwhile, your billing system might count only accounts with an active subscription. Neither definition is wrong, but if you feed data from both into the same revenue report, the numbers won’t match.

Analytics engineers start by working with business teams to agree on shared definitions, such as what counts as a customer and when revenue is recognized. They then build these definitions into one governed, enterprise-wide analytical model. This work often involves mapping each of your system’s IDs to a single customer key, combining records into shared tables like customers, products, and dates, and organizing the data into dimensional models, where facts such as orders and payments connect to the shared tables describing them.

With this foundation in place, connecting data across domains gets much easier.

Building business logic into the data

Even with clean, connected data, your teams still can’t use it directly. Your billing system might store individual invoices, but each one may handle tax, discounts, refunds, and currencies differently. Without one shared place for these calculations, every analyst builds their own version of truth, and reports end up with conflicting numbers for the same metric.

Analytics engineers standardize these calculations in the warehouse. Once the data is cleaned and modeled, they build the calculations, joins, and aggregations into reusable tables, often called marts, designed for a specific business area like finance or sales.

Most business logic also needs to track change over time. A customer table with churn status already flagged is useful, but finance may also need to know when a customer churned or which plan they were on last quarter. Analytics engineers handle this challenge with techniques like slowly changing dimensions, which keep a history of each record instead of overwriting it.

This governed data also gives AI a reliable starting point. It becomes the foundation an AI context engineer builds on, adding the semantic meaning and institutional knowledge AI needs to interpret your data correctly.

Top analytics engineering tools

Analytics engineers rely on a mix of tools, which fall into a few main categories:

• Native tooling: The features already built into your data platform. Analytics engineers use them to store data, run transformations, schedule jobs, and manage access. Because these features come with the platform, teams can do a lot of their core work without adding an extra layer of tooling. 

• Integrated development environments (IDEs): The workspace where analytics engineers build and maintain their data models. Here, they write SQL, preview results, run tests, fix errors, and save changes to version control for review. Having all of this in one place makes it easier to catch mistakes before they reach production.

• Coding languages: The languages analytics engineers use to write transformations. Since most modeling work happens in SQL, you’ll use it constantly.

• Libraries and extensions: A collection of pre-written code you can plug into your own projects. Libraries cover common tasks like cleaning, transforming, and testing data, while extensions add new features to an IDE or data platform. Both save teams from building the same functions from scratch. 

• Semantic and data catalog tools: Connected systems that store business definitions, context, and metric logic. Analytics engineers use them to define metrics. Dashboards, analysts, and AI systems can then draw on the same definitions instead of calculating metrics their own way.

Analytics engineering best practices 

Analytics engineers write SQL the way software engineers write code. Instead of one-off scripts, they manage data like a product. They test it before it ships, track every change, document how it works, and monitor it once it’s live. These habits matter more as AI enters the picture, since an AI agent will use whatever logic it happens to find. Here are the practices worth following: 

Modular, code-based transformations

SQL is declarative, meaning you describe the result you want, such as which calculations to apply or how to join tables, and the database figures out how to get there. This flexibility makes SQL great for data transformations. As projects grow, however, hundreds of standalone queries become harder to manage. The same join gets rewritten in ten places, a fix in one file never reaches the others, and nobody knows which query to depend on.

To bring order to this, many teams turn to tools like dbt, which organize transformations into structured projects. Each model is a single SQL file, and models reference each other with a ref() function instead of hardcoded table names. For logic used across many models, teams can write macros, which are essentially reusable snippets. 

Best practices to apply

• Treat transformation logic as a reusable asset, not one-off code

• Organize code and platform objects into modular projects

• Reuse common cleaning, standardization, and business rules across models

• Define each metric once, in code, and reuse it everywhere instead of recreating it in individual reports

• Keep metric and semantic definitions modular, so a change to one definition updates every place it’s used

Testing and validation

Testing and validation sound similar. However, these quality checks serve different tasks. Testing checks your code, confirming your calculations, transformations, and business rules produce the results you expect. By contrast, validation checks the data itself, verifying it’s accurate, complete, and fit for use. 

Since each one catches problems the other misses, analytics engineers need both. For example, your revenue logic might pass every test and still produce wrong numbers if a source system starts recording amounts in cents instead of dollars. In the same way, perfectly clean data won’t help if someone changes the churn calculation and introduces a bug. Either way, dashboards and AI agents keep returning answers, which is why you need built-in checks for both your code and your data.

Best practices to apply

• Add custom tests for rules specific to your business, such as flagging negative revenue or orders dated in the future, since generic tests won’t catch these.

• Use unit tests to check complex logic against small, hand-built inputs with known correct outputs, the same way software engineers test functions.

• Set up source freshness checks on key timestamp columns to confirm data arrives on schedule, with alerts when a feed falls behind.

• Test metric definitions against known correct results before rolling out changes.

Version control and CI/CD

Version control tracks every change to your code, allowing your team to see who changed what and review updates before they go live. Continuous integration and continuous deployment (CI/CD) allow you to automate how those changes move from development to testing to production. Today, analytics engineers can apply version control to far more than SQL, including pipelines, semantic models, report definitions, notebooks, and warehouse configurations.

Best practices to apply

• Put every data and analytics asset you can under version control, not just SQL.

• Include metadata, semantic definitions, and metrics in version control too.

• Make the review process the same for definition changes as for code changes.

• Use CI/CD to test changes automatically before they reach production.

Documentation

Good documentation helps other teams read, trust, and maintain your work. It matters even more for AI, since many AI tools use your data model and column descriptions to decide which tables to query. The problem is documentation often falls out of sync with the code. When a data model gets refactored, a column gets renamed, or a new table gets added, the descriptions stay the same.

Over time, teammates can’t tell which models are current, what a column contains, or which downstream reports depend on a table. Before long, simple changes take longer, debugging turns into guesswork, and a small update to one model can quietly break your existing reporting. 

Best practices to apply

• Write a description for every model and important column, explaining what it means in business terms as well as what type of data it holds. 

• Set clear naming standards, such as prefixes for staging and final tables, and document them so everyone follows the same rules.

• Include business rules and synonyms in your documentation. If finance calls it “net revenue” and sales calls it “bookings,” note both.

• Generate documentation automatically from your code wherever possible, so it updates when models change.

• Make documentation part of code review. A change to a model isn’t finished until its description is updated too.

Preparing for the next phase of AI analytics

For most data leaders, upskilling is the next move. Of those we surveyed, 52% plan to upskill their data team. The harder question is where to begin.

If you’re an analytics engineer, start by building on the skills you already have. Data modeling, testing, version control, and documentation still matter just as much. What’s different now is your work feeds AI agents as well as analysts, so you also need to understand how AI reads and uses clean data.

Once you’ve got this down, context engineering becomes a natural next step, where you learn how to give AI the enterprise knowledge it can’t pick up from the data alone.

See how other teams are preparing for AI in Meet the modern data team, with full survey results on the skills they’re investing in and how roles and priorities are shifting. 

Next in the series: AI context engineer. We’ll explore the newest role on the data team, what the job involves, and how analytics engineers and other data professionals can build the skills to step into it.