Die Suche des Shops in Google Analytics

Kurz gefasst

• Das Panel der Suche beantwortet „wie läuft die Suche“. Google Analytics beantwortet „was ist sie wert“, denn dort sind die Kampagnen, die Zielgruppen und die Conversions.
• Ist der Schalter an, wird jedes Geschehen der Suche der Seite selbst zweimal übergeben: als Browser-Ereignis und als push in den dataLayer.
• Auf diesem Weg verlässt nichts die Seite. Es werden keine Cookies geschrieben und keine Skripte geladen, und wer entscheidet, was an GA4 weitergeht, ist der Tag Manager des Shops.
• Das nützlichste Ereignis ist das unglamouröseste: eine Suche mit null Ergebnissen, aufgezeichnet mit dem Begriff, den die Person getippt hat.

Das Panel der Suche zeigt die Begriffe, die Klicks und die Suchen, die in nichts enden. Das ist das richtige Bild, um die Suche abzustimmen, und das falsche Bild, um eine Frage zu beantworten, die immer auftaucht: und in Google Analytics?

Die Frage ist berechtigt und geht nicht um Sturheit. Ein Suchwerkzeug mit eigenem Bericht ist ein Werkzeug, das niemand mit irgendetwas vergleicht, und die Kampagnen, die Zielgruppen, die Trichter und die Conversions des Shops leben in GA4. Was dort nicht ankommt, bleibt außerhalb der Rechnungen, die man über das Geschäft macht, und ein Werkzeug mit eigenem Bericht ist ein Werkzeug, das niemand mit irgendetwas vergleicht.

Was sich ändert, wenn man es einschaltet

Mit dem Schalter Ereignisse an das Analytics des Shops senden im Datenblatt des Shops wird jedes Geschehen der Suche der Seite selbst übergeben, zweimal und auf zwei Arten. Das gilt für jede unterstützte Plattform, einschließlich des Suchmoduls für PrestaShop:

• als Browser-Ereignis, mit Namen der Art buskara:search, für alle, die sie mit drei Zeilen JavaScript abhören wollen;
• als push in den dataLayer, mit Namen der Art buskara_search, was das Format ist, das der Google Tag Manager erwartet.

Es lohnt sich zu betonen, was nicht passiert. Dieser Weg schreibt keine Cookies, lädt keine Skripte und schickt nichts aus der Seite hinaus. Er legt die Information auf den Tisch des Shops und geht aus dem Weg. Ist der Schalter aus, bleibt der dataLayer genau so, wie er war.

Die Ereignisse

Zwei Anmerkungen zur Tabelle.

Die search_id ist dieselbe Kennung, die das Panel benutzt. Sie erlaubt es, eine Zahl aus GA4 zu nehmen und sie mit derselben Zahl auf der anderen Seite abzugleichen, statt zu streiten, welches der beiden Werkzeuge falsch liegt.

buskara_add_to_cart zählt das Hinzufügen zum Warenkorb in einer Sitzung, die gesucht hat, egal ob es vom Button der Suche, vom Assistenten oder vom Button des Shops selbst nach einer Suche kommt. Es ist absichtlich großzügig, und so muss man es lesen: es ist Einfluss der Suche, keine enge Zuordnung. Die enge Zuordnung passiert auf der anderen Seite, wie in wer sucht, kauft mehr erklärt wird.

Warum buskara_search nicht bei jeder Taste auslöst

Weil eine getippte Suche keine Suche pro Buchstabe ist, und ein Bericht, der die beiden Dinge verwechselt, schlimmer ist als gar kein Bericht.

„Kopfhörer“ zu tippen erzeugt ein Dutzend Zwischenzustände, und nur der letzte ist das, was die Person suchen wollte. Wenn alle zählten, wären die „meistgesuchten“ Begriffe des Shops halbe Wörter, die niemand absichtlich getippt hat, und die Quote der Suchen ohne Ergebnisse wäre eine Zahl, die von der Tippgeschwindigkeit jedes Besuchers erfunden wird.

Deshalb wartet das Ereignis, bis sich das Tippen setzt. Das ist eine Entscheidung mit Folgen: GA hat keine Möglichkeit, ein bereits gesendetes Ereignis zurückzunehmen, und eine Zahl, die sich von allein füllt, lässt sich hinterher nicht säubern.

Einschalten, in drei Schritten

1. Den fertigen Container im Panel herunterladen und im Tag Manager importieren. Er bringt die Variablen, die Trigger und die GA4-Tags schon fertig aufgebaut mit. Die vollständige Tabelle der Ereignisse und der Parameter steht im Leitfaden zu den Ereignissen in GTM und GA4.
2. Die Variable der Measurement ID öffnen und den Beispielwert durch den des Shops ersetzen, den man in GA4 unter Verwaltung → Datenstreams findet.
3. In Preview eine Suche im Shop machen und bestätigen, dass die Ereignisse ankommen. Danach Submit.

Ohne Tag Manager erfüllen die Browser-Ereignisse denselben Zweck mit sehr wenig Code:

document.addEventListener('buskara:search', function (e) {
  gtag('event', 'buskara_search', e.detail);
});

Die Einwilligung ist Entscheidung des Shops

Die importierten Tags kommen absichtlich ohne festgelegten Einwilligungsstatus.

Das ist kein Versäumnis, das zu beheben wäre: es ist die Anerkennung, dass die Einwilligungspolitik dem Shop gehört und nicht einem Anbieter von Suche. Die Sperre wird in den Regeln des Containers selbst gesetzt, mit demselben Mechanismus wie bei jedem anderen Tag. Ein Anbieter, der das für dich entscheiden würde, übernähme eine Verantwortung, die rechtlich weiterhin bei dem liegt, dem der Shop gehört.

Der Weg über den dataLayer selbst schreibt keine Cookies und identifiziert niemanden. Was Einwilligung braucht, ist das, was der Shop danach damit zu tun beschließt.

Und Microsoft Clarity

Es gibt einen zweiten Schalter, unabhängig vom ersten, für Shops, die Microsoft Clarity schon benutzen. Ist er an, werden dieselben Ereignisse an das Clarity übergeben, das auf der Seite liegt, und jede Sitzung wird mit zwei Markierungen versehen: dem gesuchten Begriff und dem Namen des Produkts.

Wichtiger als die Ereignisse sind die Markierungen, denn über sie filtert man Sitzungsaufzeichnungen und Heatmaps danach, was die Leute gesucht haben. Ein halbes Dutzend Aufzeichnungen von Leuten zu sehen, die einen Begriff gesucht haben und ohne einen einzigen Klick gegangen sind, erklärt mehr als die Spalte dieses Begriffs in einem Bericht.

Zwei ehrliche Einschränkungen: Clarity nimmt keine Parameter in den Ereignissen entgegen, was am Werkzeug liegt und nicht an dieser Integration, daher die Markierungen; und die Suche lädt das Skript von Clarity nie, ohne es auf der Seite tut der Schalter also nichts.

Für und Wider der Spiegelung in das Analytics des Shops

Der Bericht, den man zuerst aufbauen sollte

Wenn nur für einen Zeit ist, dann für diesen: buskara_search, gefiltert nach results = 0, mit search_term als Dimension.

Das ist die Liste dessen, was die Besucher gesucht haben und der Shop nicht bedient hat, mit ihren eigenen Worten geschrieben. Im Panel der Suche gibt es sie schon, mit Einordnung nach Problemtyp und einer Schätzung dessen, was sich zurückholen lässt. Was sich ändert, wenn man sie auch in GA4 hat, ist die Gesellschaft: sie lässt sich mit der Herkunft des Traffics kreuzen, und die Frage „welche Kampagne bringt Leute, die suchen, was wir nicht haben“ ist nicht mehr rhetorisch.

Das Thema hat einen eigenen Artikel, mit den vier Ursachen und dem, was gegen jede zu tun ist, in Suchen ohne Ergebnis sind die Einkaufsliste, die niemand liest.

Häufige Fragen

Wie bringe ich die interne Suche in Google Analytics 4?

Indem du das Senden von Ereignissen im Datenblatt des Shops einschaltest und den Tag-Manager-Container importierst, den das Panel bereitstellt. Die Ereignisse landen im dataLayer des Shops, und der Tag Manager leitet sie an GA4 weiter, mit den Einwilligungsregeln, die der Shop schon hat.

Schreiben diese Ereignisse Cookies oder verfolgen sie Besucher?

Dieser Weg nicht. Die Ereignisse werden der Seite selbst übergeben, und mehr verlässt sie nicht. Cookies und Identifikation sind das, was die GA4-Tags danach tun, unter den Regeln des Containers des Shops, wie bei jedem anderen Tag.

Warum stimmt die Zahl der Suchen in GA4 nicht mit der im Panel überein?

Fast immer wegen der Einwilligung und der Blocker. Das Panel zählt die Suchen, die beim Dienst angekommen sind; GA4 zählt die, die die Tags senden konnten. Die search_id steht auf beiden Seiten, und über sie untersucht man einen Unterschied, statt zu raten.

Lohnt sich das, wenn der Shop schon das Panel der Suche hat?

Es lohnt sich, wenn die Marketingentscheidungen in GA4 getroffen werden, was bei den meisten der Fall ist. Das Panel ist besser, um die Suche abzustimmen; GA4 ist besser, um sie mit allem anderen zu vergleichen, was der Shop tut. Sie konkurrieren nicht.

Was ist die search_id?

Eine Kennung, die jeder Suche zugewiesen wird und in den Ereignissen und in den Berichten des Panels vorhanden ist. Sie dient dazu, einen Klick, ein Hinzufügen zum Warenkorb oder ein Gespräch mit der konkreten Suche zu verbinden, die sie ausgelöst hat, statt sie nur nach dem getippten Begriff zu gruppieren.

Kann ich das mit Microsoft Clarity statt mit Google Analytics benutzen?

Ja, und es sind unabhängige Schalter: der eine, der andere, oder beide. Clarity gibt dir etwas, was GA4 nicht gibt, nämlich die Sitzungsaufzeichnung von jemandem zu sehen, der einen Begriff gesucht hat, und es gibt keine Parameter in den Ereignissen, was GA4 besser macht.