> ## 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. # Fehlerbehebung > Häufige Probleme der Konversionsverfolgung von Scanova lösen — keine Ereignisse, CORS-Fehler, 403 bei Domains, fehlende Zuordnung, doppelte Ereignisse. ## Probleme mit dem Browser-SDK ### Es erscheint keine Netzwerkanfrage an `/ct` Prüfen Sie der Reihe nach: 1. **Das Snippet steht an der falschen Stelle** — es gehört in ``, nicht in `` und nicht hinter `` 2. **Die `site_id` fehlt** — prüfen Sie, dass in `scanova('init', 'YOUR_SITE_ID', ...)` eine echte Website-ID steht und kein Platzhalter 3. **Die Content Security Policy (CSP) blockiert das Skript** — nehmen Sie `https://cdn.scanova.io` (script source) und `https://t.scanova.io` (connect source) in Ihre CSP-Header auf 4. **Eine Browser-Erweiterung blockiert die Anfrage** — testen Sie in einem privaten Fenster mit deaktivierten Erweiterungen 5. **`autoPageview: false` und kein manueller Aufruf** — aktivieren Sie entweder `autoPageview` oder ergänzen Sie `scanova('track', 'pageview')` 6. **Das SDK ist doppelt eingebunden** — eine Einbindung direkt im HTML und zusätzlich über GTM auf derselben Seite führt zu Problemen. Entfernen Sie eine davon. ### `403 Domain not allowed` Der Ursprung Ihrer Anfrage steht nicht in der Liste **Allowed Domains** der Tracking-Website. 1. Gehen Sie zu **Analysen → Konversionsverfolgung** 2. Klicken Sie auf Ihre Tracking-Website → **Edit** 3. Tragen Sie genau den Hostnamen ein, der in der Adressleiste Ihres Browsers steht (z. B. `yoursite.com`, `www.yoursite.com`) 4. Speichern Sie `www.yoursite.com` und `yoursite.com` gelten als verschiedene Domains. Tragen Sie beide ein, wenn Sie beide nutzen. Die Freigabeliste wird gegen den `Origin` der Anfrage geprüft, ersatzweise gegen `Referer`. Ein Nachstellen eines Browser-Ereignisses per `curl` oder vom Server liefert deshalb `403 Domain not allowed for this site`, auch wenn die Domain freigegeben ist — denn keiner der beiden Header wird mitgeschickt. Ergänzen Sie beim Nachstellen von Hand `-H "Origin: https://yoursite.com"`. ### `400` — Bad Request Die `site_id` ist ungültig oder leer, oder die Website wurde im Dashboard deaktiviert. Prüfen Sie: * dass Sie die richtige `site_id` für diese Tracking-Website verwenden * dass die Website aktiv ist (im Dashboard als aktiviert angezeigt) ### Ereignisse erscheinen in den DevTools, aber nicht im Dashboard * Warten Sie bis zu 60 Sekunden — die Verarbeitung dauert einen Moment * Vergewissern Sie sich, dass Sie im Dashboard die richtige Tracking-Website ansehen * Prüfen Sie, ob die `site_id` in den Nutzdaten der Netzwerkanfrage zu der angezeigten Website passt ### Pro Seitenaufruf werden zwei Ereignisse ausgelöst In Ihren init-Optionen steht `autoPageview: true` und irgendwo im Code gibt es zusätzlich einen Aufruf `scanova('track', 'page_view', ...)`. Das ergibt zwei getrennte Ereignisse. Entfernen Sie eines davon — siehe [Automatisch erfasste Ereignisse](/de/conversion-tracking/browser/auto-tracking#page-view). ### Für einen bestimmten Besuch kommen gar keine Ereignisse an Erscheint für einen Besuch keine Anfrage an `/ct`, kam die Person höchstwahrscheinlich ohne QR-Code-Scan auf die Seite — in der URL fehlt der Parameter `?scnv=`. Das SDK prüft vor jedem Ereignis, ob eine `scan_session_id` vorliegt, und sendet ohne sie stillschweigend nichts. Die Konversionsverfolgung von Scanova misst ausschließlich Zugriffe, die aus einem QR-Code-Scan stammen. Direkte oder organische Besuche erzeugen keine Ereignisse — das ist so gewollt. Zum Testen der Zuordnung rufen Sie Ihre Seite mit einem Parameter `?scnv=` auf und simulieren so einen Scan: ``` https://yoursite.com/?scnv=00000000-0000-0000-0000-000000000001 ``` *** ## Probleme mit serverseitigen Ereignissen ### `401` — Fehlender API-Schlüssel Der Header `X-API-Key` fehlt in der Anfrage. Siehe [Authentifizierung](/de/conversion-tracking/api/authentication). ### `403` — Ungültiger Schlüssel oder falsche Website Entweder ist der Schlüssel ungültig oder widerrufen, oder die `site_id` in Ihren Nutzdaten gehört nicht zu der Website, die den Schlüssel erzeugt hat. Prüfen Sie: * Kopieren Sie den Schlüssel erneut aus dem Dashboard (Schlüssel werden nur einmal angezeigt — ist er weg, erzeugen Sie einen neuen) * Prüfen Sie, ob die `site_id` in Ihren Nutzdaten der Website-ID aus der Liste der Tracking-Websites entspricht * Vergewissern Sie sich, dass der Schlüssel nicht widerrufen wurde ### `422` — Validierungsfehler Der Antworttext nennt genau das Feld, an dem es scheitert. Häufige Ursachen: | Ursache | Behebung | | ------------------------------------------ | ------------------------------------------- | | `scan_session_id` ist keine UUID | Es muss eine gültige UUID-Zeichenkette sein | | `event_name` fehlt | Pflichtfeld bei Server-Ereignissen | | `properties` ist größer als 10 KB | Nutzdaten verkleinern | | E-Mail-Adresse im Klartext in `properties` | Hashen: `user_identifiers.email_hash` | ### Ereignisse kommen an, werden aber keinem QR-Code zugeordnet Die gesendete `scan_session_id` ließ sich in der Scanova-Datenbank keinem QR-Code-Scan zuordnen. Das passiert, wenn: * die `scan_session_id` erfunden oder ungültig war * die Person gar keinen QR-Code gescannt hat, sondern direkt kam * die Scan-Sitzung abgelaufen ist Prüfen Sie, dass Sie die `scan_session_id` im Browser auslesen (über `localStorage._scnv`, einen internen Speicherschlüssel des SDK) und korrekt an Ihren Server übergeben. Siehe [Server-Ereignisse senden](/de/conversion-tracking/server/send-events#passing-scan_session_id-from-browser-to-server) for examples. *** ## Probleme mit der Zuordnung ### Ereignisse zeigen `null` bei `qr_code_id` Das ist ein **verwaister Datensatz** — das Ereignis traf ein, bevor die Daten der Scan-Sitzung vollständig in der Scanova-Datenbank vorlagen. Solche Datensätze werden nach 24 Stunden automatisch entfernt, falls die Sitzungsdaten nie eintreffen, oder nachträglich ergänzt, sobald sie da sind. Sehen Sie viele verwaiste Datensätze, prüfen Sie: * dass die `scan_session_id` in Ihren Ereignissen zu einer echten Scan-Sitzung gehört (und keine Test-UUID ist) * dass Ihre QR-Codes im Dashboard korrekt mit der Tracking-Website verknüpft sind ### Konversionen erscheinen beim falschen QR-Code Ihre `scan_session_id` wird nicht richtig ausgelesen — womöglich holen Sie einen veralteten oder falschen Wert aus dem `localStorage`. Prüfen Sie, dass Ihr Frontend `localStorage.getItem('_scnv')` liest (den internen Speicherschlüssel des SDK) und `.sid` aus dem JSON-Wert nimmt. Siehe [Server-Ereignisse senden](/de/conversion-tracking/server/send-events#passing-scan_session_id-from-browser-to-server) for the full pattern. *** ## Probleme mit der Leistung ### `429` — Ratengrenze überschritten Sie stoßen an die Ratengrenze: * Browser-Ereignisse: 100 Anfragen pro Minute und IP-Adresse * Server-Ereignisse: 1.000 Anfragen pro Minute und API-Schlüssel Wechseln Sie bei Server-Ereignissen zum Batch-Endpunkt (`POST /server-events/batch`) und senden Sie bis zu 100 Ereignisse je Anfrage — das senkt die Zahl der Anfragen um bis zu das Hundertfache. Bei Browser-Ereignissen kommt `429` im normalen Betrieb selten vor. Tritt es bei Lasttests auf, verteilen Sie Ihre Anfragen zeitlich.