> ## 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.

# Dépannage

> Corrigez les problèmes courants du suivi des conversions : aucun événement, erreurs CORS, 403 de domaine, attribution manquante et événements en double.

## Problèmes du SDK navigateur

### Aucune requête réseau vers `/ct` n'apparaît

Vérifiez ces points dans cet ordre :

1. **Le script est au mauvais endroit** — il doit se trouver dans `<head>`, pas dans `<body>` ni après `</html>`
2. **Le `site_id` manque** — vérifiez que `scanova('init', 'YOUR_SITE_ID', ...)` contient un véritable identifiant de site et non un texte d'exemple
3. **La Content Security Policy (CSP) bloque le script** — ajoutez `https://cdn.scanova.io` (script source) et `https://t.scanova.io` (connect source) à vos en-têtes CSP
4. **Une extension du navigateur bloque la requête** — testez dans une fenêtre de navigation privée, toutes extensions désactivées
5. **`autoPageview: false` et aucun appel manuel** — activez `autoPageview` ou ajoutez `scanova('track', 'pageview')`
6. **Le SDK est chargé deux fois** — une installation directe dans le HTML doublée d'une installation GTM sur la même page pose problème. Supprimez-en une.

### `403 Domain not allowed`

L'origine de votre requête ne figure pas dans la liste **Allowed Domains** du site de suivi.

1. Allez dans **Analyses → Suivi des conversions**
2. Cliquez sur votre site de suivi → **Edit**
3. Ajoutez exactement le nom d'hôte affiché dans la barre d'adresse de votre navigateur (par exemple `yoursite.com` ou `www.yoursite.com`)
4. Enregistrez

<Note>
  `www.yoursite.com` et `yoursite.com` sont considérés comme deux domaines distincts. Ajoutez les deux si vous utilisez les deux.
</Note>

<Warning>
  La liste d'autorisation est comparée à l'en-tête `Origin` de la requête (à défaut, à `Referer`). Reproduire un événement navigateur avec `curl` ou depuis un serveur renvoie donc `403 Domain not allowed for this site` même si le domaine est autorisé, car aucun de ces deux en-têtes n'est envoyé. Ajoutez `-H "Origin: https://yoursite.com"` lorsque vous reproduisez un événement navigateur à la main.
</Warning>

### `400` — Requête incorrecte

Le `site_id` est invalide ou vide, ou le site a été désactivé dans le tableau de bord. Vérifiez que :

* Vous utilisez le bon `site_id` pour ce site de suivi
* Le site est actif (affiché comme activé dans le tableau de bord)

### Les événements apparaissent dans les DevTools mais pas dans le tableau de bord

* Patientez jusqu'à 60 secondes — le traitement prend un court instant
* Assurez-vous de consulter le bon site de suivi dans le tableau de bord
* Vérifiez que le `site_id` du contenu de la requête correspond au site que vous consultez

### Deux événements par chargement de page

Vous avez à la fois `autoPageview: true` dans vos options d'init et un appel manuel à `scanova('track', 'page_view', ...)` quelque part dans votre code. Cela produit deux événements distincts. Supprimez-en un — voir [Événements suivis automatiquement](/fr/conversion-tracking/browser/auto-tracking#page-view).

### Aucun événement pour une visite donnée

Si aucune requête vers `/ct` n'apparaît pour une visite, la cause la plus probable est que la personne est arrivée sans scanner de QR Code : l'URL ne contient pas de paramètre `?scnv=`. Le SDK vérifie la présence d'un `scan_session_id` avant d'envoyer le moindre événement et n'envoie rien, sans message, s'il est absent.

Le suivi des conversions de Scanova ne mesure que le trafic issu d'un scan de QR Code. Les visites directes ou organiques ne produisent aucun événement — c'est voulu.

Pour tester l'attribution, ouvrez votre page avec un paramètre `?scnv=` afin de simuler un scan :

```
https://yoursite.com/?scnv=00000000-0000-0000-0000-000000000001
```

***

## Problèmes des événements serveur

### `401` — Clé d'API manquante

L'en-tête `X-API-Key` n'est pas présent dans la requête. Voir [Authentification](/fr/conversion-tracking/api/authentication).

### `403` — Clé invalide ou mauvais site

Soit la clé est invalide ou révoquée, soit le `site_id` de votre requête ne correspond pas au site qui a généré la clé. Vérifiez que :

* Vous recopiez la clé depuis le tableau de bord (les clés ne sont affichées qu'une fois ; si vous l'avez perdue, générez-en une nouvelle)
* Le `site_id` de votre requête est bien celui affiché dans la liste des sites de suivi des conversions
* La clé n'a pas été révoquée

### `422` — Erreur de validation

Le corps de la réponse indique précisément quel champ pose problème. Causes fréquentes :

| Cause                               | Correction                                    |
| ----------------------------------- | --------------------------------------------- |
| `scan_session_id` n'est pas un UUID | Ce doit être une chaîne UUID valide           |
| `event_name` manque                 | Champ obligatoire pour les événements serveur |
| `properties` dépasse 10 Ko          | Réduisez la taille du contenu                 |
| E-mail en clair dans `properties`   | Hachez-le : `user_identifiers.email_hash`     |

### Les événements arrivent mais ne sont rattachés à aucun QR Code

Le `scan_session_id` envoyé n'a pas pu être relié à un scan dans la base Scanova. Cela arrive lorsque :

* Le `scan_session_id` était inventé ou invalide
* La personne n'a pas scanné de QR Code — elle est arrivée directement
* La session de scan a expiré

Vérifiez que vous lisez bien le `scan_session_id` dans le navigateur (via `localStorage._scnv`, une clé de stockage interne au SDK) et que vous le transmettez correctement à votre serveur. Voir [Envoyer des événements serveur](/fr/conversion-tracking/server/send-events#passing-scan_session_id-from-browser-to-server) for examples.

***

## Problèmes d'attribution

### Les événements affichent `null` pour `qr_code_id`

Il s'agit d'un **enregistrement orphelin** : l'événement est arrivé avant que les données de la session de scan ne soient entièrement propagées dans la base Scanova. Ces enregistrements sont supprimés automatiquement au bout de 24 heures si les données de session n'arrivent jamais, ou complétés dès qu'elles arrivent.

Si vous voyez beaucoup d'enregistrements orphelins, vérifiez que :

* Le `scan_session_id` de vos événements correspond à une vraie session de scan (et non à un UUID de test)
* Vos QR Codes sont correctement reliés au site de suivi dans le tableau de bord

### Les conversions apparaissent sur le mauvais QR Code

Votre `scan_session_id` n'est pas lu correctement — vous récupérez peut-être une valeur périmée ou erronée dans `localStorage`. Vérifiez que votre frontend lit `localStorage.getItem('_scnv')` (la clé de stockage interne au SDK) et en extrait `.sid` depuis la valeur JSON. Voir [Envoyer des événements serveur](/fr/conversion-tracking/server/send-events#passing-scan_session_id-from-browser-to-server) for the full pattern.

***

## Problèmes de performance

### `429` — Limite de débit dépassée

Vous atteignez la limite de débit :

* Événements navigateur : 100 requêtes par minute et par adresse IP
* Événements serveur : 1 000 requêtes par minute et par clé d'API

Pour les événements serveur, passez au point de terminaison de lot (`POST /server-events/batch`) afin d'envoyer jusqu'à 100 événements par requête et de diviser votre débit de requêtes par 100 au maximum.

Pour les événements navigateur, un `429` en usage normal est rare. Si vous en voyez pendant des tests de charge, espacez vos requêtes.
