Support kontaktieren

Wir melden uns per E-Mail. Meist innerhalb von zwei Tagen.

Zum Schutz vor Missbrauch prüft Google reCAPTCHA diese Einsendung. Dabei werden Daten an Google übertragen. Das Skript wird erst beim Öffnen dieses Formulars geladen.

← Alle Beiträge

Integrationsfehler finden, ohne Statistiken zu verändern

Messungs-Debugger prüft, ob ein vorgeschlagenes Ereignis für einen eigenen Zähler angenommen würde. Es sendet kein normales Ereignis und erhöht keine Besucher-, Ziel-, Ereignis- oder Umsatzsummen. Das hilft bei Konfigurationsfehlern, wobei ein Diagnoseergebnis weiterhin von einer echten Messung zu unterscheiden ist.

123
  1. Konfiguration
  2. Diagnoseergebnis
  3. Normale Anfrage prüfen

Die erste Diagnoseprüfung ausführen

  1. Den Zähler über Meine Zähler verbinden und Dashboard und Werkzeuge öffnen.
  2. Messungs-Debugger öffnen. In Ereignisname einen stabilen Wert eingeben, etwa signup für ein manuelles Ereignis.
  3. Die passende Messart auswählen und angeben, ob der Ereignisname automatisch erzeugt wird. Ein Formularerfolg und ein manuelles Ereignis verwenden unterschiedliche Einstellungen.
  4. Vordefinierte Eigenschaften (JSON-Objekt, optional) bei {} belassen, sofern tatsächlich keine vordefinierten Eigenschaften konfiguriert sind. Niemals Formularinhalte oder personenbezogene Angaben eingeben.
  5. Testen, ohne zu zählen wählen und das Ergebnis sowie den normalisierten Ereignisnamen lesen.

Eine Ablehnung vor Codeänderungen auswerten

Bei einer deaktivierten automatischen Kategorie muss die entsprechende Messeinstellung aktiviert werden. Ein ungültiger oder personenbezogen wirkender Name erfordert einen stabilen Kategorienamen statt einer Besucherkennung. Eine Grenze für neue Namen bedeutet, dass ständig neu erfundene Ereignisnamen das Problem nicht lösen. Das auf der Seite angezeigte Ergebnis prüfen, statt jeden Fehlschlag für einen Netzwerkfehler zu halten.

Eigenschaften müssen zur vordefinierten Konfiguration passen. Die Diagnose meldet ihre Annahme, ohne übermittelte Werte wiederzugeben. Die Zielinformationen unterscheiden ein passendes Ziel von einem gezählten menschlichen Besuch: Ein konfiguriertes Ziel allein garantiert nicht, dass ein Zielbesucher hinzugefügt würde.

Die Diagnoseverbindung von der Website aus prüfen

  1. In Auf deiner Website testen mit Testcode kopieren den erzeugten Diagnosecode kopieren.
  2. Die eigene Website mit dem Zähler öffnen und diesen Code wie auf der Debuggerseite beschrieben in den Entwicklerwerkzeugen des Browsers ausführen.
  3. Das Ergebnis in der Konsole lesen. Die erzeugte Testberechtigung läuft nach fünfzehn Minuten ab; bei Bedarf die Debuggerseite des Eigentümers neu laden, um eine neue zu erhalten.

Die erzeugte vorübergehende Berechtigung verwenden und nicht den privaten Eigentümerschlüssel in einem selbst geschriebenen Skript. Ein Wechsel des Eigentümerschlüssels macht auch die Diagnoseberechtigung ungültig. Der Diagnoseendpunkt begrenzt Anfragen, erzeugt aber keine normalen Trackingdaten.

Die normale Integration getrennt prüfen

Eine angenommene Diagnose bedeutet, dass das vorgeschlagene Ereignis zu diesem Zeitpunkt zulässig wäre. Sie prüft weder die Anfragenbegrenzung des normalen Trackers noch spätere Datenbankschreibvorgänge, Browserblockaden der normalen Anfrage, erfolgreiche Formularverarbeitung oder geordneten Trichterfortschritt.

  1. Prüfen, ob s4u.js auf der vorgesehenen Website-Seite geladen wird und ob normale Trackinganfragen blockiert werden oder fehlschlagen.
  2. Zählernummer, aktivierte Kategorie und Berichtszeitraum prüfen.
  3. Bei einem Formular die tatsächlich erfolgreiche Verarbeitung durch die Anwendung bestätigen, bevor dessen Erfolgsereignis erwartet wird.

Das Diagnoseergebnis und das Ergebnis der normalen Anfrage in jedem Fehlerbericht getrennt halten. Eine fehlende Messung lässt sich nicht zuverlässig mit einer einzigen grünen Diagnoseantwort erklären.

Nächster Schritt

Den eigenen Zähler öffnen und mit einem Diagnoseereignis ohne personenbezogene Daten beginnen.

Meine Zähler öffnen
Anzeige