- Блокерите на реклами използват списъци с филтри, за да спрат скриптовете на пикселите и техните заявки, така че рекламната платформа не получава никакво събитие от този браузър.
- Блокираният пиксел губи прегледи на страници, събития за добавяне в количката и покупки, а покупката е най-важна, защото определя отчетения ROAS и наддаването.
- Покупките, изпратени от страна на сървъра от данните за поръчките ви, не са засегнати, защото браузърът на купувача не ги изпраща.
- Измерете собствената си разлика, като сравните уеб поръчките във вашия магазин със събитията Purchase, изпратени от пиксела в браузъра, а не с приписаните конверсии.
- Проследяването от страна на сървъра не може да върне събития от разглеждане или click ID-та, които никога не са били запазени, а събирането на first-party данни намалява тази загуба.
Блокерите на реклами спират проследяването, като не позволяват на скрипта на пиксела на рекламната платформа или на заявките, които той изпраща, да се заредят в браузъра на купувача. Когато това се случи, платформата така и не научава за прегледа на страницата, добавянето в количката или покупката, макар поръчката да е във вашия магазин. Покупките, изпратени от страна на сървъра от данните за поръчките ви, не са засегнати, защото браузърът на купувача не участва в изпращането им.
Това ръководство обяснява как работят блокерите на реклами и функциите за поверителност в браузърите, кои събития губи вашият магазин, какво възстановява проследяването от страна на сървъра и какво не може. Завършва с лесен начин да измерите разликата в собствения си магазин.
Как блокерите на реклами спират пикселите за проследяване?
Повечето блокери на реклами работят със списъци с филтри. Списъкът с филтри е дълъг списък от правила, които съвпадат с уеб адреси: домейни, пътища и имена на файлове на известни рекламни скриптове и скриптове за проследяване. Когато страница поиска от браузъра да зареди нещо, което съвпада с правило, блокерът отменя заявката.
Най-известните списъци са EasyList за реклами и EasyPrivacy за проследяване. Те работят с разширения като Adblock Plus, AdBlock, uBlock Origin и AdGuard. Пикселът на голяма рекламна платформа е лесна цел за тези списъци, защото зарежда един и същ скрипт от един и същ домейн в много различни сайтове.
Браузъри с вградена защита
Някои браузъри блокират проследяването без разширение. Brave включва своите Shields за всеки сайт по подразбиране, а Shields блокират реклами и скриптове за проследяване от трети страни, както и бисквитки между сайтове. Firefox блокира съдържание от известни домейни за проследяване между сайтове в частните прозорци, а потребителите могат да изберат по-строги настройки, които важат за всички прозорци. Intelligent Tracking Prevention на Safari блокира всички бисквитки от трети страни и скъсява живота на бисквитките, зададени от скриптове. Нашето ръководство за Safari ITP и проследяване на реклами обяснява тези ограничения.
Блокери за цялата мрежа
Някои хора блокират проследяването за цяло устройство или домашна мрежа с блокер, базиран на DNS, или с VPN с филтър за проследяване. Те спират заявките към домейните за проследяване във всеки браузър и приложение в тази мрежа. Смяната на браузъра не променя резултата.
Кои събития губи вашият магазин?
Когато пикселът е блокиран, всяко събитие, което би изпратил от този браузър, се губи. Вредата не е една и съща за всяко събитие.
| Събитие | За какво се използва | Губи ли се при блокиран пиксел? | Могат ли данните за поръчките да го заменят? |
|---|---|---|---|
| PageView, ViewContent | Аудитории от посетители на сайта, ретаргетиране по продукти | Да | Не |
| AddToCart, InitiateCheckout | Оптимизация към купувачи, които започват покупка, ретаргетиране по количка | Да | Не |
| Purchase | Отчетени конверсии, ROAS, оптимизация за покупки, наддаване въз основа на стойност | Да | Да |
| Click ID на целевата страница | Свързване на покупката с точното кликване върху реклама | Да, когато и скриптът за проследяване е блокиран | Не, трябва да се запази в браузъра |
Загубените събития от разглеждане правят аудиториите ви за ретаргетиране по-малки. Загубените покупки нанасят повече вреда. Платформата отчита по-малко конверсии, ROAS в отчета за реклами спада, а алгоритъмът за наддаване се учи от по-малко купувачи. Печеливша кампания тогава може да изглежда нерентабилна и да я спрете.
Защо събитията от страна на сървъра, изградени от данните за поръчките, не се блокират
Блокерът на реклами работи в браузъра на купувача. Той може да спира само заявки, които прави браузърът. Когато покупката се изпраща от данните за поръчките на вашия магазин, заявката върви от сървър към API на рекламната платформа. Браузърът на купувача не е част от този път, затова блокерът няма какво да отмени.
14:02:11 PageView pixelБлокирано от списък с филтри в браузъра14:09:47 Purchase pixel order-1042Никога не се изпраща, защото скриптът на пиксела не се е заредил14:09:52 webhook order-1042 paidМагазинът съобщава за платената поръчка на сървъра14:10:12 Purchase server order-1042Изпратено към Conversions API с хеширани имейл и телефонСлед това платформата съпоставя покупката с човек по данните в събитието: хешираните имейл и телефон от поръчката, IP адреса и user agent, както и click ID, ако е бил запазен. Нищо от това не минава през блокера. За целия път на данните прочетете какво е проследяване от страна на сървъра.
Какво не може да възстанови проследяването от страна на сървъра?
Click ID се нуждае от браузъра
Самата поръчка е в безопасност, но връзката с кликването върху реклама се създава в браузъра. Скрипт трябва да прочете click ID от URL адреса на целевата страница и да го запази. Ако блокер на реклами блокира и този скрипт, поръчката пристига без click ID. Платформата пак може да съпостави покупката чрез хешираните данни за клиента, но съвпадението е по-малко сигурно.
Две неща намаляват тази загуба. Първо, събирайте събитията като first-party: предоставяйте скрипта за проследяване и неговите заявки от собствения си домейн, например през app proxy на Shopify или поддомейн на сайта ви. Списъците с филтри са насочени към известни адреси за проследяване от трети страни, затова first-party пътят е много по-труден за блокиране, макар и не невъзможен. Второ, използвайте целевата страница, която някои онлайн магазини, като Shopify, запазват с всяка поръчка. Ако този URL все още съдържа click ID или UTM параметри, поръчката може да бъде приписана без никакво събитие от браузъра.
Събитията от разглеждане все още се губят
Данните за поръчките съдържат поръчки, а не прегледи на страници. Изпращането на покупки от поръчките не връща прегледите на страници и събитията за добавяне в количката на посетител, чийто браузър е блокирал всичко. Колекторът за first-party данни може да препраща тези събития от сървъра, когато собствените му заявки минат.
Отказаното съгласие не е блокиране
Посетител, който откаже маркетинговите бисквитки в банера ви за бисквитки, не е същото като посетител с блокер на реклами. Първият посетител е направил избор, който проследяването ви трябва да спази. При включено Respect visitor consent ROASaurus не задава ID на посетителя за този посетител, така че кликванията му върху реклами и посещенията му не се свързват с него. Събитията му в браузъра се пазят без ID на посетителя, IP адрес или данни за браузъра и не се изпращат към рекламните платформи. Платената поръчка все пак се изпраща от страна на сървъра, с хеширани данни за клиента от поръчката, както и с IP адреса и user agent на поръчката. Държете двете групи отделно, когато измервате загубата си, а за подробности вижте съгласие и поверителност.
Как да оцените собствената си загуба
Не са ви нужни средни стойности за бранша, които зависят от аудиторията, устройството и държавата. Можете да измерите собствената си разлика, като сравните поръчките във вашия магазин с покупките, отчетени от пиксела в браузъра за същия период.
- Изберете период и една платформа
Използвайте 14 или 30 дни и една платформа, например Meta. Използвайте един и същ часови пояс и в двете системи.
- Пребройте уеб поръчките във вашия магазин
Започнете с всички поръчки. Премахнете поръчките, които никога не минават през онлайн страницата ви за плащане: поръчки от точка на продажба (POS), ръчни и чернови, подновявания на абонаменти и тестови поръчки.
- Пребройте събитията Purchase от браузъра
В инструмента за събития на платформата пребройте събитията Purchase, изпратени от пиксела в браузъра. Най-лесно е да го направите, преди да добавите събития от сървъра. Ако събитията от сървъра вече работят, използвайте изгледа на платформата по метод на връзка, ако предлага такъв. Events Manager на Meta показва метода на връзка на всяко събитие и ги брои там преди дедупликацията. Не използвайте приписаните покупки от отчета за реклами.
- Разделете
Покупките от браузъра ÷ уеб поръчките е делът, който пикселът е видял. Останалото е вашата разлика.
- Отделете съгласието от блокирането
Оценете поръчките от посетители, които са отказали маркетинговите бисквитки, с процента на отказите от инструмента ви за съгласие. Останалото са предимно блокери на реклами, настройки за поверителност и страници, които не са се заредили.
| Примерен магазин, 30 дни | Поръчки | Дял от уеб поръчките |
|---|---|---|
| Всички поръчки в магазина | 1,240 | |
| Поръчки от точка на продажба, ръчни поръчки и подновявания | −90 | |
| Уеб поръчки | 1,150 | 100% |
| Събития Purchase от пиксела в браузъра | 874 | 76% |
| Разлика | 276 | 24% |
| Приблизителни поръчки от посетители, които са отказали съгласие (процент на отказ 10%) | 115 | 10% |
| Остатък: блокери на реклами, настройки за поверителност, страници, които не са се заредили | 161 | 14% |
Разликата променя и ROAS. Да допуснем, че Meta отчита ROAS 2.0 за този магазин, а ROAS на точката на рентабилност е 2.3. По данните от пиксела кампаниите губят пари. Ако поръчките от реклами са били пропускани със същия процент от 24% като всички уеб поръчки, пикселът е видял само 76% от приходите от реклами. Реалният ROAS тогава би бил около 2.0 ÷ 0.76 = 2.6, над точката на рентабилност. Това е горна оценка, защото не всяка липсваща поръчка идва от реклама. Нашето ръководство за ROAS на точката на рентабилност обяснява как да зададете този праг.
Как да намалите загубите си
Решенията са едни и същи за всяка платформа за онлайн магазини. Работят най-добре заедно.
- Изпращайте покупките от данните за поръчките. Това затваря разликата в покупките за всяка платформа, която свържете, независимо от това какво блокира браузърът на посетителя.
- Запазете пиксела със споделен ID на събитието. Посетителите без блокер продължават да изпращат събития от браузъра с бисквитки и контекст на страницата. Един и същ ID на събитието на двете копия позволява на платформата да запази само едно. Вижте как да избегнете двойното отчитане.
- Събирайте данните като first-party. Предоставяйте скрипта за проследяване и неговите събития от собствения си домейн, така че click ID-тата да се запазват за повече посетители.
- Изпращайте хеширани данни за клиента. Имейлът и телефонът от поръчката позволяват на платформата да съпостави покупки, които нямат click ID.
- Измерете отново. Повторете сравнението след месец. Събитията Purchase, които платформата получава, вече трябва да съвпадат с вашите уеб поръчки.
Как ROASaurus се справя с блокерите на реклами
ROASaurus изпраща всяка платена поръчка от страна на сървъра към рекламните платформи, които добавите в Tracking & platforms, така че блокер на реклами в браузъра на купувача не спира покупката. В Shopify събитията от витрината минават през app proxy на Shopify на собствения домейн на вашия магазин. Можете също да предоставяте скрипта и неговите събития от CNAME поддомейн на сайта ви. Когато посетителят няма контакт в браузъра, атрибуцията на ROASaurus се връща към click ID-тата и UTM параметрите в URL адреса на целевата страница на поръчката, когато магазинът записва такъв, както прави Shopify.
Всяко изпращане и отговорът на платформата са изброени в Event log, така че можете да проверите дали всяка поръчка е стигнала до всяка платформа. За настройката вижте проследяването от страна на сървъра и интеграцията с Shopify.
Източници
- EasyList: Overview
- Brave: Brave Shields
- MDN Web Docs: Firefox tracking protection
- WebKit: Tracking Prevention in WebKit
- Meta for Developers: Verifying Your Setup