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

Inhalt
Im hart umkämpften E-Commerce-Markt ist ein personalisiertes Einkaufserlebnis keine Option mehr, sondern eine Notwendigkeit. Vertex AI von Google Cloud zeichnet sich als leistungsstarke Recommendation Engine (Empfehlungsmaschine) aus, die maschinelles Lernen nutzt, um hochrelevante Produktvorschläge zu liefern. Davon profitieren vor allem Online-Shops durch höhere Konversionsraten und einen höheren durchschnittlichen Bestellwert.
Die Vorteile von Vertex AI als Recommendation Engine
Vertex AI (genauer: die Retail API, seit Juni 2026 als AI Commerce Search in Gemini Enterprise for Customer Experience vermarktet, zuvor Vertex AI Search for commerce) ermöglicht es E-Commerce-Unternehmen, Such- und Empfehlungsfunktionen in Google-Qualität auf ihren eigenen Websites einzusetzen.
- Tiefe Personalisierung: Das Nutzerverhalten wird in Echtzeit analysiert, um Produkte vorzuschlagen, die mit höchster Wahrscheinlichkeit gekauft werden.
- Umsatzsteigerung: Bessere Empfehlungen führen zu höheren Klickraten (CTR) und mehr Verkäufen.
- Automatisches Modelltraining: Das System passt sich automatisch an Saisonalität, Trends und Bestandsänderungen an.
Implementierung: Client-Side GTM vs. Server-Side GTM
Um Daten an Vertex AI zu senden, müssen Nutzerereignisse (wie Produktaufrufe) übermittelt werden. Die Art der Implementierung ist hierbei entscheidend.
| Merkmal | Client-Side GTM | Server-Side GTM (ssGTM) |
| Datenqualität | Anfällig für Adblocker, ITP und Browser-Einschränkungen. | Sehr zuverlässig. Daten werden sicher auf dem eigenen Server verarbeitet. |
| Performance | Längere Ladezeiten, da Skripte im Browser des Nutzers ausgeführt werden. | Schnellere Ladezeiten, da die Verarbeitung auf den Server ausgelagert wird. |
| Sicherheit | API-Schlüssel und Logik sind im Browser sichtbar. | Sicher. Direkte Verbindungen zur Google Cloud/Vertex AI bleiben verborgen. |
Vertex AI Daten-Reifegrade (Tiers)
Um das volle Potenzial benutzerdefinierter Empfehlungsmodelle in Vertex AI auszuschöpfen, müssen die Daten bestimmte “Tiers” (Stufen) erreichen.
- Tier 1: Baseline: Zur Verfügung steht nur der Produktkatalog. Empfehlungen sind generisch (z. B. “Beliebte Artikel”).
- Tier 2: Standard-Personalisierung: Erfordert kontinuierliches Event-Streaming in Echtzeit (Aufrufe, Klicks, Käufe). Schaltet grundlegende personalisierte Empfehlungen frei.
- Tier 3: Fortgeschrittene / Benutzerdefinierte Modelle: Hierfür braucht es eine umfangreiche Historie (meist 90+ Tage saubere Event-Daten) und hohes Traffic-Volumen. Dies schaltet Modelle wie “Wird oft zusammen gekauft” frei.Wie ist das zu erreichen? Über eine fehlerfreie Tracking-Architektur mit Server-Side GTM, die sicherstellt, dass jede Nutzerinteraktion sauber erfasst und an die Google Cloud gesendet wird.
Code-Beispiel: Daten an den GTM übergeben
Hier ist ein einfacher dataLayer-Push für einen Produktaufruf. Diese Daten werden vom Client GTM erfasst und an den Server-Side GTM weitergeleitet, der sie sicher an Vertex AI routet.
// 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
}
]
}
});
Hinweis: Im Server-Side GTM wird dafür eine HTTP-Anfrage konfiguriert (über ein benutzerdefiniertes Tag oder eine Google-Cloud-API-Integration), die diese normalisierten E-Commerce-Daten direkt an das Vertex-AI-Retail-Projekt sendet.
2 Kommentare
Die Tabelle zum Unterschied zwischen Browser- und Serverweg nennt die Sicherheit der Schlüssel als Vorteil — genau daran hängt bei uns die Architekturdiskussion.
Eine Frage dazu: Wenn die Empfehlungen im Browser angezeigt werden sollen, muss sie doch irgendetwas abrufen. Wie kommt die Seite an die Empfehlungen, ohne das Projekt preiszugeben?
Über einen eigenen Endpunkt oder gar nicht über den Browser. Beides sind gangbare Wege, und die Wahl entscheidet mehr über die Wartbarkeit als über die Sicherheit.
Der einfachere Weg ist serverseitiges Rendern: Die Anwendung holt die Empfehlungen beim Aufbau der Seite und liefert fertiges Markup aus. Der Browser spricht nie mit der Plattform, und die Zugangsdaten bleiben, wo sie hingehören. Der zweite Weg ist ein schmaler eigener Endpunkt, der die Anfrage entgegennimmt, um die Kennung des Besuchers ergänzt und weiterreicht — nötig, sobald Empfehlungen nach dem Laden ausgetauscht werden sollen.
Wichtig ist die Unterscheidung, die der Artikel an der Tabelle aufmacht: Der Weg der Ereignisse hinein und der Weg der Empfehlungen heraus sind zwei getrennte Strecken. Die erste kann vollständig serverseitig laufen, während die zweite im Browser bleibt — und ein Schlüssel im Seitenquelltext ist in beiden Fällen derselbe Fehler.