# GA4 Server-side Tracking: So richten Sie GA4 in einem Server-Container ein Leiten Sie GA4 über einen Server-Container: Google-Tag, GA4-Client und -Tag, Server-Managed-Cookies, das Measurement Protocol und ein Test auf Doppelzählung. Source: https://taggrs.io/de/ga4-server-side-tracking/ Author: Małgorzata Poddębniak, Content-Marketerin · [LinkedIn](https://www.linkedin.com/in/malgorzatapoddebniak/) Updated: 2026-11-13 --- GA4 Server-side Tracking sendet Ihre Google-Analytics-4-Events über einen Server-Container, den Sie kontrollieren, bevor sie Google erreichen. Sie gehen also nicht mehr direkt aus dem Browser Ihrer Besucher an Google. Das Google-Tag läuft weiter auf Ihrer Website, sendet seine Requests aber an Ihre eigene Subdomain. Dort nimmt der Server-Container sie an und leitet sie an GA4 weiter. An der Übergabe zwischen den beiden Containern scheitern die meisten GA4-Setups. Sendet ein Tag im Browser ein Event weiter direkt an Google, während dasselbe Event auch über den Server läuft, zählt GA4 es doppelt. GA4 hat keine Event-ID, um die beiden Kopien zusammenzuführen. Nur Käufe, die eine Transaktions-ID wiederholen, werden verworfen. Dieser Guide zeigt, was Web-Container und Server-Container jeweils tun, welche zwei serverseitigen Routen es zu GA4 gibt, wie Sie beide Container in fünf Schritten einrichten und wie Sie testen, dass jedes Event genau einmal ankommt. ## Was ist GA4 Server-side Tracking? GA4 Server-side Tracking leitet Ihre Google-Analytics-4-Events über einen Server-Container auf Ihrer eigenen Subdomain. Das Google-Tag im Browser sendet jedes Event dorthin, ein GA4-Client nimmt es an, und ein GA4-Tag leitet es an Ihre Property weiter. Dazwischen entscheiden Sie, welche Parameter Google erhält. Sie behalten Ihre bestehende GA4-Property. Browserseitige und serverseitige Erfassung können darin parallel laufen, solange jedes Event nur einen der beiden Wege nimmt. Warum GA4-Zahlen von denen Ihrer Werbeplattformen abweichen, lesen Sie in [warum Ihr GA4 ROAS ungenau ist](/de/how-to-fix-ga4-roas-inaccuracies/). ## Die wichtigsten Vorteile ### Wiederkehrende Besucher bleiben erkennbar GA4 erkennt einen wiederkehrenden Besucher an einer Client-ID, die in einem Cookie gespeichert ist. Löscht der Browser dieses Cookie zu früh, zählt der nächste Besuch als neuer Nutzer, und eine spätere Conversion verliert ihre ursprüngliche Quelle. Ein Server-Container auf Ihrer eigenen Domain kann das Client-ID-Cookie selbst setzen, und Browser gehen damit großzügiger um als mit einem Cookie, das JavaScript schreibt. Der Expertentipp unten erklärt die Details. ### Weniger Events gehen im Browser verloren Das Google-Tag sendet seine Requests an Ihre eigene Subdomain statt an die Erfassungsendpunkte von Google. Filter, die Requests an diese Domains blockieren, greifen dann nicht mehr, sodass mehr Seitenaufrufe und Conversions Ihre Property erreichen. ### Kontrolle darüber, was Google erhält Jedes Event läuft durch einen Server-Container, den Sie kontrollieren. Sie können Parameter entfernen oder umschreiben, bevor sie weitergeleitet werden, etwa um personenbezogene Daten zu entfernen, die in eine Seiten-URL geraten sind. Und Sie können dasselbe Event aus diesem einen Datenstrom auch an Google Ads oder andere Plattformen senden. ### Daten von außerhalb Ihrer Website Der Server-Container nimmt auch Requests aus Ihren eigenen Systemen an. Ein qualifizierter Lead in Ihrem CRM oder eine Rückerstattung im Backend Ihres Shops kann neben den Website-Events in GA4 landen, sodass Ihre Berichte zeigen, was nach dem Besuch passiert ist. Server-side Tracking kann keine Interaktion wiederherstellen, die Ihre Website nie erfasst hat, und es ändert nichts daran, wozu ein Besucher eingewilligt hat. Es ändert aber, wohin Ihre Daten nach dem Browser gehen und wer sie kontrolliert. **Reines Browser-Tracking und Server-side Tracking für GA4** | | Nur Browser | Server-side mit TAGGRS | | ------------------------------------- | ---------------------------------- | ----------------------------------------- | | Client-ID-Cookie | ✗ Browser können es früh löschen | ✓ Von Ihrer eigenen Subdomain gesetzt | | Filter, die Google-Domains blockieren | ✗ Anfragen können blockiert werden | ✓ Anfragen gehen an Ihre eigene Subdomain | | Personenbezogene Daten in Seiten-URLs | ✗ Wird mit dem Event gesendet | ✓ Vor dem Versand entfernt | | Events aus Ihrem CRM oder Backend | ✗ Nicht erfasst | ✓ Neben Website-Events gesendet | | Kontrolle darüber, was GA4 erhält | ✗ Begrenzt | ✓ Parameter entfernen oder umschreiben | > „Bevor wir auf serverseitiges Tracking umgestiegen sind, haben wir immer öfter gemerkt, dass die Daten in unseren Dashboards weit auseinanderlagen. Klicks in Google Ads waren überhaupt nicht mit dem vergleichbar, was wir in Google Analytics gesehen haben. Bei Meta Ads war es genauso. Deshalb haben wir nach einer Lösung gesucht, und die war serverseitiges Tracking.“ > > Romy Brookhuis, Online Content Marketer, byteffekt ## Web-Container, Server-Container oder beides? GA4 Server-side Tracking braucht immer beide Container. Sie haben unterschiedliche Aufgaben, und keiner ersetzt den anderen. | Der Web-Container | Der Server-Container | | --------------------------------------------------------------- | -------------------------------------------------------------- | | Führt das Google-Tag und Ihre GA4-Event-Tags aus | Nimmt die Requests mit dem GA4-Client an | | Liest den Data Layer: Seiten, Produkte, Bestellungen, Formulare | Leitet Events mit dem GA4-Tag an Ihre Property weiter | | Erfasst Browserkontext wie die Seiten-URL und den Referrer | Entfernt oder ändert Parameter, bevor sie den Server verlassen | | Liest den Einwilligungsstatus aus Ihrem Consent-Banner | Kann das Client-ID-Cookie von Ihrer eigenen Subdomain setzen | Einen Deduplizierungsschritt wie bei Meta gibt es hier nicht. Lassen Sie das Google-Tag auf Ihren Server-Container zeigen, dann nimmt jedes Event, das es sendet, genau einmal den Weg über den Server. Google bezeichnet hybride Setups, in denen einige Events direkt an GA4 gehen und andere über den Server, als üblich. Sie funktionieren, solange kein Event beide Wege nimmt. Das einzige Sicherheitsnetz ist die Transaktions-ID. GA4 verwirft einen Kauf, der eine bereits vom selben Nutzer erhaltene Transaktions-ID wiederholt, und das nur bei Web-Streams. Senden Sie nie eine leere Transaktions-ID: GA4 behandelt jeden Kauf mit leerem Wert als Duplikat der anderen. Wählen Sie im folgenden Checker Google Analytics 4 aus, um zu sehen, in welchen Container es gehört und wie Sie es einrichten. **In welchen Container gehört deine Plattform?** Wähle eine Plattform und sieh, in welchen Container sie gehört, warum, und wie du sie richtig konfigurierst. **Google Analytics 4**: Beide Container. Web-Container + Server-Container. Warum: GA4 ist die Grundlage jedes Server-side-Setups. Der GA4 Config-Tag läuft im Web-Container und sendet Daten an den Server-Container, der damit jeden nachgelagerten Tag versorgt, auch Google Ads. Ohne Server-side GA4 bekommt keine andere Plattform im Server-Container korrekte Daten. Konfigurationsschritte: 1. **Füge den GA4 Config-Tag hinzu**: Füge in deinem **Web-Container** einen GA4-Konfigurationstag hinzu. Trag die Measurement ID ein und lass die Server-Container-URL auf deine First-Party-Tagging-Subdomain zeigen (z. B. `sst.deinedomain.de`). 2. **Verbinde den Server-Container mit TAGGRS**: Verbinde deinen GTM-Server-Container mit TAGGRS. Deine Tagging-Subdomain muss eine First-Party-Subdomain der getrackten Domain sein. 3. **Füge den GA4-Server-Tag hinzu**: Füge in deinem **Server-Container** den GA4-Tag hinzu. Er empfängt automatisch die Events, die der GA4 Config-Tag im Web-Container weiterleitet. 4. **Prüfe den Datenfluss**: Nutze den Vorschaumodus von GTM und die GA4 DebugView, um vor dem Livegang zu prüfen, ob Events im Server-Container ankommen. [Zur Server-Seite wechseln (Google Analytics 4)](https://taggrs.io/docs/server-side-tracking/ga4/setup-in-gtm) **Google Ads**: Nur Server-Container. Alle Daten kommen vom Server. Kein Browser-Tag. Warum: Server-side Measurement für Google Ads hängt komplett davon ab, dass GA4 zuerst in beiden Containern eingerichtet ist. Sobald GA4 steht, laufen alle Google Ads-Tags (Conversion Tracking und Remarketing) ausschließlich im Server-Container. Konfigurationsschritte: 1. **Richte zuerst GA4 in beiden Containern ein**: Google Ads ist fest von GA4 abhängig. Schließ das Server-side-Setup von GA4 ab, bevor du Google Ads-Tags hinzufügst. 2. **Füge den Conversion Linker-Tag hinzu**: Füge in deinem **Server-Container** den Conversion Linker-Tag hinzu. Er verknüpft Klickdaten mit Conversion-Events. Dieser Schritt wird am häufigsten vergessen, und ohne ihn stimmt die Attribution nicht. 3. **Füge den Google Ads Conversion Tracking-Tag hinzu**: Füge in deinem **Server-Container** den Google Ads Conversion Tracking-Tag hinzu. Trag Conversion-ID und Conversion-Label aus deinem Google Ads-Konto ein. 4. **Füge den Google Ads Remarketing-Tag hinzu (optional)**: Wenn du Remarketing-Kampagnen schaltest, füge den Google Ads Remarketing-Tag im **Server-Container** hinzu. Er hat dieselbe Abhängigkeitskette wie Conversion Tracking. 5. **Teste mit dem Tag Assistant**: Prüfe die ganze Kette: GA4 Config (Web) → GA4-Server-Tag → Conversion Linker → Google Ads-Tag. Prüfe, ob Conversions in Google Ads → Messung → Conversions erscheinen. [Zur Server-Seite wechseln (Google Ads)](https://taggrs.io/docs/server-side-tracking/google-ads/conversion-linker) **Meta / Facebook**: Beide Container. Web-Container + Server-Container. Warum: Meta empfiehlt, Browser-Pixel und Server-CAPI gleichzeitig laufen zu lassen, um Match-Raten und Event-Abdeckung zu maximieren. Mit beiden steigt die Chance, dass jede Conversion korrekt zugeordnet wird, auch wenn das Browsersignal blockiert oder abgeschwächt ist. Deduplizierung erforderlich. Wenn Browser-Pixel und Server-CAPI für dasselbe Event feuern, erhält Meta es doppelt. Übergib im Browser- und im Server-Event dieselbe `event_id`. Meta dedupliziert anhand dieser ID und zählt die Conversion einmal. Konfigurationsschritte: 1. **Lass das Meta Pixel im Web-Container**: Dein bestehender Meta Pixel-Tag bleibt im **Web-Container**. Entferne ihn nicht: Das Browsersignal verbessert die Match-Raten. 2. **Füge den Meta CAPI-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den Meta Conversions API-Tag hinzu. Trag deine Pixel-ID und deinen Meta-Zugriffstoken ein. 3. **Richte die Deduplizierung mit event\_id ein**: Erzeuge für jedes Event eine eindeutige `event_id` (z. B. eine UUID oder einen String auf Basis eines Zeitstempels). Übergib dieselbe `event_id` im Pixel-Event im Browser und im CAPI-Event auf dem Server. Meta gleicht sie ab und zählt einmal. 4. **Teste im Meta Events Manager**: Geh im Meta Events Manager auf Test Events. Prüfe, ob Events aus Browser und Server ankommen und ob doppelte Events korrekt dedupliziert werden. [Zur Server-Seite wechseln (Meta / Facebook)](https://taggrs.io/docs/server-side-tracking/facebook/meta-pixel) **TikTok**: Beide Container. Web-Container + Server-Container. Warum: TikTok empfiehlt, Pixel und Events API zusammen mit Event-Deduplizierung zu nutzen, um die Performance zu maximieren. Das Pixel allein verpasst Conversions durch Browser-Unterschiede und Verbindungsprobleme. Die Events API schließt diese Lücken. Lass beide parallel laufen und übergib eine übereinstimmende `event_id`, damit TikTok Duplikate zusammenführt. Deduplizierung erforderlich. Wenn Pixel und Events API für dasselbe Event feuern, erhält TikTok es doppelt. Übergib im Browser- und im Server-Event dieselbe `event_id`. TikTok führt Duplikate anhand dieser ID zusammen und zählt die Conversion einmal. Konfigurationsschritte: 1. **Lass das TikTok Pixel im Web-Container**: Dein bestehender TikTok Pixel-Tag bleibt im **Web-Container**. Entferne ihn nicht: TikTok empfiehlt Pixel und Events API als doppeltes Setup. 2. **Füge den TikTok Events API-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den TikTok Events API-Tag hinzu. Trag deine Pixel-ID und deinen TikTok-Zugriffstoken ein. 3. **Richte die Deduplizierung mit event\_id ein**: Erzeuge für jedes Event eine eindeutige `event_id` (z. B. eine UUID oder einen String auf Basis eines Zeitstempels). Übergib dieselbe `event_id` im Pixel-Event im Browser und im Events API-Event auf dem Server. TikTok gleicht sie ab und zählt einmal. 4. **Prüfe das Hashing der Nutzerdaten**: Der Server-Tag wandelt Nutzerdaten (E-Mail, Telefon) automatisch in Kleinbuchstaben um und hasht sie mit SHA256, bevor sie an TikTok gehen. Prüfe in den Tag-Einstellungen, ob das aktiv ist. 5. **Prüfe im TikTok Events Manager**: Geh zu TikTok Ads Manager → Assets → Events → Web Events (oder Test Events). Prüfe, ob Events aus Browser und Server ankommen und ob übereinstimmende Events dedupliziert werden. [Zur Server-Seite wechseln (TikTok)](https://taggrs.io/docs/server-side-tracking/tiktok/pixel) **Pinterest**: Beide Container. Web-Container + Server-Container. Warum: Pinterest folgt derselben Logik mit zwei Signalen wie Meta: Browser-Tag und Conversions API laufen parallel. Zusammen geben sie Pinterest das genaueste Bild deiner Conversions und verbessern Attribution und Kampagnenoptimierung. Deduplizierung erforderlich. Sind Browser-Tag und Conversions API beide aktiv, erhält Pinterest jedes Event aus zwei Quellen. Übergib im Browser- und im Server-Event denselben Deduplizierungsschlüssel, damit Pinterest jede Conversion einmal zählt. Konfigurationsschritte: 1. **Lass den Pinterest Tag im Web-Container**: Dein bestehender Pinterest Tag bleibt im **Web-Container**. Er feuert weiterhin bei Events im Browser. 2. **Füge den Pinterest Conversions API-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den Pinterest Conversions API-Tag hinzu. Trage deine Tag-ID und den Zugriffstoken ein, den du im Ads Manager erzeugst. 3. **Richte die Event-Deduplizierung ein**: Übergib im Browser- und im Server-Event denselben Deduplizierungsschlüssel. Pinterest gleicht damit Conversion-Events ab und dedupliziert sie. 4. **Teste mit dem Pinterest Tag Helper**: Nutze die Chrome-Erweiterung Pinterest Tag Helper und den Pinterest Events Manager, um zu prüfen, ob Events über beide Kanäle ankommen und korrekt dedupliziert werden. [Zur Server-Seite wechseln (Pinterest)](https://taggrs.io/docs/server-side-tracking/pinterest/tag) **LinkedIn**: Beide Container. Web-Container + Server-Container. Warum: Der LinkedIn Insight Tag läuft client-side im Web-Container, für den Aufbau von Zielgruppen und für Seitenaufrufe. Conversion-Events werden zusätzlich server-side über LinkedIn CAPI gesendet. LinkedIn nennt das ein redundantes Setup: Stimmen beide überein, behält LinkedIn das Insight Tag-Event und verwirft die CAPI-Kopie. Der Serverweg deckt trotzdem die Fälle ab, in denen der Browser-Tag nie feuert. Deduplizierung erforderlich. LinkedIn nutzt eine `eventId`, um Conversion-Events aus Browser und Server abzugleichen. Übergib in beiden dieselbe `eventId`. Stimmen sie überein, behält LinkedIn das Insight Tag-Event und verwirft die Kopie aus der Conversions API. Konfigurationsschritte: 1. **Lass den LinkedIn Insight Tag im Web-Container**: Der Insight Tag bleibt im **Web-Container**, für den Aufbau von Zielgruppen und das Tracking von Seitenaufrufen. 2. **Füge den LinkedIn CAPI-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den LinkedIn Conversions API-Tag hinzu. Trag deine LinkedIn Ad Account ID und deinen Zugriffstoken ein. 3. **Richte die Deduplizierung mit eventId ein**: Übergib im Insight Tag im Browser und im CAPI-Event auf dem Server dieselbe `eventId`. LinkedIn dedupliziert damit. Hinweis: `conversion_id` kennzeichnet die Conversion-Regel und ist nicht der Deduplizierungsschlüssel. 4. **Prüfe im LinkedIn Campaign Manager**: Geh im LinkedIn Campaign Manager auf Analyze → Conversion Tracking. Prüfe, ob Insight Tag- und CAPI-Events angezeigt werden und ob redundante Treffer von der CAPI-Zahl abgezogen werden. [Zur Server-Seite wechseln (LinkedIn)](https://taggrs.io/docs/server-side-tracking/linkedin/insights-tag) **Snapchat**: Beide Container. Web-Container + Server-Container. Warum: Snap Pixel läuft im Web-Container, die Snap Conversions API im Server-Container. Beide Kanäle laufen parallel. Der Server-Tag normalisiert und hasht Nutzerparameter automatisch, darunter E-Mail, Mobile-ID, IP-Adresse und Telefonnummer, bevor sie an Snap gehen. Deduplizierung erforderlich. Übergib auf beiden Seiten dieselbe ID: `client_dedup_id` im Snap Pixel im Browser und `event_id` in den Conversions API-Events auf dem Server. Snapchat dedupliziert damit und zählt jede Conversion einmal. Konfigurationsschritte: 1. **Lass das Snap Pixel im Web-Container**: Dein bestehender Snap Pixel-Tag bleibt im **Web-Container**. Er sendet weiterhin Events aus dem Browser. 2. **Füge den Snapchat Conversions API-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den Snapchat CAPI-Tag hinzu. Trag deine Snap Pixel-ID und deinen Zugriffstoken ein. 3. **Prüfe die Normalisierung der Nutzerdaten**: Der Tag normalisiert und hasht E-Mail, Telefon, IP-Adresse und Mobile-ID automatisch mit SHA256. Prüfe in der Tag-Konfiguration, ob das aktiviert ist. 4. **Richte die Deduplizierung ein**: Übergib eine ID als `client_dedup_id` im Snap Pixel und als `event_id` in der Conversions API, damit Snapchat korrekt dedupliziert. 5. **Teste im Snap Events Manager**: Geh zu Snap Ads Manager → Events Manager. Prüfe, ob Events über beide Kanäle ankommen und dedupliziert werden. [Zur Server-Seite wechseln (Snapchat)](https://taggrs.io/docs/server-side-tracking/snapchat/snap-pixel) **Klaviyo**: Nur Server-Container. Alle Daten kommen vom Server. Kein Browser-Tag. Warum: Klaviyo unterstützt keine Event-Deduplizierung. Laufen Browser- und Server-Tracking gleichzeitig, kommt jedes Event doppelt an. Richte Klaviyo deshalb nur server-side ein. Der Tag kommuniziert direkt mit der Klaviyo API und kann Kontakte anlegen, Aktivitäten auf deiner Website tracken und Event-Parameter senden. Konfigurationsschritte: 1. **Entferne einen bestehenden Klaviyo-Browser-Tag**: Wenn du ein Klaviyo-JavaScript-Snippet in deinem Web-Container oder im Code deiner Website hast, deaktiviere es, bevor du den Server-side-Tag hinzufügst. Mit beiden entstehen doppelte Events. 2. **Füge den Klaviyo-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den Klaviyo-Tag hinzu. Trag deinen Klaviyo Public API Key und Private API Key ein. 3. **Konfiguriere die unterstützten Aktionen**: Der Tag unterstützt drei Aktionstypen: **Events tracken**, **einen Kontakt anlegen oder aktualisieren** und **einen Kontakt anlegen oder aktualisieren und gleichzeitig ein Event tracken**. Leg den Aktionstyp pro Trigger fest. 4. **Teste über den Aktivitäten-Feed in Klaviyo**: Geh in deinem Klaviyo-Konto zu Profiles. Löse ein Test-Event aus und prüfe, ob es ohne Duplikate im Aktivitäten-Feed des Profils erscheint. [Zur Server-Seite wechseln (Klaviyo)](https://taggrs.io/docs/server-side-tracking/config/klaviyo) **ActiveCampaign**: Nur Server-Container. Alle Daten kommen vom Server. Kein Browser-Tag. Warum: ActiveCampaign wird über die API aus dem Server-Container angebunden. Der Tag trackt Events, legt Kontakte an oder aktualisiert sie und kann beide Aktionen in einem Aufruf kombinieren. Richte es nur server-side ein, damit saubere Daten ohne Duplikate in deinem CRM landen. Konfigurationsschritte: 1. **Hol dir deine API-Zugangsdaten von ActiveCampaign**: Geh in deinem ActiveCampaign-Konto zu Settings → Developer. Dort findest du deine API URL und deinen API Key. 2. **Füge den ActiveCampaign-Tag im Server-Container hinzu**: Füge in deinem **Server-Container** den ActiveCampaign-Tag hinzu. Trag API URL und API Key in der Tag-Konfiguration ein. 3. **Wähle den Aktionstyp**: Wähle einen von drei Aktionstypen: **Track event**, **Create or update contact** oder **Create or update contact + track event**. Leg für jede Aktion den passenden Trigger fest. 4. **Ordne Event- und Kontaktparameter zu**: Leg fest, welche Data-Layer-Variablen zu den Event-Namen in ActiveCampaign, der E-Mail-Adresse des Kontakts und eventuellen benutzerdefinierten Feldern gehören. 5. **Teste in ActiveCampaign**: Löse ein Test-Event aus und prüfe, ob es in ActiveCampaign unter Contacts → Activity oder Reports → Event Tracking erscheint. [Zur Server-Seite wechseln (ActiveCampaign)](https://taggrs.io/docs/server-side-tracking/config/activecampaign) **Hotjar**: Nur Web-Container. Kein Server-side-Setup nötig. Warum: Hotjar zeichnet Sessions auf, erstellt Heatmaps und erfasst Nutzerverhalten direkt im Browser. Es beobachtet dafür Interaktionen im DOM (Mausbewegungen, Scrolltiefe und Klicks), die es nur im Browser gibt. Es gibt keine server-side Variante, und sie wird auch nicht gebraucht: Hotjar sendet keine Conversion-Signale an Werbeplattformen, also gibt es hier kein Signalverlust-Problem zu lösen. Lass es im Web-Container und lass deinen Server-Container unverändert. Konfigurationsschritte: 1. **Lass Hotjar im Web-Container**: Füge den Hotjar-Tracking-Code über einen benutzerdefinierten HTML-Tag in deinem **Web-Container** hinzu oder bau ihn direkt in den `` deiner Website ein. Beides ist richtig. 2. **Keine Änderungen am Server-Container nötig**: Füge Hotjar nicht zu deinem Server-Container hinzu. Es gibt keine API-Entsprechung, und server-side geroutet würde es gar nicht mehr funktionieren. **Microsoft Clarity**: Nur Web-Container. Kein Server-side-Setup nötig. Warum: Microsoft Clarity funktioniert wie Hotjar: Session Recordings und Heatmaps, direkt im Browser erfasst. Es beobachtet echte Interaktionen im DOM und kann außerhalb des Browsers nicht funktionieren. Es ist kostenlos, lässt sich nativ mit GA4 verbinden und wird oft neben Server-side-Setups genutzt, nur eben nicht als Teil davon. Konfigurationsschritte: 1. **Füge Clarity über den GTM-Web-Container hinzu**: Füge in deinem **Web-Container** einen benutzerdefinierten HTML-Tag mit dem Microsoft Clarity-Skript hinzu. Lass ihn auf allen Seiten feuern. 2. **Mit GA4 verbinden (optional)**: Verknüpfe im Clarity-Dashboard deine GA4-Property, um Session Recordings neben GA4-Segmenten zu sehen. Diese Verbindung richtest du in Clarity ein, in GTM ändert sich nichts. 3. **Keine Änderungen am Server-Container nötig**: Clarity hat keine Server-side-API. Lass es rein client-side. **LiveChat**: Nur Web-Container. Kein Server-side-Setup nötig. Warum: LiveChat fügt ein Chat-Widget in das DOM des Browsers ein und erkennt Seitenaktivität, Inaktivität und Scrollverhalten, um Gespräche im richtigen Moment zu starten. Dafür braucht es direkten Zugriff auf den Browser. Das Widget lässt sich nicht aus einem Server-Container laden oder steuern. Konfigurationsschritte: 1. **Füge LiveChat über den GTM-Web-Container hinzu**: Füge in deinem **Web-Container** einen benutzerdefinierten HTML-Tag mit dem LiveChat-Tracking-Snippet hinzu. Lass ihn auf allen Seiten feuern. 2. **Keine Änderungen am Server-Container nötig**: LiveChat hat keine Server-side-API für die Auslieferung des Widgets. Es ist bewusst ein reines Browser-Tool. **Zendesk Chat**: Nur Web-Container. Kein Server-side-Setup nötig. Warum: Zendesk Chat (Web Widget) zeigt eine Live-Chat-Oberfläche direkt im Browser. Es nutzt clientseitiges JavaScript, um das Widget anzuzeigen, Besucherverhalten zu erkennen und Gespräche in Echtzeit zu steuern. Wie alle Chat-Widgets dieser Art hängt es komplett vom Browser ab und lässt sich nicht über einen Server-Container leiten. Konfigurationsschritte: 1. **Füge das Zendesk Web Widget über den GTM-Web-Container hinzu**: Füge in deinem **Web-Container** einen benutzerdefinierten HTML-Tag mit dem Web Widget-Snippet aus deinem Zendesk-Konto hinzu (Admin Center → Channels → Messaging). Lass ihn auf allen Seiten feuern. 2. **Keine Änderungen am Server-Container nötig**: Das Zendesk Web Widget funktioniert nur im Browser. Eine Server-side-Konfiguration ist weder nötig noch möglich. **Typeform**: Nur Web-Container. Kein Server-side-Setup nötig. Warum: Eingebettete Formulare und Pop-ups von Typeform laufen komplett im Browser. Sie nutzen clientseitiges JavaScript, um das Formular anzuzeigen, auf Eingaben zu reagieren und die Anzeigelogik auszulösen (nach Scrollen, Zeit oder Exit Intent). Typeform bietet zwar eine Responses API, um Einsendungen von Server zu Server abzurufen, aber das Embed selbst funktioniert nur im Browser und gehört in den Web-Container. Konfigurationsschritte: 1. **Bette Typeform über den GTM-Web-Container ein**: Füge in deinem **Web-Container** einen benutzerdefinierten HTML-Tag mit dem Typeform-Embed-Snippet hinzu oder nutze die Standard-Einbettung mit `