Microsoft Ads Conversions API: So misst du weiter, wenn Safari dein UET-Tag blockiert

Mit der Microsoft Ads Conversions API (CAPI) kannst du Conversion-Events direkt von deinem Server an Microsoft Advertising senden, statt über den Browser des Besuchers. Sie nutzt dasselbe „Universal Event Tracking“ (UET)-Ereignismodell wie das JavaScript-Tag, sodass die Messung auch dann weiterläuft, wenn Safari oder ein Werbeblocker verhindert, dass das Browser-Tag Microsoft erreicht. Microsoft betreibt dies als Pilotprojekt, daher muss es erst in deinem Konto aktiviert werden, bevor du loslegen kannst.
Microsoft Ads misst die meisten Websites nach wie vor mit einem Universal Event Tracking (UET)-Tag im Browser. Dieses Skript liest die Microsoft-Klick-ID (msclkid) aus, setzt Cookies und sendet Seitenaufrufe und Conversions vom Gerät des Besuchers an Microsoft. Lange Zeit war das eine sinnvolle Standardeinstellung. Browser haben Pixel von Drittanbietern toleriert, und der Aufruf an bat.bing.com kam in der Regel an.
Dieser Weg lässt sich nun leicht unterbrechen. In Safari 27, das sich in der Beta-Phase befindet und mit iOS 27 sowie macOS 27 ausgeliefert wird, kann die Verbindung zu den Ad-Servern von Microsoft unterbrochen werden, bevor Daten das Gerät verlassen. Werbeblocker weisen dieselbe Anfrage zurück. Durch Cookie-Beschränkungen läuft die Identität ab, die für Remarketing und Gebotsabgabe weiterhin genutzt wird. Die Kampagnen geben weiterhin Geld aus. Das Conversion-Signal, das das automatisierte Bidding trainieren sollte, kommt zu spät oder gar nicht.
Wenn Microsoft Ads schwächer abschneidet als Google Ads, liegt das eigentliche Problem manchmal beim Kanal. Oftmals hat es das UET-Tag gar nicht aus dem Browser herausgeschafft. Das ist eine Lücke in der Messinfrastruktur.
Was ist Universal Event Tracking (UET)?
Universal Event Tracking (UET) ist die Website-Tracking-Ebene von Microsoft Advertising. Ein Tag auf der Website erfasst, was Nutzer nach einem Anzeigenklick tun. Microsoft nutzt diese Daten dann für Konversionsziele, Remarketing und automatisierte Gebote.
Normalerweise wird JavaScript installiert. Der Browser lädt das Tag von Microsoft und kommuniziert dann mit den Endpunkten von Microsoft, vor allem mit bat.bing.com. Beim automatischen Tagging wird „msclkid“ an die Landing-URL angehängt. Das Tag liest diesen Wert, speichert ihn und fügt ihn späteren Events hinzu, sodass ein Kauf wieder mit dem Klick verknüpft werden kann.
Früher reichte die reine Browser-Messung aus, weil diese Anfragen vollständig ausgeführt werden konnten. Ziele für Ziel-URLs erfassten das Laden der Seiten. Benutzerdefinierte Events wurden beim Bezahlvorgang ausgelöst. Remarketing-Pools füllten sich, weil Microsoft wiederkehrende Besucher im Browser erkennen konnte. Die UET-Helper-Erweiterung kann in Chrome immer noch gut funktionieren, während Safari und blockierte Browser fast gar keine Daten senden.
Warum Safari und Werbeblocker das Bing-UET-Tag stören
UET ist ein clientseitiges Tag. Wenn das Skript nie geladen wird oder der Netzwerkaufruf nie abgeschlossen wird, wird der Besuch bei Microsoft gar nicht erfasst.
Safari 27 ist der entscheidende Fall. Der Tracking-Schutz von WebKit kann bat.bing.com auf Domain-Ebene und nach IP-Bereich blockieren – und zwar auf der Netzwerkebene, anstatt die Seite zu überprüfen. Das Skript kann im Google Tag Manager (GTM) liegen. Die Verbindung bricht trotzdem ab. Ein First-Party-Proxy, der lediglich den Ladeort des Skripts ändert, hilft nicht, da der Browser weiterhin die Ad-Server von Microsoft erreichen muss. Genau diese IPs kann Safari blockieren. Der Bericht zum Tracking-Schutz in Safari 27 behandelt diesen Mechanismus, einschließlich der Frage, warum Bing UET zusammen mit LinkedIn auf der Liste der exponierten Dienste steht.
Werbeblocker behandeln UET wie jedes andere Werbepixel. Filter nach dem Vorbild von EasyList blockieren das Skript oder die Anfrage an bat.bing.com, und strenge Tracking-Schutzmodi in Firefox und Edge tun dasselbe. Der Besucher kauft trotzdem. Microsoft Ads erhält jedoch nie die Kaufdaten. Wie sich Werbeblocker auf die Messung auswirken, ist die umfassendere Version dieser Geschichte.
Cookies sind ein langsameres Leck. Die „Intelligent Tracking Prevention“ (ITP) von Safari begrenzt die Gültigkeitsdauer vieler JavaScript-Cookies auf sieben Tage, bei manchen seitenübergreifenden Landing-Mustern sogar noch kürzer. Remarketing-Listen schrumpfen. Bei einer Conversion, die bei einem erneuten Besuch stattfindet, geht die Klick-ID verloren, die UET im Browser gespeichert hatte.
Der Link-Tracking-Schutz von Safari kann auch „msclkid“ im privaten Modus und bei Links, die über „Mail“ oder „Nachrichten“ geöffnet werden, entfernen – genauso wie er „gclid“ und „fbclid“ entfernt. Wenn die Klick-ID nie auf der Seite landet, kann das UET-Tag nichts zuordnen, selbst wenn der Netzwerkaufruf erfolgreich ist.
Was die Microsoft Ads Conversions API macht
Die Microsoft Ads Conversion API (CAPI), die auch als UET Conversion API dokumentiert ist, ist der Serverpfad für das gleiche UET-Ereignismodell. Anstatt dass der Browser Daten an Bing sendet, sendet dein Backend (oder ein GTM-Server-Container) einen POST-Request an:
Die Autorisierung erfolgt über ein Bearer-Token, das an diesen UET-Tag gebunden ist. Die aktuelle Anleitung von Microsoft ist die „Conversions API“ (CAPI). Server-side GTM wird dort als unterstützte Methode zum Senden der Events aufgeführt.
Für Websites sind zwei Arten von Events wichtig:
Events beim Laden einer Seite. Einer pro Seitenaufruf, einschließlich Routenwechsel bei Single-Page-Anwendungen (SPA). Sie enthalten die Seiten-URL, den Referrer, den Titel und eine „pageLoadId“. Ziele für Ziel-URLs und ein Großteil des Remarketing-Kontexts hängen davon ab. Diese zu überspringen und nur Käufe zu übermitteln, ist der häufigste Fehler bei der Einrichtung.
Benutzerdefinierte Events. Käufe, Leads, „In den Warenkorb“, Suchanfragen – was auch immer mit deinen Konversionszielen zusammenhängt. Hier findest du detailliertere Felder: Wert, Währung, Transaktions-ID, Produkt-IDs.
Bevor du mit dem Senden beginnst, müssen Konversionsziele vorhanden sein. CAPI übermittelt Ereignisse an Ziele, die du bereits in Microsoft Ads erstellt hast. Wenn kein Ziel mit diesem UET-Tag verknüpft ist und zu deinem „eventName“ passt, akzeptiert Microsoft deine Ereignisse mit einer 200-Antwort, und es wird keine Konversion in der Benutzeroberfläche angezeigt.
Eine Besonderheit, die du berücksichtigen solltest: Der Umsatz kann nicht an ein Seitenladeereignis gekoppelt werden. Wenn ein Ziel-URL-Ziel einen variablen Umsatz erfordert, ist die Lösung von Microsoft ein zweites benutzerdefiniertes Event, das nur den Umsatzwert und die dazugehörige pageLoadId enthält.
Benutzerdefinierte Ereignisse sollten die „pageLoadId“ der Seite wiederverwenden, auf der sie aufgetreten sind. Microsoft möchte, dass diese ID als universell eindeutiger Identifikator (UUID) der Version 4 vorliegt. Ohne diese ID ist die Konvertierung vom Seitenkontext abgekoppelt, den das JavaScript-Tag sonst automatisch gesendet hätte.
Microsoft empfiehlt, CAPI wann immer möglich zusammen mit UET zu verwenden. Der Grund: UET erfasst browserbasierte Aktivitäten und den Seitenkontext, während CAPI als Serverpfad für zusätzliche Events und Details dient, nachdem UET ausgelöst wurde. Derselbe Leitfaden behandelt CAPI als Alternative, wenn JavaScript nicht verwendet werden kann – was bei Safari und bei Werbeblockern der Fall ist. Das CAPI-Schema enthält bereits die Seiten-URL, den Referrer, den User-Agent, die IP-Adresse, die msclkid und die gehasht E-Mail-Adresse. Wenn der Server-Container diese Felder erhalten hat, werden sie im POST-Request mitgesendet. Dieser Serveraufruf ist es, der Microsoft auch dann noch erreicht, wenn bat.bing.com blockiert ist.
The events must be current. „eventTime“ is a UNIX time stamp in seconds, and Microsoft rejects time stamps that are older than seven days. Almost real-time delivery is the most sensible mode. Nightly data dumps are in conflict with bidding systems that seek conversions while the click is still fresh.
Hashwerte für E-Mail-Adressen und Telefonnummern (SHA-256, gemäß den Normalisierungsregeln von Microsoft) verbessern den Abgleich, wenn Cookies und Klick-IDs fehlen. Microsoft nennt das „erweiterte Konversionen“. Die Daten werden über dieselbe CAPI-Nutzlast übertragen.
| UET-JavaScript-Tag | Conversions-API | |
| Wo es läuft | Browser des Besuchers | Dein Server |
| Wird von Safari und Werbeblockern blockiert | Ja | Nein |
| Liest „msclkid“ automatisch aus | Ja | Du speicherst es und verschickst es |
| Seitenkontext (URL, Referrer, Titel) | Automatisch | Schick es einfach |
| Offline- und CRM-Events | Nein | Ja |
| Für jedes Konto verfügbar | Ja | Nur Pilot-Konten |
Der Zugriff erfolgt nicht automatisch
CAPI ist zwar umfassend dokumentiert, befindet sich aber noch in der Pilotphase. Microsoft richtet es pro Konto ein, und du kannst es nicht selbst aktivieren. Die Support-Antworten von Microsoft sind diesbezüglich ganz klar: Der Weg dorthin führt über deinen Kundenbetreuer oder den Microsoft Advertising-Support, damit die Kunden-ID (CID) registriert wird.
Sobald das Konto registriert ist, findest du das Token unter dem UET-Tag in der Microsoft Advertising-Benutzeroberfläche: Bearbeite das Tag, wähle „Conversions-API verwenden“ aus und kopiere das Token. Es gibt außerdem einen Aufruf der Campaign Management API (UetTagAuthKey/Query), der denselben Schlüsseltyp zurückgibt.
Vor der Registrierung taucht diese Option einfach gar nicht auf dem Bildschirm auf. Erst die GTM-Tags erstellen und dann nach einem leeren Token-Bildschirm suchen – das ist eine typische Methode, um eine Woche zu verschwenden.
Das Kennzeichen ist im Kundenkonto hinterlegt, dem das UET-Tag gehört. Ein Agenturmanager-Konto kann zwar vollständig eingerichtet aussehen, während die CID des Kunden noch keinen CAPI-Zugriff hat.
Was die Teams oft übersehen: die clientseitige ID-Synchronisierung
CAPI verlagert die Events serverseitig. Der Identitätsabgleich für das Remarketing wird dabei nicht vollständig mitverlagert.
Microsoft möchte nach wie vor ein Pixel zur clientseitigen ID-Synchronisierung, damit es deine Besucher-IDs den Microsoft-IDs zuordnen kann. In der Dokumentation steht, dass es im Browser ausgelöst werden soll, nicht vom Server aus, damit Microsoft zum Zeitpunkt der Synchronisierung den Browserkontext auslesen kann. Der dokumentierte Endpunkt sieht so aus:
Die Felder kann man leicht verwechseln.
- Red3 ist erforderlich. Das Format lautet „BACID_“ gefolgt von der Microsoft-Kunden-ID. Diese CID ist nicht die UET-Tag-ID. Ein Kundenkonto kann mehrere UET-Tags enthalten. Bei Konten mit mehr als einer CID sollte die primäre CID verwendet werden, sofern Microsoft nichts anderes angibt.
- VID (Besucher-ID) ist erforderlich. Eine anonyme Gast-ID, vorzugsweise eine UUID der Version 1, die sich von der pageLoadId unterscheidet, bei der Microsoft eine UUID der Version 4 verlangt. Der gleiche Wert muss als anonymousId an CAPI übermittelt werden. Wenn die Werte voneinander abweichen, kann Microsoft das Server-Ereignis nicht mit der Synchronisierung verknüpfen.
- Die UID ist optional. Eine anonymisierte Benutzer-ID eines angemeldeten Nutzers. Auf der CAPI-Seite entspricht diese der „externalId“.
Microsoft bezeichnet die ID-Synchronisierung als erforderlich für die Erstellung von Zielgruppen und das Remarketing, einschließlich des dynamischen Remarketings. Für die Konversionsqualität wird sie „dringend empfohlen“, insbesondere wenn die msclkid-ID oder die gehashten E-Mail-Adressen und Telefonnummern fehlen. Microsoft empfiehlt, dies nach Möglichkeit siteweit und mindestens einmal pro Benutzersitzung durchzuführen.
Das ist die Hybridlösung, die viele übersehen: ein Thin-Client-Beacon für die Identitätsfeststellung und Server-zu-Server-Events für die Konvertierungsdaten, die Browser immer wieder blockieren.
Die ID-Synchronisierung erfolgt nach wie vor über einen Browser-Aufruf an Microsoft. Safari und Werbeblocker können c.bing.com genauso blockieren wie bat.bing.com. Das ist frustrierend. Das ist auch der Grund, warum gehashtes E-Mail, gehashtes Telefonnummer und msclkid weiterhin zum Server-Event gehören. Das Pixel hilft, wenn es ausgelöst wird. CAPI muss sich weiterhin auf Identifikatoren stützen, die du selbst kontrollierst.
Warum msclkid immer noch wichtig ist
msclkid ist die Klick-ID von Microsoft. Wenn die automatische Tagging-Funktion aktiviert ist, fügt Microsoft sie nach einem Anzeigenklick an die Ziel-URL an. Früher hat das UET-JavaScript das für dich übernommen. Bei CAPI musst du das selbst erledigen.
Die Vorgaben von Microsoft sind eindeutig: Speichere die aktuellste msclkid pro Nutzer (First-Party-Cookie, lokaler Speicher oder Serverspeicher), überschreibe sie, sobald eine neue vorliegt, bewahre sie etwa 90 Tage lang auf und sende sie bei späteren UET-Events für diesen Nutzer mit. Das Format ist eine UUID. Die Besucher-ID allein ist ein schwacher Ersatz, wenn zuvor eine Klick-ID vorhanden war.
Und ja, das lohnt sich auch dann noch, wenn die gehashte E-Mail-Adresse bereits in der Payload enthalten ist. Das Abgleichen von Klick-IDs und optimierte Conversions schließen unterschiedliche Lücken.
Auch ohne msclkid können CAPI-Events weiterhin in der Pipeline von Microsoft landen. Die Zuordnung zu dem Klick, der den Besuch tatsächlich bezahlt hat, wird dadurch ungenauer. Das automatisierte Bidding trainiert dann auf der Grundlage eines unschärferen Graphen.
Safari kann „msclkid“ entfernen, bevor die Seite geladen wird – und zwar in denselben Fällen des Link-Tracking-Schutzes, von denen bereits die Klick-IDs von Google und Meta betroffen sind. Server-side GTM kann einen Abfrageparameter nicht wiederherstellen, der nie auf deiner Website aufgetaucht ist. Eine sinnvolle Vorgehensweise ist es, ihn beim ersten Aufruf zu speichern, sofern er vorhanden ist. Bei Sitzungen, bei denen er fehlt, dienen gehashtes E-Mail-Adressen und Telefonnummern als Backup, das Microsoft weiterhin abgleichen kann.
So richtest du Microsoft CAPI im server-side GTM ein
In den Microsoft-Dokumenten wird ein Tag-Manager oder ein server-side Tag-Manager als gültiger Übertragungsweg behandelt. Die Architektur entspricht derjenigen, die auch für Meta CAPI oder Google Ads-Server-Tags verwendet wird. Der Browser kommuniziert mit einer First-Party-Domain, die du kontrollierst. Der Server-Container sendet eine POST-Anfrage an capi.uet.microsoft.com. Safari bekommt diesen Microsoft-Aufruf nie mit.
Die Platzierung folgt der üblichen Aufteilung. Conversion-Events gehören in den Server-Container. Das ID-Sync-Pixel bleibt im Web-Container, da es clientseitig ausgeführt werden muss. Der server-side GTM-Plattform-Checker (sGTM) spiegelt die allgemeine Aufteilung zwischen Web- und Server-Platzierung wider. Bei Microsoft CAPI gilt dasselbe Muster: Server für den Event-Body, Web für das Identitäts-Beacon.
Übergeordneter Pfad:
- Token- und Tag-ID. Sobald CAPI im Konto angezeigt wird, kopiere die UET-Tag-ID und das Authentifizierungstoken. Speichere beides als GTM-Servervariablen. Die aktuellen Microsoft-Empfehlungen für Dual-Signal-Konfigurationen lauten, dieselbe UET-Tag-ID wiederzuverwenden und sowohl beim Browser-Event als auch beim CAPI-Event dieselbe „eventId“ und denselben „eventName“ zu senden, damit Microsoft Duplikate entfernen kann.
- Füge die Website-Events in den Server-Container ein. Web GTM liest die Datenschicht (Kauf, „generate_lead“ und die Seitenaufrufe, die als CAPI-Seitenaufrufe gelten sollen). Google Analytics 4 (GA4) ist der übliche Transportweg in den Server-Container. Ein Daten-Client kann auch Webhooks von einem Shop oder einem CRM empfangen. Achte darauf, dass die Namen und Umsatzfelder mit den Angaben übereinstimmen, die du bereits an Google und Meta sendest.
- Erstelle die `pageLoadId` und die `eventId` frühzeitig. Für jeden Seitenaufruf oder jeden SPA-Navigationsschritt wird eine neue UUID vergeben. Benutzerdefinierte Ereignisse auf dieser Seite verwenden diese wieder. Die „Conversion eventId“ muss konsistent sein: Es muss sich um denselben String sowohl beim UET-JavaScript-Event als auch beim CAPI-Event handeln, falls beide ausgelöst werden. Eine Bestell-ID plus ein Suffix ist in Ordnung, solange sie eindeutig bleibt.
- Sende den CAPI-POST vom Server-Container aus. Server GTM verfügt über ein integriertes HTTP-Request-Tag. Ein POST-Request an capi.uet.microsoft.com mit einem „Bearer“-Header und einem JSON-Body reicht aus, wenn du die Nutzdaten selbst zuordnest. Es gibt Vorlagen in der Template Gallery, falls du dir die Zuordnung der Felder von GA4 zu UET abnehmen lassen möchtest. Einige dieser Vorlagen können den Browser auch anweisen, das ID-Sync-Pixel auszulösen. Die Anfrage benötigt weiterhin die Tag-ID im Pfad, „pageLoad“ und/oder benutzerdefinierte Ereignisse, „userData“ mit mindestens einem Identifikator, „msclkid“, falls vorhanden, sowie „pageLoadId“, um benutzerdefinierte Ereignisse mit Seitenladungen zu verknüpfen. User-Agent, IP, gehashtes E-Mail-Adress, gehashtes Telefonnummer und „anonymousId“, die mit der VID übereinstimmt, helfen alle beim Abgleich.
- Behalte die ID-Synchronisierung im Web-Container bei. Bildpixel oder Ähnliches mit VID und Red3. Laut Microsofts Dokumentation muss es sich dabei um ein clientseitiges Pixel handeln, nicht um eine HTTP-Anfrage vom Server.
- Zugang nur mit Einwilligung. CAPI unterstützt „adStorageConsent“: G für „erteilt“, D für „verweigert“. Verweigerte Ereignisse werden nicht für die Attribution oder das Retargeting verwendet. Wenn du das Feld weglässt, behandelt Microsoft die Einwilligung als erteilt. Leite die Signale der Consent Management Platform (CMP) an den GTM-Server weiter und passe das Microsoft-Tag an dieselben ads-storage-Regeln an, die du bereits für Google und Meta verwendest.
- Teste es, bevor du die Gebote änderst. GTM-Vorschau im Web und auf dem Server. Ein 200er-Status von CAPI ist nicht dasselbe wie eine Konvertierung in der Benutzeroberfläche, und ein 200er-Status kann trotzdem Warnungen für Felder enthalten, die Microsoft entfernt hat. Überprüfe die Konvertierungs- und UET-Diagnosen von Microsoft und führe anschließend einen Testkauf oder ein Test-Lead mit einer bekannten msclkid durch. Beobachte auch das Batch-Verhalten: Standardmäßig führt ein ungültiges Ereignis zum Fehlschlagen der gesamten Anfrage. Setze daher „continueOnValidationError“, wenn du lieber möchtest, dass die gültigen Ereignisse verarbeitet und die fehlerhaften gemeldet werden. Vergleiche über einen längeren Zeitraum das Volumen im Browser mit dem auf dem Server, bevor das automatisierte Bidding beginnt, aus dem neuen Feed zu lernen.
Wo TAGGRS passt
Microsoft CAPI benötigt einen Server-GTM-Container auf einer eigenen Domain, eine an einem Ort zentralisierte Einwilligungslogik und einen sauberen Ereignisstrom, den du neben Google Ads, Meta und LinkedIn auch an Microsoft senden kannst.
TAGGRS hostet diesen Server-Container, ordnet deiner Domain eine Subdomain (oder einen Same-Origin-Pfad) zu und bietet dir eine zentrale Stelle, an der du Events verarbeiten kannst, bevor sie an Werbeplattformen weitergeleitet werden. Die Zuordnung von Microsoft-Token und Payload bleibt in GTM. Das Hosting, die First-Party-Auslieferung und die operative Ebene, die das server-side Tagging erst praktikabel macht, liegen bei TAGGRS.
Wenn GA4 bereits in einen TAGGRS-Server-Container fließt, ist Microsoft CAPI ein weiteres Ziel-Tag in diesem Datenstrom. Es handelt sich dabei nicht um einen zweiten Tracking-Stack. Das ID-Sync-Pixel bleibt in jedem Fall im Web-Container.
Erstelle ein kostenloses TAGGRS-Konto und stelle sicher, dass der Server-Container läuft, bevor du von Microsoft die CAPI-Zugangsdaten erhältst, oder buche eine Demo, wenn du dir die Einrichtung lieber erst einmal auf deiner eigenen Website ansehen möchtest.
Fazit
Das Browser-UET hat sich als unzuverlässiger Standard für die Messung von Microsoft Ads erwiesen. Safari 27 und Werbeblocker blockieren einen erheblichen Teil der UET-Aufrufe, bevor sie Microsoft erreichen, und durch Cookie-Beschränkungen läuft dann die Identität ab, auf der das Remarketing basiert. Die Conversions-API verlagert diese events auf einen Serverpfad, den du kontrollierst, wobei das UET-JavaScript-Tag weiterhin überall dort ausgeführt wird, wo es geladen wird.
Für die meisten Teams ist der Zugang das größere Hindernis als die Umsetzung. CAPI ist ein Pilotprojekt – bitte deinen Microsoft-Kundenbetreuer also, es für deine Kunden-ID zu aktivieren, und nutze die Wartezeit, um den Server-Container und den Ereignisstrom einzurichten. Wenn du bereits Meta CAPI nutzt, handelt es sich um denselben Arbeitsaufwand für einen Kanal, den du derzeit mit geringerer Genauigkeit misst, als du denkst.
FAQ
Brauche ich das UET-JavaScript-Tag noch?
Ja, überall dort, wo es noch geladen wird. Microsoft empfiehlt, CAPI zusammen mit UET zu nutzen, da das JavaScript-Tag die Browseraktivität und den Seitenkontext erfasst, die ein Server-Ereignis nicht automatisch übermittelt. Wenn beide dieselbe Konversion melden, verwende dieselbe eventId, denselben eventName und dieselbe UET-Tag-ID, damit Microsoft sie nur einmal zählt.
Microsoft beschreibt CAPI außerdem als Alternative für Fälle, in denen JavaScript nicht ausgeführt werden kann – wie bei Safari und Werbeblockern, die oben bereits angesprochen wurden. Eine vollständige CAPI-Einrichtung besteht laut ihrer Dokumentation aus zwei Teilen: den Server-zu-Server-Events und dem clientseitigen ID-Synchronisierungs-Pixel. Seiten-URL, Referrer, User-Agent, IP und msclkid sind alle Teil des CAPI-Schemas.
Ist Microsoft CAPI allgemein verfügbar?
Nein. Die Dokumentation ist öffentlich und vollständig, aber der Zugriff erfolgt noch im Rahmen eines Pilotprojekts, das Microsoft pro Konto gewährt. Wenn die Option „Use Conversions API“ auf dem UET-Tag fehlt, ist das der erwartete Zustand für ein Konto, das noch von niemandem registriert wurde. Bitte deinen Microsoft-Kundenbetreuer oder den Support, die CID hinzuzufügen.
Kann ich Käufe nur server-side senden?
Du kannst nur benutzerdefinierte Conversion-Events per POST senden. Die Zielvorgaben und Zielgruppen werden schlechter aussehen, als sie sollten. Plane Seitenladungen und benutzerdefinierte Events gemeinsam.
My events give 200 back, but no conversions are shown. Why?
In den meisten Fällen ist die Antwort das Konversionsziel. Überprüfe, ob in Microsoft Ads ein Ziel vorhanden ist, ob es mit derselben UET-Tag-ID verknüpft ist, an die du Daten übermittelst, und ob die Ereignisaktion genau mit deinem „eventName“ übereinstimmt. Überprüfe anschließend, ob die „eventTime“ innerhalb des Sieben-Tage-Fensters liegt und ob „msclkid“ oder eine gehashtete Kennung im Ereignis vorhanden ist.
Ersetzt das den Import von Offline-Conversions?
CAPI kann auch CRM-, Offline- und App-Events über denselben Endpunkt übertragen. Das ist eine andere Ereignisquelle als das Laden von Webseiten. Für Conversions, die erst Tage später im CRM erfasst werden, gibt es nach wie vor klassische Offline-Import-Workflows. Das „eventTime“-Datum der Website muss innerhalb der letzten sieben Tage liegen, daher schlägt die Validierung bei einem veralteten CRM-Dump fehl.
Wo passt Microsoft CAPI in GTM hinein?
Server-Container für den CAPI-POST. Web-Container für das ID-Sync-Pixel. Microsoft empfiehlt außerdem, das UET-JavaScript-Tag dort zu belassen, wo es geladen werden kann, und eine gemeinsame „eventId“ zu verwenden, falls beide Seiten dieselbe Conversion senden.
Was ist, wenn Safari auch das ID-Sync-Pixel blockiert?
Dann kann Microsoft deine Besucher-ID in diesen Sitzungen nicht mit seinen eigenen IDs verknüpfen, sodass dieser Traffic in den Remarketing-Listen nicht erfasst wird. Die Conversion kann trotzdem stattfinden, da der CAPI-POST von deinem Server und nicht von Safari gesendet wird. Füge diesem Event „msclkid“, „anonymousId“ und die gehashte E-Mail-Adresse oder Telefonnummer hinzu, damit Microsoft es weiterhin einem Klick oder einem bekannten Nutzer zuordnen kann.
Wie vermeide ich Doppelzählungen?
Eine „eventId“ für dieselbe Conversion bei UET-JavaScript und CAPI, dieselbe UET-Tag-ID, kompatibler „eventName“. Überprüfe, ob beide Tags diese ID tatsächlich senden. Die Zahlen sollten anhand von Bestellungen oder im CRM abgeglichen werden, nicht nur anhand der Conversion-Spalte in Microsoft Ads.

