Eine korrekte Datenzuordnung, eine einheitliche Nutzeridentifizierung und ein genaues Ereignis-Tracking sorgen für zuverlässige Ergebnisse und eine optimale Modellleistung. Probleme können zu verzerrten Messwerten, voreingenommenen Vergleichen und beschädigten Trainingsdaten führen. Solche Ergebnisse erschweren fundierte Entscheidungen und die Verbesserung der Suche.
Hinweis
Weitere Informationen finden Sie unter Allgemeine Hinweise zur Durchführung von A/B-Tests.
Testkomponenten
Die A/B-Checks für den Einstieg umfassen die folgenden Testkomponenten:
Besucher-ID: Erforderlich, um einen Besucher auf einem Gerät zu erfassen, unabhängig vom Anmeldestatus. Sie sollte sich nicht ändern, wenn sich der Besucher an- oder abmeldet. Wenn sich der Nutzer zwischen den Sitzungen anmeldet, bleibt die Besucher-ID konstant.
Sitzungs-ID: Zum Tracking der Interaktionssitzung eines Besuchers. Eine Sitzung ist eine Zusammenfassung des Nutzerverhaltens in einem bestimmten Zeitraum, der in der Regel nach 30 Minuten Inaktivität endet.
User-ID: Sehr empfehlenswerte, dauerhafte Kennung für einen angemeldeten Nutzer (z. B. eine Kundennummer), die geräteübergreifend für die Personalisierung verwendet wird. Es sollte immer ein gehashter Wert sein.
Attributions-Token: Ein Hash-Token, das in jeder Suchantwort zurückgegeben wird. Attributionstokens sind eindeutig, unabhängig davon, ob die Suchparameter genau übereinstimmten.
Beschreibung
Bei dieser Prüfung wird überprüft, ob die Anzahl der eindeutigen Besucher-IDs in einem A/B-Test nach dem Zufallsprinzip zwischen der Kontroll- und der Testgruppe aufgeteilt wird.
Die Besucher-ID ist eine eindeutige Kennung für einen Nutzer auf einem einzelnen Gerät.
Auswirkungen
Eine unfaire Aufteilung von Besucher-IDs kann in der Vergangenheit zu Messfehlern bei A/B-Tests geführt haben.
Wenn eine Testgruppe eine unverhältnismäßige Anzahl bestimmter Besuchertypen enthält, z. B. einen Bot-Besucher, der eine große Menge an Test-Traffic sendet, kann sich das negativ auf die Messwerte für diese Gruppe auswirken. Das verfälscht Vergleiche von wichtigen Leistungsindikatoren und wirkt sich stark auf die Analyse aus, aber nicht direkt auf das Modelltraining.
Beschreibung
Mit dieser Prüfung wird dafür gesorgt, dass die Anzahl der eindeutigen Nutzer-IDs, die einen angemeldeten Nutzer darstellen, gleichmäßig auf die Kontroll- und Testgruppen verteilt ist. Die Nutzer-ID sollte auf allen Geräten gleich bleiben.
Auswirkungen
Die Auswirkungen sind ähnlich wie bei der Besucher-ID. Wenn angemeldete Nutzer nicht zufällig zwischen Test- und Kontrollgruppen aufgeteilt werden, kann dies zu einer verzerrten demografischen Aufteilung führen.
Wenn die Testgruppe beispielsweise hauptsächlich neue Nutzer enthält, während die Nutzer mit hohen Ausgaben in der Kontrollgruppe verbleiben, werden die Messwerte künstlich für eine Seite begünstigt.
Das wirkt sich auf die Analyse und den Vergleich von Leistungskennzahlen (KPIs) aus.
Beschreibung
Bei dieser Prüfung wird speziell die Verteilung von Nutzern mit einer hohen Anzahl von Transaktionen oder wiederholten Käufen in den Testgruppen untersucht. Diese Nutzer werden häufig anhand ihrer Besucher-IDs und ihres Bisherige Käufe identifiziert.
Ziel ist es, diese Nutzer mit hohen Ausgaben gleichmäßig aufzuteilen.
Auswirkungen
- Eine ungleichmäßige Verteilung von Power-Usern, die erheblich zum Umsatz beitragen, kann KPI-Vergleiche zwischen den Testgruppen stark verzerren.
- Es kann schwierig sein, Bias auf Grundlage demografischer Informationen wie Ausgabeverhalten zu beheben.
- Das wirkt sich überproportional auf umsatzbasierte Messwerte wie Umsatz pro Besucher oder Umsatz pro Sitzung aus.
- Betonen Sie die Auswirkungen auf die Messgenauigkeit bei A/B-Tests.
Beschreibung
Bei dieser Prüfung wird geprüft, ob das in der Suchantwort zurückgegebene Attributionstoken korrekt in das Suchereignis aufgenommen wurde, das aus dieser Suche resultiert.
Das Attributions-Token ist für Vertex AI Search for Commerce erforderlich, um Ereignisse mit der Suche zu verknüpfen, die sie generiert hat:
- Das ist in der Regel für Zugriffe relevant, die von Vertex AI Search bereitgestellt werden.
- Dieses Problem deutet auch auf die Möglichkeit des Caching von Suchantworten hin, was die Suchleistung und die Nutzerfreundlichkeit aufgrund von veraltetem Inventar und veralteten Rankings beeinträchtigt.
Auswirkungen
Eine korrekte Zuordnung mithilfe des Tokens ist entscheidend, um Nutzerverhalten wie Klicks und Käufe mit bestimmten Search API-Aufrufen zu verknüpfen. Ohne das Token werden Suchereignisse möglicherweise fälschlicherweise so verwendet, als stammten sie von einem anderen Suchanbieter, und nachfolgende Ereignisse können nicht genau mit der Suche verknüpft werden.
Ungenaue oder fehlende Attributions-Tokens stören das Modelltraining, da sie verwendet werden, um Ereignisdaten (z. B. Suchanfragen, gefolgt von Käufen) zu verknüpfen und positive und negative Beispiele zum Trainieren des Ranking-Modells zu generieren. Außerdem wird die genaue Berechnung von Messwerten pro Suche verhindert, z. B. Umsatz pro Suche, die für die Leistungsbewertung bei A/B-Tests unerlässlich sind.
Das wirkt sich sowohl auf das Modelltraining als auch auf die Analyse von Messungen und Leistung aus.
Beschreibung
Mit dieser Prüfung wird sichergestellt, dass die Besucher-ID und die Nutzer-ID, die in einem Suchanfrageaufruf an die Search API verwendet werden, mit der Besucher-ID und der Nutzer-ID übereinstimmen, die im nachfolgenden Nutzerereignis für die Suche enthalten sind (sofern möglich für Ereignisse vom Typ „Detailseite aufrufen“, „In den Einkaufswagen legen“ und „Kauf abschließen“, die sich auf diese Suchinteraktion beziehen).
- Die Felder
visitorIdunduserIdsind jeweils eine eindeutige Kennung für einen Nutzer auf einem einzelnen Gerät. - Eine einheitliche Formatierung der Besucher- und User-ID in Suchanfragen und Nutzerereignissen ist erforderlich, damit die Suche Nutzeraktivitäten richtig identifizieren kann.
- Bei der Fehlersuche können Sie Interaktionen mithilfe der Besucher-ID und der Nutzer-ID nachvollziehen.
Auswirkungen
Eine Abweichung deutet auf potenzielle Probleme wie fehlende Ereignisse oder beschädigte Daten hin.
Die Besucher-ID und die Nutzer-ID sind entscheidend für das Training von Retail Search-Modellen, insbesondere für Personalisierungsfunktionen. Für eine genaue Zuordnung von Käufen ist die konsistente Verwendung einer Besucher-ID und einer Nutzer-ID erforderlich.
Bei Vertex AI Search for Commerce wird die Besucher-ID verwendet, um die Suchergebnisse, die ein Nutzer sieht, damit zu verknüpfen, ob derselbe Besucher später ein angezeigtes Produkt gekauft hat. Damit werden Daten zu Suchanfragen, Klicks, Warenkorb- und Kaufvorgängen verknüpft, um positive und negative Beispiele für das Training des Rankingmodells zu generieren.
Wenn die Besucher-ID nicht übereinstimmt, können Kaufereignisse nicht der Suchanfrage oder dem Seitenaufruf der Detailseite zugeordnet werden, die ihnen vorausgegangen sind. Es sieht dann so aus, als ob keine Suchanfrage zu einem Kauf geführt hat. Das stört nicht nur das Modelltraining, sondern erschwert auch die Berechnung von Messwerten pro Suche wie dem Umsatz pro Suche. Eine weitere Herausforderung besteht darin, Leistungskennzahlen (Key Performance Indicators, KPIs) wie Umsatz pro Besucher, Conversion-Rate und durchschnittlicher Bestellwert genau zu berechnen. Dazu müssen Nutzerereignisse genau mit Suchanfragen verknüpft werden. Diese Prüfung wirkt sich also sowohl auf das Modelltraining als auch auf die Analyse aus.
Beschreibung
Bei dieser Prüfung wird das Volumen der Suchanfragen, die an die Search API für einen bestimmten Testlauf (insbesondere den Google-Lauf) gesendet werden, mit dem Volumen der für diesen Lauf erfassten Suchnutzerereignisse verglichen.
Die Anzahl der erfassten Suchereignisse sollte in etwa der Anzahl der Search API-Aufrufe entsprechen.
Auswirkungen
- Eine erhebliche Abweichung deutet darauf hin, dass Nutzerereignisse nicht richtig erfasst oder an Google gesendet werden.
- Das kann durch Probleme beim Erfassen von Ereignissen (fehlende oder unvollständige Ereignisse) oder durch falsches Tagging von Nutzerereignissen mit der Test-ID verursacht werden.
- Eine korrekte Erfassung von Nutzerereignissen ist unerlässlich, da die in Ereignissen erfassten Nutzerinteraktionen dem Modell das erforderliche Feedback zur Optimierung der Ergebnisse liefern.
- Wenn Ereignisse fehlen, erhält das Modell weniger Daten für das Training, was sich negativ auf die Leistung auswirken kann.
- Die Genauigkeit und Zuverlässigkeit von Messwerten, die zur Auswertung von A/B-Tests verwendet werden (z. B. Klickrate, Conversion-Rate, Umsatzmesswerte), hängen vollständig von der Vollständigkeit und Richtigkeit der Nutzerereignisdaten ab.
- Fehlende Ereignisse bedeuten, dass diese Messwerte nicht genau berechnet werden können, was zu einer verzerrten Leistungsanalyse und unzuverlässigen A/B-Testergebnissen führt.
- Eine Abweichung bei der Anzahl der Anfragen zwischen API-Aufrufen und Ereignissen wirkt sich sowohl auf das Modelltraining als auch auf die Analyse aus.
Beschreibung
Bei dieser Prüfung wird geprüft, ob das entsprechende Nutzerereignis für die Suche, das über das Attributionstoken verknüpft ist, auch die richtigen Filterinformationen enthält, wenn ein Nutzer Filter auf Suchergebnisse anwendet (was in der Suchanfrage widergespiegelt wird).
Bei dieser Prüfung wird die Konsistenz für bestimmte tokenbezogene Paare sowie die allgemeine Konsistenz der in Ereignissen vorhandenen Filterdaten im Vergleich zu API-Aufrufen überprüft.
Auswirkungen
- Um dynamische Facetten verwenden zu können, müssen Filteranweisungen in Suchereignisse aufgenommen werden.
- Das Retail Search-Modell leitet die Beliebtheit von Facetten aus den Filtern in Suchanfragen ab. Das ist entscheidend für eine optimale Leistung dynamischer Facetten.
- Wenn Filterdaten in den Nutzerereignissen fehlen oder falsch sind, kann das Modell nicht so gut aus Nutzerinteraktionen mit Filtern lernen.
- Dies wirkt sich direkt auf das Training und die Effektivität von Funktionen wie dem dynamischen Faceting aus.
- Diese Prüfung ist auch nützlich, um Probleme im Zusammenhang mit Suchergebnissen, der Konversationssuche und dynamischen Attributen zu beheben.
- Die primären Auswirkungen betreffen das Modelltraining speziell für dynamische Facetten und zugehörige Funktionen. Es wird aber auch die Möglichkeit beeinträchtigt, die Leistung dieser spezifischen Funktionen genau zu analysieren und zu messen.
- Wirkt sich auf das Modelltraining im Zusammenhang mit dynamischen Facetten aus und ist wichtig für das Debugging und die Leistungsanalyse (Messung) von Funktionen, die auf Filterdaten basieren.
Beschreibung
- Bei dieser Prüfung wird geprüft, ob die in einer Suchanfrage an die Search API enthaltenen Paginierungsparameter (Offset) und Sortierkriterien (Order by) im entsprechenden Suchnutzerereignis korrekt dargestellt werden.
- Diese Ereignisse werden in der Regel mithilfe des Attributions-Tokens mit der ursprünglichen Anfrage verknüpft.
- Die Prüfung sorgt für Konsistenz bei bestimmten tokenbezogenen Interaktionen und bei allen in Ereignissen gesendeten Daten.
- Diese Einheitlichkeit der Ereignisdaten ist wichtig, um Nutzerpfade mit Paginierung oder Sortierung zu debuggen und Funktionen wie die konversationelle Suche und dynamische Facetten zu nutzen.
Auswirkungen
- Bei einer Abweichung lässt sich nicht genau analysieren, wie Nutzer unter bestimmten Paginierungs- oder Sortierungsbedingungen mit Suchergebnissen interagieren.
- Das erschwert die Fehlersuche für diese Funktionen und macht es schwierig, ihre Leistung genau zu bewerten. Das wirkt sich auf die Analyse der Leistung von Funktionen wie der konversationellen Suche oder der dynamischen Facettierung aus.
- Konsistente Ereignisdaten sind die Grundlage für das Modelltraining. Inkonsistenzen können sich indirekt auf die Erkenntnisse auswirken, die aus der Analyse des Nutzerverhaltens unter verschiedenen Anzeigebedingungen gewonnen werden.
- Die Konsistenz von Anfrageparametern und Ereigniswerten ist wichtig für die Leistung von klickbasierten Modellen für das erneute Ranking.
- Dies wirkt sich hauptsächlich auf das Debugging und die Analyse bestimmter Funktionen aus und in gewissem Maße auf die Effektivität des Modelltrainings, das mit dem Verständnis der Nutzerinteraktion mit paginierten oder sortierten Ergebnissen zusammenhängt.
Beschreibung
- Bei dieser Prüfung wird dafür gesorgt, dass eine eindeutige Besucher-ID (für Nutzer, die nicht angemeldet sind) während des gesamten A/B-Testzeitraums einer einzelnen Testgruppe oder einem einzelnen Lane zugewiesen bleibt, also der Kontroll- oder Testgruppe.
- Eine konsistente Besucherzuweisung ist zu erwarten, sofern keine geplanten Änderungen wie Traffic-Ramping oder explizite Neuzuweisungen erfolgen.
- Wenn ein Nutzer, der durch seine Besucher-ID identifiziert wird, unerwartet zwischen Testgruppen wechselt, wird dies als „Wechsel“ bezeichnet.
- Das kann an Problemen wie dem falschen Senden von Ereignissen, einer falschen Kennzeichnung von Ereignissen mit der Test-ID, Problemen bei der Frontend-Implementierung oder einer falsch konfigurierten Weiterleitung von Suchtraffic liegen.
Auswirkungen
- Eine konsistente Zuordnung von Websitebesuchern ist für einen fairen A/B-Test entscheidend.
- Wenn ein Websitebesucher den Pfad wechselt, werden seine Nutzerereignisse (Klicks, In-den-Einkaufswagen-Legungen, Käufe) möglicherweise unter verschiedenen Test-IDs erfasst. Dadurch lässt sich sein Verhalten nicht genau einer einzelnen Variante zuordnen. Dadurch werden die Daten verfälscht, die zur Berechnung von KPIs für die einzelnen Fahrspuren verwendet werden. Das führt zu verzerrten und unzuverlässigen Messergebnissen.
- Für das Training des Retail Search-Modells, insbesondere für die Personalisierung, sind konsistente
visitorId- unduserId-Felder unerlässlich, um Nutzerinteraktionen im Zeitverlauf zu verknüpfen und Käufe den vorherigen Suchereignissen zuzuordnen. - Wenn die Besucher-ID gewechselt wird, wird diese Verknüpfung unterbrochen. Das Modell kann dann nicht effektiv aus dem Nutzerverhalten bei einer konsistenten Suche lernen. Das wirkt sich erheblich auf die Analyse und das Modelltraining aus.
Beschreibung
- Bei dieser Prüfung werden speziell Nutzerereignisse für die Suche untersucht, die mit einer Test-ID der Kontrollgruppe oder mit Holdout-Traffic getaggt sind, aber unerwartet ein von Google generiertes Attributions-Token enthalten.
- Attributionstokens werden von der Retail Search API zurückgegeben und sollen in nachfolgende Nutzerereignisse für von Google bereitgestellte Zugriffe aufgenommen werden.
- Für Kontroll-Traffic wird die vorhandene Suchmaschine verwendet. Es sollten keine Google-Attributions-Tokens empfangen oder gesendet werden.
- Dieses Problem hängt mit der Prüfung des Wechsels der Test-ID zusammen, da es darauf hindeutet, dass Ereignisse fälschlicherweise getaggt oder weitergeleitet werden.
- Dieses Problem kann auf das Caching von Suchantworten hinweisen, was die Suchleistung und die Nutzerfreundlichkeit aufgrund von veraltetem Inventar und veraltetem Ranking beeinträchtigt.
Auswirkungen
- Wenn ein Google-Attributionstoken in einem Ereignis der Kontrollgruppe vorhanden ist, werden Attributionen fälschlicherweise getaggt.
- Das bedeutet, dass Ereignisse von Nutzern, die die Kontrollsuche (nicht von Google) verwendet haben, fälschlicherweise dem Google-Testlauf zugeordnet werden.
- Dadurch wird die Berechnung der Messwerte für die Google-Gruppe direkt verfälscht, da Daten aus der Kontrollgruppe einbezogen werden. Das führt zu einer Verzerrung der wahrgenommenen Leistung und macht die Analyse ungültig.
- Aus Sicht des Modelltrainings werden dem Modell zugeordnete Nutzerereignisse verwendet, um aus Interaktionen mit Suchergebnissen zu lernen.
- Wenn fälschlicherweise Ereignisse aus der Kontrollgruppe einbezogen werden, werden irrelevante oder widersprüchliche Daten in den Trainingssatz aufgenommen, was möglicherweise zu einer Verschlechterung der Modellleistung führt.
- Diese Prüfung wirkt sich sowohl auf die Analyse als auch auf das Modelltraining aus.
Beschreibung
- Bei dieser Prüfung geht es um die eingehenden Suchanfrageaufrufe an die Retail Search API selbst.
- Es wird nach Anfragen gesucht, die von Besucher-IDs oder Test-IDs stammen, die für die Kontrollgruppe oder den Holdout-Traffic vorgesehen sind.
- Das bedeutet, dass Traffic, der für die Kontroll- oder Holdout-Gruppe vorgesehen ist, fälschlicherweise an den API-Endpunkt der Google-Testgruppe weitergeleitet wird.
- Dieses Problem ähnelt dem Check für den Wechsel der Besucher-ID, wird aber auf der Seite der API-Anfrage und nicht nur auf der Seite des Nutzerereignisses beobachtet.
Auswirkungen
- Dieser Befund weist auf eine grundlegende Fehlkonfiguration des Mechanismus für die Aufteilung und das Routing von Traffic im A/B-Test hin.
- Testgruppen sind nicht richtig isoliert, wenn Kontroll-Traffic an die Google API gesendet wird.
- Dadurch wird die A/B-Testkonfiguration ungültig und die Fairness des Vergleichs beeinträchtigt.
- Das hat direkte Auswirkungen auf die Analyse, da das Traffic-Volumen und die Zusammensetzung in der Google-Lane durch die Einbeziehung unerwünschter Nutzer aufgebläht werden. Das führt zu einer ungenauen Berechnung und Analyse von Messwerten.
- Für das Modelltraining sind die API-Logs selbst zwar nicht die primären Trainingsdaten, aber die nachfolgenden Nutzerereignisse, die durch diesen falsch weitergeleiteten Traffic generiert werden, führen, wenn sie ebenfalls fälschlicherweise zugeordnet werden, zu Rauschen und potenziell falschen Signalen in den Trainingsdaten.
- Dieses Problem wirkt sich sowohl auf die Analyse als auch auf das Modelltraining aus.
Beschreibung
- Bei dieser Prüfung wird validiert, ob für einen Nutzer (identifiziert durch seine Besucher-ID oder Nutzer-ID) erfasste Nutzerereignisse vom Typ „Kauf abgeschlossen“ mit dem richtigen
experimentIdsgetaggt sind, das dem A/B-Testlauf entspricht, dem er zugewiesen wurde, z. B. der Kontrollgruppe oder der Testgruppe. - Es werden Fälle erkannt, in denen das Kaufereignis eines Nutzers einer anderen Testgruppe zugeordnet wird als der, in der er die relevanten Suchaktionen ausgeführt hat, die zum Kauf geführt haben.
- Dieses Problem hängt eng mit der konsistenten Zuordnung von Besuchern zu Testgruppen zusammen und setzt voraus, dass „experimentIds“ im Ereignis „purchase-complete“ enthalten sind.
Auswirkungen
- Eine konsistente Zuordnung von Besuchern zu Testgruppen ist entscheidend für genaue A/B-Tests.
- Wenn Ereignisse vom Typ „Kauf abgeschlossen“ fälschlicherweise mit der falschen Test-ID getaggt werden, werden sie dieser Gruppe fälschlicherweise zugeordnet.
- Das wirkt sich direkt auf Messwerte aus, die auf Kaufdaten pro Lane basieren, z. B. Umsatzrate, Bestellrate, durchschnittlicher Bestellwert und Conversion-Rate.
- Bei einer falschen Zuordnung ist es unmöglich, die Leistung verschiedener Testgruppen genau zu vergleichen. Das führt zu ungültigen und unzuverlässigen A/B-Testergebnissen.
- Aus Sicht des Modelltrainings werden Retail Search-Modelle, insbesondere solche, die auf Umsatz oder Conversion-Rate optimiert sind, trainiert, indem Nutzerinteraktionen (z. B. Suchanfragen) mit nachfolgenden Käufen verknüpft werden, um zu ermitteln, welche Ergebnisse zu Conversions führen.
- Eine korrekte Zuordnung, bei der häufig Besucher-, Nutzer- und Test-IDs verwendet werden, um Kaufereignisse mit Suchanfragen in Verbindung zu bringen, ist für die Erstellung dieser positiven Trainingsbeispiele unerlässlich.
- Wenn Kaufereignisse aufgrund von inkonsistenten IDs oder dem Wechsel von Testgruppen fälschlicherweise zugeordnet werden, werden die Trainingsdaten durch falsche Signale beschädigt.
- Gültig, wenn Test-IDs im Kaufereignis gesendet werden:Wie bereits erwähnt, ist diese Prüfung nur gültig und wirkungsvoll, wenn
experimentIdskorrekt implementiert und in den Nutzerereignissen vom Typ „Kauf abgeschlossen“ gesendet werden.
Beschreibung
- Ähnlich wie beim Kaufereignis wird hier geprüft, ob die Nutzerereignisse vom Typ „add_to_cart“ für eine bestimmte Besucher-ID mithilfe des Felds „experimentIDs“ korrekt mit der zugewiesenen Testgruppe des Nutzers verknüpft sind.
- Es werden Fälle identifiziert, in denen ein „In den Einkaufswagen“-Ereignis mit einer Test-ID für einen Bereich getaggt ist, dem der Nutzer nicht zugewiesen wurde.
- Dieses Problem kann durch eine uneinheitliche Verwendung von Besucher-IDs bei verschiedenen Ereignistypen oder durch falsche
experimentIds-Tags verursacht werden.
Auswirkungen
- Falsch getaggte „add_to_cart“-Ereignisse führen zu einer falschen Zuordnung dieses Nutzerverhaltens zu den Testgruppen.
- Das wirkt sich direkt auf Messwerte wie die Rate der Warenkorb-Zufügungen und die Conversion-Rate aus, insbesondere wenn die Rate der Warenkorb-Zufügungen als wichtiger Schritt im Conversion-Trichter gilt.
- Ungenaue Messwerte beeinträchtigen die Zuverlässigkeit der A/B-Testergebnisse und die Möglichkeit, die Auswirkungen des Tests richtig zu messen.
- Aus Sicht des Modelltrainings sind „In den Einkaufswagen“-Ereignisse wichtige positive Signale, aus denen Modelle, insbesondere umsatzoptimierte Modelle, lernen.
- Wenn diese Ereignisse aufgrund einer inkonsistenten ID oder
experimentIds-Kennzeichnung fälschlicherweise der falschen Testgruppe zugeordnet werden, erhält das Modell verrauschte oder falsche Trainingssignale. - Gültig, wenn Test-IDs im Ereignis „In den Einkaufswagen“ gesendet werden: Wie bereits erwähnt, ist diese Prüfung nur gültig und wirkungsvoll, wenn
experimentIdskorrekt implementiert und in den Nutzerereignissen „In den Einkaufswagen“ gesendet werden.
Beschreibung
- Bei dieser Prüfung wird bewertet, ob die Verteilung der Nutzeraktivitäten, kategorisiert nach Gerätetyp (z.B. Mobilgerät, Computer, App), für jede Art von Nutzerereignis (Suche, Seitenaufruf der Detailseite, In den Einkaufswagen, Kauf) in den Kontroll- und Testgruppen ausgewogen ist.
- So soll sichergestellt werden, dass der Anteil der Nutzer, die über Mobilgeräte mit der Website interagieren, in der Kontrollgruppe und der Testgruppe ungefähr gleich ist. Das gilt auch für andere Gerätetypen.
- Wenn Sie eine erhebliche Abweichung feststellen, deutet das auf ein potenzielles Problem beim Mechanismus hin, mit dem Traffic aufgeteilt oder Ereignisse basierend auf dem Gerätetyp weitergeleitet werden.
Auswirkungen
Eine ungleichmäßige Verteilung von Geräten bedeutet, dass die Kontroll- und Testgruppen in Bezug auf die verwendeten Geräte nicht demografisch ausgewogen sind, ähnlich wie beim Problem mit der demografischen Aufteilung.
Nutzerverhalten, Suchmuster und Conversion-Raten können je nach verwendetem Gerät erheblich variieren. Deshalb führt eine ungleichmäßige Aufteilung der Geräte zwischen den Testgruppen zu einer Verzerrung des A/B‑Testvergleichs. Das hat zur Folge, dass die wichtigsten Geschäftsmesswerte für jede Gruppe nicht genau gemessen werden. Das liegt auch daran, dass die Ergebnisse einer Gruppe unverhältnismäßig stark von einem höheren oder niedrigeren Prozentsatz von Nutzern eines bestimmten Gerätetyps beeinflusst werden können. Dadurch lässt sich die tatsächliche Wirkung des Tests nur schwer ermitteln.
Der Gerätetyp ist zwar nicht immer ein direktes Merkmal in allen Modellen, aber ein ausgeglichenes Traffic-Volumen trägt dazu bei, dass die Trainingsdaten, die aus Nutzerereignissen in den einzelnen Lanes abgeleitet werden, die tatsächliche Verteilung des Nutzerverhaltens auf verschiedenen Geräten widerspiegeln. Ein Ungleichgewicht kann indirekt zu Trainingsdaten führen, die das Nutzerverhalten bestimmter Geräte über- oder unterrepräsentieren. Dies kann dazu führen, dass ein Modell nicht optimal auf die gesamte Nutzerbasis abgestimmt ist.
Ereignisse bilden die Grundlage für das KPI-Tracking und die allgemeine Fehlerbehebung.
Beschreibung
- Bei dieser Prüfung werden die Filterdaten in den Suchnutzerereignissen zwischen den Kontroll- und Testgruppen für ähnliche Suchanfragen verglichen.
- Es wird geprüft, ob Filterinformationen korrekt, konsistent und mit Parität zwischen den Lanes erfasst werden.
- Dazu gehört, zu prüfen, ob die verfügbaren Filteroptionen (Facetten), die Nutzern präsentiert werden, gleich oder gleichwertig sind, ob die in Ereignissen gesendeten Filterwerte den erwarteten Formaten oder Katalogdaten entsprechen und ob die Benutzeroberfläche für das Filtern vergleichbar ist.
- Eine Abweichung kann auftreten, wenn Filter nicht oder falsch erfasst werden oder wenn sich die Filter-Benutzeroberfläche bzw. die Filteroptionen unterscheiden. Das lässt sich in der Regel auf ein Konfigurationsproblem in der Catalog API oder Search API zurückführen.
Auswirkungen
- Unterschiede beim Filtern oder bei der Erfassung von Filterdaten zwischen Testgruppen können sich direkt darauf auswirken, wie Nutzer mit Suchergebnissen interagieren.
- Wenn eine Lane bessere oder andere Filteroptionen bietet, können Nutzer in dieser Lane ihre Suchanfragen anders eingrenzen. Das kann zu Abweichungen beim Nutzerverhalten führen und sich möglicherweise auf Messwerte wie die Conversion-Raten für gefilterte Suchanfragen auswirken.
- Dadurch wird eine variable Verzerrung in den A/B-Test eingeführt, sodass es schwierig ist, beobachtete Messwertunterschiede ausschließlich auf die Unterschiede im Suchranking zurückzuführen.
- Wenn keine Filterdaten in Ereignissen erfasst werden, können Leistungsmesswerte nicht nach Filternutzung aufgeschlüsselt werden. Das wirkt sich auf die Analyseergebnisse aus.
- Für das Modelltraining ist das Filtern von Informationen in Suchereignissen entscheidend für das Training dynamischer Facettenmodelle, da das Modell die Beliebtheit von Facetten anhand von Signalen zur Nutzung von Nutzerfiltern lernt.
- Genaue Informationen zur Filternutzung in Ereignissen sind auch für klickbasierte Modelle zur Neuberechnung des Ranks wichtig. Wenn Filterwerte in Ereignissen nicht mit denen in Suchanfragen übereinstimmen, wird die Leistung des Modells für Anfragen mit Filtern beeinträchtigt.
- Inkonsistente oder fehlende Filterdaten in Ereignissen beeinträchtigen die Modellqualität in Bezug auf dynamische Facetten und das Neusortieren für gefilterte Anfragen.
Beschreibung
- Bei dieser Prüfung wird eine bestimmte User Journey für die Suche untersucht, indem ein Suchereignis mithilfe von
attributionTokenmit der entsprechenden Search API-Anfrage verknüpft wird. - Das Attributions-Token wird von Vertex AI Search for Commerce generiert und mit jeder Suchanfrage zurückgegeben.
- Bei dieser Prüfung wird das Feld
searchQueryim Suchereignis mit dem tatsächlichen Abfragestring verglichen, der in der ursprünglichen API-Anfrage gesendet wurde, die das Attributions-Token zurückgegeben hat. - Wenn diese Abfragestrings trotz eines Attributions-Tokens für die Verknüpfung nicht übereinstimmen, bedeutet das, dass die in der Nutzeraktion gesendete „searchQuery“ nicht die ursprüngliche Suchanfrage des Nutzers widerspiegelt.
Auswirkungen
- Dieses Problem wirkt sich stark auf das Modelltraining aus.
- Bei Vertex AI Search for Commerce werden Ereignisdaten zum Trainieren der Modelle verwendet.
- Die Modelle, insbesondere Modelle für das Neuordnen von Ergebnissen auf Grundlage von Klicks, lernen, indem sie Nutzerinteraktionen wie Klicks, Artikel, die in den Einkaufswagen gelegt wurden, und Käufe mit den Suchanfragen verknüpfen, die die Ergebnisse generiert haben.
- Diese Verknüpfung basiert auf korrekten Informationen in den Ereignissen, einschließlich der Felder
searchQueryundattributionToken. - Wenn die
searchQueryim Ereignis nicht mit der tatsächlichen Anfrage aus der Search API-Anfrage übereinstimmt, wird das Modell mit falschen Daten trainiert und das Nutzerverhalten wird der falschen Anfrage zugeordnet. - Dies kann sich erheblich negativ auf die Qualität der Suchergebnisse auswirken, da das Modell auf Grundlage fehlerhafter Abfragedaten suboptimale Rankingstrategien lernt.
- Die primären Auswirkungen betreffen zwar die Qualität des Modelltrainings, dies kann sich aber auch indirekt auf die Analyse auswirken, da Modelle, die mit schlechten Daten trainiert wurden, möglicherweise schlecht abschneiden. Das kann zu verzerrten A/B-Testergebnissen führen, auch wenn Ereignisse ansonsten erfasst werden.
Beschreibung
- Bei dieser Prüfung simuliert ein Tester einen typischen Nutzerablauf mit einer Reihe von Aktionen wie Suchen, Klicken auf ein Produkt (
detail-page-view-Ereignis), Hinzufügen zum Einkaufswagen und möglicherweise Kauf. - Der Tester notiert sich die Besucher-ID und die Zeitstempel für diese Aktionen und ruft dann die aufgezeichneten Nutzerereignisse für diese bestimmte Besucher-ID aus Logs oder Datenplattformen ab.
- Ziel ist es, eine 1:1-Entsprechung zwischen den beobachteten Aktionen des Nutzers und den im System erfassten Ereignissen zu überprüfen (z. B. sollte eine Suchaktion ein Suchereignis, einen Klick oder ein
detail-page-view-Ereignis generieren). - Fehlende Ereignisse, Ereignisse mit falschen Besucher-IDs oder beschädigte Daten in den Ereignissen (z. B. fehlende Produkt- oder Test-IDs) deuten auf Probleme bei der Ereignisübermittlung hin.
Auswirkungen
- Probleme, die bei dieser Prüfung festgestellt werden, wirken sich stark auf die Analyse und das Modelltraining aus.
Messung
- Genaue und vollständige Nutzerereignisse sind unerlässlich, um wichtige Geschäftsmesswerte in einem A/B-Test zu berechnen, z. B. die Klickrate für Suchanzeigen, die Conversion-Rate für Suchanzeigen, die Rate für das Hinzufügen zum Einkaufswagen für Suchanzeigen und den Umsatz pro Besucher.
- Bei diesen Messwerten wird das Nutzerverhalten (Klicks, Artikel in den Einkaufswagen legen, Käufe) bestimmten Suchergebnissen und Testgruppen zugeordnet.
- Wenn Ereignisse für einen Nutzer fehlen oder beschädigt sind, werden seine Aktionen nicht vollständig erfasst. Das führt zu einer falschen Berechnung dieser Messwerte für die Testgruppe, der er zugewiesen war.
- Das führt zu Verzerrungen und Rauschen, wodurch die A/B-Testergebnisse ungenau und für Entscheidungen unzuverlässig werden. Fehlende Kaufereignisse wirken sich beispielsweise direkt auf die Messwerte für Conversion-Rate und Umsatzsteigerung aus.
Modelltraining
- Vertex AI Search for Commerce-Modelle werden intensiv mit Nutzerereignisdaten trainiert, um Nutzerverhaltensmuster zu lernen und das Ranking zu optimieren.
- Besucher- und Nutzer-IDs sind entscheidend für Personalisierungsfunktionen und das Verknüpfen von Ereignissen zum Erstellen von Trainingsbeispielen.
- Wenn Ereignisse fehlen oder beschädigt sind, gehen dem Modell wertvolle Trainingssignale aus der Interaktionssequenz des Nutzers verloren. Wenn beispielsweise Kauf- oder „In den Einkaufswagen“-Ereignisse fehlen, kann das Modell nicht lernen, welche Produktinteraktionen zu Conversions geführt haben.
- Fehlende Ereignisse für Seitenaufrufe bedeuten, dass das Modell keine Signale zu Klicks erhält. Diese Verringerung der Menge und Qualität der Trainingsdaten beeinträchtigt die Fähigkeit des Modells, effektiv zu lernen, was zu einer schlechten Qualität der Suchergebnisse führt und möglicherweise die Vorteile der Verwendung einer ML-basierten Suchmaschine zunichte macht.
- Inkonsistente Zuordnung oder Formatierung von Besucher-IDs kann diesen Prozess ebenfalls stören.
- Fehlende Kaufereignisse wirken sich auf das Modelltraining aus, da das Modell keine Käufe sieht.