# LinkedIn Server-side Tracking: So richten Sie die LinkedIn Conversions API ein Richten Sie die LinkedIn Conversions API neben dem Insight Tag ein: Deduplizierung, die Klick-ID li_fat_id, Ihre Match Rate und die passende Server-Route. Source: https://taggrs.io/de/linkedin-server-side-tracking/ Author: Małgorzata Poddębniak, Content-Marketerin · [LinkedIn](https://www.linkedin.com/in/malgorzatapoddebniak/) Updated: 2026-11-13 --- LinkedIn Server-side Tracking sendet Ihre Conversion-Events über die LinkedIn Conversions API von einem Server, den Sie kontrollieren, an LinkedIn. So verlassen Sie sich nicht nur auf das Insight Tag im Browser Ihrer Besucher. LinkedIn empfiehlt, beides zu nutzen: Das Insight Tag meldet weiter aus dem Browser, Ihr Server sendet dieselbe Conversion, und eine gemeinsame Event-ID zeigt LinkedIn, dass sie nur einmal gezählt werden soll. Die meisten LinkedIn-Setups scheitern an zwei Stellen. Die Klick-ID, die eine Conversion einer Anzeige zuordnet, ist verloren, bevor ein B2B-Lead konvertiert. Und die Browser- und die Server-Kopie einer Conversion werden nicht dedupliziert, sodass die Zahlen im Campaign Manager nicht mehr zu Ihrem CRM passen. Dieser Guide zeigt, wie Sie beide Quellen einrichten, wie die Deduplizierung bei LinkedIn funktioniert, welche Identifier Ihre Match Rate bestimmen und welche serverseitige Route zu LinkedIn zu Ihrem Setup passt. ## Was ist LinkedIn Server-side Tracking? Die Conversions API ist die Server-zu-Server-Verbindung von LinkedIn für Conversion-Events. Ihre Website oder Ihr CRM sendet jede Conversion zuerst an Ihren eigenen Server, und der leitet sie mit Identifiern wie einer gehashten E-Mail-Adresse und der Klick-ID von LinkedIn an LinkedIn weiter. LinkedIn ordnet das Event einem Mitglied zu und schreibt es der Kampagne zu, die es ausgelöst hat. Weil die Server-Kopie nicht von Cookies oder Skripten im Browser abhängt, haben Werbeblocker und Datenschutzeinstellungen des Browsers weniger Einfluss darauf. Sie erreicht auch Conversions, die nie in einem Browser stattfinden, etwa einen Lead, den Ihr Vertrieb Wochen später als qualifiziert markiert. Mehr zur B2B-Seite lesen Sie in [LinkedIn Conversions API für B2B](/de/linkedin-conversions-api-fur-b2b/). ## Die wichtigsten Vorteile ### Conversions aus Ihrem CRM Qualifizierte Leads, gebuchte Termine und abgeschlossene Deals entstehen in Ihrem CRM, nachdem die Website-Sitzung beendet ist. Über die Conversions API gelangen sie zu LinkedIn. Mit dem Optimierungsziel für qualifizierte Leads kann LinkedIn diese Conversions nutzen, um die Auslieferung auf Leads auszurichten, die Ihre Kriterien erfüllen, sofern Sie sie innerhalb von 30 Tagen teilen. ### Zuordnung, die einen langen Vertriebszyklus übersteht Das Insight Tag ordnet eine Conversion über ein Cookie im Browser einer Anzeige zu. Serverseitig senden Sie eine gehashte E-Mail-Adresse und die gespeicherte Klick-ID mit der Conversion, sodass LinkedIn auch einen Lead zuordnen kann, der Wochen nach dem ersten Klick konvertiert. ### Kontrolle darüber, was LinkedIn erhält Events laufen durch einen Server-Container, den Sie kontrollieren. Sie entscheiden, welche Felder weitergeleitet, welche gehasht und welche zurückgehalten werden. ### Bessere Zielgruppen und Optimierung LinkedIn optimiert und berichtet auf Basis der Conversions, die es zuordnen kann. Events aus der Conversions API, die einem Mitglied zugeordnet sind, können auch eine Retargeting-Zielgruppe bilden, die ab 300 Mitgliedern nutzbar wird, und als Quelle für eine Predictive Audience dienen. Mehr zugeordnete Conversions geben LinkedIn mehr, woraus es lernen kann. Server-side Tracking kann keine Interaktion wiederherstellen, die Ihre Website nie erfasst hat. Es verhindert aber, dass der Browser entscheidet, ob eine Conversion zählt. Lesen Sie, [wie Server-side Tracking Smart Bidding und automatisierte Kampagnen verbessert](/de/improve-smart-bidding-with-server-side-tracking/). **Reines Browser-Tracking und Server-side Tracking für LinkedIn** | | Nur Browser | Server-side mit TAGGRS | | -------------------------------------------- | ----------------------------------- | ------------------------------------------- | | Qualifizierte Leads und abgeschlossene Deals | ✗ Nicht erfasst | ✓ Aus Ihrem CRM gesendet | | Matching über einen langen Vertriebszyklus | ✗ Hängt von einem Browser-Cookie ab | ✓ Gehashte E-Mail und gespeicherte Klick-ID | | Browser-Einschränkungen und Werbeblocker | ✗ Nur, was der Browser durchlässt | ✓ Weniger betroffen | | Späte Conversions | ✗ Nicht erfasst | ✓ Bis zu 90 Tage danach | | Kontrolle darüber, was LinkedIn erhält | ✗ Begrenzt | ✓ Felder filtern, hashen oder zurückhalten | > „Mit clientseitigen Lösungen misst man an einem Tag 90 % und am nächsten nur noch 20 %. So kann man keine guten Daten senden und auch keine Maschine trainieren.“ > > Teun van Kleef, Lead Advertising & Data, Social Brothers ## Insight Tag, Conversions API oder beides? Wer die Conversions API nutzt, entfernt das Insight Tag nicht. LinkedIn empfiehlt, Conversions über beide zu senden, für ein vollständigeres Bild der Customer Journey. Die beiden Quellen sehen unterschiedliche Dinge. | Das Insight Tag sieht | Die Conversions API sieht | | ----------------------------------------------- | ----------------------------------------------------- | | Seitenaufrufe und Conversions auf Ihrer Website | Qualifizierte Leads und Deals aus Ihrem CRM | | Das li\_fat\_id-Cookie und den Browserkontext | Die gehashte E-Mail-Adresse aus dem Formular oder CRM | | Website-Besucher für Retargeting | Conversions nach dem Ende der Sitzung | | Nur das, was der Browser durchlässt | Conversions bis zu 90 Tage, nachdem sie stattfanden | Ein reines Server-Setup funktioniert, etwa wenn Sie nur CRM-Phasen senden möchten. Ihm fehlen aber der Browserkontext und die Website-Zielgruppen, die das Insight Tag liefert. Für die meisten Werbetreibenden lautet die Antwort: beide Quellen, dedupliziert. Schritt 4 unten erklärt, wie. Wählen Sie im folgenden Checker LinkedIn 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 `