GA4 Landingpage (not set): Bedeutung, Ursachen und Lösung

Was bedeutet GA4 Landingpage not set?

GA4 Landingpage not set bedeutet, dass Analytics für diese Sitzung keine Angabe zur Landingpage erhalten hat. Laut Google Hilfe entsteht der Wert, wenn eine Sitzung kein page_view Ereignis enthält. Die Sitzung existiert also, aber nichts verknüpft sie mit einem Seitenaufruf.

Allerdings ist die Zeile keine Fehlermeldung. Analytics schreibt (not set) als Platzhalter, sobald zu einer Dimension keine Daten ankommen. Die Ursache liegt daher meist in der Datenerfassung und nicht im Bericht.

In diesem Beitrag erklären wir zunächst, was der Wert bedeutet und warum er auftritt. Danach zeigen wir, wie Sie ihn diagnostizieren, verkleinern und im Bericht richtig lesen.

Was ist der Wert "(not set)" laut Google?

In der Google Analytics Hilfe ist (not set) ein Platzhalter, den Analytics nutzt, wenn für eine Dimension keine Informationen eingegangen sind. Dasselbe Label sehen Sie, wenn Quelldaten fehlen, wenn die Landingpage unbekannt ist oder wenn ein benutzerdefinierter Parameter noch nicht registriert ist.

Die Hilfeseite trennt dabei klar zwei Dinge. (not set) ist nicht dasselbe wie "(data not available)". Das zweite Label weist auf Datenschutz oder Schwellenwerte hin. (not set) können Sie dagegen oft durch Konfiguration und Tagging verringern.

Dieser Unterschied zählt daher in der Praxis. Wenn Sie (not set) sehen, nehmen Sie nicht an, Google verberge Daten. Sie prüfen zuerst Ihre eigene Einrichtung.

Als Quelle nutzen wir die offizielle Analytics Hilfe zum Wert (not set). Menünamen ändern sich mit der Zeit, deshalb beschreiben wir Konzepte statt exakter Schaltflächentexte.

Warum startet eine Sitzung ohne page_view?

Analytics leitet die Landingpage aus dem ersten page_view einer Sitzung ab. Fehlt dieser, bleibt die Dimension leer und zeigt (not set). Die eigentliche Frage lautet also: Warum begann die Sitzung mit etwas anderem als einem Seitenaufruf?

In der Praxis sehen wir vor allem diese Muster:

• Ein anderes Ereignis (Klick, Scrollen, benutzerdefiniertes Ereignis) feuert vor dem Seitenaufruf.
• Die Tag Konfiguration sendet page_view zu spät oder gar nicht.
• Ereignisse vom Server erreichen Analytics ohne Sitzungsinformationen.
• Ereignisse vor der Einwilligung tragen unvollständige Parameter.

Die Reihenfolge dieser Liste ist eine Prüfreihenfolge, keine Rangliste. Zunächst prüfen Sie, was Ihr Tag zuerst sendet. Dann untersuchen Sie die Abfolge der Ereignisse.

Deshalb behandeln wir jedes Muster unten in einem eigenen Abschnitt.

Kann ein Sitzungstimeout die Landingpage leeren?

Manchmal ja. Ein Besucher lässt einen Tab offen und kehrt später zurück, sodass die frühere Sitzung abgelaufen sein kann. Die nächste Interaktion startet eine neue Sitzung. Ist diese Interaktion kein Seitenaufruf, enthält die neue Sitzung kein page_view.

Das geben wir daher als Beobachtung aus der Praxis weiter. Googles Hilfeseite führt diese Ursache nicht gesondert auf. Trotzdem sehen wir Timeout und fehlendes page_view oft gemeinsam.

Zum Beispiel sind lange Artikel, Videoseiten und Seiten mit Formularen typische Kandidaten. Der Besucher bleibt eine Weile und klickt dann einen Button. Dieser Klick wird der erste Eintrag der neuen Sitzung.

Die Dauer des Sitzungstimeouts finden Sie in den Einstellungen des Datenstroms. Suchen Sie im Bereich der Oberfläche nach der passenden Option und vergleichen Sie den Wert mit dem echten Nutzungsverhalten. Notieren Sie den alten Wert vor der Änderung, denn die Einstellung wirkt nur auf künftige Daten.

Was passiert, wenn das Tag spät lädt oder in falscher Reihenfolge feuert?

Läuft Ihr Tag lange nach dem Seitenaufbau, kann die erste Interaktion vor dem Tag stattfinden. Analytics erhält Ereignisse aber erst, nachdem das Tag feuert. Der erste Eintrag kann deshalb ein anderes Ereignis als page_view sein.

Beim Google Tag Manager sind die Trigger entscheidend. Googles Hilfeseite führt ein fehlendes session_start Ereignis auf (not set) bei Quelle und Medium zurück und nennt eine falsche Trigger Konfiguration als typische Ursache. Dieselbe Logik gilt für die Landingpage.

Unsere Checkliste:

1. Läuft das Konfigurationstag auf allen Seiten mit dem frühesten Trigger?
2. Feuern Ereignis Tags vor dem Konfigurationstag?
3. Enthält die Seite ein fest eingebautes Tag und ein Tag aus dem Tag Manager?
4. Hat ein Trigger beim Laden eine Verzögerung?

Grundlagen zur Tag Verwaltung finden Sie in unserer Anleitung zum Google Tag Manager.

Warum tritt es bei Single Page Applications häufiger auf?

Eine Single Page Application (SPA) lädt bei einem Seitenwechsel kein neues Dokument. Umsetzungen mit React oder Vue sind häufige Beispiele. Die Navigation ändert nur die Adresszeile.

Bei dieser Bauweise feuert page_view daher oft nicht von selbst. Entwickler müssen es also bei jedem Routenwechsel auslösen. Tut das niemand, surfen Besucher durch die Seite, aber Analytics sieht nur Klicks und andere Ereignisse.

Folglich entstehen Sitzungen ohne Landingpage. Das fällt leicht nicht auf, weil die Gesamtzahl der Sitzungen weiterhin stimmt.

Zur Diagnose prüfen Sie dann diese Punkte:

• Zeigt DebugView bei jedem Seitenwechsel ein page_view, wenn Sie durch die Seite klicken?
• Ist der Parameter für die Seitenadresse bei diesen Ereignissen gefüllt?
• Sendet schon der erste Seitenaufruf ein page_view?

Die Lösung braucht meist Ihre Entwickler. Halten Sie daher in einem kurzen Messplan fest, welcher Routenwechsel welche Ereignisse und Parameter sendet.

Warum bleibt die Landingpage bei Measurement Protocol Ereignissen leer?

Mit dem Measurement Protocol senden Server oder Apps Ereignisse direkt an Analytics. Teams nutzen es, um CRM Abschlüsse oder Offline Verkäufe zu importieren. Details finden Sie in der Dokumentation von Google zum Measurement Protocol.

Zudem kommen diese Ereignisse außerhalb der Browser Sitzung an. Senden Sie die Sitzungskennung und die zugehörigen Parameter nicht mit, kann Analytics das Ereignis keiner bestehenden Sitzung zuordnen. Weil zudem kein page_view mitkommt, entsteht auch keine Landingpage.

Beispielszenario: Ein Shop sendet nach der Zahlung ein purchase Ereignis vom Server. Der Besucher ist nicht mehr im Browser, daher wirkt das Ereignis wie eine neue Sitzung. Deren Landingpage zeigt (not set).

Lesen Sie Ereignisse vom Server deshalb mit einem eigenen Blick. Wenn Sie sehen wollen, woher Abschlüsse wirklich stammen, lesen Sie unseren Beitrag GA4 Conversions fehlen: Ursachen und Lösungen.

Wie beeinflusst der Consent Mode die Landingpage?

Der Consent Mode ändert das Verhalten von Tags je nach Cookie Entscheidung des Besuchers. Googles Hilfeseite nennt einen falschen default Befehl und das Senden von Ereignissen bei verweigerter Einwilligung als Ursachen für (not set).

In der Praxis sehen wir zwei Probleme. Erstens legen Teams den Standardstatus der Einwilligung erst fest, nachdem die Tags geladen haben. Die ersten Ereignisse gehen dann mit dem falschen Status hinaus. Zweitens erscheint das Einwilligungsbanner spät, und der Besucher interagiert vor der Zustimmung.

Dann kann die erste Übertragung als unvollständiger Eintrag ohne page_view ankommen. Spätere Ereignisse landen in einer anderen Sitzung.

Prüfen Sie dann diese Punkte:

• Läuft der default Befehl vor jedem Google Tag?
• Wird das Update gesendet, sobald der Besucher wählt?
• Verhalten sich Ereignisse bei verweigerter Einwilligung wie erwartet?

Bei rechtlichen Pflichten sprechen Sie mit Ihrer Datenschutzberatung. Dieser Beitrag ist keine Rechtsberatung.

Ist es dasselbe wie Schwellenwerte oder "(data not available)"?

Nein. Diese Labels haben unterschiedliche Ursachen. (not set) heißt, dass Analytics zur Dimension keine Information erhielt. "(data not available)" heißt, dass eine Datenschutz oder Schwellenwert Regel die Daten verbirgt.

In Berichten mit Schwellenwerten können einzelne Zeilen wegen kleiner Nutzerzahlen fehlen. Der Bericht wirkt dann unvollständig, obwohl Ihre Tags funktionieren, also fehlt nur ein Teil der Zeilen. Das aktuelle Verhalten der Schwellenwerte lesen Sie in Googles offizieller Hilfe nach, denn wir nennen hier keine Zahlen.

Mit einem einfachen Test unterscheiden Sie dann beides:

1. Öffnen Sie denselben Bericht in Erkunden.
2. Wählen Sie denselben Zeitraum und prüfen Sie die Ereignisanzahl der Zeile (not set).
3. Erscheint die Zeile weiterhin, liegt die Ursache im Tagging.
4. Verschwindet sie, vermuten Sie einen Schwellenwert oder Datenschutzeffekt.

Somit reparieren Sie keine Tags, die nie defekt waren. Einen breiteren Rahmen zur Plattform liefert unser Beitrag Was ist GA4 und welche Vorteile bietet es.

In welchen Dimensionen erscheint (not set) und warum?

Das Label tritt nicht nur bei der Landingpage auf. Die folgende Tabelle fasst die wichtigsten Fälle zusammen, die Googles Hilfeseite nennt. Menünamen können sich ändern, nutzen Sie sie daher als Konzeptkarte.

Die Tabelle zeigt, dass jede Dimension also ihre eigene Ursache hat. Einen einzigen Schritt namens "alle (not set) beheben" gibt es daher nicht. Sie diagnostizieren jede Dimension getrennt.

Wie diagnostizieren Sie GA4 Landingpage not set mit einem Erkunden Bericht?

Erkunden ist der freie Berichtsbereich. Kombinieren Sie Landingpage mit Ereignisname, sehen Sie, welches Ereignis die (not set) Sitzungen gestartet hat. Standardberichte liefern dieses Detail nicht.

Wir empfehlen daher diese Reihenfolge:

1. Legen Sie eine leere Erkundung an und wählen Sie den Zeitraum.
2. Fügen Sie "Landingpage" und "Ereignisname" als Dimensionen hinzu.
3. Fügen Sie Ereignisanzahl und Sitzungen als Messwerte hinzu.
4. Setzen Sie die Landingpage in die Zeilen und den Ereignisnamen in die Spalten.
5. Filtern Sie so, dass nur die Zeile (not set) übrig bleibt.

Nun sehen Sie, welche Ereignisnamen sich in dieser Zeile häufen. Erscheinen zum Beispiel fast nur click oder scroll, starten Sitzungen ohne page_view.

Allerdings liefert diese Analyse eine Diagnose, keine Heilung. Testen Sie die gefundenen Ereignisnamen danach live in DebugView.

Was verrät die Aufschlüsselung nach Ereignisnamen?

Das dominante Ereignis in der Zeile (not set) deutet oft auf die Ursache hin. Die Tabelle unten ist eine Hypothesenliste, keine feste Regel.

Entscheiden Sie nie anhand einer einzelnen Zeile, ohne DebugView zu prüfen. Bedenken Sie außerdem, dass auf einer Website mehrere Ursachen gleichzeitig wirken können. Beheben Sie daher zuerst das Ereignis mit dem größten Volumen.

Wie prüfen Sie das erste Ereignis mit DebugView?

DebugView zeigt Ereignisse Ihres Geräts in einem Strom nahezu in Echtzeit. Für die Tag Reihenfolge ist es das beste Werkzeug, weil Sie sehen die Abfolge Sekunde für Sekunde.

Gehen Sie dann so vor:

1. Schalten Sie den Debugmodus ein (Vorschau im Tag Manager oder eine Debug Erweiterung).
2. Öffnen Sie Ihre Website mit einer sauberen Sitzung, wie ein neuer Besucher.
3. Lesen Sie die ersten Ereignisse von oben nach unten.
4. Notieren Sie jedes Ereignis, das vor page_view eintrifft.
5. Vergleichen Sie das Verhalten vor und nach dem Klick auf das Einwilligungsbanner.

Konkret ist das Ziel einfach: Der erste Eintrag einer Sitzung sollte page_view sein. Ist er es nicht, brauchen Tag Reihenfolge oder Einwilligungsablauf Arbeit.

Testen Sie außerdem verschiedene Einstiegswege: direkter Aufruf, Anzeigenklick und E-Mail Link. Jeder Weg kann einen anderen Trigger auslösen. Einen markierten Testlink erstellen Sie mit unserem UTM Generator.

Wie verkleinern Sie GA4 Landingpage not set?

Auf den meisten Websites bekommen Sie die Zeile nicht auf null, denn manche Sitzungen haben tatsächlich kein page_view. Ihr Ziel ist ein kleiner, verstandener Anteil. Setzen Sie die folgenden Schritte passend zu Ihrer Diagnose um.

• Lassen Sie das Konfigurationstag auf jeder Seite als Erstes feuern.
• Legen Sie Ereignis Tags hinter das Konfigurationstag.
• Senden Sie in einer SPA bei jedem Routenwechsel page_view.
• Definieren Sie den Standard der Einwilligung vor allen Tags.
• Geben Sie bei Aufrufen des Measurement Protocol Sitzungsdaten mit.
• Vergleichen Sie das Sitzungstimeout mit den echten Besuchsdauern.

Speichern Sie außerdem jede Änderung als eigene Version. So sehen Sie, welcher Schritt geholfen hat.

Alte Daten heilen nach einer Korrektur nicht, denn Analytics verarbeitet die Vergangenheit nicht neu. Beobachten Sie daher einige Tage lang die neuen Daten. Wenn Sie Ihr Tracking von einer zweiten Person prüfen lassen möchten, lesen Sie über unsere SEO Beratung.

Unterscheidet sich (not set) bei Google Ads und UTM Parametern?

Ja, die Quelle ist eine andere. Bei Anzeigendimensionen entsteht (not set) meist durch nicht verknüpfte Ads und Analytics Konten oder durch deaktivierte automatische Markierung. Manuell markierte URLs mit fehlenden oder falschen UTM Parametern liefern dasselbe Ergebnis.

Dieses Thema ist allerdings von der Landingpage getrennt. Beide Labels stehen jedoch oft nebeneinander im selben Bericht, deshalb werden sie verwechselt. Die Spalten Quelle und Medium helfen bei der Unterscheidung.

Ein schneller Check, zum Beispiel:

• Ist die automatische Markierung für Ihre Anzeigenlinks aktiv?
• Sind bei manueller Markierung Quelle, Medium und Kampagne ausgefüllt?
• Ist die Schreibweise der Parameter in allen URLs einheitlich?

Die richtige UTM Struktur erklärt unser Beitrag UTM Parameter für Kampagnen Tracking. Kanalgruppen behandeln wir hier nicht, denn dieser Leitfaden bleibt bei der Dimension Landingpage.

In welchen Berichten taucht GA4 Landingpage not set auf?

Sie sehen die Zeile in jedem Bericht mit der Dimension Landingpage. Fügen Sie sie in Akquise, Interaktion oder Conversion Berichten als Spalte hinzu, erscheint (not set) als zusätzliche Zeile. In Erkunden Berichten verhält es sich genauso.

Beachten Sie allerdings einen Punkt. Die Zeile bedeutet nicht, dass Ihre Website eine Seite namens "(not set)" hat. Analytics konnte für diese Sitzungen schlicht keine Seite finden. Das Aufrufen dieser Adresse bringt also nichts.

Die relative Größe schwankt je nach Bericht. Ein kleiner Anteil im Seitenbericht kann zum Beispiel im Conversion Bericht wie ein großer Verlust aussehen. Der Grund: Abschlüsse aus Ereignissen vom Server haben häufiger kein page_view.

Beurteilen Sie die Zeile daher nicht in nur einem Bericht. Vergleichen Sie den Anteil in zwei oder drei Berichten und suchen Sie die Quelle jeder Abweichung. So erkennen Sie, ob das Problem an einem Ereignistyp oder an der ganzen Website liegt.

Bedeutet GA4 Landingpage not set, dass Sie echte Besucher verloren haben?

Nein. Die Sitzungen und Ereignisse sind bei Analytics angekommen. Nur ihre Startseite ist unbekannt, deshalb bleiben Gesamtsitzungen und Nutzer meist intakt.

Stattdessen entsteht der Verlust bei der Interpretation. Berechnen Sie Conversions je Landingpage, gehören (not set) Sitzungen zu keiner Seite. Dadurch lesen Sie die Leistung einzelner Seiten womöglich niedriger, als sie tatsächlich ist.

Beispielszenario: Eine Kampagnenseite lässt einen Teil ihrer Formular Abschlüsse in der Zeile (not set) liegen. Im Bericht wirkt ihre Conversion Rate daher schwach. In Wahrheit kann sie besser abschneiden.

Um diesen Effekt zu begrenzen, stützen Sie Seitenentscheidungen nicht auf eine einzige Kennzahl. Lesen Sie Conversion Ereignisse, Sitzungsquelle und Seitentraffic zusammen. Prüfen Sie außerdem vor großen Budgetentscheidungen den Anteil von (not set).

Wie sieht ein Praxisbeispiel für GA4 Landingpage not set aus?

Das folgende Beispielszenario fasst einen Ablauf zusammen, den wir oft sehen. Es enthält keine Zahlen, denn es soll nur die Methode zeigen.

Eine Unternehmenswebsite misst mit dem Tag Manager und nutzt ein Einwilligungsbanner. Im Bericht kommen die meisten Sitzungen mit Formularabschluss mit (not set) als Landingpage an.

Das Team schlüsselt die Zeile zunächst in Erkunden nach Ereignisnamen auf. Formularabschlüsse und Klicks dominieren. Danach öffnet es DebugView mit einer sauberen Sitzung. Das Ergebnis ist eindeutig: Das Konfigurationstag läuft erst nach dem Klick auf das Banner, das Formulartag feuert dagegen sofort beim Laden.

Die Korrektur hat zwei Schritte:

1. Standardstatus der Einwilligung und Konfigurationstag an die erste Stelle beim Laden setzen.
2. Den Trigger des Formularereignisses hinter das Konfigurationstag legen.

Nach der Änderung beginnen neue Sitzungen mit page_view. Somit sinkt der Anteil von (not set). Alte Daten bleiben unverändert.

Wie wirkt es sich auf SEO und Werbeentscheidungen aus?

Zunächst zeigen Landingpage Daten, welche Seiten in organischem und bezahltem Traffic Ergebnisse bringen. Sind sie lückenhaft, stehen Content Prioritäten und die Wahl der Anzeigenziele auf schwacher Basis.

Beim SEO kann dann eine große Zeile (not set) Sie bei der Rangfolge Ihrer besten Seiten täuschen. Bei Anzeigen lassen Vergleiche von Landingpages diese Sitzungen aus. Das kann A/B Entscheidungen verzerren.

Unser praktischer Rat: Notieren Sie vor jeder wichtigen Entscheidung den Anteil von (not set). Ist er sichtbar, dann verschieben Sie die Entscheidung oder bestätigen Sie sie mit einer zweiten Quelle wie der Search Console. Dieses Werkzeug erklärt unsere Anleitung zur Google Search Console.

So wird aus einer Messlücke kein Strategiefehler.

Unterscheiden sich Inhaltsgruppe und benutzerdefinierte Parameter?

Ja. Laut Googles Hilfeseite entsteht (not set) bei der Inhaltsgruppe, wenn automatische Ereignisse den Parameter content_group nicht annehmen oder wenn Ereignisse einen leeren Wert senden. Benutzerdefinierte Parameter können dasselbe Label in den ersten 24 Stunden nach der Registrierung zeigen.

Allerdings haben beide Fälle mit einem fehlenden page_view nichts zu tun. Trotzdem stehen sie in denselben Berichten, daher halten viele alles für ein einziges Problem. Dann korrigieren sie die falsche Stelle.

So trennen Sie die Fälle:

1. Notieren Sie, in welcher Dimension die Zeile steht.
2. Bei einer benutzerdefinierten Dimension prüfen Sie das Registrierungsdatum.
3. Geht es um die Landingpage, untersuchen Sie den Ablauf von page_view.
4. Bei der Inhaltsgruppe prüfen Sie, welche Ereignisse den Parameter tragen.

Zum Beispiel ist (not set) am ersten Tag einer neuen benutzerdefinierten Dimension normal. Warten Sie einen Tag und aktualisieren Sie den Bericht. Echte Probleme sind nur Zeilen, die nach dem Warten bleiben.

Wie bestätigen Sie, dass Ihre Korrektur gewirkt hat?

Zunächst testen Sie das Ergebnis auf zwei Wegen: mit einem Live Test und mit dem Vergleich einiger Tage an Daten.

Für den Live Test öffnen Sie DebugView erneut und prüfen das erste Ereignis in sauberen Sitzungen. Probieren Sie direkten Einstieg, Anzeigenklick und E-Mail Link getrennt aus. In jedem Fall sollte der erste Eintrag page_view sein.

Danach stellen Sie beim Datenvergleich die Tage nach der Korrektur den Tagen davor gegenüber. Vergleichen Sie gleiche Wochentage, denn Traffic Muster unterscheiden sich je nach Tag.

Notieren Sie außerdem diese Punkte:

• Datum der Änderung und die ausführende Person.
• Welches Tag oder welcher Trigger sich geändert hat.
• Anteil von (not set) vor und nach der Korrektur.

Dieses Protokoll spart daher Zeit, falls das Problem zurückkehrt. Entspricht das Ergebnis nicht Ihren Erwartungen, testen Sie die nächste Ursache: SPA, Ereignisse vom Server oder Timeout.

Welche Checkliste nutzt unser Team?

Wir von Talha Aslan und Team gehen bei (not set) immer in derselben Reihenfolge vor. Die Reihenfolge beschleunigt die Lösung und verhindert unnötige Änderungen. Die Liste unten ist zum Beispiel ein Beispiel für einen Arbeitsablauf.

1. Bestimmen Sie die Dimension und das Datum, ab dem die Zeile auftrat.
2. Schlüsseln Sie sie in Erkunden nach Ereignisnamen auf.
3. Beobachten Sie in DebugView das erste Ereignis einer sauberen Sitzung.
4. Prüfen Sie Tag Reihenfolge und Trigger.
5. Kontrollieren Sie die Reihenfolge der Befehle im Consent Mode.
6. Testen Sie SPA und Ereignisse vom Server getrennt.
7. Ändern Sie jeweils nur eine Sache und notieren Sie das Datum.
8. Vergleichen Sie denselben Bericht einige Tage später.

Allerdings garantiert diese Liste kein Ergebnis. Jede Website ist anders, und manche Sitzungen bleiben immer ohne page_view. Dennoch lesen Sie Berichte sicherer, wenn Sie die Ursache kennen.

Planen Sie bei der Messplanung auch Micro Conversions ein. Lesen Sie dazu unseren Beitrag Was sind Micro Conversions im Onlineshop.

Was tun bei ähnlichen Platzhalter Warnungen auf anderen Plattformen?

Wie das (not set) in GA4 kennzeichnen auch andere Plattformen fehlende Daten mit eigenen Hinweisen, denn jede Plattform kennt Lücken. Die Logik ist gleich: Die Plattform hat die Information nicht erhalten, also suchen Sie die Quelle.

Zum Beispiel kann bei sozialen Plattformen eine fehlende Einstellung eine ähnliche Warnung auslösen. Unser Beitrag zur Meldung Instagram Musik für Business Konten nicht verfügbar zeigt einen Fall. Das Thema ist ein anderes, die Diagnose folgt aber ähnlichen Gewohnheiten: erst den Umfang prüfen, dann die Einstellungen.

Wenn Sie wissen möchten, wie Besuche über KI Antworten in GA4 aussehen, lesen Sie KI Traffic in GA4 erkennen und analysieren. Dieses Thema wiederholen wir hier nicht.

Wann sollten Sie Expertenhilfe holen?

Ein Blick von außen beschleunigt daher die Arbeit in diesen Fällen:

• Der Anteil von (not set) bleibt lange hoch.
• Conversion und Umsatzberichte brechen zusammen mit (not set) ein.
• Sie nutzen SPA oder serverseitige Messung.
• Ein Consent Tool und der Tag Manager arbeiten zusammen.

Dann empfehlen wir ein Mess Audit. Es prüft Tag Reihenfolge, Einwilligungsablauf und Ereignisplan gemeinsam. Somit beheben Sie die Quelle, statt Symptome einzeln zu flicken.

Unser Team führt solche Audits im Rahmen von SEO und Werbearbeit durch. Möchten Sie Ihre Anzeigenmessung prüfen lassen, lesen Sie über unsere Google Ads Verwaltung.

Hinweis: Dieser Beitrag ist eine allgemeine Information und keine Rechts oder Steuerberatung. Menüs und Funktionen ändern sich, bestätigen Sie den aktuellen Stand daher in der Google Analytics Hilfe.