Analytics Engineering in English: dbt, Data Models, and Stakeholder Communication

Analytics engineering sits between data engineering and data analysis. Analytics engineers transform raw data into clean, reliable models that analysts and business stakeholders can use. The modern analytics engineering stack is dominated by dbt (data build tool), and the vocabulary has become standard across the industry. This guide covers the key English terms and communication patterns.

dbt Vocabulary

Term	Definition
Model	A SQL file that defines a transformation — dbt compiles and runs it as a SELECT statement
ref()	A dbt function that creates a dependency reference between models (e.g. ref('stg_orders'))
Materialisation	How a model is stored: table, view, incremental, or ephemeral
Source	A raw table ingested from an external system, declared in dbt for documentation and freshness testing
Seed	A CSV file loaded into the data warehouse as a table, used for lookup data
Test	An automated check on a model’s data (e.g. uniqueness, not-null, referential integrity)
Lineage	The visual graph showing how data flows between sources and models
Schema YAML	A YAML file that documents models, columns, and tests

The Three-Layer Architecture

Most dbt projects use a three-layer convention:

1. Staging (stg_) — Clean and rename raw source data; one staging model per source table. “Staging models should apply only renaming, casting, and basic cleaning — no business logic.”

2. Intermediate (int_) — Join and reshape staging models to create useful intermediate datasets. “Intermediate models are not exposed to end users — they’re building blocks for marts.”

3. Mart (mart_ or fct_ / dim_) — Final, business-facing models. These are what analysts query. “The fct_orders mart is the single source of truth for order-level metrics.”

ref() in Practice

The ref() function is central to dbt’s dependency management. When you write ref('stg_customers'), dbt knows to build stg_customers before the current model.

“We use ref() instead of hardcoding table names so that dbt can manage build order and correctly resolve environment-specific schemas.”

Data Contract Language

A data contract is an agreement between a data producer and a data consumer about the schema, freshness, and quality of a dataset.

Term	Meaning
Data contract	A formal specification of what a dataset will contain and how it will behave
Schema	The column names, data types, and structure of a table
Freshness SLA	How up-to-date the data must be (e.g. updated within 6 hours)
Breaking change	A change to a data model that would break downstream consumers
Backward compatibility	A model change that doesn’t break existing consumers
Data catalogue	A searchable inventory of available datasets with documentation

Contract language patterns:

• “The fct_revenue model is covered by a data contract — any changes to column names or data types must go through a review process.”
• “This is a breaking change: renaming customer_id to user_id will require all downstream consumers to update their queries.”

Stakeholder Communication Phrases

Analytics engineers frequently translate between the technical world of SQL and the business world of KPIs and decisions. The language must bridge both.

Explaining a data model to a business stakeholder:

• “The fct_orders table is your single source of truth for order data — everything you see in the revenue dashboard is built from this model.”
• “When you filter by order_status = 'completed', you’re looking at orders that have been fully delivered and invoiced.”

Explaining a data quality issue:

• “We noticed some discrepancies between the dashboard and the finance report. After investigating, we found that the finance report was using a different definition of ‘active customer’ — we’re aligning the definitions now.”

Setting expectations on data freshness:

• “This dashboard refreshes every four hours. For real-time figures, you’ll need to query the source system directly — but for daily and weekly reporting, the mart data is sufficient.”

Example Sentences

1. “The staging model for the orders source applies type casting and column renaming only — all business logic is deferred to the mart layer.”
2. “We use ref('stg_customers') in the intermediate model so that dbt can correctly infer the build order and prevent stale data from propagating downstream.”
3. “The data contract for fct_revenue specifies that the revenue_usd column is always denominated in US dollars and is never null — any upstream change that violates this will trigger an alert.”
4. “Lineage analysis showed that the proposed schema change to stg_products would break 14 downstream models across three mart tables — we’ve communicated this to the consuming teams.”
5. “Following the stakeholder review, we agreed to add a reporting_category column to the mart, which will allow the product team to filter revenue by the new business segment taxonomy.”

Navigating Feedback – A Practical Example

Let’s be honest, communicating effectively about your work as an analytics engineer isn’t just about knowing the technical terms; it’s about articulating them clearly and receiving feedback constructively. A common scenario is a code review comment that initially feels critical but holds valuable insight into improving your dbt models or data flow. As non-native speakers, we sometimes interpret direct criticism as a personal judgment of our abilities rather than an opportunity for growth. Recognizing this difference – seeing the comment as input on the work, not on you – is key.

One frequent phrase you’ll encounter is “Consider refactoring…” This isn’t necessarily a condemnation of your existing code. It often signals a suggestion to improve efficiency, readability, or maintainability. Instead of defensively dismissing it, try responding with something like, “Thank you for the feedback. I appreciate the suggestion regarding ref(). Could you elaborate on what specifically you’d like me to change? Understanding the rationale behind your recommendation will help me ensure I’m building a sustainable and efficient dbt model.” Notice how we’ve shifted the focus – from our initial feeling of defensiveness to a genuine desire for clarification. Similarly, when discussing “staging layers” or “marts,” be prepared to explain why you’ve structured your data in that way. Stakeholders need context; simply stating “this is how I built it” won’t cut it. Use analogies – perhaps relating the staging layer to a building’s foundation – and clearly articulate the benefits of each design choice, such as improved query performance or simplified downstream analysis.

The core skill here isn’t just mastering the vocabulary itself, but learning to frame technical discussions in a way that emphasizes clarity and collaboration. Remember that stakeholders often don’t have the same level of technical detail as you do, so simplification is key. Don’t fall into the trap of using overly complex jargon without explanation. If someone asks for “data lineage,” provide a concise visual representation if possible—a dbt diagram, even—and explain how it helps them understand where their data comes from and how it’s transformed. This proactive communication builds trust and ensures everyone is on the same page.

-- Example of a simple dbt model to illustrate data lineage (simplified)
{{ config(material='dbt_models') }}

WITH source_data AS (
    SELECT * FROM staging.raw_customer_data
),
transformed_data AS (
    SELECT
        customer_id,
        customer_name,
        -- Example transformation - calculating total order value
        SUM(order_total) AS total_spent
    FROM source_data
    GROUP BY customer_id, customer_name
)

SELECT *
FROM transformed_data;