Skip to main content
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

Contacts

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

Offers / Content / Treatments

The things a contact can interact with — a mailing, a telemarketing call, an email, an appeal. The “what we sent”.

Responses

An interaction between a contact and an offer — a gift, a click, an open, a refusal. The “what happened”. Responses carry a timestamp and, for gifts, an amount.

Subscriptions

A standing agreement — a recurring gift / 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 gift Responses across Contacts.
The Allyy data model — how Contacts, Offers, Responses and Subscriptions relate

Field categories

When you map a source, each column falls into one of these roles:
CategoryExamples
IDsContactID, OfferID, ResponseID — the keys that link entities.
Attributesage, gender, postcode, income index — descriptive fields.
Classes & typesoffer type, content category, response type (gift / click / refusal).
Valid fromwhen a record became valid — lets Allyy reason about change over time.
Mandatory fieldsrequired for an entity to be usable (e.g. subscription start date).
Optional fieldsenrich 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 gift amounts, timestamps, and response types) is the single most important thing for accurate models and analytics.
Gifts often live in more than one place — one-off donations, mailing responses, and recurring-gift payments. Make sure each is mapped so that all giving is captured, not just one channel.
Next: Connect a data source · Data mapping