> 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/audience-and-activation/activate-your-audiences/set-up-a-destination/feed.md).

# Feed

What a feed is, the two kinds, their statuses, and what a live feed actually sends.

## What a feed is

A **feed** is a connector that synchronises an audience segment from mediarithmics to an external partner, by sending the identifiers of the users belonging to that segment. It is the concrete delivery instance at the bottom of the [activation hierarchy](/audience-and-activation/activate-your-audiences/set-up-a-destination.md#the-four-levels), built on a [preset](/audience-and-activation/activate-your-audiences/set-up-a-destination/preset.md), and it adds only what is specific to one data stream: the source audience, optional filters, and the schedule.

Both kinds of feed can be used on **any** [segment type](/audience-and-activation/build-your-audiences/segment-reference/segment-types.md).

The underlying plugin model - how a connector is packaged and versioned - is documented in the **Setup & Monitor** section, under *Plugin architecture*.

## Server-side feeds

Server-to-server connections: the users' identifiers are sent directly from mediarithmics' servers to your partner's servers.

Their lifecycle has **seven statuses**.

<table data-search="false"><thead><tr><th width="180">Status</th><th>What is happening</th></tr></thead><tbody><tr><td><strong>Initial</strong></td><td>The feed has been added on a segment but has not been activated. No information has been sent to the activation platform.</td></tr><tr><td><strong>Creation</strong></td><td>The segment is being created on the activation platform.</td></tr><tr><td><strong>Connection</strong></td><td>Connecting to the segment on the destination, and checking the identifier can be sent to the partner.</td></tr><tr><td><strong>Starting</strong></td><td>Sending upserts as users enter the segment.</td></tr><tr><td><strong>Initial loading</strong></td><td>All users from the segment are being synchronised with the activation platform.</td></tr><tr><td><strong>Live</strong></td><td>Initial loading has finished. Differential updates keep the segment synchronised - see below.</td></tr><tr><td><strong>Closed</strong></td><td>The feed is closed. No more updates will be synchronised.</td></tr></tbody></table>

### What a Live feed sends

Once **Live**, the feed no longer resends the whole segment. It sends differences:

* **Upsert operations** for users entering the segment, and for users already in the segment who gain additional identifiers used in the sync.
* **Delete operations** for users leaving the segment, users deleted from the datamart, and users who updated their user choice in a way that makes it incompatible with being in the segment - where you chose to use a processing activity when defining that segment. See [Enforce compliance on your audience](/audience-and-activation/build-your-audiences/enforce-compliance-on-your-audience.md).

{% hint style="info" %}
This is why editing a segment does not cause a full resend: after the segment is recomputed, the feed upserts and deletes according to the new population.
{% endhint %}

## Client-side feeds

Client-side feeds share segments with your partners **from the user's browser**, when users visit the sites where you installed the mediarithmics JavaScript tag.

Their lifecycle has **two statuses**.

| Status     | What is happening                                                          |
| ---------- | -------------------------------------------------------------------------- |
| **Active** | Data is being sent to your partner's platform, through the user's browser. |
| **Paused** | No data is being sent.                                                     |

### How one works

{% stepper %}
{% step %}

### You activate the feed on a segment

Nothing is sent yet - the mechanism waits for traffic.
{% endstep %}

{% step %}

### A user visits your site

The mediarithmics JavaScript tag calls the platform with each ID available in the user's browser: cookies, email hash, network IDs.
{% endstep %}

{% step %}

### The platform resolves and responds

It resolves the user's identity, identifies which segments the user belongs to, and if those segments are activated with a client-side feed, returns the partner script to load in the browser.
{% endstep %}
{% endstepper %}

The last two steps are refreshed:

* Every time a new identifier is captured on the site, for example at login.
* Every time a new tab or window is opened on the site.
* Every 24 hours within an open tab that has not been closed, based on the `lastFeedRefreshDate` value held in local storage.

### The four caveats

{% hint style="warning" %}

* **A ramp-up period is unavoidable.** Unlike a server-side feed, a client-side feed can only synchronise a user while that user is visiting your sites. How long it takes to reach full volume at the partner depends on how often the segment's users come back.
* **On a Query segment, the sync waits for the computation.** Create a Query segment and attach a client-side feed straight away, and there will be a delay before the first users appear at the partner. See [Counting is not persistence](/audience-and-activation/build-your-audiences/segment-reference.md#counting-is-not-persistence).
* **There is no exit signal.** A client-side feed only works from the list of segments a user belongs to at the time of the visit, so removal from a segment cannot be communicated. To exclude users you previously synchronised, build a segment of the users to exclude and use it as an exclusion criterion in the partner's own campaign configuration.
* **Web browsers only, and only when the tag runs.** Client-side feeds are not supported in native mobile apps. If the user has an ad blocker, or opted out through your CMP, the mediarithmics tag does not fire and nothing is sent.
  {% endhint %}

### Two client-side mechanisms

For some partners a partner pixel or JavaScript API is integrated directly; for others the platform relies on the browser's local storage.

| Mechanism                 | What it does                                                                                                                                                                                                                         |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Pixel**                 | A piece of code placed on your pages. The call to the ad server transmits the audience IDs the user belongs to, which lets you track ad conversions and build remarketing audiences from visitors to your site or to specific pages. |
| **Browser local storage** | The segments a user belongs to are written to the browser's local storage, where any supported partner can read them.                                                                                                                |

The connectors using each mechanism, and the partners that read from local storage, are listed in the **Connectors** section.

## Feed sessions

A **feed session** is initiated whenever a feed is activated. A new session is also created if a feed is paused and then reactivated. Sessions are not visible in the interface - they matter because they are the unit the initial loading belongs to: reactivating a paused feed starts a new session, not a continuation of the old one.

## 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>Preset</strong></td><td>Where the identifiers a feed sends are decided.</td><td><a href="/audience-and-activation/activate-your-audiences/set-up-a-destination/preset.md">Preset</a></td></tr><tr><td><strong>Track a feed (stats and troubleshoot)</strong></td><td>Reading what a running feed is actually doing.</td><td><a href="/audience-and-activation/activate-your-audiences/track-a-feed-stats-and-troubleshoot.md">Track a feed (stats and troubleshoot)</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/audience-and-activation/activate-your-audiences/set-up-a-destination/feed.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.