> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/plan-and-integrate/set-up-advanced-features/cross-cdp.md).

# Cross-CDP

Aggregate data from several organisations into a parent organisation.

## Your goal

Bring the data of several organisations together so it can be analysed and activated at group level, without merging the organisations themselves.

## Expected outcome

An organisation hierarchy in which a parent organisation aggregates the data of its children, and clarity about which settings and objects are genuinely shared.

## What Cross-CDP is

**Cross-CDP** is an architecture model rather than a feature you switch on: data from multiple organisations is aggregated into a parent organisation, sometimes called a **Master CDP**.

It relies entirely on the community and organisation hierarchy described in [How your instance is organised](/setup-and-monitor/plan-and-integrate/set-up-the-environment/prerequisites-organisation-and-datamart.md#organisations-and-communities): an organisation can have one parent and several children, and the top-level organisation of a hierarchy is a community.

```mermaid
flowchart TD
    P["Parent organisation<br/>(Master CDP)"]
    A["Organisation A"]
    B["Organisation B"]
    C["Organisation C"]
    A --> P
    B --> P
    C --> P
```

{% hint style="warning" %}
Inheritance of settings and objects from parent organisations is **not systematic**. Designing a Cross-CDP model means deciding deliberately, per object type, what exists where - not assuming that a parent sees everything its children have.
{% endhint %}

## When to consider it

Consider a Cross-CDP model when several entities each need their own CDP - their own users, their own settings, their own datamart - while the group needs a consolidated view for analysis or activation.

If that is not your situation, one of the other collaboration models may fit better:

| You want to                                                                                                     | Model                   | Where it is documented                                       |
| --------------------------------------------------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------ |
| Consolidate several of your own organisations into a parent                                                     | **Cross-CDP**           | This page                                                    |
| Share audience segments directly between entities, in the same group or across groups, both using mediarithmics | **Shared Segment feed** | The `Connectors` section, under mediarithmics Shared Segment |
| Run marketing and monetisation use cases with a partner **without sharing your data**                           | **Data Clean Room**     | The `Collaboration` section                                  |

## What to settle before you build it

Because Cross-CDP is a structural choice, the decisions are the same ones you take in [Frame your CDP project](/setup-and-monitor/plan-and-integrate/frame-your-cdp-project.md), applied twice - once per child organisation and once at group level:

* **Where each datamart lives**, and whether the parent has one of its own.
* **Which identifiers are common across entities.** Consolidation is only meaningful where users can be recognised in more than one entity; that depends on your [compartments](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-compartments.md) and [device registries](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-device-registries.md).
* **Which roles are granted where.** Roles set on an organisation are inherited by its children, so a role granted at group level reaches every entity below it. See [Manage users and roles](/setup-and-monitor/manage-the-platform/manage-users-and-roles.md).
* **What each entity's retention policy is.** Cleaning rules are per datamart. See [Data retention](/setup-and-monitor/plan-and-integrate/set-up-the-environment/manage-data-retention.md).

{% hint style="info" %}
Because a Cross-CDP model shapes your organisation structure - and structure is hard to change once data is in it - plan it with your mediarithmics contact before creating the organisations.
{% endhint %}

## Related pages

<table data-view="cards" data-search="false"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>How mediarithmics works</strong></td><td>Communities, organisations, and what a datamart is.</td><td><a href="/setup-and-monitor/understand-mediarithmics/how-mediarithmics-works.md">How mediarithmics works</a></td></tr><tr><td><strong>Frame your CDP project</strong></td><td>The decisions to take per entity and at group level.</td><td><a href="/setup-and-monitor/plan-and-integrate/frame-your-cdp-project.md">Frame your CDP project</a></td></tr><tr><td><strong>Manage users and roles</strong></td><td>How access is inherited down a hierarchy.</td><td><a href="/setup-and-monitor/manage-the-platform/manage-users-and-roles.md">Manage users and roles</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mediarithmics.io/setup-and-monitor/plan-and-integrate/set-up-advanced-features/cross-cdp.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.