> 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/operate-and-monitor/monitor-collection-volume.md).
# Monitor collection volume
Count the elements indexed in each collection of your datamart, day by day.
## Your goal
Know how many elements are **indexed** in each collection of your datamart - UserPoints, events, profiles, segments - and watch how those counts move.
## Expected outcome
A daily count per collection you can trend, and a way to tell an indexing problem apart from an ingestion problem.
## What is counted, and what is not
{% hint style="warning" %}
Collection counts are retrieved every day, through OTQL queries, **for each indexed collection**. A collection is indexed **if it is in your schema** - volumes for non-indexed collections are **not computed**.
So a collection showing no volume means one of two very different things: nothing arrived, or it is not in your schema.
{% endhint %}
This is the complement to [ingestion monitoring](/setup-and-monitor/operate-and-monitor/monitor-data-ingestion.md): ingestion tells you what **arrived**, collection volume tells you what is **queryable**.
## The queries behind the numbers
The platform runs one count per collection, so you can reproduce any figure yourself:
| Collection | OTQL query |
| -------------- | ------------------------------------ |
| `UserPoint` | `SELECT @count {} FROM UserPoint` |
| `UserAccount` | `SELECT @count {} FROM UserAccount` |
| `UserEmail` | `SELECT @count {} FROM UserEmail` |
| `UserAgent` | `SELECT @count {} FROM UserAgent` |
| `UserProfile` | `SELECT @count {} FROM UserProfile` |
| `UserActivity` | `SELECT @count {} FROM UserActivity` |
| `UserEvent` | `SELECT @count {} FROM UserEvent` |
| `UserSegment` | `SELECT @count {} FROM UserSegment` |
| `UserChoice` | `SELECT @count {} FROM UserChoice` |
| `UserScenario` | `SELECT @count {} FROM UserScenario` |
{% hint style="info" %}
The query is adapted automatically when the runtime schema uses the [`@Mirror` directive](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md#mirror).
{% endhint %}
## Read the report
The endpoint is a mediarithmics **data cube**, like the other monitoring APIs.
```
POST https://api.mediarithmics.com/v1/platform_monitoring/collections
```
| Field | Type | Description |
| -------------------------- | ------ | ------------------------------------------------------------------ |
| `metrics` | Array | The metrics to retrieve. **Required.** |
| `dimensions` | Array | The dimensions to group by. **Required.** |
| `dimension_filter_clauses` | Object | Filters on dimensions before calculating the metric. **Required.** |
| `date_ranges` | Array | The periods to analyse. **Required.** |
```json
{
"date_ranges": [
{
"start_date": "2021-10-10T00:00:00",
"end_date": "2021-10-25T23:59:59"
}
],
"dimensions": [
{ "name": "date_time" },
{ "name": "community_id" },
{ "name": "collection" }
],
"dimension_filter_clauses": {
"operator": "AND",
"filters": [
{
"dimension_name": "community_id",
"operator": "EXACT",
"expressions": [100]
}
]
},
"metrics": [
{ "expression": "count" }
]
}
```
The response returns a report view with `columns_headers` and `rows` - for example `date_time`, `datamart_id`, `collection`, `count`.
## Retention
{% hint style="info" %}
These aggregated statistics are kept for **two years**.
{% endhint %}
Long enough for year-on-year comparison, unlike ingestion monitoring's three months.
## What the trends tell you
| Observation | What to look at |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| A collection has **no volume at all** | It is not in your schema. See [Schema definition](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md). |
| `UserPoint` grows **faster than your real user base** | Identifiers are being minted rather than matched - a format problem or a missing registry. See [Resolve identities](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/resolve-identities.md). |
| `UserPoint` **drops sharply** | An identifier association import merged more than you expected, or cleaning rules removed users with no remaining activity or profile. |
| `UserActivity` or `UserEvent` **plateaus** | Collection stopped, or a cleaning rule now expires as fast as data arrives. Cross-check with [ingestion monitoring](/setup-and-monitor/operate-and-monitor/monitor-data-ingestion.md). |
| `UserChoice` is **low** before you enforce a privacy wall | You are about to drop data. See [Manage consent & Processing activities](/setup-and-monitor/ensure-privacy-and-compliance/manage-consent-and-processing-activities.md). |
| Volume grew but a **new indexed property returns nothing** | Adding an index only covers data arriving afterwards. See [what happens when you change a schema](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md#what-happens-when-you-change-a-schema). |
## 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/operate-and-monitor/monitor-collection-volume.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.