HourTab

Blog › ICP guides

Analytics engineer on retainer: tracking data transformation advisory and demonstrating dbt governance value between data model migrations and warehouse architecture decisions

July 18, 2026 · ~15 min read

The data model migration and the warehouse architecture decision are the visible events in an analytics engineering engagement. When a data director presents the analytical data quality improvement to the VP of Data, when a head of analytics justifies the dbt investment to the engineering leadership team, when a business intelligence manager reports the dashboard accuracy improvement to the CFO — those are the artifacts on the table: the model migration that consolidated three siloed revenue tracking tables into a single canonical orders model, the warehouse migration that moved 800 dbt models from Redshift to Snowflake over six weeks, the semantic layer implementation that codified the company’s revenue metric definitions across eleven previously inconsistent dashboard sources. What none of those artifacts shows is the continuous transformation layer governance between those visible milestones, or whether that ongoing advisory is what maintained the data model correctness, controlled the warehouse compute cost, and kept the dbt project organized enough to support the analyst team’s reporting without creating the data quality incidents that cause leadership to distrust the numbers.

The dbt project governance session that identified a model producing incorrect results because a date dimension join was using the event timestamp rather than the event date — where a fact model was joining to the date dimension on event_timestamp::date in a timezone-aware warehouse that was storing timestamps in UTC while the business operated in US/Eastern time, causing events that occurred between 8pm and midnight Eastern to join to the following calendar day in the date dimension and producing revenue attribution figures that were off by one day for approximately 15% of transactions — that prevented twelve weeks of incorrect daily revenue figures from reaching the board dashboard before the Q3 board meeting. The semantic layer advisory that caught a metric definition aggregating over a non-additive measure without the grain adjustment that would prevent double-counting — where a monthly active users metric was defined using COUNT(DISTINCT user_id) at the day grain but was being aggregated to the month grain using SUM rather than COUNT DISTINCT, causing the monthly MAU figure to sum 30 days of daily distinct user counts rather than counting distinct users across the full month and overstating MAU by a factor of 3-5x — that prevented a fundraising deck from presenting a user engagement metric that was structurally incorrect.

The transformation layer design consultation that redesigned the incremental model strategy to prevent the full refresh that had been running nightly on a 400-million-row fact table from blocking downstream models during business hours — where the fact model’s incremental filter was using a non-deterministic timestamp comparison that caused dbt Cloud to treat every run as requiring a full refresh when the target table’s max timestamp was within 10 minutes of the current run time, and where the full refresh was consuming 4-6 hours of warehouse compute that overlapped with the analyst team’s morning dashboard refresh window — that prevented the analyst team from working with stale dashboard data every morning while the full refresh completed. The data quality monitoring governance session that identified a data test asserting uniqueness on a combination key that had silently stopped running because the model had been renamed in a dbt project refactor without updating the test YAML — where a daily order deduplication test had been failing to execute for six weeks because the model reference in the test configuration was pointing to the old model name that no longer existed in the DAG, meaning that duplicate orders introduced by an upstream system bug had been propagating into the analytical data for six weeks without any detection — that, when identified, required a historical data remediation that took three days to complete.

Analytics engineers and dbt consultants on monthly retainer do their most consequential work in the continuous stretches between major data model migrations and warehouse architecture decisions: the dbt project governance that maintains model correctness, DAG structure, and test coverage; the semantic layer advisory that ensures business metric definitions are consistent and produce accurate aggregations at every grain of analysis; the transformation layer design consultation that ensures new models are structured to answer the questions being asked without introducing the fanout joins, non-additive aggregations, or slowly-changing dimension mismatches that produce subtly incorrect analytical data; the data quality monitoring governance that maintains the detection coverage that catches data reliability problems before they propagate to dashboards; and the performance advisory that keeps warehouse compute costs aligned with the data team’s budget. All of that advisory is invisible to the data director, VP of Data, and business stakeholders without a work log that connects the ongoing transformation layer governance to the data quality, cost profile, and analyst productivity it maintains.

Analytics engineer versus data engineer versus data analyst: the primary distinctions

Three data-adjacent advisory roles are routinely conflated in data leadership conversations: the analytics engineer, the data engineer, and the data analyst on retainer. The conflation produces situations where the transformation layer governance function — the discipline that maintains dbt model correctness, manages semantic layer complexity, governs the data quality detection coverage, and ensures the dimensional models can answer the business questions being asked — is either missing, distributed across advisors without clear ownership, or misassigned to advisors whose expertise is adjacent but not equivalent.

A data engineer on retainer focuses on the upstream layer: the pipelines that extract data from production systems and load it into the data warehouse, the warehouse configuration and partitioning strategies that govern storage cost and query performance at the raw table layer, the pipeline orchestration frameworks that govern scheduling and dependency management, and the data reliability monitoring that detects ingestion failures before they affect downstream consumers. The data engineer’s domain ends at the raw table layer. The analytics engineer’s domain begins there — taking the raw ingested data that the data engineer’s pipelines produce and transforming it into the clean dimensional models, metric definitions, and semantic layer objects that analysts can query correctly. Both are essential data infrastructure roles, but they govern entirely different layers of the analytical data stack, use different tooling, and produce failures with different symptoms and remediation paths.

A data analyst on retainer focuses on the downstream layer: consuming the clean analytical data that the analytics engineer’s transformation models produce, building dashboards and reports that surface business trends, conducting exploratory analyses that answer specific business questions, and interpreting data patterns for non-technical stakeholders. The data analyst asks “what does the data show?” The analytics engineer asks “is the data correct, and is the model structured so that the analyst can ask that question without getting a subtly wrong answer?” A data analyst who is building dashboards on top of a poorly governed dbt project — where metric definitions are inconsistent across models, where slowly changing dimension handling produces incorrect historical figures, where incremental model strategies miss late-arriving data — is reporting on incorrect data without the tooling expertise to diagnose why the numbers don’t match across different reports.

A machine learning engineer on retainer focuses on a third adjacent layer: the ML model training pipelines, feature stores, model serving infrastructure, and model monitoring systems that use analytical data as inputs to predictive systems. The machine learning engineer asks “how do we build a model that generates accurate predictions at inference time?” The analytics engineer asks “how do we build a transformation layer that produces clean, correctly-defined analytical data for both human analysis and ML feature consumption?” The two roles share a dependency on clean upstream data, but the analytics engineer governs the transformation layer that produces that clean data; the machine learning engineer builds the systems that consume it for prediction rather than reporting.

What ongoing analytics engineering retainer advisory actually consists of

dbt project governance

The dbt project is the primary artifact of analytics engineering. A well-governed dbt project — with a clear DAG structure that makes data lineage traceable, model naming conventions that make the layer of each model in the transformation stack evident, test coverage that detects incorrect transformations before they reach downstream consumers, and documentation that makes each model’s grain and intended use case explicit — is the foundation that allows the analyst team to consume analytical data with confidence. A dbt project that has accumulated technical debt — models that perform joins at the wrong grain and silently fan out rows, models named inconsistently across the staging, intermediate, and mart layers, tests that have drifted from the models they are supposed to validate, documentation that was written for the model’s original purpose and has not been updated as the model’s use has evolved — produces the subtle data quality problems that analysts discover through inconsistent numbers across reports and dashboard stakeholders discover through questions that the data cannot answer correctly.

dbt project governance on retainer covers the ongoing review of the DAG structure, model layer organization, test coverage, and documentation completeness: identifying models that have accumulated complexity beyond the layer they are intended to represent; reviewing new model pull requests for grain correctness, join logic, and test adequacy before they are merged; advising on refactoring opportunities when the project structure has drifted from patterns that support correctness and maintainability; and maintaining documentation of the transformation design decisions that are not evident from the SQL itself.

On retainer: reviewing new model additions and model changes before they are merged to the production dbt project; advising on project structure improvements when technical debt has accumulated in the DAG; and maintaining documentation coverage for business-critical models where the transformation logic requires context beyond what the SQL expresses.

Semantic layer advisory

The semantic layer is the interface between the transformation layer and the analytical consumer. A well-designed semantic layer — where each metric is defined once, where the grain at which each metric is additive is explicit, where dimension joins are governed by consistent relationship definitions, and where the metric logic is testable and version-controlled — ensures that every dashboard, analyst query, and embedded analytics surface is computing the same business metrics from the same definitions. A poorly governed semantic layer — where the same business metric is defined differently in ten different LookML explores, where the revenue metric in the finance dashboard uses a different attribution logic than the revenue metric in the sales dashboard, where slowly changing dimension joins are handled inconsistently across metric definitions — produces the situation where a room full of stakeholders is looking at different numbers for the same metric and spending the meeting arguing about which number is correct rather than acting on the data.

Semantic layer advisory on retainer covers the review of metric definitions, dimension hierarchies, and join relationships in the semantic layer tooling (dbt Metrics, Looker LookML, Cube.dev, or equivalent): evaluating new metric definitions for aggregation correctness at each analytical grain; identifying metric definitions that are computing correctly at one grain but producing incorrect results when aggregated or disaggregated across the time or dimension hierarchy; advising on dimension modeling patterns that support consistent join behavior across multiple fact models; and reviewing the relationship between the semantic layer definitions and the underlying dbt models they reference for grain alignment.

On retainer: reviewing new metric definitions before they are published to the semantic layer; advising on metric governance patterns that reduce the number of divergent definitions in the analytical environment; and auditing the semantic layer periodically for metric definitions that have drifted from the underlying model grain or business definition they were designed to capture.

Data model design consultation

The design of a dimensional model — the grain of a fact table, the slowly changing dimension strategy for a customer or product dimension, the partitioning and clustering columns that determine query performance and cost, the degenerate dimension columns that preserve atomic detail without requiring a separate dimension table — determines what analytical questions the model can answer correctly and how expensive it is to answer them. A fact model designed at the wrong grain produces either fanout joins that inflate row counts when joined to finer-grained dimensions, or aggregation errors when the business question requires a grain finer than the model supports. A slowly changing dimension strategy that does not distinguish between type 1 (overwrite), type 2 (add row), and type 3 (add column) changes produces incorrect historical analysis when the business question requires knowing what attribute value was current at the time of a historical event.

Data model design consultation on retainer covers the advisory on new fact and dimension model designs before they are built: evaluating proposed grain choices against the business questions the model needs to answer; advising on slowly changing dimension strategies appropriate for the volatility and historical analysis requirements of each dimension; reviewing partitioning and clustering column selections against the query patterns that will be run against the model; and advising on the materialization strategy (table, view, incremental, ephemeral) appropriate for the model’s size, refresh frequency, and downstream dependency pattern.

On retainer: advising on new model designs before implementation begins; reviewing existing model designs when analysts report that a model cannot answer a question that it should be able to answer; and advising on the refactoring strategy when a model’s grain or slowly changing dimension strategy needs to change to support new analytical requirements.

Data quality monitoring governance

Data quality monitoring is the detection layer that catches transformation errors before they reach the dashboards and analyst outputs that business stakeholders rely on. A well-maintained data quality monitoring system — with schema tests that enforce uniqueness and referential integrity constraints, custom data tests that validate business-specific invariants, freshness checks that detect stale model runs before they affect downstream consumers, and anomaly detection rules that flag unexpected changes in row counts, null rates, and metric values — gives the data team confidence that the transformation layer is producing correct results and gives business stakeholders a signal that the data they are looking at has been validated. A data quality monitoring system that has drifted — where tests reference model names that no longer exist, where threshold-based anomaly detection rules have not been updated as the underlying data has grown, where new models have been added to the DAG without corresponding data tests — provides the appearance of validation without the substance.

Data quality monitoring governance on retainer covers the regular review of test coverage, test execution results, and anomaly detection rule calibration: identifying models that have no test coverage or only schema-level tests without the custom business logic tests that would catch transformation errors; reviewing test execution logs for tests that are silently failing to run due to model reference errors; advising on anomaly detection threshold calibration when the underlying data volume or pattern has changed; and reviewing the freshness check coverage for models that business stakeholders are consuming in time-sensitive reporting contexts.

On retainer: reviewing data test coverage and execution results on a regular cadence; advising on test additions for new models and models with identified coverage gaps; and auditing the monitoring system periodically for tests that have drifted from the models they are intended to validate.

Transformation layer performance advisory

The cost of running the transformation layer — the warehouse compute consumed by dbt model runs, the storage cost of the intermediate materialized tables, the query execution time that determines when the analyst team’s morning dashboard refresh completes — accumulates continuously and reflects both the design quality of the dbt project and the change in data volume over time. A fact model that was designed for 10 million rows and is now processing 400 million rows has a performance profile that has changed significantly since the original materialization strategy and partitioning choices were made. An incremental model that is performing a full refresh every night because the incremental filter logic is not eliminating enough rows to make the incremental run cheaper than the full refresh is consuming warehouse compute at full-refresh cost for the economics of an incremental use case.

Transformation layer performance advisory on retainer covers the review of dbt model run times, warehouse compute costs, and query execution plans: identifying models whose run time has grown beyond the window available in the nightly transformation schedule; advising on partitioning, clustering, and materialization strategy changes that improve query performance for high-cost models; reviewing incremental model configurations for filter logic that is not eliminating rows effectively; and advising on the model dependency restructuring that would allow downstream models to begin running earlier when the transformation DAG has accumulated sequential dependencies that create an unnecessarily long critical path.

On retainer: reviewing model run time trends and warehouse cost allocation on a regular cadence; advising on performance improvements for models with run times outside acceptable bounds; and evaluating the transformation schedule critical path when nightly runs are not completing within the business’s required data freshness window.

The work that most commonly goes unlogged in an analytics engineering retainer

The most consistently underlogged analytics engineering advisory work falls into two patterns: monitoring and review work that confirmed the transformation layer was operating correctly, and advisory work that prevented a data quality problem before it manifested rather than remediating one after it had already propagated to dashboards. Both patterns produce the misimpression that the retainer period was quiet when it contained the continuous governance that maintains data reliability in ways that are only visible when they are absent.

Model health monitoring reviews with no failures detected are the canonical underlogging case. A review of dbt test execution results, model freshness metrics, and row count anomaly detection that found all models passing, all freshness thresholds met, and all row count trends within normal range still required the monitoring to be performed. The test execution logs had to be retrieved and reviewed. The freshness metrics had to be checked against the freshness thresholds for each model. The row count trends had to be evaluated against the expected growth trajectory for each fact table. The dbt project that is confirmed healthy requires the same monitoring coverage as the project that is accumulating test failures and stale model runs; the difference is the finding, not the work.

Data model reviews that approved proposed changes are consistently underlogged by analytics engineers who conflate “the model design looks correct” with “no review was required.” A review of a new dbt model’s grain definition, ref dependency structure, join logic, and test coverage that concluded the proposed model was correctly structured and safe to add to the production DAG required the same analysis as a review that identified a fanout join: the proposed SQL had to be read against the source model grains; the join conditions had to be evaluated for many-to-many relationships that would produce row duplication; the incremental filter logic had to be checked for late-arriving data handling; and the test coverage had to be evaluated against the business invariants the model is designed to preserve. The model that is approved after review represents the review’s positive finding, not the absence of review work.

Semantic layer advisory sessions that confirmed sound metric definitions are consistently underlogged because the session that reviews a metric definition and concludes it is computing correctly appears, in the retainer record, to have produced nothing. In practice: the metric’s aggregation function was evaluated against the grain at which the underlying measure is additive; the dimension join logic was verified against the source model’s relationship definitions; the time intelligence logic was checked for correct handling of partial periods at the boundaries of date filters; and the filter conditions were evaluated against the population the metric is intended to represent. That review produces the finding that the metric definition is sound, which is the result the data team needs before publishing the metric to business stakeholders — not a finding that no review was necessary.

Performance reviews that found no immediate optimization opportunities are systematically underlogged by consultants who conflate “the run times are acceptable” with “no review was performed.” A review of model run times, warehouse compute cost allocation, and incremental filter effectiveness that found all models completing within the required transformation window and all incremental filters eliminating a sufficient proportion of rows still required the performance data to be retrieved and analyzed, the run time trends to be checked for growth patterns that would push a model outside its window within the next quarter, and the incremental filter logic to be evaluated against the late-arriving data patterns in the source systems. The data team that knows its transformation layer performance has been reviewed and is within acceptable bounds is in a materially different position than one that makes the same assumption without the review to support it.

Retainer rates for analytics engineers and dbt consultants

Analytics engineer and dbt consultant retainer rates vary with experience level, warehouse platform specialization, and the complexity of the dbt project under advisory:

Advisory-only retainers (dbt project governance, model review, semantic layer advisory, performance monitoring) are typically priced differently from implementation retainers that include hands-on model development or semantic layer definition writing. Pure advisory retainers focus the engagement on the governance function where the consultant’s leverage is highest — reviewing and advising before models are built or published, rather than executing the development directly.

The most common retainer structure for analytics engineers is a minimum monthly hour commitment — typically 10–20 hours — with additional hours available at the agreed hourly rate for periods when a warehouse migration, major model refactor, or data quality incident requiring historical remediation requires deeper engagement than the baseline advisory cadence.

Making analytics engineering retainer advisory visible to data leadership

The principal challenge in analytics engineering retainer relationships is not the quality of the transformation layer governance — it is the legibility of that governance to the data directors, VPs of Data, and business stakeholders who are making the retention decision. An analytics engineer who reviews every model PR before it is merged, maintains the dbt project’s structure and test coverage through ongoing governance, audits the semantic layer for metric definition drift, monitors transformation performance monthly, and keeps the data quality detection coverage current against the evolving dbt project is producing continuous value that is structurally invisible to anyone not present in the advisory sessions. The data organization that benefits from transformation layer governance often cannot articulate precisely why the data quality incidents have been infrequent, why the analyst team trusts the numbers, or why new model additions to the dbt project have not introduced the fanout joins and metric definition inconsistencies that produce stakeholder distrust in analytical data — because the value of ongoing transformation layer governance is experienced as the absence of the data quality problems it prevents.

The work log that connects advisory sessions to specific model review findings, semantic layer advisory outcomes, data quality monitoring improvements, and performance optimization recommendations is the primary mechanism for making transformation layer value legible over time. An entry that records the grain error identified in a proposed model and the incorrect aggregation that would have reached the revenue dashboard gives the data director a concrete example of what the dbt project governance function produces. An entry that records the metric definition’s non-additive aggregation identified before publication, and the MAU overstatement that publication would have caused, allows the VP of Data to understand what the semantic layer advisory function produces. An entry that records the performance anomaly identified, the incremental model configuration corrected, and the warehouse compute savings achieved allows the data leadership team to understand what the performance advisory function produces.

A retainer dashboard that makes the analytics engineer’s work log visible to the data director or VP of Data without requiring the consultant to send a monthly report email converts the work log from a private record into a shared artifact of the advisory relationship. The data leader who can see the full month’s model reviews, semantic layer advisory sessions, data quality monitoring governance, and performance optimization findings in a single URL understands immediately what the transformation layer retainer is producing — and has a concrete record to reference when making renewal decisions or justifying the analytics engineering investment to engineering leadership or the CFO.

The transformation layer events that matter most to log

Not all analytics engineering advisory work carries equal weight in the retainer record. Three categories warrant particular attention because they represent the clearest evidence of the transformation layer governance function working as intended and the highest-leverage applications of the analytics engineer’s expertise.

Prevented data quality incidents. The model review that caught a fanout join before the model was merged, the semantic layer advisory that identified a non-additive metric definition before it was published to the business intelligence tool, the data quality monitoring governance that identified a test that had silently stopped running before it had been failing to detect real data problems — these represent the transformation layer governance function at its highest value. The work log entry should capture the specific model or metric, the problem identified, and the analytical error that would have reached business stakeholders if the change had proceeded without review. This is the analytics engineering equivalent of the infrastructure review that prevented the production outage: the value is in the prevention, and the prevention is only legible through the record of what was prevented.

Metric definition governance decisions. The semantic layer advisory that established the consistent definition for a business-critical metric, the governance decision about which slowly changing dimension strategy to use for a customer dimension that multiple teams are querying for historical analysis, the data model design consultation that determined the grain of a new revenue fact table — these represent the metric governance function of analytics engineering advisory. The work log entry should capture the decision made, the options considered, and the analytical correctness rationale for the chosen approach. Data leadership can evaluate the retainer’s governance value directly from these entries.

Performance improvements with measurable outcomes. The performance advisory that reduced a model’s run time from four hours to forty minutes by correcting the incremental filter logic, the refactoring consultation that restructured the DAG to allow downstream models to begin running earlier and bring the morning data freshness window within the analyst team’s requirements, the partitioning advisory that reduced warehouse compute costs for a high-cardinality fact model by 60% — these represent the performance optimization function. The work log entry should capture the problem addressed, the solution implemented, and the improvement to run time, compute cost, or data freshness that the change produced.

Frequently asked questions

What does an analytics engineer on retainer typically do?

An analytics engineer or dbt consultant on monthly retainer typically provides dbt project governance (reviewing model structure, DAG organization, test coverage, and documentation), semantic layer advisory (reviewing metric definitions and dimension join logic for aggregation correctness), data model design consultation (advising on grain choices, slowly changing dimension strategies, and materialization approaches for new models), data quality monitoring governance (reviewing test coverage and anomaly detection calibration), and transformation layer performance advisory (reviewing model run times and warehouse compute cost allocation). The data model migration is the visible milestone; the continuous transformation layer governance between migrations is the ongoing retainer function.

How is an analytics engineer different from a data engineer or a data analyst on retainer?

An analytics engineer governs the transformation layer: the dbt models that transform raw ingested data into clean dimensional models, the semantic layer definitions that codify business metric logic, and the data quality tests that validate transformation correctness. A data engineer governs the upstream layer: the ingestion pipelines that extract data from production systems and load it into the warehouse, the raw table schemas, and the pipeline orchestration frameworks. A data analyst governs the downstream layer: building dashboards on the clean analytical data the analytics engineer produces, conducting exploratory analysis, and interpreting trends for business stakeholders. A data engineer retainer and an analytics engineering retainer serve different functions in the data stack: the data engineer moves raw data in; the analytics engineer transforms it into trustworthy analytical models.

What analytics engineering retainer work is most commonly underlogged?

Model health monitoring reviews with no failures detected, data model reviews that approved proposed changes, semantic layer advisory sessions that confirmed sound metric definitions, and transformation layer performance reviews where run times were within acceptable bounds. All represent genuine governance work whose value is in the ongoing confirmation and prevention rather than in the correction of identified problems — and all are systematically underlogged by consultants who conflate “no problem found” with “no work done.”

What should an analytics engineer retainer agreement include?

Data warehouse and dbt project access scope, scope boundary between advisory and implementation, data confidentiality requirements for production data access, model ownership and review process for implementing recommendations, and a shared work log visible to data leadership that documents the ongoing transformation layer governance, model review sessions, and semantic layer advisory that the retainer produces.

How should analytics engineer retainer hours be logged?

Log entries should capture the analytics engineering function (dbt project governance, semantic layer advisory, model design consultation, data quality monitoring, performance advisory), the specific model or metric reviewed, the activity performed, and the recommendation or finding. Every session should be logged, including model reviews that found no issues and monitoring reviews that confirmed all tests passing. The transformation layer review that confirmed every model was producing correct results required the same review work as the review that identified a fanout join; logging only the sessions with findings systematically understates the volume of governance work and misrepresents the retainer’s value.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark. No client login required. See how it works →