Pomiar konwersji w ChatGPT Ads opiera się na dwóch źródłach: pikselu działającym w przeglądarce i Conversions API wysyłającym zdarzenia z serwera. Dokumentacja OpenAI odpowiada wprost, które jest pewniejsze — Conversions API jest źródłem bardziej wiarygodnym niż sam piksel.
W tym kanale pomiar nie jest warstwą raportową, którą warto odkładać na później. Kampania optymalizowana pod konwersje wymaga skonfigurowanego źródła i wybranego standardowego zdarzenia. Bez wiarygodnych danych system nie ma podstaw do optymalizacji, a zespół nie potrafi ocenić, czy kliknięcia prowadzą do wartościowych działań.
Ten wpis opisuje pełną konfigurację: 12 standardowych zdarzeń i mechanizm zdarzenia własnego, deduplikację przeglądarki i serwera, identyfikatory atrybucyjne, normalizację danych, przekazywanie kwot oraz obsługę zgody i CSP.
W skrócie
- Dwa źródła: piksel w przeglądarce i Conversions API z serwera. Dokumentacja wskazuje Conversions API jako źródło bardziej wiarygodne; sensowne jest wdrożenie obu i połączenie ich deduplikacją.
- Dostępnych jest 12 standardowych nazw zdarzeń oraz typ
custom, aapp_installediapp_openedprzechodzą wyłącznie przez Conversions API. Zdarzenie własne nie może być celem oCPC. - Deduplikacja działa na trzech elementach: identyfikatorze piksela, nazwie zdarzenia i identyfikatorze zdarzenia. OpenAI zapisuje pierwsze zdarzenie o danym kluczu i pomija późniejsze duplikaty.
- Identyfikatory użytkownika idą jako skróty SHA-256, po normalizacji, jako 64-znakowy ciąg szesnastkowy małymi literami. Dane geograficzne przekazuje się jako tekst, bez hashowania.
- Numer telefonu hashuje się bez plusa i bez zer wiodących — z prefiksem kraju, w postaci 8–15 cyfr.
- Kwoty przekazuje się jako liczby całkowite w jednostce podrzędnej waluty. Dla złotego
12999znaczy 129,99 zł, a kwota wymaga podania waluty. - Zgoda na pomiar jest domyślnie włączona. Piksel przyjmuje zgodę jako
true, dopóki nie zostanie ustawiona nafalse; zdarzenia zablokowane nie są później odtwarzane. - Restrykcyjna polityka Content Security Policy może zablokować część pomiaru. Dokumentacja wymienia cztery źródła, które trzeba połączyć z istniejącą polityką, bez osłabiania jej przez dodanie
unsafe-inline. - Konwersje po wyświetleniu raportowane są osobno i nie wchodzą do metryki
Conversions, która pozostaje sumą konwersji po kliknięciu. - Piksel sam przechwytuje
oppref, ale Conversions API nie robi tego automatycznie. Przy integracji hybrydowej warto także przekazać niezmienionyobrefz własnego pliku cookie, zgodnie z wymaganiami dotyczącymi zgody.
Dwa źródła pomiaru
Piksel to biblioteka działająca w przeglądarce. Skrypt trafia do sekcji <head> każdej strony, na której mają być mierzone konwersje, i to możliwie wysoko — inaczej wczesne konwersje przepadają, gdy reszta strony jeszcze się ładuje. Piksel inicjuje się identyfikatorem, a konwersję zgłasza wywołanie oaiq("measure", ...).
Conversions API przyjmuje zdarzenia wyłącznie z serwera. Identyfikator piksela i klucz interfejsu generuje się w zakładce konwersji panelu. Interfejs przyjmuje paczki do 1 000 zdarzeń, przy czym błąd jednego zdarzenia unieważnia całą paczkę — warto to uwzględnić w obsłudze błędów, zamiast wysyłać maksymalne paczki i zakładać, że przejdą.
Zdarzenia z cyklu życia aplikacji, czyli app_installed i app_opened, przechodzą tylko przez Conversions API, z parametrem action_source ustawionym na mobile_app. Piksel ich nie obsługuje. Natywne biblioteki mobilne nie są na razie wspierane.
Warto zapamiętać jeszcze jedno ograniczenie techniczne: znacznik czasu zdarzenia musi mieścić się w ostatnich 7 dniach i nie może wyprzedzać teraźniejszości o więcej niż 10 minut. Zaległe zdarzenia wysyłane po tygodniu nie zostaną przyjęte.
Dwanaście zdarzeń standardowych i zdarzenie własne
| Zdarzenie | Kształt danych | Do czego służy |
|---|---|---|
page_viewed |
contents |
wejście na istotną stronę |
contents_viewed |
contents |
wyświetlenie produktu, oferty lub treści |
items_added |
contents |
dodanie pozycji do koszyka lub zestawu |
checkout_started |
contents |
rozpoczęcie zamawiania |
order_created |
contents |
zakończony zakup |
lead_created |
customer_action |
wysłanie formularza albo prośba o kontakt |
appointment_scheduled |
customer_action |
rezerwacja spotkania, prezentacji lub konsultacji |
registration_completed |
customer_action |
zakończona rejestracja konta lub zapis |
app_installed |
customer_action |
instalacja aplikacji (tylko Conversions API) |
app_opened |
customer_action |
uruchomienie aplikacji (tylko Conversions API) |
trial_started |
plan_enrollment |
start okresu próbnego |
subscription_created |
plan_enrollment |
start płatnej subskrypcji |
custom |
custom |
zdarzenie własne poza taksonomią standardową |
Dwa rozróżnienia warto trzymać w głowie. page_viewed dotyczy wczytania strony, a contents_viewed obejrzenia konkretnego produktu albo elementu treści, także wtedy, gdy dzieje się to już po wczytaniu strony. Nazwy zdarzeń własnych mają od 1 do 64 znaków.
Zdarzenie własne ma jedno poważne ograniczenie po stronie kampanii: nie może być celem optymalizacji pod konwersje. Cel oCPC przyjmuje wyłącznie zdarzenie standardowe.
Deduplikacja przeglądarki i serwera
Bez deduplikacji ta sama konwersja policzy się dwa razy — raz z piksela, raz z serwera.
Mechanizm jest prosty i wymaga jednej dyscypliny: ten sam identyfikator zdarzenia po obu stronach. W Conversions API idzie jako pole id, w pikselu jako event_id. Oba zdarzenia muszą trafić na ten sam identyfikator piksela. Przy zdarzeniach własnych po obu stronach musi zgadzać się także nazwa zdarzenia własnego.
Klucz deduplikacji składa się z trzech części:
- identyfikator piksela,
- nazwa zdarzenia,
- identyfikator zdarzenia.
OpenAI zapisuje pierwsze zdarzenie o danym kluczu i pomija późniejsze duplikaty. Ma to praktyczną konsekwencję: kolejność nie ma znaczenia dla poprawności, ale ma dla kompletności danych. Jeśli zdarzenie z serwera niesie więcej informacji do dopasowania niż zdarzenie z przeglądarki, a przeglądarka zdąży pierwsza, przyjęta zostanie wersja uboższa.
Identyfikator trzeba wygenerować samodzielnie i przekazać do obu ścieżek. Ponownego użycia tego samego identyfikatora dokumentacja dopuszcza tylko przy ponawianiu wysyłki albo przy przesłaniu tej samej konwersji innym kanałem.
oppref i obref: identyfikatory potrzebne do dopasowania
Deduplikacja odpowiada na pytanie „czy to samo zdarzenie dotarło dwa razy”. Atrybucja odpowiada na inne: „czy zdarzenie można połączyć z kontaktem z reklamą”. Do tego służą między innymi dwa nieprzezroczyste identyfikatory OpenAI:
opprefjest przekazywany w adresie po kliknięciu reklamy. Piksel odczytuje go automatycznie i zapisuje w pliku cookie__oppref, aby wykorzystać go także na kolejnych stronach. Conversions API nie przechwytuje go samo — integracja serwerowa musi zachować wartość i wysłać ją bez zmian jako pole zdarzenia.obrefpochodzi z własnego pliku cookie__obrefpiksela. W integracji łączącej przeglądarkę i serwer można przekazać go bez hashowania wevents[].user.obref. Najpierw trzeba jednak spełnić wymagania serwisu dotyczące zgody na pomiar; po jej cofnięciu identyfikatora nie należy dalej wysyłać.
Dla webowego zdarzenia serwerowego wymagany jest również source_url z prawidłowym schematem i hostem oraz action_source: "web". Próba wywołania Conversions API bezpośrednio z kodu strony ujawniałaby klucz i jest niezgodna z przeznaczeniem interfejsu — wysyłka odbywa się wyłącznie z serwera.
Normalizacja i hashowanie danych
Dane identyfikujące użytkownika przekazuje się wyłącznie jako skróty SHA-256. Surowych adresów e-mail, numerów telefonu, identyfikatorów zewnętrznych, imion i nazwisk wysyłać nie wolno.
Normalizacja przed policzeniem skrótu:
| Dane | Normalizacja | Przykład |
|---|---|---|
| adres e-mail | usunięcie białych znaków z początku i końca, małe litery | Jan@Firma.PL → jan@firma.pl |
| numer telefonu | prefiks kraju zostaje; usunięcie spacji, nawiasów, kropek i myślników, potem plusa i zer wiodących; skrót z 8–15 cyfr | +48 (601) 234-567 → 48601234567 |
| imię i nazwisko | małe litery, usunięcie białych znaków i znaków przestankowych ASCII, polskie znaki diakrytyczne zostają | Łukasz → łukasz |
| identyfikator zewnętrzny | usunięcie białych znaków z początku i końca, wielkość liter zachowana | AB-1024 → AB-1024 |
Wartość znormalizowaną koduje się w UTF-8, liczy z niej SHA-256 i wysyła jako 64-znakowy ciąg szesnastkowy małymi literami.
Dwa błędy są szczególnie łatwe do popełnienia. Pierwszy to usuwanie polskich znaków diakrytycznych albo ich transliteracja — dokumentacja wymaga ich zachowania, więc józef po zamianie na jozef da inny skrót. Drugi to pozostawienie plusa w numerze telefonu.
Wartości geograficzne — miasto, region, kod pocztowy — przekazuje się jako tekst, bez hashowania. Miasto i region do 128 znaków, kod pocztowy do 32 znaków.
Kwoty i waluty
Kwoty przekazuje się jako liczby całkowite w jednostce podrzędnej waluty według ISO 4217. Dla złotego jednostką podrzędną jest grosz, więc 12999 oznacza 129,99 zł. Kiedy zdarzenie zawiera kwotę, musi zawierać także walutę.
Przekazanie 129.99 zamiast 12999 zaniża wartość konwersji o dwa rzędy wielkości. Taki błąd może pozostać niezauważony, ponieważ zdarzenie nadal wygląda jak poprawna liczba, ale raportowana wartość jest sto razy niższa od właściwej.
Zgoda na pomiar
Tu jest pułapka istotna dla każdego serwisu działającego w Europie.
Piksel domyślnie przyjmuje zgodę jako udzieloną. Dokumentacja mówi to wprost: zgoda inicjuje się jako true, chyba że zostanie ustawiona na false albo piksel znajdzie zapisaną odmowę. Domyślne zachowanie to więc pomiar włączony.
Kiedy zgoda jest wymagana, kolejność wygląda tak: najpierw oaiq("consent", false), potem inicjalizacja piksela, a oaiq("consent", true) dopiero po uzyskaniu zgody użytkownika. Wywołanie ustawiające zgodę przed inicjalizacją jest tu istotne — inaczej piksel startuje w trybie mierzącym.
Dwie konsekwencje operacyjne:
- Zdarzenia zablokowane brakiem zgody nie są później odtwarzane. Udzielenie zgody dopuszcza zdarzenia przyszłe, nie odzyskuje przeszłych.
- Wdrożenie piksela trzeba wpiąć w istniejący mechanizm zgód, a nie obok niego. Sam skrypt w
<head>bez tej integracji mierzy od pierwszego wczytania strony.
Automatyczne dopasowanie zaawansowane
Po włączeniu tej funkcji piksel może rozpoznawać obsługiwane dane klienta na stronie, normalizować je i hashować w przeglądarce algorytmem SHA-256. Według dokumentacji surowe dane wykryte w ten sposób nie są wysyłane do OpenAI. Funkcja może poprawić dopasowanie, gdy brakuje identyfikatora kliknięcia, ale nie znosi obowiązków dotyczących informacji, podstawy prawnej i zgody. Jej użycie trzeba ocenić w kontekście konkretnego serwisu, a nie włączać automatycznie na każdym rynku.
Content Security Policy
Restrykcyjna polityka bezpieczeństwa treści może zablokować pobranie biblioteki, konfiguracji albo wysyłkę zdarzeń. Wymagane źródła:
| Dyrektywa | Źródło | Po co |
|---|---|---|
script-src |
https://bzrcdn.openai.com |
wczytanie biblioteki piksela |
connect-src |
https://bzr.openai.com |
wysyłka zdarzeń |
connect-src |
https://bzrcdn.openai.com |
pobranie konfiguracji piksela |
img-src |
https://bzr.openai.com |
wysyłka zdarzeń metodą awaryjną przez żądanie obrazu |
Brakujący wpis w img-src może zablokować mechanizm awaryjny oparty na żądaniu obrazu. Nie należy jednak dodawać unsafe-inline tylko dla piksela. Przy polityce z nonce trzeba zastosować świeży nonce dla każdej odpowiedzi i dodać go do skryptu instalacyjnego; przy script-src-elem należy uwzględnić także źródło CDN oraz używany nonce lub hash.
Atrybucja i to, co wchodzi do metryki
Zdarzenia webowe obsługują atrybucję po kliknięciu, a na części kont także atrybucję po wyświetleniu. Okno po wyświetleniu jest stałe i wynosi jeden dzień od kwalifikującego się wyświetlenia reklamy. Dostępność raportowania po wyświetleniu nie zależy od skonfigurowanego okna kliknięcia. Kiedy konwersja kwalifikuje się do obu, pierwszeństwo ma kliknięcie.
Najważniejsze rozróżnienie raportowe:
Konwersje po wyświetleniu są raportowane osobno, na poziomie kampanii, i nie wchodzą do metryki Conversions. Ta pozostaje sumą konwersji po kliknięciu. Koszt pozyskania, współczynnik konwersji po kliknięciu, licytacja, rozliczenie i optymalizacja pod konwersje również liczą się z kliknięć. Zdarzenia z cyklu życia aplikacji pozostają oparte na kliknięciu.
Dodanie obu liczb do siebie zawyża wynik kanału i, co gorsze, zawyża go niesymetrycznie — bo tylko część kont ma raportowanie po wyświetleniu. Porównanie dwóch kont staje się wtedy porównaniem dwóch różnych definicji.
Atrybucja po wyświetleniu nie wymaga zmian we wdrożeniu piksela ani w treści zdarzenia.
Warunki optymalizacji pod konwersje
Kampania oCPC nie ruszy, dopóki nie są spełnione wszystkie warunki:
- Konto obsługuje licytację pod konwersje — brak tej możliwości daje błąd
403z komunikatemConversion bidding is not enabled. - Pomiar jest wdrożony pikselem, przez Conversions API albo jednym i drugim.
- Istnieje dokładnie jedno aktywne standardowe zdarzenie jako cel; zdarzenia własne nie mogą być celem.
- Ustawienie zdarzenia należy do tego konta i łączy się z jednym aktywnym źródłem konwersji.
- Cel i zdarzenie są wybrane przed utworzeniem kampanii, bo później nie podlegają zmianie.
Trzy z pięciu punktów dotyczą pomiaru. To ta lista tłumaczy, dlaczego w tym kanale pomiar jest pracą przed kampanią, a nie po niej.
Image Tag i wiele pikseli
Image Tag pozwala wysłać zdarzenie z HTML bez JavaScriptu — przydaje się w szablonach wiadomości i w systemach, w których nie da się uruchomić skryptu. Przyjmuje własny identyfikator zdarzenia, więc wchodzi do tej samej deduplikacji: identyfikator z tagu obrazu podaje się potem jako id zdarzenia w Conversions API.
Obsługa wielu pikseli działa wtedy, gdy jedna strona ma mierzyć konwersje dla kilku identyfikatorów — na przykład przy wspólnym serwisie obsługującym dwie marki. Zdarzenie można skierować do wszystkich pikseli albo do jednego wskazanego.
Jak podchodzimy do tego w Space Ads
Pomiar projektujemy od zdarzenia biznesowego, nie od dostępnej listy tagów. Najpierw ustalamy, które działanie oznacza zakup, kwalifikowany lead, rejestrację albo umówione spotkanie. Następnie nadajemy mu standardową nazwę OpenAI, ustalamy jeden identyfikator dla przeglądarki i serwera oraz zachowujemy oppref i — po spełnieniu wymagań dotyczących zgody — obref. Kwoty, waluty i znormalizowane skróty walidujemy przed wysyłką. Conversions API najpierw uruchamiamy z validate_only: true, a piksel z trybem debugowania. Potem wykonujemy jedną kontrolowaną konwersję i porównujemy payloady obu ścieżek. Kampania oCPC powstaje dopiero wtedy, gdy zdarzenie ma właściwą semantykę, deduplikacja działa, a wynik trafia do raportu tylko raz.
Najczęstsze błędy
- Wdrożenie samego piksela i pominięcie Conversions API, choć dokumentacja wskazuje je jako źródło pewniejsze.
- Brak wspólnego identyfikatora zdarzenia po obu stronach i podwójne liczenie konwersji.
- Przekazanie kwoty jako
129.99zamiast12999i zaniżenie przychodu sto razy. - Pominięcie waluty przy zdarzeniu zawierającym kwotę.
- Usuwanie polskich znaków diakrytycznych przed hashowaniem imienia albo nazwiska.
- Pozostawienie plusa albo zer wiodących w numerze telefonu przed policzeniem skrótu.
- Wysyłka surowych danych zamiast skrótów SHA-256.
- Poleganie na domyślnym ustawieniu zgody, które jest włączone, i pomiar bez podstawy.
- Brak wymaganych źródeł w Content Security Policy i zablokowane żądania piksela.
- Pominięcie
opprefw zdarzeniu serwerowym alboobrefw integracji hybrydowej mimo dostępnej i prawidłowo pozyskanej wartości. - Wywołanie Conversions API bezpośrednio z przeglądarki i ujawnienie klucza dostępowego.
- Dodanie konwersji po wyświetleniu do konwersji po kliknięciu w jednej liczbie.
- Wybór zdarzenia własnego jako celu kampanii optymalizowanej pod konwersje.
- Wysyłka zaległych zdarzeń starszych niż 7 dni.
Najczęstsze pytania
Piksel czy Conversions API — co wybrać?
Dokumentacja OpenAI wskazuje Conversions API jako źródło bardziej wiarygodne niż sam piksel. W praktyce warto wdrożyć oba i połączyć je deduplikacją: piksel łapie zdarzenia przeglądarkowe, serwer dostarcza komplet danych do dopasowania.
Jak działa deduplikacja zdarzeń?
Klucz deduplikacji to identyfikator piksela, nazwa zdarzenia i identyfikator zdarzenia. Ten sam identyfikator trzeba podać jako id w Conversions API i jako event_id w pikselu. OpenAI zapisuje pierwsze zdarzenie o danym kluczu i pomija późniejsze duplikaty.
Jak przekazać wartość zamówienia w złotówkach?
Jako liczbę całkowitą w groszach, razem z kodem waluty. Kwota 129,99 zł to 12999 z walutą PLN. Kwota bez podanej waluty nie zostanie przyjęta.
Czy piksel wymaga zgody użytkownika?
Piksel domyślnie startuje ze zgodą ustawioną na udzieloną. Jeśli zgoda jest wymagana, trzeba ustawić ją na false przed inicjalizacją i przełączyć na true po jej uzyskaniu. Zdarzenia zablokowane brakiem zgody nie są później odtwarzane.
Dlaczego konwersje nie pojawiają się w panelu, choć piksel jest wdrożony?
W pikselu warto tymczasowo włączyć debug: true i sprawdzić konsolę przeglądarki oraz żądania sieciowe. Dla Conversions API można najpierw wysłać payload z validate_only: true. Trzeba także skontrolować CSP, zgodę, identyfikator piksela, source_url, znacznik czasu i odpowiedź całej paczki — błąd jednego zdarzenia odrzuca wszystkie zdarzenia w danym żądaniu.
Czy konwersje po wyświetleniu wchodzą do metryki konwersji?
Nie. Raportowane są osobno, na poziomie kampanii, i nie wchodzą do metryki Conversions, która pozostaje sumą konwersji po kliknięciu. Koszt pozyskania, licytacja i optymalizacja również liczą się z kliknięć.
Najważniejsze
W ChatGPT Ads pomiar jest warunkiem odpowiedzialnego testu, a dla oCPC także elementem wymaganym technicznie. Nawet gdy część funkcji targetowania nie nadaje się do danego setupu, wynik nadal zależy od celu, stawki, kontekstu, reklamy i strony docelowej. Pomiar pozwala ocenić te decyzje na podstawie działań po kliknięciu.
Od pierwszego dnia trzeba zadbać o wspólny identyfikator zdarzenia, prawidłowe kwoty i waluty, identyfikatory atrybucyjne oraz zgodną z prawem obsługę danych i zgody. Dopiero na tej podstawie można łączyć piksel z Conversions API bez podwójnego liczenia i oceniać oCPC na zdarzeniu, które naprawdę opisuje wynik biznesowy.
Mechanikę całego kanału opisuje wpis o ChatGPT Ads, a pomiar jako usługę strona analityki.
Źródła i dalsza lektura
- OpenAI Developers — Measurement Pixel
- OpenAI Developers — Conversions API
- OpenAI Developers — Supported Events
- OpenAI Developers — Conversion-Optimized Campaigns
- OpenAI Developers — Image Tag
- OpenAI Developers — Multiple Pixel IDs
- OpenAI Developers — Conversion Setup
- Analityka i pomiar konwersji
- ChatGPT Ads — prowadzenie kampanii
- ChatGPT Ads — jak je kupić, ile kosztują i kto je widzi
- OpenAI Ads Manager — panel i pierwsza kampania
- Server-side tagging, sGTM i Conversions API
Czytaj również
ChatGPT Ads — jak je kupić, ile kosztują i kto je widzi
ChatGPT Ads to reklamy wyświetlane pod odpowiedzią i dobierane do kontekstu rozmowy, bez klasycznych słów kluczowych. Wpis wyjaśnia format, modele CPM, CPC i oCPC, pomiar konwersji, feedy produktowe, wymagania strony docelowej oraz to, kiedy kanał ma sens biznesowy.
ChatGPT Ads — formaty reklam i limity znaków według dokumentacji OpenAI
Reklama w ChatGPT pojawia się pod odpowiedzią i ma sześć elementów, a limity są konkretne: tytuł 3–50 znaków, opis do 100. Obiegowe liczby „24 / 48 znaków" nie zgadzają się z dokumentacją, więc wpis podaje pełną tabelę limitów, pokazuje, jak zmieścić komunikat po polsku, i opisuje wymogi wobec obrazu, reklam produktowych oraz strony docelowej.
OpenAI Ads Manager — jak wygląda panel i jak uruchomić pierwszą kampanię
OpenAI Ads Manager ma trzy poziomy struktury — kampanię, grupę reklam i reklamę — lecz start wymaga także weryfikacji firmy, konfiguracji płatności i świadomego wyboru nieodwracalnych ustawień. Wpis prowadzi przez aktualny proces i wyjaśnia podpowiedzi kontekstowe, budżety, oCPC, kierowanie oraz różnice między panelem, Ads API i operacjami hurtowymi.
