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

Wiele sklepów notuje część sprzedaży w Arkuszu Google: zamówienia przyjęte przez telefon, sprzedaż w sklepie stacjonarnym albo zamówienia firmowe opłacane przelewem. Ktoś dopisuje wiersz, a gdy pieniądze wpłyną, zmienia status na „opłacone”. 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, zakup w sklepie stacjonarnym, zamówienie opłacone przelewem po kilku dniach. 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 albo telefon.

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 Basketly 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. 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.

Basketly 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 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 ktoś w ciągu minuty zmieni status z PRZYJETE na OPLACONE, 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: jedno zamówienie telefoniczne

Zobacz, co dzieje się z jednym wierszem (dane przykładowe). Obsługa sklepu dopisuje w poniedziałek zamówienie T-1042 przyjęte przez telefon, z numerem +48600100200 i statusem PRZYJETE. Przepływ nie mapuje PRZYJETE, więc nic nie wychodzi.

1. Środa, 11:20. Przelew wpłynął. Ktoś zmienia status na OPLACONE, wpisuje czas zmiany, wartość 489 i walutę PLN. W ciągu kilku minut odczyt widzi nowy status, a kolejka wysyła Purchase z zahashowanym telefonem, kwotą i czasem ze środy 11:20.
2. Czwartek. Ktoś przypadkiem zmienia status z powrotem na PRZYJETE, a potem znów na OPLACONE. Para T-1042 + OPLACONE 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. Ktoś poprawia kwotę na 520. Ta zmiana dotyczy już zgłoszonej pary, więc jest odrzucana z komunikatem. Meta zna wartość ze środy.

Wniosek: kwotę i status wpisuj dopiero wtedy, gdy są ostateczne. Najprościej ustalić w zespole, że status „opłacone” 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.
• Zamówienia pochodzą ze sklepu internetowego. Wtedy lepiej połączyć sam sklep (Shoper, IdoSell, BaseLinker): Basketly zapisze zamówienie z pozycjami, kupującego i zakup bez przepisywania do arkusza. Jak to działa, opisuje artykuł o zakupach ze Shopera przez Conversions API.
• 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 albo telefonu 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 arkuszu jako źródle znajdziesz na stronie Integracje, a plany w cenniku.