> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scanova.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Le fonctionnement du suivi des conversions

> Le parcours complet des données, du scan du QR Code au rapport : modèle d'attribution, durée de vie de la session et traitement des événements expliqués.

## Du scan au rapport

Voici ce qui se passe entre le moment où une personne scanne votre QR Code et celui où l'événement apparaît dans vos rapports.

```mermaid theme={null}
sequenceDiagram
  participant User as Visiteur
  participant QR as QR Code
  participant Scanova as Redirection Scanova
  participant Site as Votre site
  participant SDK as SDK navigateur
  participant API as API de suivi
  participant Reports as Analyses / Rapports

  User->>QR: Scanne le QR Code
  QR->>Scanova: Ouvre l'URL courte scnv.io
  Scanova->>Site: Redirige vers votre URL avec ?scnv=<session_id>
  Site->>SDK: Le SDK se charge et lit le paramètre ?scnv
  SDK->>SDK: Enregistre scan_session_id dans localStorage
  SDK->>API: Envoie l'événement page_view avec scan_session_id
  User->>Site: Clique, remplit un formulaire, fait défiler
  SDK->>API: Envoie les événements click / form_submit / scroll
  Site->>API: Votre serveur envoie l'événement purchase (côté serveur)
  API->>Reports: Les événements sont traités et rattachés au QR Code
```

## La session de scan

Le paramètre `scnv` de l'URL est la clé de l'attribution. Il contient un **identifiant de session de scan** : un UUID qui désigne un scan précis, d'un QR Code précis, par une personne précise, à un instant précis.

```
https://yoursite.com/landing?scnv=7ad26d4f-3181-4ef8-b6ca-b8f59499dd43
                                    └─────────────────────────────────────┘
                                           scan_session_id
```

Au chargement d'une page portant ce paramètre, le SDK navigateur fait ceci :

1. Il lit la valeur de `scnv` dans l'URL
2. Il l'enregistre dans `localStorage` avec une validité de 60 jours
3. Il la joint sous le nom `scan_session_id` à chaque événement envoyé depuis ce navigateur

Autrement dit, si la personne quitte le site puis revient dans les 60 jours, ses actions suivantes restent rattachées au scan d'origine.

## Attribution entre les pages et les sessions

L'identifiant de session de scan est conservé d'une page à l'autre sur un même domaine. Si une personne :

1. scanne un QR Code → arrive sur `/landing`
2. poursuit vers `/pricing`
3. s'inscrit sur `/signup`

les trois pages vues sont rattachées au même scan, à condition que le SDK soit installé sur toutes les pages.

## Événements du navigateur et événements serveur

Il existe deux types d'événements :

| Type                         | Envoyé depuis                         | Authentification  | Idéal pour                                             |
| ---------------------------- | ------------------------------------- | ----------------- | ------------------------------------------------------ |
| **Événements du navigateur** | Le navigateur du visiteur, via le SDK | Aucune (publique) | Pages vues, clics, défilement, envois de formulaires   |
| **Événements serveur**       | Votre backend, via l'API              | Clé d'API requise | Achats, inscriptions, leads, toute action côté serveur |

Les deux types acceptent un `scan_session_id`, qui les relie au scan du QR Code. Pour les événements serveur, votre backend doit recevoir le `scan_session_id` depuis le navigateur — le plus souvent via un champ de formulaire, un cookie de session ou un appel d'API.

## Le traitement des événements

Dès que l'API de suivi reçoit un événement, celui-ci passe par une chaîne de traitement :

1. **Validation** — contrôle des champs obligatoires, de la taille du contenu et de l'autorisation du site et du domaine
2. **Déduplication** — les valeurs répétées de `event_id` sont marquées comme doublons (elles restent stockées, elles ne sont pas supprimées)
3. **Données d'appareil** — analyse du user-agent pour en extraire le type d'appareil, le navigateur et le système
4. **Données de localisation** — résolution du pays et de la ville à partir de l'adresse IP via GeoIP
5. **Rapprochement d'identité** — résolution du `scan_session_id` vers l'identifiant du QR Code et celui de l'utilisateur dans la base Scanova
6. **Détection de fraude** — notation heuristique pour signaler les comportements de robots
7. **Confidentialité / RGPD** — suppression des champs personnels si `consent` vaut `denied` ou `pending`

Les événements traités apparaissent dans les rapports de votre tableau de bord après un court délai d'ingestion (moins de 10 secondes en général).

## Identité et sessions

Chaque événement envoyé par le SDK porte trois valeurs d'identité distinctes. En comprendre la différence aide à lire les rapports :

| Identité          | Clé de cookie ou de stockage | Durée de vie            | Ce qu'elle représente                                                                                                            |
| ----------------- | ---------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `scan_session_id` | `localStorage._scnv`         | 60 jours                | Le scan de QR Code précis qui a lancé ce parcours. La clé d'attribution principale.                                              |
| `web_session_id`  | Cookie `_scnv_ws`            | 30 minutes d'inactivité | Une session de navigation continue. Elle repart après 30 minutes sans activité, comme toute session classique.                   |
| `visitor_id`      | Cookie `_scnv_vid`           | 1 an                    | Un identifiant anonyme durable pour un navigateur. Il permet de reconnaître un visiteur revenu après plusieurs sessions de scan. |

Un même visiteur peut avoir de nombreuses sessions web, et une session web de nombreux événements. Tous les événements survenus dans les 60 jours suivant un scan partagent le même `scan_session_id`.

## Disponibilité des données

* Les événements sont ingérés et mis en file dès leur réception
* En charge normale, les événements traités apparaissent dans les rapports en quelques secondes
* De courts délais, jusqu'à quelques minutes, peuvent survenir lors des pics de trafic
