OpenAI Ads Measurement - Anleitung und FAQ

Die Vermessung von Performance des Traffics aus ChatGPT Anzeigen ist nicht neu - sowohl das Pixel als auch die Conversions API existieren bereits eine ganze Weile. Seit die Bewerbung in ChatGPT allerdings in Deutschland und weiteren EU Ländern angekommen ist, steigt der Bedarf für entsprechendes Tagging. Dieser Post soll allerdings weniger eine Schritt-für-Schritt-Anleitung zum Einbau werden, als vielmehr auf die wesentlichen Aspekte und Stolperstellen hinweisen, die bei der Einrichtung ggf. bestehen. Denn obschon es "ein Pixel wie jedes andere" ist, gibt es ein paar Besonderheiten zu beachten.

Tracking für OpenAI per Pixel und CAPI

OpenAI bietet einen (auf den ersten Blick) relativ schlanken Trackingcode für die Vermessung im Browser sowie eine serverseitige Option zum Senden der gleichen Ereignisse an.

Üblich ist nach wie vor vor allem die Verwendung des "ChatGPT Ad Measurement Pixels". Nicht verwirren lassen: Wer vom "OpenAI Pixel" spricht, meint das Gleiche. Zur Messung muss dieser Code daher auf die Website. Statt ihn allerdings so zu verbauen, wie es in der Anleitung beschrieben ist und sich nicht um Zustimmung zu scheren, wird üblicherweise ein Tag Manager und / oder Consent Manager zum Ausspielen des Codes verwendet. Dazu weiter unten mehr im Abschnitt zur Implementierung.

Der ChatGPT Ad Measurement Pixel Code unter der Lupe

Der Tracking-Code wird im Ads-Konto  unter "Tools -> Conversions"  nach Anlage einer Datenquelle (es kann mehrere Pixel geben) zur Integration angezeigt.

Das Pixel nutzt eine zentrale Funktion oaiq() mit einer eigenen Command- bzw. Event-Queue. Das vom "Pixel-Code" geladene Tracking-Script / SDK arbeitet die per Kommando wie init angelegten Anweisungen und Ereignisse ab. Dabei gibt es zahlreiche Parameter, die das Verhalten steuern. Weiter unten bei der Implementierung wird davon noch mehr zu lesen sein. Grundsätzlich existieren nur dreieihalb Kommandos:

Das SDK wird vom implementierten Code geladen, lädt danach die Konfiguration anhand der Pixel ID nach und ist anschließend für alles zuständig, was a) automatisch gesammelt oder b) explizit an Events in der Warteschlange abgeladen wird. Die Übertragung erfolgt je nach Rahmenbedingungen per Request aus dem Browser mittels sendBeacon() oder fetch(); Service Worker sind ebenso im Einsatz wie bei vielen anderen modernen Tracking-Scripts.

Seitenaufrufe und... was genau?

Unter Supported Events findet sich eine Aufzählung dessen, was man neben einem page_viewed so alles senden kann.  Neben zwei Events (app_installed und app_opened), die nur für Apps relevant sind und vom Pixel nicht gesendet werden können, sind dies die typischen Kandidaten zur Vermessung von Erfolg bei der Leadgenerierung, Kontaktanfragen, Buchungen, Registrierungen und Verkäufen. Aus dem E-Commerce sind dazu neben dem Kaufabschluss z. B. der Start des Checkouts, das Hinzufügen zum Warenkorb und das Ansehen von Produkten vorgesehen; einschließlich Details zu den Produkten. Wie bei Meta & Co. kann man daher viele GA4-Standard-Events auf das OpenAI Format übertragen.

GA4 Event	OpenAI Ereignis
page_view	page_viewed
add_to_cart	items_added
sign_up	registration_completed
begin_checkout	checkout_started
generate_lead	lead_created
purchase	order_created
view_item	contents_viewed

Für alles andere gibt es Custom Events. Damit ist also theoretisch alles, was für GA4 oder andere Dienste derzeit bereits auf einer Website vermessen wird, ebensio als Signal an das OpenAI Ads Konto zu senden.

Interessant sind die weiteren Requests, die den Browser verlassen. Darunter sind "Telemetrie"-Anfragen, die diagnostische Informationen beinhalten. Darin kann man z. B. sehen, wenn Events verworfen wurden, weil z. B. Pflichtparameter gefehlt oder Formatanforderungen nicht erfüllt wurden. Ein solches Event ist also nicht "marketingrelevant"; fließt dennoch. Die Tracking Auditor Extension zeigt daher diese Requests ebenfalls an. Wenn alles okay war, sieht man hier beim dropped_event_count eine saubere Null - anderenfalls gibt es etwas zu korrigieren. Ein Beispiel eines solchen Payloads, der in einem "oai::diagnistic" Event den Browser verlässt:

{
"type": "diagnostic", "schema_version": 1,
"consent": true,
"is_first_visit_in_session": true,
"is_first_consent_grant_in_session": true,
"config": { "automatic_advanced_matching": "enabled" },
"dropped_event_count": 0,
"dropped_event_reason_counts": {},
"dropped_event_name_counts": {},
"dropped_event_phase_counts": {},
"dropped_event_details": [ { "reason": …, "code": …, "field": …, "count": … } ]
}

Conversions

Im Menüpunkt "Tools -> Conversions" wohnt nicht nur der Pixel Code selbst, den man nach der Anlage einer Datenquelle dort abrufen kann, sondern es können dort beliebige Ereignisse aus dem Standard oder als Custom Event gesendet zur Conversion erhoben werden. Auf Basis dieser Conversion(s) lassen sich dann Kampagnen steuern. Dazu werden Datenquelle und Eventname angegeben; ein Attributionsfenster - fertig. Kein "Once per Klick" o. Ä., aber es ist ein Anfang 😉

Damit funktioniert das Ganze ähnlich wie bei GA4: Wir senden beliebige Events und einige davon werden anhand des Namens zum besonderen Ereignis gemacht. Hier Conversion, dort "Schlüsselereignis".

Weiterhin findet sich hier schön denglisch gezeichneter "Ereignisstream", der vor allem dann sinnvoll und wichtig wird, wenn man die eigene Implementierung kontrollieren will; vergleichbar mit den Test-Events und der Deduplizierungsansicht im Meta Events Manager. Gut zu wissen: der ganze Bereich "Conversions" ist wahlweise komplett per API Call zu bedienen.

Hinsichtlich Transparenz ist hier übrigens noch Luft nach oben. Weder sieht man einem Event an, von welchem Host es hergekommen ist, noch sind URLs o. Ä. Dinge zu finden, die typischerweise in einer solchen Debug-Ansicht zu sehen sein sollten (und die den Browser nachweislich verlassen....).

Handling von Consent

Es existiert kein "Consent Mode" wie bei Google, Bing oder Clarity. Das bedeutet, dass die Implementierung sich an Zustimmung ausrichten sollte und eine Ausspielung nur dann stattfindet, wenn diese gegeben wurde. Unabhängig davon bietet der Code ein Kommando "consent" an, mit dem Zustimmung signalisiert oder verweigert werden kann (true oder false).

Ist keine Zustimmung vorhanden, sendet das Pixel keinerlei Daten; es wird nicht einmal die Konfiguration geladen. Events werden in der Warteschlange ggf. abgelegt, jedoch nicht verarbeitet. Mit einem debug Parameter bei der Initialisierung kann man sich das sogar in der Konsole des Browsers anzeigen lassen ("event queued"). Ohne Zustimmung hört der Code auf, auf der Seite nach Daten wie Mailadressen zu suchen, die zur Anreicherung von Events genutzt werden könnten.

Wird diese Zustimmung nachträglich auf "false" gesetzt, werden sogar Daten in der Queue aktiv verändert und Events fliegen raus. Nur ein Marker für die Session mit der Pixel ID bleibt erhalten; vorher ggf. dort abgelegte Userdaten verschwinden ebenso. Damit ließe sich theoretisch also eine sehr "sparsame" reine Erhebnung von Besuchszahlen ohne Nutzerinteraktionen oder Cookies etc. erheben, aber das ist alles reine Theorie. Das klingt nach viel Aufwand für etwas, was man im realen Leben (zumindest hier) eigentlich nicht nutzen kann. Stattdessen: "Consent" (Default ist hier ohnehin true) sollte ohnehin immer aktiv sein, das Tag allerdings eben gar nicht erst ausgespielt werden, wenn keine Zustimmung besteht. Ob man sich die Mühe macht, bei Änderung der Zustimmung dieses Kommando zu verwenden? Spätestens in einer Single Page Application kann das vielleicht sogar sinnvoll sein.

Eine gewisse Herausforderung ist es in diesem Zusammenhang, den Dienst sauber in der eigenen CMP einzutragen. Dabei stellt sich z. B. die Frage, welche Cookies hier im Spiel sind und welchem Zweck sie dienen. Das hier habe ich in den bisher bedienten Installationen dazu angegeben, denn das sind die First-Party Cookies & Co., die im Zusammenhang mit dem Pixel eine Rolle spielen:

Name	Speicherart	Inhalt	Lebensdauer
__obref	Cookie	v4 UUID Geräte-Referenz (obref in Requests)	1 Jahr
__oppref	Cookie	Ad Klick-ID aus oppref URL Parameter	60 Tage
__oaiq_consent	Cookie	true/false	30 Tage
oaiq_consent	localStorage	true/false	---

Speziell die letzten beiden wären allerdings nur vorhanden, wenn ein Tag mit per Kommando signalisierter Ablehnung ohne Zustimmung hantert, was die ganze Nummer schon allein disqualifiziert. Daher sollte es ausreichend sein, die ersten beiden Cookies in der CMP zu erfassen.

Nutzerdaten für verbesserte Attribution

Wie alle anderen will auch OpenAI Mailadressen, Telefonnummern, Namen und Anschriften zur Verbesserung der Zuordnung von Ereignissen und Conversions zu Klicks haben, selbst wenn es die Click ID nicht bis zur Landingpage geschafft hat. Neben dem schon angesprochenen automatischen Einsammeln solcher Daten aus dem DOM der Seiten und Nutzereingaben können diese Angaben explizit gesendet werden. Bemerkenswert ist dabei, dass das OpenAI Pixel hier (anders als alle anderen Dienste) explizit unterscheidet, aus welcher Quelle die Informationen stammen. Möglich sind:

• Explizit bei der Initialisierung angegebene Daten ("in")
• Aus Eingaben in Formularfelder übernommene Daten ("fm")
• In einer JS Variable gefunden ("js")
• Aus dem DOM gescraped ("ht")

Dabei werden teilweise Hashwerte (SHA-256, lowercase hex, 64 Zeichen) verwendet oder vollständige Daten (wie Angaben zur Adresse) im Klartext gesendet. Was als Klartext rein kommt, wird vor dem Versand vom SDK in Hashwerte verwandelt. Gut zu wissen: Wer einen zip_code angibt, wird diesen als postal_code verarbeitet bekommen. Es gibt also eine gewisse Toleranz gegenüber unterschiedlichen typischen Key-Namen bei unterschiedlichen Diensten.

Wer PII selbst übergibt, muss sich dabei nicht auf das Hashing des Pixels verlassen. Wie bei z. B. Google oder Meta können hier bereits Hashwerte in entsprechenden Schlüsseln wie email_sha256 übergeben werden. Die Normalisierungsregeln sind die üblichen: Kleinschreibung (bis auf externe IDs), Leerzeichen entfernen (z. B. bei der Telefonnummer) dann nach dem o. a. Muster per SHA256 in einen Hash verwandeln. Telefon wie bei Meta ohne führendes "+". In der oben verlinkten Anleitung finden sich Beispiele, so dass ich diese hier ausspare. Darüber hiais gelten die Hinweise, die ich in einem eigenen Post zur Nützlichkeit von Adressdaten zum Abgleich von Conversions zusammengetragen habe.

Ansonsten habe ich durchaus beobachtet, dass bei Ausfüllen von Login-Dialogen oder Formularen die Mailadresse über die automatische Sammlung gefunden und versendet wurde. Über Mailadressen hinaus habe ich es allerdings nicht geschafft, wirklich einen Namen oder Adressdaten auf einem der automatischen Wege den Browser verlassen zu sehen. Das ist vermutlich also ähnlich wie beim Google-Tag, das lieber weniger sendet als unnötige Hashwerte zum Abgleich daheim einzureichen.

OpenAI Pixel implementieren

Wie oben bereits angesprochen existiert eine Anleitung zur direkten Implementierung in eine Website - wenig praxistauglich (oder zumindest mit Aufwand verbunden, wenn es um Zustimmung geht). Gehen wir deshalb davon aus, dass es einen Tag Manager gibt. Wer im Google Tag Manager z. B. nach einer entsprechenden Vorlage sucht, findet das "offizielle" Template OpenAI Ads Measurement Pixel von OpenAI selbst. Darin ist alles verbaut, was zur Definition von Events inkl. Consent, Event ID, Wert, Währung und "Contents" erforderlich ist. Speziell der letzte Punkt bedeuet bei Verwendung dieses Templates allerdings, dass man für jedes E-Commerce Event ein eigenes Tag verbauen und die items eines typischen GA4 E-Commerce dataLayer Pushes auslesen, konvertieren und in der dazu vorgesehenen Tabelle manuell definiert. Das ist je nach Setup aufwändig - genauso, wie es bei vielen anderen Diensten wie Meta, TikTok, Pinterest etc. der Fall ist.

Und genau wie bei vielen anderen Diensten ist das Template OpenAI Ads Pixel by Stape eine gute Wahl, die ich bevorzugt verwende. Selbst dann, wenn der Dienstanbieter ein eigenes Tenplate wie in diesem Fall bereitstellt. Der Grund ist die sehr gut durchdachte Struktur des Codes: Er unterstützt die Verwendung einer GA4 Datenschicht (nicht nur, aber vor allem beim E-Commerce) ideal. Im einfachsten Fall kommt man mit zwei oder drei Tags aus, um ein komplettes Tagging aufzubauen.

Ein Grund ist die automatische Konvertierung von Ereignisnamen und Parametern in den Vorlagen von Stape. Aus typischen Datenschicht-Ereignissen wird so ohne manuelle Konvertierung von Produktdaten etc. ein für OpenAI passendes Ereignis erzeugt und versendet. Weiterhin sind Parameter bei Bedarf individuell zu überschreiben und das (inzwischen für alle Tracking Scripts zum Standard gehörende) automatische Sammeln von Nutzerdaten für verbesserte Attribution von Conversions (wie den "Enhanced Conversions" bei Google Ads) direkt im Tag gesteuert werden. Das ist ein wichtiger Punkt, denn damit kann der Datenhunger des Tags an den Umfang angepasst werden, der mit der datenschutzbeauftragten Person abgestimmt und auf der Website (in der CMP und den Datenschutzhinweisen) dokumentiert ist.

Die folgenden Tags und Konfigurationen sind i. d. R. sinnvoll:

Seitenaufrufe

Davon ausgehend, dass alles nur bei Zustimmung feuern soll, kann eine automatische Konvertierung von "gtm.js" (dem "Seitenaufruf" im GTM nur bedingt verwendet werden. Ich feuere daher i. d. R. ein separates Tag für den Seitenaufruf beim entsprechenden Consent Ereignis der CMP wie consent_status von Usercentrics o. A. Ein blockierender Trigger kann das Feuern verhindern, wenn keine Zustimmung besteht. Also kurz gesagt: Standard.

In diesem Fall wird der Ereignisnamen wie dargestellt fest als page_viewed vorgegeben. Advanced Matching ist hier aktiviert - das ist freilich nicht unbedingt immer "richtig". Vorsicht ist mit dem angebotenen Event User Data Enhancement angebracht. Wer diese Option aktiviert, speichert solche gefundenen Daten im Browser, so dass diese Daten auch bei Folgeereignissen oder bei einem neuen Seitenaufruf etc. verwendet werden können, ohne dass erneut eine Eingabe erforderlich ist. Für das Matching prima, aber ein Datenschutzthema, dass Transparenz und Abstimmung erfordert und zudem die dazu verwendeten localStorage Keys den o. a. Persistenzpunkten für die CMP hinzugefügt werden müssen.

Generell ist es wichtig zu wissen, dass ein einmal beim Aufruf eingeschaltetes Matching gefundene Daten beibehält und auch bei Folgeevents auf der gleichen Seite weiter verwendet, wenn diese z. B. in einem Batch den Browser verlassen. Gibt man explizit - z. B. über eine Variable für vom Nutzer bereitgestellte Daten im Tag im Bereich User Data des Tags an und wird dieses nach Ausfüllen eines Formulars befüllt, dessen Absenden wiederum ein OpenAI Tag auslöst, können Nutzerdaten sowohl aus dem explizit angegebenen Objekt kommen ("init") und zudem auch aus dem Formzlar ("form") ausgelesen werden. Die Enhanced Conversions Data Validator Chrome Extension macht das ab Version 2.9.0 auch für OpenAI Requests besonders gut sicht- und validierbar.

Der o. a. Tracking Auditor als allgemeinere Erweiterung zum Debugging von Tracking-Setups zeigt diese Unterscheidung ebenso an, ohne die dort gesendeten gehashten Daten allerdings im Detail validierbar wären.

Wichtig: Selbst wenn man für E-Commerce auf eine Konvertierung setzen kann (siehe unten), ist das explizite Setzen des Ereignisnamens beim Seitenaufruf m. E. die einzige Wahl. Es kann nicht funktionieren, wenn man hier die für E-Commerce hilfreiche Setup Methode Inherit from DataLayer verwendet, jedoch der Ereignisname dem Consent-Push der CMP entspricht. Ein "consent_status" benanntes Ereignis als Custom Event an OpenAI zu senden ergibt nun mal wenig Sinn.

Leads und andere Events

Weil Kampagnen Signale brauchen, die als Conversion verwendet werden können, sind reine Seitenaufrufe keine Lösung. Die wichtigste Aufgabe des Seitenaufruf-Tags ist - und auch das ist nicht anders als bei vielen anderen Marketing Tags - vor allem das Speichern von Klick-IDs aus der URL in einem Cookie (dem o. a. __oppref Cookie im Fall von OpenAI).

Wenn es daher um einen Lead, eine Registrierung oder andere Dinge geht, sind hier ggf. weitere Tags erforderlich. Um beim Lead zu bleiben: selten hat eine Website einen dataLayer Push, der tatsächlich generate_lead heißt. Üblicher sind da schon login oder sign_up; letzteres wird vom Stape Pixel bei aktiver "Übersetzung" der dataLayer Ereignisse wie beim E-Commerce (siehe unten) z. B. zu einem registration_completed für OpenAI.

Wer also einen Lead z. B. anhand einer Danke-Seite vermisst, kann genau wie beim Seitenaufruf vorgehen und den Ereignisnamen lead_created mittels der Option Override bei der Methode für den Ereignisnamen im Tag selbst angeben. Alles andere wie appointment_scheduled, subscription_created oder trial_started behandelt man vermutlich ebenso. Entweder damit, dass alles wiederum mit einem Tag verarbeitet wird, aber der Ereignisname hier über eine Variable gesteuert wird - oder mit separaten Tags und explizit definierten Ereignisnamen.

E-Commerce

Besonders praktisch wird das Stape Template wie schon angesprochen bei Standard E-Commerce Ereignissen. Aus

Aus view_item wird so ein contents_viewed, add_to_cart wird zu items_added, begin_checkout zu checkout_started und der purchase wird als order_created an OpenAI gesendet - alles mit dem gleichen Tag.

In den meisten Fällen wird es dabei sinnvoll sein, die zweite hier angehakte Option zur Reduktion auf den aktuellen dataLayer Push zu verwenden. Nur in seltenen Fällen gelangen die Inhalte eines E-Commerce Events wie z. B. die Warenkorbdaten nicht gemeinsam mit dem Ereignisnamen selbst im dataLayer. Falls doch, kann das Ausschalten dieser Option ggf. helfen.

Damit ist das Tagging mittels des Pixels denkbar simpel und kann oft mit bereits vorhandenen Triggern bedient werden, denn selten fängt man erst jetzt damit an, seine Website mit Tagging zu versehen. Soll dabei nicht nur auf den Browser gesetzt werden, sondern zusätzlich ein Datenfluss vom Server hinzukommen, ist lediglich daran zu denken, den GA4-Requests für den Server und den OpenAI Pixel Tags jeweils die gleiche "Event ID" zuzuweisen. Das Stape-Tag hat dazu im Bereich Server Side Tracking Settings ein Eingabefeld; GA4 Ereignissen werden diese als Ereignisparameter event_id zugewiesen. Ich verwende dazu (wen wundert es) meine eigene Variablenvorlage im Tag Manager.

OpenAI Conversions API

Die API zum Füttern von OpenAI Ads vom Server aus arbeitet wie die meisten CAPIs: Ein Acess-Token wird generiert und dann werden die Ereignisse damit versehen an einen Endpunkt gesendet. Ebenso nicht neu: Hybrirdmodus ist erwünscht, Deduplizierung erfolgt über die o. a. Event ID (und den Namen): DIe API sendet eine id und das Pixel eine event_id. Das erste Event mit gleichem Namen und gleichen ID Infos wird verwendet; unabhängig von der Quelle; das zweite verworfen. Das ist etwas anders als z. B, bei Meta oder anderen Diensten, wo oft Infos aus mehreren Events gemerged werden, das parameterreichere verwendet oder grundsätzlich Browser oder CAPI bevorzugt werden, wenn beide Varianten es zum Empfänger geschafft haben.

Da eine Implementierung direkt im CMS eher ungewöhnlich ist (aber sicher in WordPress Lösungen wie Pixel Your Site u. a. verfügbar sein wird), ist der typische Weg zur Umsetzung ein entsprechendes CAPI Tag in einem server-side GTM. Unabhängig vom Weg ist ein API Key erforderlich, wenn Daten per CAPI eingesendet werden sollen. Die Anlage eines solchen Keys findet sich im Ads Manager unter Einstellungen -> Allgemeine Einstellungen -> API-Schlüssel. Achtung: Ein erstellter Schlüssel kann kopiert oder heruntergeladen werden, aber nicht mehr eingesehen, nachdem der anzeigende Dialog nach der Neuanlage geschlossen wurde. Wie alle Konstanten sollte dieser Schlüssel als Variable im ssGTM Container abgelegt werden, um ihn im Tag verwenden zu können.

OpenAI CAPI per server-side GTM

Wie schon im Browser, kann ebenfalls im server-side GTM auf eine Vorlage von Stape zurückgegriffen werden. Anders als im Client ist hier die Konvertierung eingehender GA4-Events nicht mehr an passende Bezeichnungen im dataLayer angewiesen. Wenn ein generate_lead Event im GA4 Format am Server ankommt, kann das Stape Tag dieses ebenso wie im Browser via Megode "Inherit from client" automatisch konvertieren. Auf diese Weise ist in vielen Setups auch für OpenAI ein einziges Tag ausreichend, um Seitenaufrufe, Standard-Events und E-Commerce zu managen.

Sollte es erforderlich sein, können in Sonderfällen ansonsten separate Tags genutzt und der Ereignisname explizit angegeben werden. Sinnvoller ist in solchen Fällen allerdings vermutlich die Verwendung von Transformationen im ssGTM, so dass wieder die Konvertierung genutzt werden kann. Die in der oben bereits gezeigten eingehenden GA4 Ereignisse werden so zu ihren Pendants für OpenAI.

Bzgl. der Einstellungen zu Cookies ist es je nach Setup sinnvoll bzw. sogar erforderlich, die entsprechenden Optionen zu aktivieren: Ist der server-side GTM tatsächlich im echten First-Party-Betrieb (bzgl. der IP des Servers vs. des Website-Servers), kann so die Lebensdauer verlängert werden. Zudem wäre ein Setup für OpenAI ausschließlich vom Server aus ansonsten wirkungslos, weil die erforderlichen Cookies sonst nie entstehen und keine Attrbution möglich ist, wenn man im Browser auf das Pixel verzichtet. Was - wie bei Meta und anderen - durchaus eine Option ist.

Beim Auslösen dieses Tags ist es also wichtig, nur solche Events zu senden, die entweder über diese Tabelle konvertiert werden oder als Custom Event unter ihrem eingehenden Namen unverändert rausgesendet werden sollen. Es ergibt demnach keinen Sinn, das Tag bei allen eingehenden GA4-Events zu triggern und so jedes scroll, user_engagement, click etc. an OpenAI zu senden. Zudem sollte wie beim Browser die Zustimmung beachtet werden - logisch.

Empfehlungen und Fazit

Wer Geld bei OpenAI ausgibt für Werbung in ChatGPT, sollte wie bei allen anderen Werbeplattformen nicht auf das Tagging verzichten. Rahmenbedingungen:

• Nur bei Zustimmung feuern, es gibt keinen Consent Mode
• Nutzerdaten wie E-Mail-Adressen bewusst außen vor lassen und die Optionen dazu entsprechend einstellen oder aktiv lassen und ggf. explizit Userdaten im Tag setzen und senden; z. B. beim Kaufabschluss. Das allein wird die Attribution nicht retten: Klick IDs sind nach wie vor im Spiel und erforderlich
• Tagging im Browser per Pixel, vom Server per CAPI oder gar beides parallel möglich

Als Minimum ist die Klick ID aus einem Cookie o. Ä. erforderlich, um diese Referenz bei einer Conversion mit zu senden. Ohne E-Commerce kann es also theoretisch reichen, sich selbst um die Klick ID zu kümmern und nur eine Conversion wie einen Lead mit einem einmaligen Request rauszusenden. Das geht im Zweifelsfall mittels CAPI Request ausschließlich vom Server aus. Zwar wird der Hybridbetrieb gern gesehen - da speziell bei OpenAI (derzeit) keine Zielgruppenbildung oder andere Argumente für ein Pixel im Browser sprechen, ist eine rein serverseitige Anbindung gleichwertig und würde den Browser tatsächlich entlasten.

Wo kein Server verfügbar ist, ist die Implementierung des Pixels in den meisten Fällen eine überschaubare Aufgabe. Gern unterstütze ich freilich dabei, diese Aufgabe sauber und robust umzusetzen... wie bei jedem anderen Marketing-Pixel auch 😉