Bing Server-Side Tracking: Microsoft Ads über deinen sGTM

Bing Server-Side Tracking ist kein eigenes Projekt. Wenn du für Google und Meta schon einen Server-Container betreibst, ist das Setup dasselbe: gleicher sGTM, gleicher Hoster, ein Microsoft-Tag mehr, das deine Conversions über die Conversions API an Microsoft Ads schickt. Ein Tag ist ein kleines Stück Code, das bei einer bestimmten Aktion Daten an ein Werkzeug wie Google Ads oder GA4 schickt. Zwei Dinge sind trotzdem anders als bei Google, und um die geht es in diesem Artikel: Microsoft gibt die Schnittstelle bisher nur kontoweise frei, und ohne saubere Deduplizierung zählst du jede Conversion doppelt.

1. Bing Server-Side Tracking: dieselbe Logik wie bei Google und Meta

Wie serverseitiges Tracking grundsätzlich funktioniert, warum Adblocker und Safaris ITP deine Daten löchrig machen und ab welchem Budget sich ein Tagging-Server lohnt, habe ich ausführlich in Serverseitiges Tracking mit GTM beschrieben. Die Kurzfassung: Der Browser schickt seine Events an deinen eigenen Server unter deiner Subdomain, und von dort verteilt ein zweiter GTM-Container, der Server-Container, die Daten an die Werbeplattformen.

Für Microsoft Ads ändert sich an diesem Prinzip nichts. Neu ist nur das Ziel am Ende der Leitung. Für Meta heißt die serverseitige Schnittstelle Conversions API, und Microsoft hat sein Gegenstück genauso genannt: Conversions API, kurz CAPI. Der Server schickt Conversion-Events direkt an Microsoft, aufgebaut nach demselben Event-Modell wie das UET-Tag im Browser.

UET bleibt, CAPI kommt dazu

Ein Missverständnis gleich vorweg: Die Conversions API ersetzt dein UET-Tag nicht. Microsoft empfiehlt in der eigenen Dokumentation ausdrücklich, CAPI wo immer möglich zusammen mit UET einzusetzen. Das UET-Tag erfasst, was im Browser passiert, die CAPI liefert zusätzlich die Events, die der Browser verliert oder gar nicht sehen kann.

Das heißt für dich:

• Dein bestehendes Browser-Setup bleibt stehen. Wie du das UET-Tag im GTM aufbaust, steht in Bing Conversion Tracking einrichten. Diese Anleitung ist weiterhin die Basis.
• Das Server-Tag ist eine zweite Leitung für dieselben Conversions, keine neue Messung.
• Weil dieselbe Conversion jetzt auf zwei Wegen ankommen kann, brauchst du eine gemeinsame Event-ID. Mehr dazu in Abschnitt zwei.

Was die Conversions API an Microsoft schickt

Damit Microsoft ein Server-Event einem Anzeigenklick zuordnen kann, braucht jedes Event mindestens eine Kennung. Die wichtigsten:

• msclkid: die Klick-ID, die Microsoft bei aktiviertem Auto-Tagging an deine Landingpage-URL hängt. Für die Zuordnung zum Klick ist sie die stärkste Kennung.
• anonymousId: die Besucher-ID, die das UET-Tag als Cookie speichert.
• Gehashte E-Mail und Telefonnummer: per SHA-256 verschlüsselt, nie im Klartext.
• Dazu, wo erlaubt: IP-Adresse und User-Agent des Besuchers.

Wenn dir das bekannt vorkommt: Bei Meta sind es fbclid und gehashte Nutzerdaten, bei Google die gclid und die erweiterten Conversions. Die Logik ist überall dieselbe.

Was Bing Server-Side Tracking nicht ist

Auch hier gilt, was beim serverseitigen Tracking immer gilt: Es ist kein Weg an der Einwilligung vorbei. Bei Microsoft gibt es dazu eine Falle, die du kennen solltest. Laut Dokumentation verarbeitet die Conversions API jedes Event standardmäßig so, als läge eine Einwilligung vor. Erst wenn du den Parameter adStorageConsent mit dem Wert D mitschickst, nutzt Microsoft das Event nicht für Werbezwecke. Für Websites in Deutschland heißt das: Das Server-Tag feuert nur nach Marketing-Einwilligung, genau wie dein UET-Tag im Browser. Die Trigger-Mechanik kennst du aus Consent Mode v2 einrichten.

2. Das Setup: derselbe Server-Container, ein Microsoft-Tag mehr

Hier kommt der Teil, der dir am meisten Arbeit spart. Du brauchst keinen neuen Server, keinen zweiten Container und keinen anderen Anbieter. Ob dein sGTM bei Stape, bei Taggrs oder auf deinem eigenen VPS läuft, spielt keine Rolle. Das Microsoft-Tag ist eine Vorlage aus der Vorlagengalerie des Server-Containers, du installierst es also im Container selbst und nicht beim Hoster.

Schritt 1: Prüfen, ob dein Konto die Conversions API hat

Bevor du im GTM irgendetwas anlegst, schau in Microsoft Ads nach, ob die Schnittstelle für dein Konto überhaupt verfügbar ist. Laut Microsoft-Dokumentation holst du dir das Token so:

1. Im Konto den Bereich UET öffnen und dein bestehendes UET-Tag über das Stift-Symbol bearbeiten.
2. Im Abschnitt „Edit UET tag” auf Save and next klicken.
3. Unter „Set up tagging” die Option Use Conversions API wählen.
4. Im Abschnitt „Conversions API” auf Copy Token klicken und das Token sicher ablegen.

Und hier ist der ehrliche Haken an „das Setup ist dasselbe”: Die Option fehlt in vielen Konten. Stand September 2026 berichtete ppc.land, dass Microsoft die Conversions API als Pilot behandelt, der pro Konto freigeschaltet wird. Selbst einschalten kannst du sie dann nicht, du musst über deinen Microsoft-Ansprechpartner oder den Microsoft-Ads-Support die Freischaltung für deine Kunden-ID anfragen. Plan das als ersten Schritt ein, nicht als letzten. Sonst steht der fertig konfigurierte Container da und hat nichts, wohin er senden darf.

Schritt 2: Das Microsoft-Tag in den Server-Container holen

Im Server-Container geht es dann so weiter, wie du es von der Meta Conversions API kennst:

1. Tags → Neu → Tag-Konfiguration → in der Vorlagengalerie nach Microsoft Ads UET Conversion API by Stape suchen und zum Arbeitsbereich hinzufügen.
2. Neues Tag mit dieser Vorlage anlegen.
3. UET Tag ID eintragen. Das ist dieselbe ID, die schon in deinem Browser-Tag steckt.
4. Das Token aus Schritt eins eintragen. Es gehört genau zu diesem UET-Tag, ein Token von einem anderen Tag funktioniert nicht.
5. Mindestens einen Nutzerdaten-Parameter mitgeben, etwa die gehashte E-Mail aus deinem Formular-Event.
6. Trigger: dasselbe Event, das in deinem Server-Container schon das Google-Ads- oder Meta-Tag auslöst.

Die Klick-ID und die Besucher-ID liest die Vorlage aus den Cookies, die das UET-Tag ohnehin setzt (_uetmsclkid und _uetvid), oder direkt aus dem msclkid-Parameter in der URL. Prüf in Microsoft Ads, ob Auto-Tagging aktiv ist. Ohne Auto-Tagging gibt es keine msclkid, und die Zuordnung zum Klick wird deutlich schwächer.

Schritt 3: Deduplizierung einrichten

Das ist die Stelle, an der die meisten Setups schiefgehen. Dein UET-Tag im Browser meldet eine Conversion, dein Server-Tag meldet dieselbe Conversion noch einmal. Ohne Abgleich zählt Microsoft beide, und dein Smart Bidding optimiert auf doppelt so viele Conversions, wie es wirklich gab.

Die Lösung ist eine gemeinsame Event-ID:

• Im Web-Container bekommt dein UET-Event-Tag einen Parameter event_id mit einer eindeutigen ID pro Conversion.
• Dieselbe ID geht mit dem Event an deinen Server-Container und vom Server-Tag als eventId an Microsoft.
• Tag-ID und Event-Name müssen auf beiden Wegen identisch sein. Laut Microsoft ist genau diese Kombination das, woran Duplikate erkannt werden.

Wenn du die Meta Conversions API schon dedupliziert hast, kennst du das Muster. Wie das bei Meta aussieht, steht in Meta Pixel einrichten. Bei Microsoft ist es eins zu eins dasselbe Prinzip, nur mit anderen Feldnamen.

Schritt 4: Testen

Drei Prüfungen, in dieser Reihenfolge:

1. Vorschau im Server-Container: Feuert das Microsoft-Tag auf dem richtigen Event, und antwortet Microsoft mit Status 200? Ein 401 heißt fast immer falsches Token oder falsche Tag-ID, ein 400 ein fehlerhaftes Feld im Event.
2. Gleiche Testconversion im Web-Container prüfen: Trägt das UET-Event dieselbe event_id wie das Server-Event?
3. In Microsoft Ads nach einer Weile das Conversion-Ziel ansehen. Steigt die Zahl nach einem Test um zwei statt um eins, greift die Deduplizierung nicht.

3. Wann sich Bing Server-Side Tracking lohnt

Die Budget-Logik aus dem allgemeinen Artikel gilt auch hier, mit einem Unterschied: Bei Microsoft geht es selten um die Frage „Server ja oder nein”, sondern um die Frage „Läuft der Server schon?“.

Wenn du schon einen sGTM betreibst

Dann ist die Rechnung einfach. Der Server läuft, die Kosten fallen ohnehin an, die Events kommen schon an. Für Microsoft legst du ein Tag an, richtest die Deduplizierung ein und testest. Das ist überschaubare Arbeit, und Microsofts automatische Gebote bekommen danach dieselbe bessere Datengrundlage wie Google und Meta. Wenn du Microsoft Ads mit conversion-basierter Gebotsstrategie fährst und die Freischaltung bekommst, würde ich das nicht liegen lassen.

Wenn du noch keinen Server hast

Dann ist Microsoft allein in den meisten Fällen kein Grund, einen aufzusetzen. Wenn Microsoft bei dir der kleinere Kanal neben Google und Meta ist, und das ist er in vielen Konten, entscheidet nicht Bing über den Server. Die Entscheidung für einen Tagging-Server triffst du deshalb anhand deines gesamten Werbebudgets, mit der Faustregel aus dem Artikel zum serverseitigen Tracking: unter rund 1.000 € im Monat erst Basis-Tracking, Anzeigen und Landingpage, darüber lohnt sich der Server. Microsoft hängst du dann mit an.

Leads aus dem CRM: ja, aber nur sieben Tage zurück

Die Conversions API nimmt nicht nur Website-Events an, sondern laut Microsoft auch CRM- und Offline-Events. Für Leadgenerierung ist das interessant, weil du einen qualifizierten Lead oder einen Abschluss als Conversion melden kannst statt nur das Formular. Ein Detail entscheidet hier aber über die Planung: Das Feld eventTime muss innerhalb der letzten sieben Tage liegen. Ein Abschluss, der drei Wochen nach dem Klick im CRM landet, passt über diesen Weg nicht mehr. Wie du lange Verkaufszyklen für Google sauber zurückspielst, steht in Offline-Conversion-Import für Leadgenerierung.

Wann (noch) nicht

• Dein UET-Tag im Browser misst nicht sauber oder deine Conversion-Ziele zählen nichts. Dann reparierst du zuerst die Basis, sonst schickst du über den Server nur dieselben falschen Daten zuverlässiger. Was auf deiner Website überhaupt feuert, zeigt dir der Tracking-Check.
• Microsoft hat die Conversions API für dein Konto nicht freigegeben. Dann bleibt das UET-Tag dein einziger Weg, und das ist kein Drama, solange es sauber misst.
• Niemand kümmert sich um die Deduplizierung. Ein Server-Tag ohne gemeinsame Event-ID verschlechtert deine Daten, statt sie zu verbessern.

FAQ

Brauche ich für Bing einen eigenen Tagging-Server?

Nein. Das Microsoft-Tag läuft in demselben Server-Container wie deine Google- und Meta-Tags, egal ob Stape, Taggrs oder ein eigener Server dahinter steht. Du legst ein zusätzliches Tag an, keinen zusätzlichen Server.

Ersetzt die Conversions API das UET-Tag?

Nein. Microsoft empfiehlt, beide zusammen zu nutzen. Das UET-Tag bleibt im Browser, die Conversions API schickt zusätzlich Events vom Server. Damit nichts doppelt zählt, tragen beide dieselbe Event-ID.

Warum finde ich in meinem UET-Tag die Option „Use Conversions API” nicht?

Wahrscheinlich ist die Schnittstelle für dein Konto noch nicht freigeschaltet. Stand September 2026 schaltet Microsoft die Conversions API laut Fachpresse pro Konto frei. Frag beim Microsoft-Ads-Support oder deinem Ansprechpartner nach und nenn dabei deine Kunden-ID.

Fazit

Bing Server-Side Tracking ist das Setup, das du für Google und Meta schon hast, mit einem Microsoft-Tag mehr. Der Unterschied liegt nicht in der Technik, sondern in der Freischaltung und in der Sorgfalt bei der Deduplizierung.

Die wichtigsten Punkte:

• Derselbe Server-Container, derselbe Hoster: Stape, Taggrs oder eigener VPS, das Microsoft-Tag kommt einfach dazu.
• Die Conversions API ergänzt das UET-Tag, sie ersetzt es nicht. Dein Browser-Setup bleibt die Basis.
• Erst die Freischaltung klären: Fehlt „Use Conversions API” im UET-Tag, frag Microsoft nach der Freigabe für deine Kunden-ID.
• Gemeinsame Event-ID in Web- und Server-Tag, sonst zählt jede Conversion doppelt.
• Das Server-Tag feuert nur nach Einwilligung. Microsoft behandelt Events ohne Consent-Parameter als eingewilligt.
• Ohne bestehenden sGTM ist Microsoft allein selten der Grund für einen Server. Mit sGTM ist es ein überschaubarer Zusatzschritt.