> 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/build-your-audiences/enforce-compliance-on-your-audience.md).

# Enforce compliance on your audience

Attach processing activities to a segment so user choices are respected before anyone is included or activated.

## Your goal

Make sure a segment only ever contains users whose choices permit the use you intend, and that the permission is enforced by the platform rather than by convention.

## Expected outcome

A segment carrying one or more processing activities, with the platform checking user choices before including a user - and feeds deleting users from partner platforms when a choice changes in a way that makes them incompatible with the segment.

## When this is useful

Before any activation. Processing activity, user choice, and the privacy wall are defined in the **Setup & Monitor** section, under *Manage consent & Processing activities*. This page covers what those concepts mean **on a segment**, which is where the behaviour is specific and easy to get wrong.

## Steps

{% stepper %}
{% step %}

### Open the segment wizard

In the segment creation or edition wizard, find the **User Choices** section and click **Add Processing Activity**.
{% endstep %}

{% step %}

### Select the activities

Select the processing activity, or activities, that justify the creation of this segment.
{% endstep %}

{% step %}

### Save

Click **Save** to apply the configuration. From this moment, the platform checks user choices before including end users in the segment.
{% endstep %}
{% endstepper %}

## What the platform then does

The check point depends on the segment type, and the difference is not cosmetic.

<table data-search="false"><thead><tr><th width="200">Segment type</th><th>How consent is enforced</th></tr></thead><tbody><tr><td><a href="/audience-and-activation/build-your-audiences/segment-reference/segment-types/query-segment.md"><strong>Query</strong></a></td><td>Implicit conditions are added to the segment query, so it only scans users with compatible user choices. Enforcement happens <strong>at computation</strong>.</td></tr><tr><td><a href="/audience-and-activation/build-your-audiences/segment-reference/segment-types/list-import-segment.md"><strong>List</strong></a></td><td>User choices are checked <strong>before the user is added</strong> to the segment.</td></tr></tbody></table>

{% hint style="info" %}
The consequence for a Query segment: attaching a processing activity changes the query, so the segment has to be computed again before its population reflects the new rule.
{% endhint %}

## Combining several choices

This is the asymmetry to remember, because the two cases pull in opposite directions.

{% columns %}
{% column %}

### On a segment: AND

If you add several choices to a segment, the user choices must be compatible with **all** the processing activities. You are using the AND condition between choices.
{% endcolumn %}

{% column %}

### On a channel: OR

For a channel, choices from **at least one** processing activity must be valid for data to be ingested. You are using the OR condition between choices.
{% endcolumn %}
{% endcolumns %}

{% hint style="warning" %}
**Worked through.** A segment carrying two processing activities, `Analytics` and `Advertising`, includes only users who have valid choices for both - a user who consented to analytics alone is excluded. A channel carrying the same two activities ingests data from a user who consented to either one.
{% endhint %}

## Three segment types cannot carry a processing activity

{% hint style="danger" %}
User choices are **not supported** on [Campaign](/audience-and-activation/build-your-audiences/segment-reference/segment-types/campaign-segment.md), [Lookalike](/audience-and-activation/build-your-audiences/segment-reference/segment-types/cohort-lookalike-segment.md) and [Edge](/audience-and-activation/build-your-audiences/segment-reference/segment-types/edge-segment.md) segments.
{% endhint %}

That does not mean consent stops mattering on them - Edge follows the same consent management requirements as the rest of the platform, and an unconsented user's tag does not fire at all. It means the *segment-level* mechanism is unavailable, so compliance for those audiences has to be handled upstream: at collection, in the channel's processing activities, or in the segment they derive from.

## What happens when a choice changes later

Consent is not only checked on the way in. A live [feed](/audience-and-activation/activate-your-audiences/set-up-a-destination/feed.md) sends **delete operations** for users leaving the segment - and that includes 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 it.

{% hint style="info" %}
This is the practical reason to attach the processing activity to the segment rather than filtering the audience yourself before import: the deletion path back to the partner only exists if the platform knows the rule.
{% endhint %}

## Verification

* The segment's **User Choices** section lists the processing activities you expect.
* For a Query segment, the user count after the next computation reflects the restriction.
* On an activated segment, delete operations appear in the feed's stats as choices change. See [Track a feed](/audience-and-activation/activate-your-audiences/track-a-feed-stats-and-troubleshoot.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>Segment types</strong></td><td>Which type you are dealing with, and what that constrains.</td><td><a href="/audience-and-activation/build-your-audiences/segment-reference/segment-types.md">Segment types</a></td></tr><tr><td><strong>Feed</strong></td><td>Upserts, deletes, and what a live feed actually sends.</td><td><a href="/audience-and-activation/activate-your-audiences/set-up-a-destination/feed.md">Feed</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/build-your-audiences/enforce-compliance-on-your-audience.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.
