> 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/sync-with-your-data-warehouse/replicate-live-tracking-to-your-warehouse.md).

# Replicate live tracking to your warehouse

Capture live activity with the mediarithmics tag and store it in your own warehouse instead of the datamart.

## Your goal

Keep collecting live activity from your sites and apps, and have it come to rest in your warehouse rather than in the platform - because in a [Hybrid or Zero-copy deployment](/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md#the-three-modes) the warehouse is the source of truth.

## Expected outcome

Activity captured by the mediarithmics tag, processed by the platform, and written into a location you chose in your warehouse, in the shape your schema declares.

{% hint style="info" %}
This feature is in Alpha. Contact your account manager to learn more.
{% endhint %}

## Why this is not optional in these deployments

Identity resolution is computed from raw activity. When the source of truth is the warehouse, the raw activity has to be in the warehouse, or there is nothing to compute the [identity graph](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/userpoint-and-identity-graph.md) from.

So replication is not an extra you switch on for convenience. It is the collection route itself, replacing the write to the datamart that a Hosted deployment performs.

## What stays the same, and what moves

|                                   | Hosted       | Hybrid and Zero-copy                         |
| --------------------------------- | ------------ | -------------------------------------------- |
| The tag on your sites and apps    | The same tag | The same tag                                 |
| Where activity is processed       | The platform | The platform                                 |
| Where activity is stored          | The datamart | Your warehouse                               |
| Long-term storage in the platform | Yes          | No. Live data transits through the platform. |
| Identity resolution at write time | Yes          | No. Activity is stored unreconciled.         |

Your [tracking plan](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/define-your-tracking-plan.md), your [web](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/web-tracking.md) and [app](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/app-tracking.md) integrations, and your [activity analyzers](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/activity-analyzers.md) are unaffected by the change of destination.

## What the platform does before writing

{% stepper %}
{% step %}

### Processing runs as usual

Activity passes through the processing pipeline, including activity analyzers and session aggregation.
{% endstep %}

{% step %}

### Identity reconciliation does not run

Activity is written carrying only the identifiers the tag collected. No UserPoint is referenced on it, because the reconciliation that would assign one happens later, in your warehouse.

This is deliberate. Keeping the original link between an activity and the identifiers it arrived with is what allows the identity graph to be recomputed after a configuration change, instead of being rebuilt from data that has already been merged.
{% endstep %}

{% step %}

### Activity that does not fit the schema is dropped

Only activity that can be mapped to the object tree your schema declares for live ingestion is replicated. In particular, an activity carrying no main identifier cannot be attached to anyone and is dropped.

[Map your warehouse tables to a schema](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/map-your-warehouse-tables-to-a-schema.md)
{% endstep %}

{% step %}

### Raw objects are written, then rebuilt into tables

Activity is written as raw objects into object storage in your environment, and the tables your schema describes are reconstructed from those objects at a regular frequency.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Because activity that does not match the schema is dropped rather than stored, the schema has to be right **before** you switch collection over. Publish and test the live object tree first, on a small scope, and compare counts before you extend it to all of your traffic.
{% endhint %}

## What you need in place

| Requirement                            | Notes                                                                                                                                                                      |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A declared warehouse**               | Google BigQuery or Snowflake. See [Warehouse compatibilities](/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/warehouse-compatibilities.md). |
| **Object storage in your environment** | Google Cloud Storage or Amazon S3, holding the raw objects the tables are rebuilt from.                                                                                    |
| **A location you choose**              | You decide where in the warehouse the live data is written.                                                                                                                |
| **An object tree for live ingestion**  | Declared in your datamart schema, describing the shape the activity is written in.                                                                                         |

## Verify

* Activity collected from a tagged page appears in the destination you configured.
* The rebuilt tables carry the identifiers the tag collects, and the properties your schema declares.
* A deliberately non-conforming event - one missing a main identifier - does not appear, which confirms the schema is being enforced.
* Counts in your warehouse match what [Monitor collection volume](/setup-and-monitor/operate-and-monitor/monitor-collection-volume.md) reports for the collections concerned.

## 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>Run your computation in the warehouse</strong></td><td>What happens to the replicated activity next.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/run-your-computation-in-the-warehouse.md">Run your computation in the warehouse</a></td></tr><tr><td><strong>Collect data in real time</strong></td><td>The tag, the tracking plan, and the collection routes.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time.md">Collect data in real time</a></td></tr><tr><td><strong>Choose your deployment mode</strong></td><td>Why the warehouse holds the source of truth here.</td><td><a href="/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md">Choose your deployment mode</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/collect-and-manage-your-data/sync-with-your-data-warehouse/replicate-live-tracking-to-your-warehouse.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.