> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/model-your-data/commerce-data-models.md).

# Commerce data models

## Introduction

Data models, or transformations, are tables created by our analytics engineering team to present data in a shape that is easy to consume for analytics purposes. Orders facts, product dimensions, and user dimensions are all examples of potential entities (or tables) in a data model.

Creating data models is essential for transforming raw data into structured, meaningful, and usable formats that drive analytics, reporting, and decision-making. Well-designed data models also serve as the foundation for powering more robust and useful AI systems by providing clean, consistent inputs that improve model accuracy, reduce noise, and support richer feature engineering. In short, data models not only enable better business intelligence but also unlock the full potential of AI by ensuring data is trustworthy, well-organized, and aligned with real-world context.

## Why data models matter

🔧 **Structure and Organization**

* Data models define **how data is organized**, related, and stored.
* They bring **consistency and clarity** to how teams understand and query data.

{% hint style="info" %}
Example: Instead of dealing with hundreds or even thousands of unconnected tables, a well-designed model organizes them into clean dimensions (like Customers, Products) and facts (like Revenue).
{% endhint %}

**🤖 Unlock Full Potential of AI with Organized, Accurate, and Business-Ready Context**

* Models provide the structured, high-quality data that machine learning systems rely on for accuracy and relevance.
* They enable richer feature engineering, reduce noise, and ensure AI outputs are grounded in business-ready context.

**📊 Enable Reliable Analytics**

* Models establish **clean relationships** between metrics and dimensions, reducing errors and ambiguity.
* They ensure that calculations like revenue, retention, or conversion rate are **accurate and consistent** across tools and users, creating a **single source of truth**.

**🚀 Power Self-Service & Scale**

* With intuitive, documented models (e.g., via dbt or semantic layers), non-technical users can explore data confidently.
* Teams avoid reinventing logic and reduce dependency on data engineers or analysts for every question.

🔒 **Governance and Control**

* Data models provide **defined logic, lineage, and ownership**, supporting governance, auditing, and compliance.
* They help enforce **data quality checks, contracts, and access controls**.

📐 **Improve Performance and Efficiency**

* Well-modeled data reduces duplication and streamlines queries.
* Optimized joins, indexing, and aggregations improve performance in warehouses and BI tools.

🧠 **Support Business Understanding**

* Models reflect the **business logic**—how the company defines a customer, transaction, or lifecycle stage.
* They bridge the gap between technical schemas and business needs.

## How it works

Chord utilizes the **Kimball approach** to data modeling. This is a widely used method in analytics and data warehousing that enables teams to build models that are easy to understand and utilize.

It breaks data into two core types of tables:

🧾 **Fact Tables (fct\_)** – The “What Happened”

Fact tables track **events or transactions**, such as purchases, logins, or ad clicks. They include **measurable data** such as revenue, quantities, time of action, and user IDs.

{% hint style="info" %}
Example: A table of all orders placed on your website, including order amount, date, and customer ID.
{% endhint %}

👤\*\* Dimension Tables (dim\_) – The “Who” and “What”\*\*

Dimension tables provide **context** for facts. They describe things like customers, products, or regions.

{% hint style="info" %}
Example: A table of customer information with name, email, signup date, and status (active/inactive).
{% endhint %}

These two types of tables are designed to **join together** easily, allowing users to answer questions like:

* *“How much revenue did we make from active customers last month?”*
* *“Which products are most popular among new users?”*

### 🛠️ How Chord builds data models

**Step 1: Ingest Raw Data**

Data often starts messy—coming from tools like:

* Shopify (orders, line items, products, etc.)
* Chord CDP (website client-side events and server-side events)
* Klaviyo (messaging)
* Facebook Ads (ad spend and metrics)

This data is loaded into a cloud data warehouse. However, at this point, it remains messy, inconsistent, and contains duplicates, inconsistent naming, or missing values. Additionally, each source typically contains tens or hundreds of separate tables that must be combined to make sense of the data.

**Step 2: Clean and Normalize the Data**

Chord utilizes **dbt** (short for *data build tool*), a transformation tool that helps data teams clean, organize, and document data as it flows from raw sources to clean, usable models. Chord's analytics engineers build these data models in layers in dbt using programming languages like SQL, python, jinja and YAML. The various data modelling layers allow us to:

* **Clean** the raw data (e.g., standardize names, remove junk values, Handle nulls, trims, formatting, or simple derived fields
* **Deduplicate** records
* **Convert** data types (e.g., string to timestamp)
* **Filte**r out irrelevant rows (e.g., deleted or test records)
* **Add flags** like is\_active
* **Convert or standardize** (e.g., currency conversion, unit standardization)
* **Join related tables** from different systems (e.g., linking a CDP session to a Shopify order)
* **Enrich** records with helpful metadata or flags
* **Define** metrics

**Step 3: Organize into Facts and Dimensions**

Once cleaned, the data is structured into:

* **Dimension models** like dim\_customers, dim\_products, dim\_dates
* **Fact models** like fct\_orders, fct\_pageviews, fct\_subscriptions

**Step 4: Explode!**

Chord utilizes an explosion technique to join every applicable dimension and fact table into a single, consolidated table, such as Orders, so that every field applicable to orders is now available in a single, unified table. We call these x\_fct tables. Now, there's no need for one-to-many joins between dimension and fact tables, and instead, data is readily joined to immediately start analysis!

These data models models are **versioned, documented, and tested** in dbt to ensure reliability. They run daily (or even hourly), so dashboards and AI models always use fresh, trustworthy data.

## Getting started

Chord's data models power your AI, Analytics, and Activations in the Chord platform. You'll see data models such as Orders, Sessions, and more in your Explores section of Analytics. For the full list of models, along with each field therein, see the documentation in [Chord Data Attribute Definitions](/model-your-data/dbt-model-reference.md).

{% hint style="success" %}
if you have any questions or need help, please reach out to us at <help@chord.co>
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/model-your-data/commerce-data-models.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.