Probleme mit dem Browser-SDK
Es erscheint keine Netzwerkanfrage an /ct
Prüfen Sie der Reihe nach:
- Das Snippet steht an der falschen Stelle — es gehört in
<head>, nicht in <body> und nicht hinter </html>
- Die
site_id fehlt — prüfen Sie, dass in scanova('init', 'YOUR_SITE_ID', ...) eine echte Website-ID steht und kein Platzhalter
- 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
- Eine Browser-Erweiterung blockiert die Anfrage — testen Sie in einem privaten Fenster mit deaktivierten Erweiterungen
autoPageview: false und kein manueller Aufruf — aktivieren Sie entweder autoPageview oder ergänzen Sie scanova('track', 'pageview')- 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.
- Gehen Sie zu Analysen → Konversionsverfolgung
- Klicken Sie auf Ihre Tracking-Website → Edit
- Tragen Sie genau den Hostnamen ein, der in der Adressleiste Ihres Browsers steht (z. B.
yoursite.com, www.yoursite.com)
- 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)
- 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.
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:
Probleme mit serverseitigen Ereignissen
401 — Fehlender API-Schlüssel
Der Header X-API-Key fehlt in der Anfrage. Siehe Authentifizierung.
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:
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 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 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.
