> 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/track-a-feed-stats-and-troubleshoot.md).

# Track a feed (stats and troubleshoot)

Read a single feed's numbers - the three that matter, and the technical detail behind them.

## Your goal

Answer one question about one feed: is it successfully transmitting identifiers to the destination platform, and if not, where does the chain break?

## Expected outcome

A reading of the feed's three headline numbers, and - if they look wrong - a diagnosis from the troubleshooting graphs rather than a guess.

## Getting there

Go to the segment where the feed is configured, click the feed's menu button, and choose **Stats** or **Edit**.

The feed detail view has three sections, aimed at different readers:

<table data-search="false"><thead><tr><th width="180">Section</th><th>For whom, and what it holds</th></tr></thead><tbody><tr><td><strong>Stats</strong></td><td>Non-technical users. A high-level summary: the feed instance's status, and the identifiers sent to the partner for addition or deletion.</td></tr><tr><td><strong>Configuration</strong></td><td>Anyone checking what this instance is set to. Lists the properties configured on it. The layout is determined when the connector version is built, and the values are <strong>read-only once the feed is activated</strong>.</td></tr><tr><td><strong>Troubleshooting</strong></td><td>Technical users investigating an anomaly. Detailed graphs of the processing steps.</td></tr></tbody></table>

## The three numbers that matter

For a server-side feed, the **Stats** tab shows three high-level metrics over a selected period - 7 days by default, adjustable with the date selector.

| Metric                  | What it tells you                                                                                                       |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Upserts sent**        | The number of identifiers, attached to users that entered the segment, successfully pushed to the destination platform. |
| **Deletes sent**        | The number of identifiers, attached to users that left the segment, successfully pushed for deletion.                   |
| **Identifier coverage** | The percentage of users for which compatible identifiers could be sent to the destination platform.                     |

**Identifier coverage is the number the whole activation turns on.** A segment of a million users with low coverage delivers a small audience at the partner, and no amount of resending changes that - the constraint is which identifiers your users carry versus which identifiers the preset sends.

{% hint style="info" %}
**Reading it.** Large segment, healthy upserts, low coverage: the audience at the partner will be a fraction of the segment. The fix is on the [preset](/audience-and-activation/activate-your-audiences/set-up-a-destination/preset.md#identifying-resources) - send an identifier your users actually have - or on addressability, by adding a third-party identifier. See [Extend your reach with third-party ids](/audience-and-activation/activate-your-audiences/send-your-audience-to-a-destination/extend-your-reach-with-third-party-ids-connect-id.md).
{% endhint %}

Below the headline figures, the detailed metrics chart the volumes of identifiers upserted and deleted per day or per hour, depending on the period selected.

## For client-side feeds

A client-side feed does not push identifiers to a partner's API: browsers download it while users visit your sites. Its activity is therefore counted in feed downloads, not in identifiers sent.

On the **Stats** tab, a client-side feed shows **Downloads of the client-side feed** over the selected period:

* The headline figure is the total number of times browsers downloaded the feed.
* The chart below it shows the number of downloads per day or per hour, depending on the period selected.

{% hint style="warning" %}
Deletes and identifier coverage do not apply to a client-side feed. Judge it on download volume, and expect a ramp-up. See [Client-side feeds](/audience-and-activation/activate-your-audiences/set-up-a-destination/feed.md#client-side-feeds).
{% endhint %}

## The troubleshooting tab

The graphs here are displayed in pairs. What you see depends on how the connector delivers data.

### General information

* Both feed types: resource details, connector information, and connector version information.
* Server-side only: instance details, and initial loading logs.

### Unit updates

Present for all feeds. Tracks the number of users and identifiers sent to the feed, with a status per operation.

**Actions:**

| Action     | Meaning                                                         |
| ---------- | --------------------------------------------------------------- |
| **Push**   | Adding a user to the segment, or an identifier to a user.       |
| **Remove** | Removing a user from the segment, or an identifier from a user. |

**Statuses:**

<table data-search="false"><thead><tr><th width="270">Status</th><th>Meaning</th></tr></thead><tbody><tr><td><code>PROCESSED</code></td><td>Successful, with no response from the destination platform - typical of batch or file delivery.</td></tr><tr><td><code>SUCCEEDED</code></td><td>Successful, with a positive response from the destination platform.</td></tr><tr><td><code>FAILED</code></td><td>An error occurred, either inside the connector or at the destination platform.</td></tr><tr><td><code>NO_ELIGIBLE_IDENTIFIERS</code></td><td>There were no eligible identifiers to send.</td></tr></tbody></table>

{% hint style="warning" %}
A high `NO_ELIGIBLE_IDENTIFIERS` score is the same finding as low identifier coverage, seen per operation: most users in the segment do not carry the IDs this connector is configured to send. Adjust the identifiers sent through it.
{% endhint %}

### Batch metrics or file delivery metrics

Where present, these count the identifier groups and lines sent by the connector to the destination platform - rows per batch, or files sent and their response statuses, with rows per file. A row may contain several identifiers.

{% hint style="info" %}
**If this section is missing**, the connector is most likely sending user information individually rather than in batches. In that case **Unit updates** represents the data exchanged between the connector and the destination platform, and there is nothing further to look for.
{% endhint %}

### For client-side feeds

A daily graph of browser downloads, the same data as on the **Stats** tab.

## Diagnosis order

{% stepper %}
{% step %}

### Is the feed in the status you expect?

Check it against the seven server-side statuses. A feed stuck before **Live** has not finished initial loading. See [Feed](/audience-and-activation/activate-your-audiences/set-up-a-destination/feed.md#server-side-feeds).
{% endstep %}

{% step %}

### Is the destination still authenticated?

An **Error** on the destination can stop its feeds sending correctly. See [Understand destination status](/audience-and-activation/activate-your-audiences/set-up-a-destination/destination.md#understand-destination-status).
{% endstep %}

{% step %}

### Are upserts being sent at all?

No upserts on a populated segment points upstream - the segment may not be persisted or computed. See [Counting is not persistence](/audience-and-activation/build-your-audiences/segment-reference.md#counting-is-not-persistence).
{% endstep %}

{% step %}

### Is coverage the real constraint?

If upserts are healthy and the partner's audience is small, read the coverage percentage and the `NO_ELIGIBLE_IDENTIFIERS` count. This is the most common answer.
{% endstep %}

{% step %}

### Are operations failing at the partner?

`FAILED` in unit updates, or error statuses in the batch or file delivery graphs, point at the connector or the destination platform. Raise it with your Account manager with the period and the statuses you observed.
{% endstep %}
{% endstepper %}

## 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>Monitor your audiences</strong></td><td>The organisation-wide view this page zooms in from.</td><td><a href="/audience-and-activation/activate-your-audiences/monitor-your-audiences.md">Monitor your audiences</a></td></tr><tr><td><strong>Send your first-party data to a destination</strong></td><td>Creating and managing the feed itself.</td><td><a href="/audience-and-activation/activate-your-audiences/send-your-audience-to-a-destination/send-your-first-party-data-to-a-destination.md">Send your first-party data to a destination</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/track-a-feed-stats-and-troubleshoot.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.