> ## 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.
# Key Concepts
> The core ideas behind Collaborate — the data clean room, join keys, insight dimensions, aggregate thresholds, activation settings, the partnership lifecycle, composable vs ingested sources, suppression, and the activity log.
This reference explains the core ideas behind Zeotap Collaborate. Understanding these concepts will help you configure partnerships correctly and interpret analysis results accurately.
## Data Clean Room
Zeotap Collaborate is built on **Google BigQuery's Analytics Hub Data Clean Room** infrastructure. This is what makes privacy-safe collaboration possible.
When a partnership is created, Zeotap provisions a secure, isolated environment inside BigQuery. Overlap analysis runs inside this environment — neither organisation's raw data leaves their own environment. The Contributor's data is queried in place; the Subscriber's data is brought in for matching; the result that comes out is an aggregated count, not a list of individuals.
This architecture means:
* The Subscriber never receives the Contributor's raw records.
* The Contributor never sees what is in the Subscriber's dataset.
* Both sides can trust that the analysis reflects true overlap without either party exposing their customer data.
## Join Keys
A **Join Key** is the identity attribute used to match records between the Contributor's dataset and the Subscriber's dataset. It must be an ID-type attribute — a field that uniquely identifies a person, such as a hashed email address or hashed phone number.
**How matching works**
The clean room compares the join key values from both sides. A match occurs when the same identifier value appears in both datasets. For example, if both organisations hold Email MD5 values, a user with Email MD5 `a3f…` on the Contributor side is matched to the same `a3f…` value on the Subscriber side.
Use consistent, mutually agreed-upon hashed data (such as SHA-256 emails or user IDs) as a standard best practice for privacy-safe data collaboration.
**Multiple join keys**
A partnership can have more than one join key — for example, both Email MD5 and Phone MD5. Each join key is matched independently. This generally increases the size of the overlap, because users who are present in only one identifier type can still be matched.
**Unmapped join keys**
If the Subscriber has not mapped one of the Contributor's join keys (because they do not hold that identifier type), that join key is simply excluded from the analysis. The partnership still works; the overlap is calculated using only the keys that were successfully mapped.
**Common join key types**
Email MD5, Email SHA256, Phone MD5, Phone SHA256, Zeotap ID, and other platform-specific IDs are typical join key types. The key requirement is that both organisations hold the same type and have applied the same hashing algorithm.
## Insight Dimensions
An **Insight Dimension** is an attribute the Contributor chooses to share for analysis purposes — not for matching. It allows the Subscriber to break down the overlap count by characteristics of the Contributor's audience.
**What the Subscriber sees**
When a Subscriber selects an insight dimension in analysis, they see the matched overlap count split by each value of that attribute. For example, if the Contributor shares "Gender" as an insight dimension, the Subscriber sees:
| Gender | Overlap |
| :----- | :------ |
| Male | 11,678 |
| Female | 11,800 |
The Subscriber does not see which specific users fall into each group — only the aggregate count per segment.
**What the Contributor should consider**
Insight dimensions are a deliberate choice. By enabling an attribute as an insight dimension, you are giving your partner partial visibility into the demographic or behavioural composition of the matched audience. Consider whether this is appropriate for your data governance policies before enabling dimensions beyond the join key. This applies to both composable and ingested sources — in both cases, aggregated breakdown values are visible to your partner in results.
**Choosing the right attributes**
Insight dimensions are designed for categorical attributes with a finite set of values — gender, age band, purchase category, region, device type. Do **not** enable individual-level attributes (customer IDs, precise timestamps, free-text fields, or any attribute whose values differ at the per-person level) as insight dimensions. Even though results are guarded by the aggregate threshold, these attributes are not suitable for group-by analysis and will not produce meaningful results.
**Common insight dimension examples**
Age group, gender, purchase category, interest segment, loyalty tier, device type, and geography (country or region) are frequently used as insight dimensions.
## Aggregate Threshold
The **Aggregate Threshold** is a minimum group size set by the Contributor. Any cohort in the analysis results that contains fewer users than this threshold is hidden entirely from the Subscriber — not shown as a small number, but suppressed completely.
**Default**
The default threshold is **1,000**. Groups smaller than 1,000 are not shown in results by default.
**Why suppression exists**
If a Subscriber could see very small cohort sizes — for example, "3 matched users are Female aged 25–34 in Munich" — it would be possible in some cases to infer the identity of individuals. Suppressing small cohorts prevents this.
**Effect on Save as Audience**
The threshold also governs whether a Subscriber can save a cohort as an audience. Any overlap bucket not shown due to the threshold cannot be saved as an audience.
## Activation Settings
**Activation Settings** are configured by the Contributor and control what the Subscriber can do with analysis results beyond viewing them.
**Allow Activation toggle**
When this is off, the Subscriber can run analysis and view all result panels, but the **Save as Audience** button is disabled throughout. No audiences can be created from this partnership. When this is on, the Subscriber can save audiences from the Overlap, Insight Dimension, and Suppression sections.
**Activation Channels**
When activation is enabled, the Contributor selects which downstream channels the Subscriber may push audiences to. Only destinations from these channels appear in the Subscriber's activation workflow. If the Contributor has not permitted a particular channel, the Subscriber cannot activate it — even if that channel is connected in their own Zeotap org.
A channel selected by the publisher also needs to be enabled for the subscriber org to facilitate activation.
## Partnership Lifecycle
A Collaborate partnership moves through the following statuses:
| Status | What it means |
| :----------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pending** | The partnership has been created. An invitation email has been sent to the Subscriber's CDP admins. Waiting for the Subscriber to accept. The Contributor can begin their configuration at this stage. |
| **In Setup** | The Subscriber has accepted the invitation. Both sides are completing their configuration. The Subscriber can map join keys once the Contributor has submitted their configuration. |
| **Active** | Both sides have submitted their configuration. Analysis can be run. |
| **Archived** | The partnership has been closed. It is no longer available for analysis. Both organisations receive an email when a partnership is archived. This is a terminal status. |
The **Activity Log** tab on each partnership shows a timestamped record of all user-facing events, visible to both sides. See [Activity Log](#activity-log) below for the full reference.
## Composable Sources vs Ingested Attributes
These are the two ways data can be brought into Zeotap, and they behave differently in the context of Collaborate.
**Composable Sources (warehouse-native)**
A composable source connects to data that lives in the **client's own BigQuery environment**. Zeotap creates a view over the data and queries it in place — no raw data is copied into Zeotap's systems.
Collaboration only works if the subscriber's org is a composable org. This is to enable audience creation and activation on the publisher's attributes without copying the publisher's data into the subscriber's project.
**Ingested Attributes**
Ingested attributes are data the client has uploaded into **Zeotap's managed environment** through standard data ingestion pipelines. The data is stored and processed within Zeotap's infrastructure.
**Why they cannot be mixed**
Each partnership must use one source type exclusively. The underlying infrastructure that powers the clean room analysis handles composable and ingested data through different query paths, and these paths cannot be combined within a single analysis context.
## Suppression Analysis
Suppression is an analysis view that shows the portion of the Subscriber's dataset that was **not matched** by the Contributor. It is the inverse of the overlap. This is valuable for:
* **Exclusion targeting** — identifying customers your partner has not yet reached, for campaigns aimed at filling that gap.
* **Incrementality measurement** — understanding what share of your audience is unique versus shared with your partner.
* **Frequency management** — suppressing already-reached audiences from campaigns to avoid over-exposure.
The Subscriber can save the suppression result as an audience in the same way they can save the overlap result, subject to the same aggregate threshold and activation settings.
## Activity Log
The Activity Log is a chronological, tamper-evident record of significant events on a partnership. It is visible to both the Contributor and the Subscriber — both sides see the same log, with no separate view per role. Each entry shows the event label, a human-readable description, the actor's organisation, and a timestamp.
The following events are displayed in the UI.
**When it fires:** Immediately when the Contributor creates the partnership.
**What it shows:** "\[Contributor org] sent invite to \[Subscriber org]"
**What it means:** The partnership has been created and an invitation email has been dispatched to the CDP admins of the Subscriber's organisation. The Contributor can begin their configuration at this point.
**When it fires:** When a Subscriber CDP admin accepts the invitation.
**What it shows:** "\[Subscriber org] accepted the invite"
**What it means:** The Subscriber has acknowledged the partnership. The status moves from **Pending** to **In Setup**. The Subscriber can now see the configuration screen and begin mapping their join keys, but only after the Contributor has completed their configuration.
**When it fires:** When a Subscriber CDP admin declines the invitation.
**What it shows:** "\[Subscriber org] declined the invite"
**What it means:** The Subscriber has rejected the partnership. The partnership does not progress. The Contributor would need to create a new partnership to try again.
**When it fires:** When the Contributor submits their attribute selection and privacy settings (Steps 1 and 2 of the configuration wizard).
**What it shows:** "\[Contributor org] submitted their configuration"
**What it means:** The Contributor has defined which attributes are shared, which are join keys, which are insight dimensions, the aggregate threshold, and the activation settings. This unlocks the Subscriber's configuration step — the Subscriber can now map their join keys.
**When it fires:** When the Subscriber submits their join key mapping.
**What it shows:** "\[Subscriber org] mapped X join keys successfully"
**What it means:** The Subscriber has mapped their identity attributes to the Contributor's join keys. The number of successfully mapped keys is shown in the description. If both sides have now submitted, the partnership status moves to **Active** and analysis can begin.
**When it fires:** When an analysis pipeline run completes successfully.
**What it shows:** "Overlap analysis completed with X matched records"
**What it means:** The Subscriber triggered an overlap analysis and it has finished. The overlap count in the description is the total number of matched records across all mapped join keys. The Subscriber can view the full results in the Analysis tab.
**When it fires:** When the Subscriber saves an audience from analysis results.
**What it shows:** "Audience saved from \[overlap / insight dimension / suppression] segments"
**What it means:** The Subscriber has created a new audience from their analysis results. The description indicates which part of the results it was saved from — the main overlap, an insight dimension breakdown, or the suppression view. The audience is now available in **Segment → Audiences** for activation.
**When it fires:** When either the Contributor or the Subscriber terminates the partnership.
**What it shows:** "\[Org name] terminated the partnership"
**What it means:** The partnership has been archived. No further analysis can be run. Both organisations receive an email notification. Any audiences already saved from previous analyses are unaffected.
## Related guides