Short answer
Analytics engineering turns source data into dependable analytical datasets through versioned transformations, tests, documentation, and operating practices.
About Analytics engineering
Analytics engineering builds tested, documented data transformations that make analysis reliable and repeatable. It treats analytical data products as maintained software rather than one-off query output.
Use this competency for
- Roles that build shared transformations, analytical datasets, metric layers, or data pipeline workflows.
- Work where analyses depend on repeatable logic that multiple consumers can inspect and reuse.
Do not use this competency for
- Use data modeling when the main responsibility is defining concepts and relationships rather than implementing and operating transformations.
Important distinctions
Data modeling
Data modeling defines concepts and relationships, while analytics engineering implements, tests, deploys, and operates the transformations.
Data quality
Data quality defines fitness conditions and investigates failures, while analytics engineering owns the transformation lifecycle that may enforce them.
Expectations by level
IC1
IC1: Maintained transformations
Builds or changes a scoped transformation with guidance using established project patterns. Adds tests and documentation and verifies the deployed output.
Observable behaviors
- Implements transformations with readable, version-controlled logic.
- Adds tests for keys, required fields, and stated business rules.
- Documents lineage, grain, and field meaning for the changed model.
Examples
- Adds a daily account-status model with key tests and confirms the scheduled run produces the expected rows.
- Refactors a repeated query into a shared transformation and verifies existing reports remain unchanged.
IC2
IC2: Domain pipelines
Independently owns transformation workflows for a team domain. Designs for reliable change, diagnoses failures, and improves reuse and runtime where evidence warrants it.
Observable behaviors
- Plans dependencies and deployment steps for multi-model changes.
- Adds monitoring and recovery paths for recurring pipeline failures.
- Consolidates duplicated logic into documented shared models.
Examples
- Migrates product metrics to a shared session model with parallel comparisons before switching consumers.
- Reduces a slow daily build by changing incremental logic and verifies late-arriving records are still captured.
IC3
IC3: Platform patterns
Sets analytics engineering patterns used across teams and leads complex migrations. Balances reliability, maintainability, cost, and consumer continuity with explicit evidence.
Observable behaviors
- Defines shared conventions for testing, deployment, lineage, and ownership.
- Reviews architecture changes for failure modes and downstream migration risk.
- Leads cross-domain migrations with validation, rollback, and consumer communication plans.
Examples
- Introduces a common deployment check that blocks breaking column changes for registered consumers.
- Leads a warehouse-layer redesign while old and new outputs run in parallel until reconciled.