> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/configure-privacy-identity-retention-and-regional-use.md).

# Configure privacy, identity, retention, and regional use

Define consent, data use, identity, retention, regional processing, and safe fallback rules.

Podigee Audio Video Ad Server uses a versioned privacy and data-use policy for every request that may use listener or device signals. After the first mention, this article uses Podigee Ad Server for the product name. The policy limits what a delivery decision may use. It does not create a new targeting capability.

Use this task when you need to define consent signals, lawful purpose, identity evidence, regional processing, retention, provider sharing, targeting use, measurement use, or the no-consent fallback.

## Before you start

* You have permission to manage privacy and data-use rules.
* You know the workspace, business unit, portfolio, or show scope.
* You have the approved legal basis and retention requirement.
* You know which integrations can provide each consent signal.
* You know the region where the data may be processed.
* You know the safe behavior when consent or a required signal is missing.

## Open the policy

1. Open **Monetization > Monetization settings**.
2. Select **Revenue and data rules**.
3. Select **Privacy and data use**.
4. Choose **Add policy** or open the policy to revise.
5. Select the exact scope where the rule applies.

Do not create a second policy with the same scope and purpose only to work around a conflict. Create a new version of the current policy and keep the previous version in the history.

## Define the purpose and lawful basis

1. Select the purpose: ad selection, frequency control, measurement, or fraud prevention.
2. Select the lawful basis: consent, legitimate interest, contract, or legal obligation.
3. Add one row for each separate purpose and basis.
4. Remove a row when the purpose is no longer approved.

Use one row for one purpose. Do not use a broad purpose to justify an unrelated data use. The purpose and lawful basis are part of the policy version that the decision records.

## Select verified identity and consent signals

1. Select the consent signals that the connected player or provider can verify.
2. Select the identity evidence that may be used: contextual, coarse region, pseudonymous session, or consent signal.
3. Select only the signals that the delivery surface can send and the policy permits.
4. Check the provider name and the allowed purposes for shared data.

Do not treat a missing signal as consent. Do not select a signal because a provider claims to support it. The connection must have a current contract and a tested request mapping.

![The One Podigee privacy rule shows recognized consent signals, permitted identity evidence, and allowed-use controls.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-6c206084d221832b04899de0256b7b7131ff452d%2Fdoc-monetization-035-consent-and-use.jpg?alt=media)

*A stronger identity signal does not permit a use that the policy forbids.*

## Set targeting and measurement use

Select the uses that are allowed by the policy:

* **Targeting:** content context, coarse region, device class, or frequency control.
* **Measurement:** aggregate delivery, qualified audience, conversion, or fraud prevention, according to the available controlled values.

Select only the uses supported by the data and the provider contract. For example, a contextual signal can support content targeting but does not prove a personal audience segment.

The policy can reduce eligible demand. That is the intended result when a signal, purpose, or region is not permitted.

## Set retention and regional processing

1. Enter the approved retention period in days.
2. Select the data region.
3. Select the deletion behavior.
4. Select the behavior when a retention or deletion request affects an active delivery record.
5. Review the effect on reports, event evidence, and financial records.

Retention controls stored identity and policy evidence. It does not remove the minimum evidence needed for an active commercial, financial, security, or audit obligation. A deletion or restriction request uses the privacy request workflow and the applicable legal basis.

## Configure provider sharing

For each provider that may receive data:

1. Select **Add provider**.
2. Choose the approved provider identity.
3. Select its allowed purposes.
4. Select the data classes that may be shared: context, coarse region, pseudonymous session, or consent signal.
5. Set the provider validity period.
6. Remove a provider when the contract or purpose ends.

Do not paste an API key, token, or raw personal identifier into the policy. Credential handling and provider identity belong to the integration setup.

## Set the no-consent fallback

Choose the safe result when consent is missing, invalid, or outside the permitted purpose. The available fallback may select contextual demand, return no fill, or use another approved path.

The fallback must not use a signal that the policy rejected. Check the result against one audio and one video request when both media types are enabled.

## Review and publish

1. Check the policy scope and effective time.
2. Check every purpose, lawful basis, signal, identity level, and allowed use.
3. Check retention, region, deletion behavior, provider sharing, and fallback.
4. Preview the effect on targeting, measurement, and eligible supply.
5. Complete the configured review or solo confirmation.
6. Select **Publish policy**.
7. Keep the policy receipt.

Use [Set targeting, exclusions, and brand safety](/documentation/grow-and-monetize/monetization/set-targeting-exclusions-and-brand-safety.md) to check the supply effect after you publish the policy.

## If delivery changes after the policy update

* **More no-fill results:** check whether a new purpose, signal, region, or provider rule excludes the request.
* **A provider receives no data:** check the provider purpose and data-class selections.
* **A request uses an unapproved signal:** pause the affected connector and inspect its mapping.
* **The policy is waiting for review:** complete the required review or use the configured solo confirmation when the workspace permits it.
* **The current policy is wrong:** publish a successor version. Do not edit the historical version.

## Expected result

The workspace has one clear privacy policy for each scope and purpose. Decisions use only verified signals, approved purposes, permitted regions, and active provider contracts. Missing consent uses the declared fallback. Reports and evidence show the policy version used by each result.

## Next useful tasks

Use [Set targeting, exclusions, and brand safety](/documentation/grow-and-monetize/monetization/set-targeting-exclusions-and-brand-safety.md) to apply the policy to Campaign planning. Use the privacy request workflow when a person asks to access, export, delete, or restrict their data.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/configure-privacy-identity-retention-and-regional-use.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.