Vertex AI im E-Commerce: Recommendation Engine, GTM-Anbindung und Stufen der Datenreife

Eine Empfehlungsmaschine wählt Produkte passend zu einem Kontext aus, etwa für eine Produktseite oder einen Warenkorb. Google Cloud bietet verwaltete Produktempfehlungen neben der Suche an. Die aktuelle Dokumentation nennt das Produkt AI Commerce Search in Gemini Enterprise for Customer Experience; für die Anbindung bleibt die Retail API relevant. Vertex AI bezeichnet eine breitere Plattform, kein einzelnes universelles Empfehlungsmodell.

Was Empfehlungen verbessern können

Passende Vorschläge können das Entdecken von Produkten erleichtern. Höhere Kaufquoten oder Bestellwerte sind mögliche Ergebnisse, keine zugesicherten Wirkungen. Bei einem A/B-Test sehen zufällig zugeteilte Besuchergruppen entweder die bisherige Shopdarstellung oder die neuen Empfehlungen. Eine vor dem Test festgelegte Kennzahl, etwa Umsatz pro Besuch, bildet die gemeinsame Vergleichsgrundlage. Lange Antwortzeiten, nicht verfügbare Artikel und schlechte Katalogdaten können Vorteile aufheben.

Drei getrennte Datenwege

1. Katalog: Produktkennungen, Namen, Preise und Verfügbarkeit gelangen über Importe oder Aktualisierungen zum Commerce-Dienst.
2. Ereignisse: Produktaufrufe, Warenkorbänderungen und abgeschlossene Käufe liefern Verhaltenssignale. Die Produktkennungen müssen zum Katalog passen.
3. Empfehlungen: Die Anwendung fragt Ergebnisse ab und zeigt ausgewählte Produkte an. Das Senden von Ereignissen erzeugt noch keinen Empfehlungsbereich.

Client- und serverseitiger GTM

Google Tag Manager (GTM) bündelt Erfassungscode und dessen Ausführungsregeln in einem Container. Ein Webcontainer läuft im Browser. Ein Servercontainer empfängt Anfragen und kann Ereignisdaten prüfen, umformen und weiterleiten. Wird bereits die Browseranfrage blockiert oder gar nicht gesendet, kann serverseitiger GTM diese Interaktion nicht rekonstruieren. Kaufereignisse aus dem Backend sind eine weitere Datenquelle, benötigen aber ebenfalls zuverlässige Zustellung und Schutz vor Doppelzählung.

Die Verlagerung einzelner Verarbeitungsschritte kann Browserarbeit verringern; den tatsächlichen Leistungseffekt muss eine Messung zeigen. Hinzu kommen Betrieb, Antwortzeit und Kosten der Serverinfrastruktur. Private Dienstkonto-Zugangsdaten gehören auf den Server. Eingeschränkte API-Schlüssel für dokumentierte Browser-Erfassungswege sind ein anderer Zugangstyp; ein sichtbarer API-Schlüssel ist nicht automatisch ein offengelegtes privates Dienstkonto-Geheimnis.

Datenreife: Suchstufen sind keine Empfehlungsstufen

Google dokumentiert Leistungsstufen für Textsuche und Kategoriesuche. Empfehlungsmodelle haben dagegen jeweils eigene Anforderungen an Ereignisarten, Datenmengen und Zeitfenster. Eine allgemeine Leiter aus drei Stufen, die nach 90 Tagen sämtliche Empfehlungsmodelle freischaltet, existiert so nicht.

Similar Items kann beispielsweise Katalogdaten ohne Nutzerereignisse verwenden. Frequently Bought Together benötigt Kaufdaten. Maßgeblich sind die aktuelle Dokumentation zur Modellerstellung und die Anzeige im Cloud-Projekt. Ein Beobachtungsfenster von 90 Tagen bedeutet nicht zwangsläufig 90 aufeinanderfolgende Erfassungstage.

Codebeispiel: nur der erste Schritt

Das folgende dataLayer-Ereignis im GA4-Format beschreibt einen Produktaufruf. Der Push legt Daten in der Datenschicht der Seite ab; allein dadurch entsteht noch keine API-Anfrage.

// Produktinformationen in den Data Layer pushen (Client-Side)
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "view_item",
  ecommerce: {
    currency: "EUR",
    value: 49.99,
    items: [
      {
        item_id: "SKU_98765",
        item_name: "Laufschuhe XYZ",
        item_category: "Schuhe",
        price: 49.99,
        quantity: 1
      }
    ]
  }
});

Für die vollständige Anbindung erkennt ein Auslöser den Produktaufruf. Ein Tag, also der zugehörige Programmbaustein im Webcontainer, versendet die Daten. Der empfangende Dienst muss die Anfrage unter der vorgesehenen Adresse entgegennehmen und verarbeiten; diese Adresse heißt Endpunkt. Bei einer eigenen Zuordnung zur Retail API entspricht view_item dem Ereignis detail-page-view; die Artikelkennung muss das Katalogprodukt bezeichnen. Zusätzlich sind erforderliche Besucherkennungen und die API-spezifische Ereignisstruktur nötig. Das ursprüngliche GA4-Objekt ist keine unmittelbar versendbare Retail-API-Nutzlast.

Prüfungen vor dem Einsatz

Ein sinnvoller Abnahmetest verfolgt ein bekanntes Produkt vom Katalogimport über ein erfasstes Ereignis bis zur angezeigten Empfehlung. Zur Überwachung gehören abgewiesene Ereignisse, fehlende Produktzuordnungen, verspätete Updates, doppelte Käufe und leere Ergebnisse. Ein bloßer Vergleich der Kataloganzahl erkennt weder geänderte Preise noch vertauschte Kennungen. Die Datenerfassung benötigt außerdem die jeweils geltenden Datenschutzkontrollen; ein anderer Transportweg hebt diese Anforderungen nicht auf.