Glossary

Key terms and concepts used in Zeotap and the CDP domain, sorted alphabetically.

A/B Test — A division of an audience into random percentage-based groups for experimentation. Uses deterministic hashing for consistent assignment — the same customer always falls into the same A/B test group, ensuring stable test populations across evaluations.

Access Policy — A row-level access control policy applied to groups. When an access policy is active for a group, all queries by group members are automatically scoped to matching rows only. Used for team-based data isolation (e.g., regional teams see only their region’s data).

Activation — The process of sending audience data or customer attributes from your warehouse to a destination platform for marketing, advertising, analytics, or operational use. Activation is the output stage of the CDP pipeline.

API Key — A secret token used for programmatic access to the Zeotap REST API and MCP server. API keys are workspace-scoped, hashed with bcrypt at rest, and support rotation and expiration.

Audience — A defined segment of customers based on computed attribute conditions and attribute filters. Audiences are created under Activation using the filter builder or NL Audience Builder, and activated via syncs to destinations.

Branch — An orchestration tile that splits the customer flow into two or more paths based on conditions. Branch types include computed attribute conditions, event checks, percentage splits, and time-based conditions.

CDP — Customer Data Platform. A system that unifies customer data from multiple sources, builds a single view of the customer, and enables activation to marketing, sales, and analytics tools. Zeotap is an Agentic, warehouse-native CDP.

Computed Attribute — A derived metric about a customer entity, evaluated as SQL against your warehouse. Three types: SQL computed attributes (custom SQL queries), aggregation computed attributes (count, sum, average, min, max over a related table), and formula computed attributes (combine existing computed attributes with expressions). Computed attributes are the building blocks for audience conditions.

Connected Components — The graph algorithm used in identity resolution to group related customer records into unified profiles. Records sharing a common identifier (directly or transitively) are placed in the same component, forming a cluster that becomes a golden record.

Consent Category — A classification (e.g., analytics, marketing, advertising, functional) used in event consent management to control which events are forwarded to which destinations based on the user’s consent state.

Contract — See Event Contract.

Data Prep — The module that builds prepared tables: clean, typed tables Zeotap creates and maintains in your warehouse from raw data that is not yet shaped for modelling. Enabled per workspace by a platform administrator. Deliberately never called a “transformation” — that word already names event transformations and field-mapping transforms elsewhere in the product.

Data Test — A rule declared on a prepared table that must hold true of its data — not null, unique, accepted values, a minimum row count, a maximum row change, a maximum age, or a custom expression. Measured against the new data before anything downstream can see it, so a failure at error severity refuses to publish and leaves the previous contents in place.

Destination — An external tool or platform where Zeotap sends data. Destinations span CRM, advertising, marketing, analytics, warehouses, cloud storage, and streaming categories. Zeotap supports 280+ destinations.

Destination Policy — A governance policy that controls which data can flow to specific destinations. Policies can block certain audiences from syncing to a destination, enforce field restrictions, or apply rate limits to protect destination APIs.

Entity Type — The role a model plays in your data model: parent (the people or accounts you build audiences about), related (attributes belonging to a parent record) or event (timestamped things that happened). A model carries exactly one, and classifying it is what makes it usable in the audience builder, in relationships and in identity resolution.

Event — A timestamped action or occurrence sent to Zeotap via the events API. Events follow a Segment-compatible format with six types: track (actions), identify (user traits), page (web page views), screen (mobile screen views), group (group membership) and alias (merging two identifiers for one person).

Event Contract — A schema definition that enforces required properties and data types on incoming events. Its enforcement mode decides what happens when an event breaks the declared schema — allow it, warn, or block it — and a separate undeclared-fields setting does the same for properties the contract does not declare.

Event Forwarding — Real-time routing of events from Zeotap to downstream analytics and marketing tools. Forwarding rules define which events go to which destinations, with optional property mapping and consent filtering.

Event Source — A secret token used to authenticate event sources when sending data to the Zeotap events API. Each event source is associated with a named source (e.g., “Production Web App”) for tracking and independent revocation.

Field Mapping — The configuration that maps columns from a Zeotap model or audience to fields in a destination. Field mapping defines how source data translates to the destination’s schema, including type conversions and field renaming.

Filter Builder — The visual interface in Activation for defining audience conditions using AND/OR logic, comparison operators (equals, greater than, contains, is null, etc.), and nested groups. Supports computed attribute values, entity attributes, and cross-entity conditions via relationships.

Formula Computed Attribute — A computed attribute that combines existing computed attributes using arithmetic or logical expressions. Formula computed attributes reference other computed attributes by name and support operations like lifetime_value / total_orders or days_since_last_order > 60.

Golden Record — The unified customer profile output from identity resolution, containing the best-known values for each attribute across all matched source records. Survivorship rules determine which source value wins when multiple records contribute the same attribute.

Governance — The set of features controlling access, data flow, and compliance: RBAC (who can do what), destination policies (where data can flow), access policies (which data is visible), organizations (multi-workspace management), and AI guardrails (safety boundaries for AI operations).

Group — A collection of people, belonging to an organization, granted roles on the workspaces it should reach. Groups are the only way access is granted: there is no direct workspace membership. A group is also the assignment target for access policies, so its members share both what they may do and which rows they may see.

Identifier Family — A category of customer identifier used in identity resolution (e.g., email, phone, device_id, customer_id). Each family can have variants (e.g., personal email, work email) and configurable matching rules.

Identity Graph — A configuration that defines how customer records are linked across data sources during identity resolution. Contains identifier families, merge rules, limit rules, and survivorship rules that control the unification algorithm.

Identity Resolution — The process of unifying customer records from multiple data sources into a single golden record using shared identifiers and a connected-components algorithm. Runs as SQL in your warehouse, supporting both full and incremental resolution modes.

Incremental Resolution — An identity resolution mode that only processes new or changed records since the last run, rather than recomputing the entire identity graph from scratch. Significantly faster for ongoing resolution after the initial full run.

Materialization — How a prepared table is built: a full rebuild every time, or incrementally, processing only the rows that arrived since the last build. Incremental tables use one of two strategies, append (replace the window) or merge (upsert on a unique key).

Orchestration — A multi-step, multi-channel workflow that customers move through based on triggers, conditions, and time delays. Built using a visual canvas editor with tiles for entry, wait, branch, action, and exit. Orchestrations automate customer experiences across destinations.

Limit Rule — A constraint in identity resolution that prevents super-clusters (unreasonably large merged profiles) by capping the maximum cluster size or the number of identifiers per family within a single cluster.

Loader — A connector that pulls data from SaaS applications (Salesforce, HubSpot, Stripe, Zendesk, etc.) into your data warehouse on a configurable schedule, making external application data available for modeling and audience building.

MCP Server — Model Context Protocol server that exposes Zeotap’s capabilities as AI-callable tools. Enables integration with Claude Desktop, Cursor, and any MCP-compatible client. Supports schema introspection, audience operations, sync management, and write operations with guardrail enforcement.

Membership API — The personalization surface that answers whether one person is in an audience right now. You ask by a single raw identifier and get back the realtime audiences in the workspace that they are in; narrowing to one audience returns that audience’s verdict either way. It is public and browser-callable, authenticated by a membership key. It returns verdicts only, never profile attributes — for those, see Profile API, which can also return membership alongside them for a server-side caller.

Merge Rule — A rule in identity resolution that defines which identifier matches can merge two records together. Merge rules support deterministic matching (exact value match on a specified identifier family) and can be configured to require matching on multiple identifier families.

Mirror Mode — A sync mode that keeps the destination in perfect sync with the source — creating new records, updating changed records, and deleting records that no longer exist in the source. The recommended mode for most syncs where the destination should always reflect current audience membership.

Model — A SQL query that defines a view of data from a connected source. Models shape raw warehouse tables into the format needed for syncing, computed attribute evaluation, audience building, and relationship mapping. Models are the bridge between raw data and Zeotap features.

Organization — A multi-workspace container for centralized billing, member management, and SSO configuration. Organizations allow companies to manage multiple workspaces (e.g., production, staging, different business units) under a single administrative umbrella.

Permission — A fine-grained access right in the RBAC system. Zeotap has 120 permissions across 43 resource categories, keyed {category}.{action} — sources.read, audiences.write, syncs.trigger. Permissions are granted only through roles, and a role reaches a person only through a group.

Prepared Table — A table Zeotap builds and owns in your warehouse, defined by a recipe and rebuilt on a schedule or when its inputs change. It sits between raw data and a model, so cleaning runs once per build rather than inside every query that reads the model.

Priority — An ordered list of audiences used to resolve membership overlap. When a customer qualifies for multiple audiences in a priority, they are assigned to the highest-priority audience only. Useful for tiered marketing programs and mutually exclusive segmentation.

Profile API — The personalization surface that reads one person’s published attributes by their id, in milliseconds, without querying the warehouse. It serves Entries out of a Store. It returns attributes, and on request also the realtime audiences that person is in — add ?include=audiences and the response carries an _audiences list alongside the fields. For membership on its own, or from a browser, see Membership API.

Profile Explorer — A UI for searching and viewing unified customer profiles from identity resolution. Search by any identifier (email, phone, customer ID) to see the golden record, linked source records, merge history, computed attribute values, and audience memberships.

RBAC — Role-Based Access Control. A permission model based on built-in roles (Owner, Admin, Member) with additive permissions. RBAC controls who can view, create, edit, and delete resources across the platform. Applied at the workspace level.

Realtime Audience — An audience whose filter tree contains at least one condition about a realtime event. It combines live behaviour — re-evaluated within about a second of an event arriving — with warehouse attributes taken from a periodically rebuilt Snapshot. It is never synced on a schedule: it is read through the Membership API, and pushed through a Realtime Sync.

Realtime Sync — The push egress of a realtime audience: it tells one destination when an event shows that one person has joined the audience, and — under the mode that sends both — when an event shows they have left. It pushes a change rather than a list, which is why a realtime audience can have one while it can never have a scheduled sync. A person whose answer changes with no event of their own is sent at their next event.

Realtime Sync mode — What a realtime sync promises its destination, chosen when the sync is created and changeable afterwards. Send people as they join tells the destination only about arrivals, so the destination keeps everyone it was told about and holds a superset of the audience. Send people as they join and as they leave tells it both ways. Departures under the first mode are still recorded, and counted as not sent.

Recipe — The definition of a prepared table: one primary input plus an ordered list of steps, which compiles to a single SELECT. A step is either typed — a set of options Zeotap compiles for your warehouse — or a SELECT you write yourself.

Relationship — A defined connection between two entity types (e.g., User belongs_to Account, User purchased Product). Relationships enable cross-entity audience building (e.g., “Users whose Account has over 100 employees”) and cross-entity computed attribute evaluation.

Relationships — The structural definition of your customer data, including entity types, their attributes (identifiers and properties), and relationships between entity types. The Relationships module gives Zeotap a unified understanding of your data model across all connected sources.

Reverse ETL Sync — A connection between a model and a destination that defines field mapping, sync mode, schedule, and error handling. Reverse ETL syncs move data from your warehouse to external tools on a configured cadence.

Role — A named set of permissions. A role is held by a grant — one group, one workspace — rather than by a person. Built-in roles are Owner (full access), Admin (everything but deleting the workspace) and Member (read across the platform). Custom roles belong to the organization, so one role can be granted on every workspace in it.

Reconcile — A check that an incremental prepared table matches what a full rebuild would produce. It rebuilds the table into a scratch copy, compares row counts and a checksum over every column, reports the keys that differ, and drops the copy — never swapping, applying or moving the watermark.

Snapshot — The precomputed warehouse half of a realtime audience. Attribute conditions are not queried at read time; they are worked out in advance into a snapshot, and a membership verdict combines that snapshot with live behaviour from the event stream. One snapshot per audience, and one cadence per workspace.

Snapshot rebuild — Recomputing an audience’s snapshot from the warehouse, either on the workspace cadence or on demand with Rebuild now. A snapshot is rebuilt, never “refreshed” — a Store feed is what refreshes. The distinction is worth keeping because the two are different objects on different schedules: rebuilding a snapshot changes who is in an audience, refreshing a feed changes what a Store serves about a person.

Store — A low-latency cache of selected warehouse model columns, addressed by name and holding Entries keyed by a primary key. Populated by feeds on a schedule and read by key through the Profile API. A Store is a read layer you query directly, not a destination data is pushed to.

Sync (Activation) — A connection that sends audience membership and mapped fields to a destination. Supports three modes: mirror (full sync with adds, updates, and removes), additive (only adds new members), and subtractive (only removes exited members).

Sync Mode — The strategy for how data is written to a destination: upsert (create or update based on a matching identifier), mirror (full sync with creates, updates, and deletes), append (add only, no deduplication), or insert (create only, fail on duplicates).

Sync Run — A single execution of a sync. Each run produces metrics including rows synced (added, updated, removed), errors encountered, duration, throughput (rows/second), and completion status. Sync runs are logged in the audit trail and visible in the Insights dashboards.

Tile — A building block in the orchestration canvas. Tile types include: entry (defines who enters), wait (pause for a duration), branch (split based on conditions), action (send a message or trigger an API call), update profile (modify a computed attribute or attribute), webhook (call an external URL), sub-orchestration (nest another orchestration), and exit (end the orchestration).

Transformation — A processing step applied to events between receipt and forwarding. Transformations can rename properties, add computed properties, remove sensitive fields, filter events, or modify values before the event reaches its destination.

Upsert — A sync mode that creates new records when the matching identifier doesn’t exist in the destination, and updates existing records when it does. Does not delete records that are removed from the source. The most common sync mode for model-to-destination syncs.

Variant — A sub-type within an identifier family in identity resolution. For example, the “email” family might have “personal” and “work” variants. Variants allow more granular control over which identifier matches can trigger a merge.

Warehouse — A connection to a data warehouse (Snowflake, BigQuery, Databricks, ClickHouse, Redshift). Warehouses are read-only connections from which models query data. Zeotap executes SQL against warehouses but does not write to warehouse tables (except for its own operational schemas).

Warehouse-Native — Zeotap’s core architecture principle where all computation (computed attribute evaluation, audience building, identity resolution, model execution) runs as SQL queries directly in the customer’s data warehouse. Customer data never leaves the warehouse except during activation to destinations.

Workspace — The top-level organizational unit in Zeotap. A workspace contains all resources (sources, models, destinations, syncs, audiences, computed attributes, orchestrations, events, governance policies) and manages member access via RBAC. Each workspace connects to one primary data warehouse.