> 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/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/network-ids.md).
# Network IDs
Extend recognition beyond your own identifiers with third-party network IDs.
## Your goal
Decide which third-party identifiers to integrate, and wire each one up so it is ingested from your sites and usable in your graph.
## Expected outcome
Each network ID you have contracted for exists as a registry or a compartment, is activated on your datamarts, and is captured from the channels where you want it.
## What a network ID is
A **network ID** - also called a universal ID - is an identifier whose generation or management involves a third-party actor, whether that means running the framework, defining it, or licensing it.
The goal is interoperability between ecosystem participants: consistent recognition of individual users or devices across different digital properties. Network IDs are built from emails, phone numbers, or softer signals such as IP addresses, and they support insight and campaign planning, targeting and activation, and reporting and attribution.
They can also increase addressability, by reaching users in environments that exclude third-party cookies.
There is no single network ID: multiple actors have launched initiatives, and they differ along three axes.
| Axis | Options |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **How they identify** | **Deterministic** - identifies the user deterministically on their web journey. **Probabilistic** - relies on different signals and attempts to identify the user, so identification is **less precise** but reach is higher. |
| **What they identify** | **Device-centric** - identifies a device. The same user browsing the same site from a computer and a smartphone has two different IDs. **User-centric** - identifies the user consistently across devices; a hashed email or an account ID behaves this way. |
| **Interoperability** | Some network IDs are interoperable with each other, which lets publishers and marketers find relevant audiences regardless of the network ID they use. |
{% hint style="warning" %}
The precision-versus-reach trade-off has a concrete consequence in the platform: for identifiers considered **probabilistic**, merging device points and UserPoints is **not allowed**, to avoid inconsistencies in your ID graph. A probabilistic ID therefore extends reach without consolidating history. See [UserPoint & Identity graph](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/userpoint-and-identity-graph.md).
{% endhint %}
## How the platform stores them
Network IDs are not a separate object type - they reuse the two containers you already know, and which one applies depends on what the ID identifies.
{% columns %}
{% column %}
### Device-based network IDs
Stored in **device registries**, because each device is assigned a registry where its identifiers are kept.
Registry type: usually `NETWORK_DEVICE_ID`.
[Device registries](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-device-registries.md)
{% endcolumn %}
{% column %}
### User-based network IDs
Stored in **compartments**, because each user network ID is assigned a compartment where its identifiers are kept.
Category: shared user account compartments.
[Compartments](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-compartments.md)
{% endcolumn %}
{% endcolumns %}
{% hint style="info" %}
Some network identifiers are user-related rather than device-related - those generated from an email address, for example. Check which family an ID belongs to before starting, because it decides whether you work with registries or compartments.
{% endhint %}
## The integration pattern
Whichever family the ID belongs to, the shape of the work is the same.
{% stepper %}
{% step %}
### Contract with the network ID provider
Contractualise with the network ID of your choice **before** activating it on mediarithmics. Your account manager can help with the details.
{% endstep %}
{% step %}
### Create or subscribe to the container
A device registry, or a compartment.
* Device: **Settings > Organisation > Device Registries**, then either **New Registry** for first-party registries, or **Shared device registries > Manage subscriptions** to subscribe.
* User: **Settings > Organisation > Compartments**, then either **First-party user account compartments > New Compartment**, or **Shared user account compartments > Manage subscriptions** to subscribe.
{% endstep %}
{% step %}
### Activate it on the datamarts concerned
Only necessary when your environment has several datamarts - with a single datamart it is automatic.
For a container created at community level, activate it across organisations: for compartments, select **Enable Compartment** in the **Shared user account compartments enabled** section.
{% endstep %}
{% step %}
### Activate ingestion on your channels
Most network IDs are ingested natively by the tag once enabled per channel: go to **Settings > Datamart > Channels**, select the site, and under **JS Tag Configuration > Device Identification** enable the identifier. Repeat for every site where you expect the ID to be collected.
Some IDs need more than a toggle - see the examples below.
{% endstep %}
{% endstepper %}
## Worked examples
{% tabs %}
{% tab title="First ID" %}
Device-based, and enabled entirely from the interface.
1. **Subscribe.** Go to **Settings > Organisation > Device Registries**, open **Shared device registries > Manage subscriptions**, and subscribe to First ID.
2. **Activate on all datamarts** if you have several.
3. **Activate ingestion.** First ID requires a modification of the tag to ingest the identifier: go to **Settings > Datamart > Channels**, select the site, open **JS Tag Configuration > Device Identification**, and enable **First ID**. Repeat for every site.
{% endtab %}
{% tab title="ID5" %}
Device-based, but ingestion is not self-service.
1. **Subscribe.** Go to **Settings > Organisation > Device Registries**, open **Shared device registries > Manage subscriptions**, and subscribe to ID5.
2. **Activate the subscription on all datamarts** if you have several.
3. **Ask for the channel configuration.** ID5 requires a specific technical configuration to be ingested correctly from your website. Contact your account manager to complete it - an activity analyzer is added to your channel to handle ID5 IDs.
{% endtab %}
{% tab title="UTIQ martechpass" %}
User-based, so it lives in compartments - and there are two of them.
UTIQ proposes two types of identifier: **UTIQ martechpass (mobile)** for identifiers coming from mobile network connections, and **UTIQ martechpass (fixed)** for identifiers coming from internet box connections.
1. **Subscribe to each type individually**, depending on which identifiers you want to capture: **Settings > Organisation > Compartments**, then **Shared user account compartments > Manage subscriptions**, and subscribe to the mobile and fixed variants.
2. **Activate on each datamart** if you manage several.
3. **Activate ingestion.** UTIQ IDs can be ingested natively by the tag: **Settings > Datamart > Channels**, select the site, then **JS Tag Configuration > Device Identification**, and enable **UTIQ martechpass (mobile)** and **UTIQ martechpass (fixed)**. Repeat per site.
The configuration steps are the same for both variants.
{% endtab %}
{% tab title="IP address" %}
IP addresses are captured through registries of type `IP_V4_ADDRESS_ID` and `IP_V6_ADDRESS_ID`.
{% hint style="info" %}
Automatic IP address capture is only available for **CTV channels**. To discuss activating it for site or mobile channels, get in touch with your account manager.
{% endhint %}
**Option 1 - dedicated registries per CTV channel.** Go to **Settings > Channels**, select or create a CTV channel, toggle **Active** in the IP addresses capture section, and save. Dedicated IPv4 and IPv6 registries are created automatically, and all captured addresses are stored in them. Repeat for each CTV channel.
**Option 2 - shared registries across CTV channels.** Create two device registries yourself under **Settings > Organisation > Device Registries** - one of type `IP_V4_ADDRESS_ID` and one of type `IP_V6_ADDRESS_ID`. Then on each CTV channel, activate IP capture, check **Use existing device registries**, select the two registries, and save.
{% endtab %}
{% tab title="Your own identifiers" %}
Not network IDs strictly speaking, but they follow the same mechanics.
**A custom device ID** - for instance a first-party cookie you generate. Go to **Settings > Organisation > Device Registries**, and in **First-party device registries** click **New Registry**:
| Parameter | What it is |
| --------------- | ----------------------------------------------------------------- |
| **Name** | The name of the device registry. |
| **Token** | A technical identifier used to link the registry with the JS tag. |
| **Type** | `MOBILE_VENDOR_ID` or `CUSTOM_DEVICE_ID`. |
| **Description** | Optional. |
**A custom user ID** - used to identify your users in your own systems such as CRMs, loyalty programmes, or authentication systems. Go to **Settings > Organisation > Compartments**, and in **First-party user account compartments** click **New Compartment**, giving it a **Name** and a **Token**.
In both cases, activate the new container on your other datamarts if you have several.
{% endtab %}
{% endtabs %}
## What the platform can host
Beyond network IDs, the graph supports first-party and third-party cookies, CRM IDs, mobile app IDs such as GAID and IDFA, hashed emails, telco box IDs, and TV advertising IDs. The identifier formats for each are in [User Device](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/user-identifiers/user-device.md).
## Choosing which network IDs to integrate
Compatibility is not universal: activation platforms have specific agreements with network IDs, so you will not be able to activate every network ID on every platform. Interoperability between network IDs can compensate for part of that.
Questions worth answering before you commit:
* What percentage of your users are logged in?
* Do you own one website, or several?
* Do you activate on your own sites, in audience extension, or both?
* Which activation platforms do you use?
* Do you already have your own first-party cookie?
{% hint style="info" %}
Which network IDs can be activated on which destination changes as connectors evolve. Check the `Connectors` section for the destination you use, and confirm with your account manager rather than relying on a snapshot.
{% endhint %}
## Verify
* Every network ID you contracted for has a registry or compartment that exists.
* With several datamarts, each container is activated on the ones that need it.
* The channels expected to collect the ID have it enabled in their tag configuration.
* After collection starts, the identifier appears on UserPoints under the expected registry or compartment.
## Related pages
---
# 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/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/network-ids.md?ask=&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.