> 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/import-data-in-batch/import-user-consent.md).

# Import user consent

Get consent decisions from your consent platform into the datamart, by the right route.

## Your goal

Make the consent decisions your users have given reach the datamart, so the platform can apply them to the data it collects.

## Expected outcome

A `UserChoice` per user and per processing activity, current enough that enforcing a privacy wall does not start dropping data you were entitled to keep.

{% hint style="danger" %}
Order matters. **Valid user choices must exist in the datamart before you enforce a privacy wall** on a channel or a compartment. Enforcing first means incoming activities or profiles are dropped, and **dropped data cannot be recovered**.
{% endhint %}

## What has to exist first

{% stepper %}
{% step %}

### The processing activities

A user choice always references a `$processing_id`. The processing activities have to be declared before any choice can point at them.

[Manage consent & Processing activities](/setup-and-monitor/ensure-privacy-and-compliance/manage-consent-and-processing-activities.md)
{% endstep %}

{% step %}

### An identifier you can key the choice on

A choice is attached to a user through an account ID with its compartment, an email hash, or a device identifier - one per record.
{% endstep %}

{% step %}

### A decision on where consent is captured

Your consent management platform on the website, your CRM, a mobile application, or a preference centre. Each implies a different route below.
{% endstep %}
{% endstepper %}

## Choosing a route

Three routes exist, and the right one depends on where the decision is made.

| Where consent is captured                             | Route                                                                             | Why                                                                                                                                                                                             |
| ----------------------------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| On your website, at the moment the user decides       | The `$set_user_choice` event through the tag                                      | Real time, and it travels with the activity.                                                                                                                                                    |
| In a mobile app or any environment without the tag    | A `$set_user_choice` event through the tracking API, or the user choices endpoint | Real time, and no tag required. See [Server-side events](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/server-side-events.md#create-or-update-a-user-choice).       |
| In a CRM, a preference centre, or a historical export | A `USER_CHOICE` document import                                                   | Bulk, and the only practical route for a backlog of existing decisions. See [Import user choices](/setup-and-monitor/collect-and-manage-your-data/import-data-in-batch/import-user-choices.md). |

{% hint style="warning" %}
`$set_user_choice` events sent through the tracking API pass through the [processing pipeline](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time.md#the-processing-pipeline) before being stored. Make sure no [activity analyzer](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/activity-analyzers.md) removes them on the way - an analyzer that filters unknown events will silently discard consent.
{% endhint %}

## Loading an existing backlog

This is the typical first task: the platform is new, but your users have already made choices.

{% stepper %}
{% step %}

### Export the decisions with their timestamps

`$choice_ts` matters - a choice without its original timestamp cannot be reasoned about later, and it is mandatory on an upsert.
{% endstep %}

{% step %}

### Map each decision to a processing ID

One record per user and per processing activity. A user who accepted two processings has two records.
{% endstep %}

{% step %}

### Decide between replace and merge

`force_replace: true` replaces the stored choice entirely; `false` merges into it. For a full authoritative export, replace. For an incremental feed covering one processing at a time, merge.
{% endstep %}

{% step %}

### Import, and check the result

See [Import user choices](/setup-and-monitor/collect-and-manage-your-data/import-data-in-batch/import-user-choices.md) for the command, and [reading the result](/setup-and-monitor/collect-and-manage-your-data/import-data-in-batch.md#reading-the-result) for what to check.
{% endstep %}

{% step %}

### Only then enforce

Attach the processing activities to your channels and compartments once the choices are in place. See [Channels](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-channels.md) and [Compartments](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-compartments.md).
{% endstep %}
{% endstepper %}

## Keeping it current

Consent changes, so the load is not a one-off:

* **New decisions** should arrive in real time, through the tag or the API - a nightly batch means up to a day of enforcement based on stale choices.
* **Withdrawals** matter more than acceptances: a choice that is not updated keeps the platform collecting data the user no longer accepts.
* **History is available.** The change log endpoint returns the history of a choice for a user and a processing, which is what you use to answer a question about a specific person. See [Server-side events](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/server-side-events.md#create-or-update-a-user-choice).

## Verify

* A test user's choice can be read back for the processing ID you referenced.
* The count of imported choices matches the count of decisions you exported.
* After enforcement, ingestion volumes for the channel do **not** collapse - a sharp drop means choices are missing rather than that users refused. See [Monitor data ingestion](/setup-and-monitor/operate-and-monitor/monitor-data-ingestion.md).

## 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>Manage consent &#x26; Processing activities</strong></td><td>The concepts, and the privacy wall.</td><td><a href="/setup-and-monitor/ensure-privacy-and-compliance/manage-consent-and-processing-activities.md">Manage consent &amp; Processing activities</a></td></tr><tr><td><strong>Import user choices</strong></td><td>The import command reference.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/import-data-in-batch/import-user-choices.md">Import user choices</a></td></tr><tr><td><strong>Exercise rights of the user</strong></td><td>Acting on an individual's request.</td><td><a href="/setup-and-monitor/ensure-privacy-and-compliance/exercise-rights-of-the-user.md">Exercise rights of the user</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/import-data-in-batch/import-user-consent.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.