Konwersje offline z Arkusza Google do Meta: kolumny, hashowanie i deduplikacja

Wiele firm prowadzi sprzedaż w Arkuszu Google: handlowiec dopisuje wiersz, zmienia status na „zakwalifikowany”, a potem na „sprzedany”. Meta nic o tym nie wie, bo Pixel widzi tylko stronę, a nie arkusz. Conversions API pozwala przekazać te zmiany do Meta jako konwersje offline, czyli zdarzenia, które wydarzyły się poza stroną. Ten poradnik pokazuje, jak przygotować kolumny, jak dane są hashowane, jak uniknąć podwójnego liczenia i gdzie są granice tego podejścia.

Co to są konwersje offline w Meta?

To zdarzenia, które Twój system zna, a przeglądarka nie: sprzedaż przez telefon, podpisana umowa, lead zakwalifikowany po rozmowie. Meta przyjmuje je dziś przez to samo Conversions API, co zdarzenia ze strony. Dawny osobny interfejs dla konwersji offline Meta opisuje jako starszy i przy nowych wdrożeniach zaleca Conversions API.

Zdarzenie z arkusza ma action_source równe system_generated, czyli „wygenerowane przez system firmy”. Najważniejsze reguły z dokumentacji parametrów zdarzenia:

• event_time to rzeczywisty czas zdarzenia, najwyżej 7 dni wstecz od wysyłki,
• jedno za stare zdarzenie w paczce powoduje odrzucenie całego żądania,
• zdarzenie potrzebuje co najmniej jednego identyfikatora osoby.

Jakie kolumny musi mieć arkusz?

Nazwy kolumn możesz mieć własne, bo w panelu przypisujesz je do pól. Liczy się zawartość.

Wymagane minimum to identyfikator, status, czas, zgoda i co najmniej jeden identyfikator osoby: e-mail, telefon albo identyfikator leada z Meta.

Dlaczego czas zmiany statusu jest tak ważny?

Bo Meta przypisuje konwersję do momentu, w którym się wydarzyła. Gdyby narzędzie wstawiało czas synchronizacji, sprzedaż z piątku wyglądałaby jak sprzedaż z poniedziałku. Dlatego Convs nie zastępuje brakującej daty czasem odczytu: wiersz bez daty jest odrzucany z komunikatem, który wskazuje numer pierwszego błędnego wiersza (bez danych klienta).

Daty z komórek arkusza są czytane w strefie czasowej arkusza. Daty tekstowe muszą mieć strefę (np. 2026-04-14T10:30:00+02:00).

Jak dane z arkusza są hashowane?

Meta wymaga, żeby e-mail i telefon były znormalizowane i zahashowane SHA-256, a identyfikator leada wysłany jawnie. Według listy parametrów klienta:

1. E-mail: usunięcie spacji z brzegów, małe litery, potem SHA-256. Anna.Kowalska@Example.com i anna.kowalska@example.com dają ten sam skrót.
2. Telefon: usunięcie spacji, myślników i nawiasów, kod kraju obowiązkowy, potem SHA-256 z samych cyfr. +48 600-100-200 staje się skrótem z 48600100200.
3. Identyfikator leada z Meta: bez hashowania, bo Meta zna go w tej postaci.

Convs robi to po stronie serwera. Telefon bez kodu kraju jest odrzucany, zamiast zgadywać prefiks, bo źle dopisany prefiks dałby skrót, który nikomu nie odpowiada. Skróty to nadal dane osobowe: o podstawie prawnej i retencji piszemy w artykule o RODO i hashowaniu (to nie jest porada prawna).

Jak przypisać statusy do zdarzeń Meta?

W przepływie mówisz, który status ze źródła ma zostać którym zdarzeniem w Meta. Przykład:

Nazwę zdarzenia dobierz do tego, co chcesz potem wykorzystać w kampanii lub konwersji niestandardowej. Jedno źródło może wysyłać do kilku odbiorców (np. dwóch Pixeli), a każdy cel ma osobny status wysyłki. Jak zaprojektować etapy, z których Meta może się czegoś nauczyć, opisujemy w artykule o etapach leada w CRM.

Jak działa deduplikacja przy arkuszu?

Arkusz czytany co minutę oznacza, że ten sam wiersz jest widziany setki razy. Gdyby każdy odczyt wysyłał zdarzenie, Meta dostałaby lawinę duplikatów. Są więc dwie warstwy ochrony:

• Zdarzenie biznesowe: para identyfikator + status ze źródła jest konwersją jednorazową. Ponowne wejście w ten sam status nie tworzy nowej konwersji.
• Wysyłka: zdarzenie ma stały event_id, wyliczony z identyfikatora i statusu, a kolejka nie wyśle drugi raz tego samego zdarzenia do tego samego datasetu Meta w tym samym trybie, także z dwóch różnych połączeń.

Ponowienia po błędach zachowują ten sam event_id, więc nawet gdy odpowiedź Meta zginie po drodze, Meta może zdeduplikować powtórkę. Pixel nie wysyła zdarzeń z arkusza, więc nie trzeba niczego uzgadniać z przeglądarką. Szczegóły w artykule o deduplikacji zdarzeń.

Czego synchronizacja nie odtworzy?

Arkusz pokazuje aktualny stan wiersza, a nie historię. Jeśli handlowiec w ciągu minuty zmieni status z QUALIFIED na CONVERTED, odczyt może zobaczyć tylko ten drugi. Gdy kilka zmian statusu może nastąpić szybciej niż odczyt, zapisuj zdarzenia w osobnej zakładce: jeden wiersz na każdą zmianę, z własnym identyfikatorem.

Przykład: jeden wiersz od leada do sprzedaży

Zobacz, co dzieje się z jednym wierszem (dane przykładowe). Handlowiec dopisuje w poniedziałek rekord K-1042 z telefonem +48600100200 i statusem NEW. Przepływ nie mapuje NEW, więc nic nie wychodzi.

1. Wtorek, 11:20. Handlowiec zmienia status na QUALIFIED i wpisuje czas zmiany. W ciągu kilku minut odczyt widzi nowy status, a kolejka wysyła QualifiedLead z zahashowanym telefonem i czasem z wtorku 11:20.
2. Środa. Ktoś przypadkiem zmienia status z powrotem na NEW, a potem znów na QUALIFIED. Para K-1042 + QUALIFIED już była zgłoszona, więc druga konwersja nie powstaje. Jeśli przy okazji zmienił się czas statusu, wiersz dostaje komunikat o konflikcie, bo zgłoszonej konwersji nie da się zmienić.
3. Piątek, 15:05. Status CONVERTED, wartość 4900, waluta PLN. Wychodzi Purchase z kwotą i czasem z piątku.
4. Poniedziałek. Handlowiec poprawia kwotę na 5200. Ta zmiana dotyczy już zgłoszonej pary, więc jest odrzucana z komunikatem. Meta zna wartość z piątku.

Wniosek: kwotę i status wpisuj dopiero wtedy, gdy są ostateczne. Jeśli korekty się zdarzają, ustal w zespole, że sprzedaż trafia do arkusza po zaksięgowaniu płatności.

Jak sprawdzić, czy zdarzenia dochodzą?

1. Utwórz odbiorcę Meta w trybie testowym z kodem z Menedżera zdarzeń.
2. Zmień status w jednym wierszu z prawdziwymi danymi testowymi.
3. W panelu sprawdź wysyłkę: „Przyjęte przez Meta” oznacza odpowiedź z events_received: 1.
4. W Menedżerze zdarzeń, w zakładce zdarzeń testowych, sprawdź, czy zdarzenie przyszło z właściwą nazwą i parametrami.
5. Dopiero potem utwórz odbiorcę produkcyjnego i przepływ. Testy i produkcja mają osobną deduplikację.

Przyjęcie zdarzenia nie mówi, jak dobrze Meta dopasowała je do osoby. To pokazuje jakość dopasowania w Menedżerze zdarzeń; jak ją podnieść, opisujemy w poradniku o Event Match Quality.

Najczęstsze błędy i ich przyczyny

Kiedy arkusz to zły pomysł?

• Zmiany wpisujesz raz w tygodniu. Część zdarzeń przekroczy limit 7 dni i przepadnie. Arkusz musi żyć na bieżąco.
• Leady pochodzą z formularzy natywnych Meta i chcesz optymalizacji pod jakość leadów. Meta oczekuje do niej zdarzeń CRM w ściśle określonej postaci. Prościej podłączyć formularz bezpośrednio, a etapy zmieniać na karcie osoby. Wymagania opisuje artykuł o optymalizacji pod jakość leadów.
• Masz dziesiątki tysięcy aktywnych wierszy. Odczyt po 500 wierszy na minutę sprawi, że pełne przejście potrwa długo. Lepiej przesyłać zdarzenia przez integrację serwerową.
• Arkusz nie ma żadnego identyfikatora osoby. Bez e-maila, telefonu albo identyfikatora leada Meta nie ma z czym dopasować zdarzenia.

Następny krok

Dodaj do arkusza kolumny z tabeli, połącz go w trybie testowym i zmień status w jednym wierszu. Więcej o wysyłce znajdziesz na stronie Meta Conversions API, a plany w cenniku.