> For the complete documentation index, see [llms.txt](https://docs.didomi.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didomi.io/fr/analyses/analyses-de-la-plateforme-de-gestion-du-consentement-cmp/introduction/visiteurs-uniques-mensuels-muv.md).

# Visiteurs uniques mensuels (MUV)

Les visiteurs uniques mensuels (MUV) sont une estimation du nombre total d’utilisateurs distincts qui visitent le site Web et/ou l’application de votre organisation au cours d’un mois donné. Dans cet article, nous aborderons :

* [Taux d’échantillonnage des MUV](#muvs-sampling-rate)
* [Calcul des MUV](#muvs-calculation)
* [Calcul des MUV par fonctionnalité](#muvs-calculation-by-features)
* [Écarts des MUV](#muvs-discrepencies)

{% hint style="info" %}
Les MUV ne sont pas équivalents au nombre total de décisions de consentement prises par les utilisateurs finaux. Les MUV couvrent tout le trafic vers votre site Web et/ou votre application, que l’utilisateur final ait fourni ou non une décision de consentement pendant la période.
{% endhint %}

<figure><img src="https://1244787492-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNDxbAdc00ce6bH5u1urh%2Fuploads%2FxTcM9vaAea30LwUX7Lcp%2FCapture%20d%E2%80%99e%CC%81cran%202022-11-14%20a%CC%80%2008.21.10.webp?alt=media&amp;token=ec2a4cdb-474d-4ae9-b086-368d047d7d26" alt="" width="563"><figcaption></figcaption></figure>

***

### Taux d’échantillonnage des MUV

L’échantillonnage désigne la collecte d’événements auprès d’utilisateurs finaux tirés au hasard, puis l’extrapolation des données analytiques dans les tableaux de bord CMP de votre organisation. La stratégie d’échantillonnage de Didomi [stratégie d’échantillonnage](/fr/analyses/analyses-de-la-plateforme-de-gestion-du-consentement-cmp.md#data-sampling) garantit que l’échantillon est représentatif de l’ensemble de la base d’utilisateurs finaux en sélectionnant des utilisateurs finaux purement aléatoires et en consignant tous les événements pour ces utilisateurs finaux (ce qui garantit que nous capturons le comportement complet de ces utilisateurs finaux).

Le taux d’échantillonnage des MUV est le suivant :

<table><thead><tr><th width="121.550048828125">Plateforme</th><th>Taux d’échantillonnage</th></tr></thead><tbody><tr><td>Web</td><td>3 % des utilisateurs finaux</td></tr><tr><td>Mobile</td><td>10 % des utilisateurs finaux</td></tr><tr><td>CTV</td><td>10 % des utilisateurs finaux</td></tr></tbody></table>

### Calcul des MUV

Les MUV sont déterminés en comptant les identifiants uniques d’utilisateurs finaux enregistrés lors des pages vues ou des sessions d’application, puis en extrapolant le nombre total de visiteurs sur la base d’un taux d’échantillonnage prédéfini.&#x20;

Les SDK Didomi sont appelés chaque fois qu’une page est chargée ou qu’une application est initialisée (c’est ainsi que Didomi génère respectivement les métriques de pages vues et de sessions d’application). Lors du chargement, le SDK Didomi effectuera une vérification pour tous les visiteurs afin de déterminer si l’utilisateur est connu, quel est son statut de consentement et si l’avis de consentement doit être affiché (ou affiché à nouveau). Quel que soit le nombre de fois qu’un utilisateur final connu charge une page Web ou une application, son identifiant unique (`uuid`) restera toujours le même et sera compté comme un seul utilisateur unique dans les MUV.

Voir ci-dessous le processus général du SDK Didomi :

{% stepper %}
{% step %}
Le SDK Didomi est appelé à chaque chargement de page Web/application
{% endstep %}

{% step %}
Collecte les événements de page vue/session d’application
{% endstep %}

{% step %}
Vérifie si l’utilisateur final est connu et s’il a donné ou non son consentement
{% endstep %}

{% step %}
Vérifie si le consentement doit être redemandé en fonction de la mise à jour ou des paramètres de l’avis de consentement
{% endstep %}

{% step %}
Si nécessaire, l’avis est affiché
{% endstep %}

{% step %}
Collecte l’événement de demande de consentement
{% endstep %}

{% step %}
Collecte le consentement de l’utilisateur final
{% endstep %}

{% step %}
Transfère les informations de consentement de l’utilisateur final aux intégrations des fournisseurs ou au système de gestion des balises (TMS)
{% endstep %}
{% endstepper %}

### Calcul des MUV par fonctionnalité

Comme Didomi propose plusieurs outils et méthodes pour collecter et partager les consentements entre les propriétés détenues par votre organisation, la façon dont les MUV sont calculés pour certains comportements d’utilisateur final peut également varier légèrement. Dans cette section, nous couvrirons l’impact éventuel sur le calcul des MUV de certaines fonctionnalités populaires :

* [Inter-domaines](#cross-domain)
* [Multi-appareil](#cross-device)
* [Webview](#webview)
* [`setUserStatus` (consentements « externes »)](#setuserstatus-external-consents)
* [Collecte du consentement sur différentes pages](#collection-of-consent-on-different-pages)
* [Pays/Région configuré(e) pour la réglementation](#country-region-configured-for-regulation)

#### Inter-domaines

La fonctionnalité inter-domaines permet à un utilisateur final de partager le même identifiant utilisateur sur plusieurs domaines et, par conséquent, le choix de consentement de l’utilisateur final peut être conservé et utilisé sur plusieurs sites Web (même navigateur).

Les MUV sont calculés par domaine ; par conséquent, l’utilisateur final ayant le même identifiant sur plusieurs domaines ne sera toujours compté qu’une seule fois par domaine.

#### Multi-appareil

Les MUV multi-appareil sont calculés de la même manière que les MUV standard et s’appuient sur le `user_organization_id` sur plusieurs appareils permettent de lier un utilisateur final à une seule personne.

Les MUV multi-appareil sont répartis en trois groupes :&#x20;

* MUV d’opt-in
* MUV d’opt-out
* MUV sans choix

#### Webview

Les webviews sont utilisées dans le contexte d’une application hybride. Une application hybride est une application avec deux environnements distincts : un **environnement natif** et un **environnement Web**. Les webviews transfèrent le consentement de l’environnement natif vers l’environnement Web. Malgré les deux environnements différents, le choix de consentement n’est demandé qu’une seule fois à l’utilisateur.

Dans ce contexte, l’utilisateur final a un **ID env. app.** et un **ID env. Web** et sera donc compté deux fois.

#### `setUserStatus` (consentements « externes »)

Pour toute collecte personnalisée du consentement de l’utilisateur final qui n’est pas effectuée via l’avis lui-même mais via la `setUserStatus` fonction, Didomi collecte un autre type de consentement, intitulé «**externe**».

Le déclenchement des choix de consentement externes n’a pas d’impact sur le volume de MUV, car la métrique MUV est calculée à partir des événements de pages vues/sessions d’application (déclenchés lorsque le SDK se charge, et non lorsque l’avis est chargé ou affiché).

#### Collecte du consentement sur différentes pages

La personnalisation de la collecte du consentement en modifiant les noms des [cookies Didomi avec le SDK Web](https://developers.didomi.io/cmp/web-sdk/consent-notice/cookies#enabling-collection-of-consent-for-different-pages) aura un impact sur le comptage des visiteurs uniques. Pour le même domaine, un utilisateur final qui visite des pages ou des sous-domaines où différents noms de cookies ont été définis sera compté plusieurs fois.

#### Pays/Région configuré(e) pour la réglementation

Lorsque votre organisation configure son avis de consentement, vous devrez définir les pays/régions auxquels la réglementation s’applique.&#x20;

![Capture d’écran 2025-01-23 à 18.57.20](https://1244787492-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNDxbAdc00ce6bH5u1urh%2Fuploads%2FhM5LbID9sKWXhpsKzBLx%2FCapture%20d%E2%80%99e%CC%81cran%202025-01-23%20a%CC%80%2018.57.20.webp?alt=media\&token=3c46321c-9c7e-4b35-81a5-1d30bd79f88c)

Cependant, comme le SDK Didomi est initialisé globalement pour chaque page vue et session d’application, y compris dans les régions où votre réglementation s’applique, cela signifie que tous les visiteurs sont inclus dans vos MUV.

Pour éviter d’être facturé pour les utilisateurs finaux situés en dehors des régions où une réglementation s’applique, vous devez conditionner l’appel à notre balise d’initialisation afin que le SDK Didomi ne soit pas initialisé si aucune réglementation ne s’applique.

### Écarts des MUV

Il peut arriver que les MUV générés par Didomi ne correspondent pas aux MUV générés par votre organisation. Cela peut être dû à :

<table><thead><tr><th width="239.25">Raison</th><th>Description</th></tr></thead><tbody><tr><td>Différence de périmètre</td><td>Le périmètre des domaines/applications couverts par votre outil d’analyse et par le CMP peut être différent.</td></tr><tr><td>Calcul des MUV</td><td>Votre outil d’analyse calcule les utilisateurs connectés ou le partage du consentement entre domaines différemment de Didomi</td></tr><tr><td>Visiteurs ayant opté pour le consentement vs tous les visiteurs</td><td>Dans la plupart des cas, votre outil d’analyse est déclenché lorsqu’un utilisateur final donne son consentement, au lieu de lorsque la page Web ou l’application est chargée</td></tr><tr><td>Échantillonnage</td><td>Le calcul des MUV est une estimation. Le nombre exact de MUV peut <strong>varier de +/- 10 %</strong>. </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.didomi.io/fr/analyses/analyses-de-la-plateforme-de-gestion-du-consentement-cmp/introduction/visiteurs-uniques-mensuels-muv.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.
