> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allyy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The Allyy data model

> The handful of entities every data source is mapped onto

Allyy is generic: it doesn't care whether you're a wildlife charity or a hospital foundation. It achieves that by mapping every customer's data onto the same small set of entities. Understanding these makes data mapping, models and dashboards all click into place.

## The core entities

> [card] Contacts
>
> The people or organisations you engage — your supporters. Carry static attributes like age, gender, postcode, and acquisition source.

> [card] Offers / Content / Treatments
>
> The campaigns a contact can be targeted by — an appeal, a mailing, a telemarketing or email campaign. One row per campaign, describing what it was. The "what we sent".

> [card] Responses
>
> An interaction between a contact and an offer — a donation, a click, an open, a refusal. The "what happened". Responses carry a timestamp and, for donations, an amount.

> [card] Subscriptions
>
> A standing agreement — a recurring donation / direct debit / standing order — with a start date and an optional end date (open-ended while active).

**Lists** sit alongside these: a collection of contacts (or offers) used as the population for a model or a campaign — for example "everyone eligible for the spring appeal".

## How the entities relate

A **Contact** receives an **Offer**; their reaction is a **Response**; if they commit to give regularly, that's a **Subscription**. Models and analytics are built by combining these — for example:

* *DM propensity* learns from **Responses** to past **Offers**, per **Contact**.
* *Subscription churn* learns from **Subscriptions** and their **Responses** (payments).
* *Income concentration* (analytics) aggregates donation **Responses** across **Contacts**.

![The Allyy data model — how Contacts, Offers, Responses and Subscriptions relate](https://mintcdn.com/allyyio/-6byzLIs4C96d-3q/images/processes/data/data_mapping_1.png?fit=max\&auto=format\&n=-6byzLIs4C96d-3q\&q=85\&s=ba56e313dde409eb19525875f698d1b3)

## Field categories

When you map a source, each column falls into one of these roles:

| Category | Examples |
| - | - |
| **IDs** | `ContactID`, `OfferID` — the keys that link entities. |
| **Attributes** | age, gender, postcode, income index — descriptive fields. |
| **Classes & types** | offer type, content category, response type (donation / click / refusal). |
| **Valid from** | when a record became valid — lets Allyy reason about change over time. |
| **Mandatory fields** | required for an entity to be usable (e.g. subscription start date). |
| **Optional fields** | enrich an entity but aren't required (e.g. subscription frequency). |

## Why this matters

Because everything is expressed in these entities, **the same model and the same dashboard work for any customer** — only the mapping changes. Getting the mapping right (especially donation amounts, timestamps, and response types) is the single most important thing for accurate models and analytics.

> [!TIP]
>
> Donations often live in more than one place — one-off donations, mailing responses, and recurring-donation payments. Make sure each is mapped so that **all** of it is captured, not just one channel.

Next: [Preparing your data](https://docs.allyy.io/data/data-requirements.md) · [Connect a data source](https://docs.allyy.io/processes/data.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.