> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zeotap.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Taxonomy and Categories in Catalogue
# What are categories?
Every field you bring into Catalogue is classified into a category. The category tells the platform what *kind* of data the field represents — an identifier, a profile attribute, a time-stamped event, and so on — which in turn determines how the value is stored, whether it's overwritten or appended over time, and how it behaves during ID resolution. Choosing the right category up front prevents the two most common data-quality problems: losing history that should have been kept, and overwriting values that should have been retained.
# Categories
| Category | Description | Storage/ingestion behaviour | When to use |
| :----------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ID** | A value that uniquely identifies a customer, contextually or personally. Includes device-level identifiers (`MAIDs`, `cookies`) and universal or brand-specific identifiers (`email`, `cellphone number`, `crmID`, `User ID`). This field stores the user’s attributes, like user ID, account ID, and so on. | This category creates an attribute of the type`ID`. Stores one value per ID; a new value overrides the existing one after ID resolution. (Exception: the *No. of IDs* feature maintains more than one value.) | Zeotap uses these identifiers to create a Unique Customer ID that captures all other data points within the defined taxonomic groups. |
| **User Trait** | A specific attribute or characteristic of a customer — demographic (`age`, `gender`, `location`) or psychographic (`interests`, `values`, `personality traits`). Typically collected from website tracking, CRM systems, or third-party providers. | Attribute type `Profile`. Stores one value per attribute; a new value overrides the existing one after ID resolution. | Zeotap uses this data to build a complete customer profile and to help businesses personalise their interactions with customers based on their unique characteristics and preferences. |
| **Event** | Any time-stamped interaction between a user and a brand, tied to a Unique Customer ID — e.g. browsing a product page, an in-store purchase, or clicking an ad. Event attributes (`event name`, `timestamp`, `page name`, `device type`) describe the action. | Attribute type `Event`. Stores time-series information; new values are appended, not overwritten, after ID resolution. | Zeotap uses when you need a history of behavioural or interaction data, not just the latest state. |
| **Consent** | Permission granted by a customer to collect and use their personal data for a specific purpose — including `type`, `date`, `scope`, and changes to that consent. | Attribute type `Consent`. Stores one value per attribute; a new value overrides the existing one after ID resolution. | Zeotap uses this data to comply with data privacy regulations and build customer trust. |
| **Marketing Preference** | The communication channels and message types a customer has consented to receive — `email`, `SMS`, `social media`, `direct mail`, etc. Preferences may be self-declared (e.g. via a preference portal) or derived by the brand from prior feedback. | Attribute type `Marketing Preference`. Stores one value per attribute; a new value overrides the existing one after ID resolution. | Use for channel-level opt-ins that drive campaign targeting and suppression. |
| **Product** | Information about an item or service a business offers — `product name`, `category`, `price`, and attributes such as `color`, `size`, `material` — captured at the user level. | Attribute type `Profile`. Currently stores one value per attribute; a new value overrides the existing one after ID resolution. | Zeotap uses this data to help businesses understand the customer’s product preferences, purchase history and to personalise their marketing and sales efforts. This data is also used for inventory management, forecasting and product development. |
| **Campaign** | A set of marketing activities designed to achieve specific goals, activated across channels like `email`, `social media`, and `display ads`. Includes `campaign name`, `campaign type`, `target audience`, and performance metrics (`open rate`, `CTR`, `conversions`). | Attribute type `Event`. Like Events, stores time-series information; new values are appended, not overwritten, after ID resolution. | Zeotap uses this data to help businesses understand the effectiveness of their marketing efforts and optimise their future campaigns. |
| **ID Metadata** | Information *about* an identifier — such as `MAID`, `cookie`, `email`, or `crmID` — for example ID priority (`primary`, `secondary`, `official`, `personal`) or ID status (`active`, `inactive`). Must be linked to the corresponding ID's group name. | Attribute type `ID Metadata`. Stores one value per ID; a new value overrides the existing one after ID resolution. | Zeotap uses this information for segmentation or at the time of activation. |
| **ID Consent** | Consent information about an identifier — for example, `Email ID Consent`. Must be linked to the corresponding ID's group name. | Attribute type `ID Consent`. Stores one value **per ID value**, not per ID attribute — if a user has multiple values under an ID attribute (e.g. three email addresses), each of those values carries its own separate ID Consent value, tied to that specific value's metadata. A new value overrides the existing one for that particular ID value after ID resolution. | Use when consent applies to a specific identifier rather than the customer as a whole — e.g. tracking opt-in status for one email address rather than the customer's overall profile. |
| **Non-Customer Entity** | Data not directly tied to an individual customer but to an associated entity — for example, `product catalogues`, `order data`, `feed data`, `campaign data`, or `account data`. | Attribute type `Non-Customer Entity`. Stores one value at a time; a new value replaces the existing one after ID resolution. | Use for entity-level data that doesn't belong to a single customer profile, rather than customer attributes themselves. |
# Choosing the right category
* **Is the field the identifier itself** (an email, cookie, crmID)? → **ID**.
* **Is the field describing that identifier** (its priority or status)? → **ID Metadata**, not ID.
* **Does the value change over time, and do you need the history** (a purchase, a campaign touch)? → **Event** or **Campaign**.
* **Is it a snapshot fact about the customer or a product**, where only the latest value matters? → **User Trait** or **Product**.
* **Is it about permission to use data or to contact the customer**? → **Consent** or **Marketing Preference**.
If a field doesn't fit any of the above — for example, it belongs to an entity like a product catalogue, order feed, or account rather than to an individual customer — see the special-case categories below.
## Special-case categories
**ID, ID Metadata, and ID Consent are not the same thing.** This is the most common point of confusion in Catalogue: ID is the identifier itself; ID Metadata describes an existing ID (its priority or status) and must be linked to that ID's group name; ID Consent stores consent tied to a specific ID value and is likewise linked to that ID's group name. If you're tagging a field like "ID status" or "ID priority," it belongs under ID Metadata. If you're tagging consent for a specific identifier value, it belongs under ID Consent, not ID.
**Consent vs. ID Consent.**
* **Consent** captures a customer's overall permission for a purpose (e.g. overall marketing consent) and stores one value per attribute, at the customer level.
* **ID Consent** is tied to a specific identifier *value*, not the customer as a whole. If a customer has multiple values under one ID attribute — say, three email addresses — each of those values gets its own independent ID Consent value.
Use Consent for a customer-level permission. Use ID Consent when the permission genuinely varies by identifier value, such as when one email address has opted in but another hasn't.
* **ID** — see [Add an ID Category](https://docs.zeotap.com/articles/unify-customer/adding-an-id-category) for setup steps.
* **ID Metadata** — see [Add an ID Metadata Category](https://docs.zeotap.com/articles/unify-customer/adding-an-id-metadata-category) for setup steps, including how to link it to its parent ID.
* **ID Consent** — see [Add an ID Consent Category](https://docs.zeotap.com/articles/unify-customer/adding-an-id-consent-category) for setup steps, including how to link it to its parent ID's group name.
* **Non-Customer Entity (NCE)** — data not directly tied to an individual customer but to a related entity (product catalogues, order data, feed data, account data). Setup is covered in [Add a Non-Customer Entity Category](https://docs.zeotap.com/articles/unify-customer/adding-a-non-customer-entity-category); how NCE data joins to customer profiles is covered separately in Integrate > Sources > Non-Customer Entity Data.
## Related Topics