# Overview & Entity Relationships

CenterCheck's data model is organized around the **Business Location** — every dataset in the schema is anchored to a physical point of interest. Metrics, demographics, and behavioral signals are all delivered at the Business Location level, scoped to a specific time period.

The schema is composed of seven core entities:

| Entity                                                                                                               | Description                                                                   |
| -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| [Business Location](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/business-location.md)                         | The foundational record for each physical store or venue                      |
| [Brand](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/brand.md)                                                 | Retail chain or multi-location business entity grouping Business Locations    |
| [Transactions & Sales Metrics](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/transactions-and-sales-metrics.md) | Revenue, transaction count, and unique customer count per location per period |
| [Shopper Demographics](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/shopper-demographics.md)                   | Shopper profiles by age, gender, income, ethnicity, and other attributes      |
| [Spend Journey](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/spend-journey.md)                                 | Customer movement patterns before and after visiting a Business Location      |
| [ZIP Code Capture](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/zip-code-capture.md)                           | Origin ZIP codes of shoppers visiting each Business Location                  |
| [Time of Sales](/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema/time-of-sales.md)                                 | Transaction and revenue distribution by day of week and hour of day           |

***

## Entity Relationships

All entities relate back to a central **Business Location** record via `business_location_id`. Metric and demographic datasets are further scoped by `start_at` and `end_at` fields, enabling time-series analysis.

## Key Design Principles

**Business Location is the anchor.** Every dataset joins back to a Business Location via `business_location_id`. This means all analysis — whether financial, demographic, or behavioral — can be consistently scoped to a physical place.

**Brand groups locations.** A Brand is linked to one or more Business Locations via `brand_id`, enabling chain-level aggregation across all locations belonging to the same retail brand.

**Time-scoped metrics.** Transactions, demographics, ZIP capture, and spend journey data are all scoped to a reporting period via `start_at` and `end_at`. This enables trend analysis, period-over-period comparisons, and seasonal benchmarking.

**Spend Journey uses journey arrays.** Unlike flat metric datasets, the Spend Journey entity delivers `previous_locations`, `next_locations`, and `secondary_next_locations` as nested JSON arrays. Each entry in these arrays references another Business Location by `location_id`, along with `transaction_pct`, `customer_pct`, and `revenue_pct` representing the share of transactions, unique customers, and revenue attributed to customers who followed that journey path.

**Parent-child location hierarchy.** Business Locations support a self-referencing hierarchy via `parent_business_location_id`, allowing individual stores to be rolled up to a parent complex (e.g. a mall or shopping center).

**Nested arrays require unnesting.** The Spend Journey dataset deliver data as nested JSON arrays. When ingesting into a data warehouse, these fields should be exploded into individual rows for row-level analysis.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.centercheck.com/xbxMQACVcX90R5ugyGdt/data-schema-reference/schema.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.