Проследяване

Блокери на реклами и проследяване: какво губи вашият магазин

Блокерите на реклами спират пикселите за проследяване, затова рекламните платформи пропускат покупки. Вижте кои събития се губят, защо събитията от страна на сървъра не се губят и как да измерите своята разлика.

·8 мин четене·От екипа на ROASaurus

Основни изводи
  • Блокерите на реклами използват списъци с филтри, за да спрат скриптовете на пикселите и техните заявки, така че рекламната платформа не получава никакво събитие от този браузър.
  • Блокираният пиксел губи прегледи на страници, събития за добавяне в количката и покупки, а покупката е най-важна, защото определя отчетения 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 на поръчката. Държете двете групи отделно, когато измервате загубата си, а за подробности вижте съгласие и поверителност.

Как да оцените собствената си загуба

Не са ви нужни средни стойности за бранша, които зависят от аудиторията, устройството и държавата. Можете да измерите собствената си разлика, като сравните поръчките във вашия магазин с покупките, отчетени от пиксела в браузъра за същия период.

  1. Изберете период и една платформа

    Използвайте 14 или 30 дни и една платформа, например Meta. Използвайте един и същ часови пояс и в двете системи.

  2. Пребройте уеб поръчките във вашия магазин

    Започнете с всички поръчки. Премахнете поръчките, които никога не минават през онлайн страницата ви за плащане: поръчки от точка на продажба (POS), ръчни и чернови, подновявания на абонаменти и тестови поръчки.

  3. Пребройте събитията Purchase от браузъра

    В инструмента за събития на платформата пребройте събитията Purchase, изпратени от пиксела в браузъра. Най-лесно е да го направите, преди да добавите събития от сървъра. Ако събитията от сървъра вече работят, използвайте изгледа на платформата по метод на връзка, ако предлага такъв. Events Manager на Meta показва метода на връзка на всяко събитие и ги брои там преди дедупликацията. Не използвайте приписаните покупки от отчета за реклами.

  4. Разделете

    Покупките от браузъра ÷ уеб поръчките е делът, който пикселът е видял. Останалото е вашата разлика.

  5. Отделете съгласието от блокирането

    Оценете поръчките от посетители, които са отказали маркетинговите бисквитки, с процента на отказите от инструмента ви за съгласие. Останалото са предимно блокери на реклами, настройки за поверителност и страници, които не са се заредили.

Примерен магазин, 30 дниПоръчкиДял от уеб поръчките
Всички поръчки в магазина1,240
Поръчки от точка на продажба, ръчни поръчки и подновявания−90
Уеб поръчки1,150100%
Събития Purchase от пиксела в браузъра87476%
Разлика27624%
Приблизителни поръчки от посетители, които са отказали съгласие (процент на отказ 10%)11510%
Остатък: блокери на реклами, настройки за поверителност, страници, които не са се заредили16114%
В този примерен магазин пикселът пропуска около 1 от 4 уеб поръчки. Около 1 от 7 се губи заради блокиране и грешки в браузъра, а не заради съгласието.

Разликата променя и ROAS. Да допуснем, че Meta отчита ROAS 2.0 за този магазин, а ROAS на точката на рентабилност е 2.3. По данните от пиксела кампаниите губят пари. Ако поръчките от реклами са били пропускани със същия процент от 24% като всички уеб поръчки, пикселът е видял само 76% от приходите от реклами. Реалният ROAS тогава би бил около 2.0 ÷ 0.76 = 2.6, над точката на рентабилност. Това е горна оценка, защото не всяка липсваща поръчка идва от реклама. Нашето ръководство за ROAS на точката на рентабилност обяснява как да зададете този праг.

Как да намалите загубите си

Решенията са едни и същи за всяка платформа за онлайн магазини. Работят най-добре заедно.

  1. Изпращайте покупките от данните за поръчките. Това затваря разликата в покупките за всяка платформа, която свържете, независимо от това какво блокира браузърът на посетителя.
  2. Запазете пиксела със споделен ID на събитието. Посетителите без блокер продължават да изпращат събития от браузъра с бисквитки и контекст на страницата. Един и същ ID на събитието на двете копия позволява на платформата да запази само едно. Вижте как да избегнете двойното отчитане.
  3. Събирайте данните като first-party. Предоставяйте скрипта за проследяване и неговите събития от собствения си домейн, така че click ID-тата да се запазват за повече посетители.
  4. Изпращайте хеширани данни за клиента. Имейлът и телефонът от поръчката позволяват на платформата да съпостави покупки, които нямат click ID.
  5. Измерете отново. Повторете сравнението след месец. Събитията Purchase, които платформата получава, вече трябва да съвпадат с вашите уеб поръчки.
Примерен магазин: събития Purchase, получени от Meta за 30 дни
Само пикселПиксел + сървър, с дедупликация
Събития Purchase
874
1,150
След като покупките се изпращат от данните за поръчките, всичките 1,150 уеб поръчки стигат до платформата. Пикселът все пак добавя данни от браузъра за 874-те поръчки, които е видял.

Как ROASaurus се справя с блокерите на реклами

ROASaurus изпраща всяка платена поръчка от страна на сървъра към рекламните платформи, които добавите в Tracking & platforms, така че блокер на реклами в браузъра на купувача не спира покупката. В Shopify събитията от витрината минават през app proxy на Shopify на собствения домейн на вашия магазин. Можете също да предоставяте скрипта и неговите събития от CNAME поддомейн на сайта ви. Когато посетителят няма контакт в браузъра, атрибуцията на ROASaurus се връща към click ID-тата и UTM параметрите в URL адреса на целевата страница на поръчката, когато магазинът записва такъв, както прави Shopify.

Всяко изпращане и отговорът на платформата са изброени в Event log, така че можете да проверите дали всяка поръчка е стигнала до всяка платформа. За настройката вижте проследяването от страна на сървъра и интеграцията с Shopify.

Източници

  1. EasyList: Overview
  2. Brave: Brave Shields
  3. MDN Web Docs: Firefox tracking protection
  4. WebKit: Tracking Prevention in WebKit
  5. Meta for Developers: Verifying Your Setup

В ROASaurus

Продължете да четете

ПроследяванеConsent Mode v2 и GDPR: какво може да изпраща един онлайн магазинConsent Mode v2 за онлайн магазини: четирите сигнала за съгласие на Google, какво изисква законодателството на ЕС и какво проследяването от страна на сървъра все още може да изпраща. Само обща информация.ПроследяванеДублирани събития за покупка: защо продажбите се отчитат два пътиДублираните събития за покупка завишават конверсиите и ROAS. Вижте причините, как Meta, TikTok, Snapchat, Pinterest и Reddit правят дедупликация и как да го поправите.ПроследяванеSafari ITP и проследяване на реклами: какво все още работиSafari ITP ограничава бисквитките, зададени от скриптове, до 7 дни, или до 24 часа след някои кликвания върху реклами. Вижте как това влияе на атрибуцията и кое проследяване все още работи.
ЧЗВ

Въпроси и отговори

Блокират ли блокерите на реклами пиксела на Meta?

Много блокери на реклами и браузъри за поверителност го блокират. Когато скриптът е блокиран, до Meta не стигат събития от браузъра на този посетител, но покупките, изпратени от страна на сървъра от данните за поръчките ви, все пак пристигат.

Колко купувачи използват блокери на реклами?

Зависи от вашата аудитория, устройства и държави, затова общо число казва малко за вашия магазин. Измерете собствената си разлика, като сравните уеб поръчките със събитията Purchase, изпратени от пиксела ви за същия период.

Могат ли блокерите на реклами да блокират проследяването от страна на сървъра?

Не и покупката, изпратена от данните за поръчките, защото тази заявка върви от сървър към API на платформата. Блокерът може да спре скрипта в браузъра, който запазва click ID, затова събирането на first-party данни е важно.

Блокерът на реклами същото ли е като отказ от съгласие?

Не. Отказът от съгласие е избор в банера ви за бисквитки, който проследяването ви трябва да спази. Блокерът на реклами е инструмент в браузъра. И двете намаляват събитията от пиксела, затова ги измервайте поотделно.

Все още ли ми е нужен пикселът, ако изпращам покупките от страна на сървъра?

Да, за посетителите без блокер. Пикселът добавя събития от разглеждане и бисквитки на браузъра, а при един и същ ID на събитието платформата запазва по едно копие на всяка покупка.

Всяка продажба, проследена до рекламата, която я е донесла

Проследяване от страна на сървъра, печалба и пожизнена стойност на клиента в едно приложение. 14-дневен безплатен пробен период, без кредитна карта.

Започнете безплатния си пробен период →