- Blokery reklam używają list filtrów, żeby zatrzymać skrypty pikseli i ich żądania, więc platforma reklamowa nie dostaje z tej przeglądarki żadnego zdarzenia.
- Zablokowany piksel gubi wyświetlenia stron, dodania do koszyka i zakupy, a najbardziej liczy się zakup, bo od niego zależą raportowany ROAS i licytacja.
- Zakupy wysyłane server-side z danych zamówień nie są dotknięte, bo przeglądarka kupującego ich nie wysyła.
- Zmierz własną lukę, porównując zamówienia internetowe w swoim sklepie ze zdarzeniami Purchase wysłanymi przez piksel w przeglądarce, a nie z przypisanymi konwersjami.
- Server-side tracking nie przywróci zdarzeń przeglądania ani click id, które nigdy nie zostały zapisane, a zbieranie danych first-party zmniejsza tę stratę.
Blokery reklam zatrzymują tracking, uniemożliwiając załadowanie w przeglądarce kupującego skryptu piksela platformy reklamowej albo wysyłanych przez niego żądań. Wtedy platforma nigdy nie dowiaduje się o wyświetleniu strony, dodaniu do koszyka ani zakupie, choć zamówienie jest w twoim sklepie. Zakupy wysyłane server-side z danych zamówień nie są dotknięte, bo przeglądarka kupującego nie bierze udziału w ich wysyłaniu.
Ten poradnik wyjaśnia, jak działają blokery reklam i funkcje prywatności w przeglądarkach, jakie zdarzenia traci twój sklep, co odzyskuje server-side tracking, a czego nie. Kończy się prostym sposobem na zmierzenie tej luki w twoim sklepie.
Jak blokery reklam zatrzymują piksele śledzące?
Większość blokerów reklam działa na listach filtrów. Lista filtrów to długi zbiór reguł dopasowujących adresy internetowe: domeny, ścieżki i nazwy plików znanych skryptów reklamowych i śledzących. Gdy strona prosi przeglądarkę o załadowanie czegoś, co pasuje do reguły, bloker anuluje żądanie.
Najbardziej znane listy to EasyList, dla reklam, i EasyPrivacy, dla trackingu. Działają z rozszerzeniami takimi jak Adblock Plus, AdBlock, uBlock Origin i AdGuard. Piksel dużej platformy reklamowej to łatwy cel dla tych list, bo ładuje ten sam skrypt z tej samej domeny na wielu różnych stronach.
Przeglądarki z wbudowaną ochroną
Niektóre przeglądarki blokują trackery bez rozszerzenia. Brave domyślnie włącza swoje Shields na każdej stronie, a Shields blokują reklamy i trackery podmiotów trzecich oraz cookie międzywitrynowe. Firefox blokuje treści ze znanych domen śledzenia międzywitrynowego w oknach prywatnych, a użytkownicy mogą wybrać ostrzejsze ustawienia, które obowiązują we wszystkich oknach. Intelligent Tracking Prevention w Safari blokuje wszystkie cookie podmiotów trzecich i skraca życie cookie ustawianych przez skrypty. Nasz poradnik Safari ITP a tracking reklam wyjaśnia te ograniczenia.
Blokery działające w całej sieci
Część osób blokuje trackery dla całego urządzenia albo sieci domowej, za pomocą blokera opartego na DNS lub VPN z filtrem trackerów. Takie rozwiązania zatrzymują żądania do domen śledzących w każdej przeglądarce i aplikacji w tej sieci. Zmiana przeglądarki niczego nie zmienia.
Jakie zdarzenia traci twój sklep?
Gdy piksel jest zablokowany, każde zdarzenie, które wysłałby z tej przeglądarki, przepada. Szkody nie są jednak takie same dla każdego zdarzenia.
| Zdarzenie | Do czego służy | Ginie, gdy piksel jest zablokowany? | Czy mogą je zastąpić dane zamówień? |
|---|---|---|---|
| PageView, ViewContent | Grupy odbiorców z odwiedzających stronę, retargeting produktowy | Tak | Nie |
| AddToCart, InitiateCheckout | Optymalizacja pod kupujących, którzy zaczynają zakup, retargeting koszyka | Tak | Nie |
| Purchase | Raportowane konwersje, ROAS, optymalizacja pod zakup, licytacja oparta na wartości | Tak | Tak |
| Click id przy wejściu na stronę | Powiązanie zakupu z konkretnym kliknięciem w reklamę | Tak, gdy zablokowany jest także skrypt trackingu | Nie, musi być zapisany w przeglądarce |
Utracone zdarzenia przeglądania zmniejszają twoje grupy odbiorców do retargetingu. Utracone zakupy szkodzą bardziej. Platforma raportuje mniej konwersji, ROAS w raporcie reklam spada, a algorytm licytacji uczy się na mniejszej liczbie kupujących. Rentowna kampania może wtedy wyglądać na nierentowną i możesz ją ograniczyć.
Dlaczego zdarzenia server-side z danych zamówień nie są blokowane
Bloker reklam działa w przeglądarce kupującego. Może zatrzymać tylko żądania, które wysyła przeglądarka. Gdy zakup jest wysyłany z danych zamówień twojego sklepu, żądanie idzie z serwera do API platformy reklamowej. Przeglądarka kupującego nie jest częścią tej ścieżki, więc bloker nie ma czego anulować.
14:02:11 PageView pixelBlokowane przez listę filtrów w przeglądarce14:09:47 Purchase pixel order-1042Nigdy nie wysłane, bo skrypt piksela się nie załadował14:09:52 webhook order-1042 paidSklep zgłasza opłacone zamówienie do serwera14:10:12 Purchase server order-1042Wysłane do Conversions API z zahashowanym e-mailem i telefonemPlatforma dopasowuje wtedy zakup do osoby na podstawie danych w zdarzeniu: zahashowanego e-maila i telefonu z zamówienia, adresu IP i user agenta oraz click id, jeśli został zapisany. Nic z tego nie przechodzi przez bloker. Pełną ścieżkę danych opisuje artykuł czym jest server-side tracking.
Czego server-side tracking nie odzyska?
Click id wymaga przeglądarki
Samo zamówienie jest bezpieczne, ale powiązanie z kliknięciem w reklamę powstaje w przeglądarce. Skrypt musi odczytać click id z adresu strony docelowej i je zapisać. Jeśli bloker reklam zatrzymuje także ten skrypt, zamówienie dociera bez click id. Platforma nadal może dopasować zakup na podstawie zahashowanych danych klienta, ale takie dopasowanie jest mniej pewne.
Tę stratę zmniejszają dwie rzeczy. Po pierwsze, zbieraj zdarzenia w trybie first-party: serwuj skrypt trackingu i jego żądania z własnej domeny, na przykład przez app proxy Shopify albo subdomenę twojej strony. Listy filtrów celują w znane adresy śledzące podmiotów trzecich, więc ścieżkę first-party znacznie trudniej zablokować, choć nie jest to niemożliwe. Po drugie, wykorzystaj stronę docelową, którą niektóre sklepy internetowe, jak Shopify, zapisują przy każdym zamówieniu. Jeśli ten adres nadal zawiera click id lub UTM, zamówienie można przypisać bez żadnego zdarzenia z przeglądarki.
Zdarzenia przeglądania nadal giną
Dane zamówień zawierają zamówienia, a nie wyświetlenia stron. Wysyłanie zakupów z zamówień nie przywraca wyświetleń stron ani dodań do koszyka odwiedzającego, którego przeglądarka zablokowała wszystko. Kolektor first-party może przekazać te zdarzenia z serwera, gdy jego własne żądania przechodzą.
Odmowa zgody to nie blokowanie
Odwiedzający, który odrzuca marketingowe cookie w twoim banerze cookie, to nie to samo co odwiedzający z blokerem reklam. Pierwszy dokonał wyboru, którego twój tracking musi przestrzegać. Przy włączonym Respect visitor consent ROASaurus nie ustawia dla takiego odwiedzającego visitor id, więc jego kliknięcia w reklamy i wizyty nie są z nim powiązane. Jego zdarzenia z przeglądarki są zachowywane bez visitor id, adresu IP i danych przeglądarki i nie są wysyłane do platform reklamowych. Opłacone zamówienie nadal jest wysyłane server-side, z zahashowanymi danymi klienta z zamówienia oraz adresem IP i user agentem zamówienia. Rozdzielaj te dwie grupy, gdy mierzysz stratę, a szczegóły znajdziesz w artykule zgody i prywatność.
Jak oszacować własną stratę
Nie potrzebujesz średnich branżowych, które zależą od odbiorców, urządzenia i kraju. Własną lukę zmierzysz, porównując zamówienia w swoim sklepie z zakupami, które piksel w przeglądarce zaraportował w tym samym okresie.
- Wybierz okres i jedną platformę
Użyj 14 lub 30 dni i jednej platformy, na przykład Meta. W obu systemach ustaw tę samą strefę czasową.
- Policz zamówienia internetowe w swoim sklepie
Zacznij od wszystkich zamówień. Odejmij zamówienia, które nigdy nie przechodzą przez twój checkout online: sprzedaż w punkcie sprzedaży, zamówienia ręczne i robocze, odnowienia subskrypcji i zamówienia testowe.
- Policz zdarzenia Purchase z przeglądarki
W narzędziu platformy do zdarzeń policz zdarzenia Purchase wysłane przez piksel w przeglądarce. Najłatwiej zrobić to, zanim dodasz zdarzenia server-side. Jeśli zdarzenia server-side już działają, użyj widoku platformy według metody połączenia, o ile go oferuje. Meta Events Manager pokazuje metodę połączenia każdego zdarzenia i liczy tam zdarzenia przed deduplikacją. Nie używaj przypisanych zakupów z raportu reklam.
- Podziel
Zakupy z przeglądarki ÷ zamówienia internetowe to odsetek, który widział piksel. Reszta to twoja luka.
- Oddziel zgodę od blokowania
Oszacuj zamówienia od odwiedzających, którzy odrzucili marketingowe cookie, na podstawie odsetka odmów z twojego narzędzia do zgód. To, co zostaje, to głównie blokery reklam, ustawienia prywatności i strony, które się nie załadowały.
| Przykładowy sklep, 30 dni | Zamówienia | Udział w zamówieniach internetowych |
|---|---|---|
| Wszystkie zamówienia w sklepie | 1,240 | |
| Zamówienia z punktu sprzedaży, ręczne i odnowienia | −90 | |
| Zamówienia internetowe | 1,150 | 100% |
| Zdarzenia Purchase z piksela w przeglądarce | 874 | 76% |
| Luka | 276 | 24% |
| Szacowane zamówienia od odwiedzających, którzy odrzucili zgodę (10% odmów) | 115 | 10% |
| Reszta: blokery reklam, ustawienia prywatności, strony, które się nie załadowały | 161 | 14% |
Luka zmienia także ROAS. Załóżmy, że Meta raportuje dla tego sklepu ROAS 2.0, a jego ROAS progu rentowności wynosi 2.3. Na danych z piksela kampanie przynoszą stratę. Jeśli zamówienia z reklam były pomijane w tym samym tempie 24% co wszystkie zamówienia internetowe, piksel widział tylko 76% przychodu z reklam. Prawdziwy ROAS wynosiłby wtedy około 2.0 ÷ 0.76 = 2.6, czyli powyżej progu rentowności. To szacunek górny, bo nie każde brakujące zamówienie pochodziło z reklamy. Nasz poradnik ROAS progu rentowności wyjaśnia, jak ustawić ten próg.
Jak ograniczyć to, co tracisz
Rozwiązania są takie same dla każdej platformy sklepowej. Najlepiej działają razem.
- Wysyłaj zakupy z danych zamówień. To zamyka lukę zakupów dla każdej podłączonej platformy, niezależnie od tego, co blokuje przeglądarka odwiedzającego.
- Zostaw piksel, ze wspólnym event id. Odwiedzający bez blokera nadal wysyłają zdarzenia z przeglądarki z cookie i kontekstem strony. Ten sam event id w obu kopiach pozwala platformie zachować jedną. Zobacz jak zapobiegać podwójnemu liczeniu.
- Zbieraj dane first-party. Serwuj skrypt trackingu i jego zdarzenia z własnej domeny, żeby click id były zapisywane dla większej liczby odwiedzających.
- Wysyłaj zahashowane dane klientów. E-mail i telefon z zamówienia pozwalają platformie dopasować zakupy, które nie mają click id.
- Zmierz ponownie. Powtórz porównanie miesiąc później. Zdarzenia Purchase, które odbiera platforma, powinny teraz zgadzać się z twoimi zamówieniami internetowymi.
Jak ROASaurus radzi sobie z blokerami reklam
ROASaurus wysyła każde opłacone zamówienie server-side do platform reklamowych, które dodasz w sekcji Tracking & platforms, więc bloker reklam w przeglądarce kupującego nie zatrzymuje zakupu. W Shopify zdarzenia z witryny przechodzą przez app proxy Shopify na domenie twojego sklepu. Możesz też serwować skrypt i jego zdarzenia z subdomeny CNAME swojej strony. Gdy odwiedzający nie ma żadnego kontaktu z przeglądarką, atrybucja ROASaurus wraca do click id i UTM z adresu strony docelowej zamówienia, jeśli sklep go zapisuje, tak jak robi to Shopify.
Każda dostawa i odpowiedź platformy są wypisane w Event log, więc możesz sprawdzić, czy każde zamówienie dotarło do każdej platformy. Konfigurację opisują artykuły server-side tracking i integracja z Shopify.
Źródła
- EasyList: Overview
- Brave: Brave Shields
- MDN Web Docs: Firefox tracking protection
- WebKit: Tracking Prevention in WebKit
- Meta for Developers: Verifying Your Setup