Skip to main content

​
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

​
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 for setup steps.
  • ID Metadata — see Add an ID Metadata Category for setup steps, including how to link it to its parent ID.
  • ID Consent — see Add 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; how NCE data joins to customer profiles is covered separately in Integrate > Sources > Non-Customer Entity Data.

Adding an ID Category

Adding a User Trait Category

Add an Event Category

Adding a Consent Field

Add an ID Consent Category

Add a Marketing Preference Category

Add a Product Category

Add a Campaign Category

Add an ID Metadata Category

Add a Non-Customer Entity Category

Last modified on September 1, 2026