Der erwartete Zustand und wie man Abweichungen liest

Bei jedem Scan wird die aufgezeichnete Journey abgespielt, und der Scanner hält fest, was jeder Schritt an den dataLayer und an Analytics-Tools gesendet hat. Für sich genommen sagt das wenig. Nützlich wird es erst, wenn es etwas zum Vergleichen gibt. Dieser Maßstab ist der erwartete Zustand: eine Aufzeichnung, welche Ereignisse und Parameter jeder Schritt senden soll.

Diese Anleitung erklärt, wie der erwartete Zustand entsteht, was mit ihm verglichen wird und was nicht, und was die Schaltflächen neben einer Änderung bewirken.

Wie der erwartete Zustand entsteht

Den erwarteten Zustand schreiben Sie nicht von Hand. Er wird aus dem ersten Scan übernommen, dem man trauen kann. Bis ein solcher Scan vorliegt, läuft die Aufwärmphase, und im Testdetail steht dieser Hinweis:

Ein Scan taugt dafür, wenn er:

• mit dem Status „Abgeschlossen“ endete,
• alle aufgezeichneten Schritte abdeckte und keiner davon fehlschlug oder übersprungen wurde,
• jeden Schritt auf der aufgezeichneten Seite beendete und nicht anderswo,
• jedes Ziel über Ihre Aufnahme fand, also über den aufgezeichneten Selektor oder einen Ersatz-Selektor, und nicht über Text, Koordinaten oder ein Ersatzelement, das die Wiedergabe selbst abgeleitet hat,
• für keinen seiner Schritte einen wartenden Korrekturvorschlag hatte,
• in mindestens der Hälfte der Schritte zumindest einige Analytics-Ereignisse gemessen hat.

Aus dem ersten solchen Scan wird der erwartete Zustand genau so übernommen, wie er gemessen wurde. Dieser Scan meldet selbst keine Änderungen, denn er wird zum Maßstab. Verglichen wird ab dem nächsten Scan.

Erfüllen mehrere Scans hintereinander diese Bedingungen nicht, wechselt der Hinweis zu „Das Monitoring dieser Journey läuft nicht“ und nennt, was zu tun ist. Meist heißt das: die Journey neu aufzeichnen oder herausfinden, warum die Wiedergabe nicht bis zum Ende kommt.

Was verglichen wird

Für jeden Schritt vergleicht der Scanner drei Dinge: ob dieselben Ereignisse kamen, ob sie dieselben Parameter tragen und ob jeder Parameter denselben JavaScript-Typ hat (String, Zahl, Boolean, Array, Objekt). Verschachtelte Objekte werden Feld für Feld verglichen, zum Beispiel ecommerce.items[].price.

Werte werden nicht verglichen. Eine Journey legt bei jedem Durchlauf gern ein anderes Produkt in den Warenkorb, also ändern sich item_id und price, und das ist in Ordnung. Eine Änderung von 1290 auf 990 wird deshalb nicht gemeldet. Kommt value aber als String "990" statt als Zahl, ist das eine Typänderung.

Zwei Details. Ein leerer Wert (null, undefined, ein leerer String) gilt nicht als Typ, ein Wechsel hin zu ihm oder weg von ihm wird also nicht gemeldet. Und bei Anfragen an die Server von Tools lässt der Scanner Parameter weg, die sich bei jedem Seitenaufruf ändern, etwa Zeitstempel oder zufällige Kennungen. Bei dataLayer-Pushes lässt er nur die eigenen Ereignisse und Schlüssel von Google Tag Manager (gtm.*) weg sowie Pushes ohne Ereignisnamen, etwa Aufrufe für Einwilligung oder Konfiguration.

Die Ausnahme: Einwilligungswerte

Bei der Einwilligung zählt der Wert. Der Scanner liest die Signale von Google Consent Mode (adStorage, analyticsStorage, adUserData, adPersonalization) aus den Parametern gcs und gcd, die Google-Tags senden, und vergleicht sie mit dem erwarteten Zustand. Zeigt ein Schritt, der granted hatte, jetzt denied (oder umgekehrt), meldet der Scan das als „Einwilligung geändert“.

Die erwarteten Einwilligungswerte werden für jedes Land, aus dem ein Scan läuft, getrennt geführt. Scannen Sie aus einem neuen Land, hält der erste brauchbare Scan von dort dessen Einwilligungswerte erst fest. Kann der Scanner einen Wert nicht lesen, meldet er „Einwilligung nicht lesbar“. Das ist ein Messfehler, kein Fehler Ihrer Website.

Welche Änderungen ein Scan meldet

Rot markiert sind nur zwei Typen: „Event entfernt“ und „Einwilligung geändert“. In beiden Fällen tut die Website nicht mehr, was der erwartete Zustand behauptet. Die übrigen Änderungen sind Warnungen, die Sie beurteilen. „Parameter hinzugefügt“ ist nur eine Information. „Schritt nicht verifiziert“ und „Einwilligung nicht lesbar“ bedeuten, dass wir nicht messen konnten, und sagen nichts über Ihre Website.

Verschiebung um einen Schritt und Pflicht-Ereignisse

Ein Ereignis gehört zu dem Schritt, in dem es ankam. Ein langsamer Tag meldet sich deshalb manchmal erst im nächsten Schritt. Damit daraus kein Paar aus „entfernt“ und „hinzugefügt“ wird, gilt eine Toleranz von ±1 Schritt. Ein Ereignis, das einen Schritt daneben ankam, wird als „Event verschoben“ gemeldet.

Für die Pflicht-Ereignisse purchase, begin_checkout, add_payment_info, consent_update, consent_default gilt die Toleranz nicht. Sendet das eigene Tracking der Website (dataLayer, Google Analytics 4, Google Tag Manager) eines davon nicht in seinem Schritt, meldet der Scan es als „Event entfernt“, nicht als verschoben. Gleichnamige Ereignisse, die andere Tools von sich aus senden, fallen nicht unter diese Regel.

Wird ein Schritt bei der Wiedergabe nicht abgeschlossen, werden die darin fehlenden Ereignisse nicht der Website angelastet. Der Scan zeigt stattdessen eine Zeile „Schritt nicht verifiziert“.

Welche Anbieter überwacht werden

Änderungen werden nur für überwachte Anbieter gemeldet. Standardmäßig sind das dataLayer, Google Analytics 4 und Adobe Analytics. Weitere schalten Sie unter „Überwachte Anbieter“ ein; ein neu erkannter Anbieter erscheint dort unter „Neu erkannt — entscheiden“. Der dataLayer wird immer überwacht.

Was die Schaltflächen neben einer Änderung tun

• „Als korrekt markieren“ schreibt die Änderung in den erwarteten Zustand. Ein fehlendes oder zusätzliches Ereignis oder ein solcher Parameter wird als optional eingetragen: Weder sein Vorhandensein noch sein Fehlen wird erneut gemeldet, sein Typ wird aber weiter geprüft, sobald er auftaucht. Eine Typänderung schreibt den neuen Typ, eine Einwilligungsänderung den neuen Wert, und ein verschobenes Ereignis wandert in den Schritt, in dem es auftrat. „Alle genehmigen“ macht dasselbe für alle ausstehenden Änderungen: im Änderungsbereich eines Schritts für diesen Schritt, in der Leiste des Scans für den ganzen Scan.
• „Ignorieren“ meldet die Änderung nicht mehr. Wird ein ganzes Ereignis ignoriert, gilt das auch für seine künftigen Parameter.
• „Als Fehler markieren“ führt die Änderung als „Bekannte Regression“, bis ein späterer Scan sie nicht mehr findet.

Warum ein Mensch den ersten erwarteten Zustand prüfen muss

Der erwartete Zustand wird aus dem ersten brauchbaren Scan genau so übernommen, wie dieser Scan ihn gemessen hat. Der Scanner weiß nicht, wie Ihr Tracking aussehen soll. Er weiß nur, wie es damals aussah. Hat die Website zu diesem Zeitpunkt value schon als String gesendet, fehlte in der Bestellbestätigung purchase oder stand ein Einwilligungssignal früher auf granted als erlaubt, dann wird genau das zum erwarteten Zustand. Spätere Scans melden dann nur Abweichungen vom Fehler, nicht den Fehler selbst.

Öffnen Sie deshalb nach der Aufwärmphase den Scan, aus dem der erwartete Zustand aufgebaut wurde, und gehen Sie ihn Schritt für Schritt durch:

• Enthalten die Schritte die Ereignisse, die dorthin gehören, zum Beispiel purchase im Schritt mit der Bestellbestätigung?
• Haben die wichtigen Parameter den richtigen Typ, zum Beispiel value als Zahl?
• Passen die Einwilligungssignale zu dem, was der Besucher an dieser Stelle im Banner gewählt hat?

Stimmt etwas nicht, korrigieren Sie die Website. Der nächste Scan zeigt die Korrektur als Änderung, und Sie übernehmen sie mit „Als korrekt markieren“. Beachten Sie dabei eines: Ein hinzugekommenes Ereignis oder ein neuer Parameter wird mit der Genehmigung als optional eingetragen, ein späterer Ausfall wird dann nicht gemeldet. Am meisten haben Sie vom Monitoring, wenn das Tracking schon vor dem ersten Scan stimmt.