Какво е проследяване от страна на сървъра? Ръководство за онлайн магазини

Проследяването от страна на сървъра означава, че събитията за конверсии, като покупка, се изпращат към рекламните платформи от сървър, а не само от скрипт в браузъра на купувача. При онлайн магазин сървърът изпраща всяка поръчка към Meta, TikTok или Google през техните API, така че продажбата се отчита дори когато пикселът в браузъра е блокиран или никога не се зареди.

Това ръководство обяснява разликата между пиксел в браузъра и проследяване от страна на сървъра, следва данните от кликването върху рекламата до рекламната платформа и показва какво съдържа едно събитие от сървъра. Обхваща още дедупликацията, server-side tagging, съгласието и как да разберете дали магазинът ви има нужда от него. За самата настройка в Shopify прочетете проследяването от страна на сървъра в Shopify.

Пиксел в браузъра срещу проследяване от страна на сървъра

Пикселът в браузъра е фрагмент JavaScript код от рекламната платформа. Той се изпълнява във вашите страници и изпраща събития от устройството на купувача директно към платформата: преглед на страница, добавяне в количката, покупка на страницата за благодарност. Работи само когато скриптът се зареди, изпълни и достигне до платформата, преди купувачът да напусне страницата.

Проследяването от страна на сървъра прехвърля изпращането към сървър. Събитието може да тръгне от данни, които магазинът ви вече има, например платена поръчка, а сървърът го изпраща към API на платформата. Meta нарича това API Conversions API, а TikTok — Events API. Google Ads използва enhanced conversions, които добавят хеширани данни за клиента към конверсията.

Използването и на двата дава на платформата най-пълни данни. Събитието от браузъра добавя бисквитки и контекст на страницата. Събитието от сървъра пристига дори когато браузърът се провали. Общ ID на събитието гарантира, че платформата брои всяка покупка само веднъж.

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

Проследяването от страна на сървъра за онлайн магазин има две половини. Първата се случва в браузъра: когато купувач пристигне от реклама, скрипт записва click ID от URL адреса. Втората се случва на сървъра: когато поръчката е платена, сървърът свързва този click ID с поръчката и изпраща покупката.

Улавяне на кликването

Рекламните платформи добавят click ID към URL адреса на целевата страница: fbclid за Meta, ttclid за TikTok, gclid за Google Ads и msclkid за Microsoft Ads. Click ID е най-силната връзка между една продажба и рекламата, която я е предизвикала, затова трябва да бъде запазен при първото преглеждане на страница. UTM параметрите добавят имената на кампанията, набора от реклами и рекламата във формат, който контролирате вие.

Съпоставяне на поръчката

След това сървърът трябва да знае кой посетител е направил поръчката. Най-надеждната връзка е стойност, която пътува с количката до поръчката, например ID на посетител, запазен в количката. Другите методи са по-слаби: имейл адрес, който посетителят е въвел по-рано в сайта, или същият IP адрес и браузър, видени малко преди поръчката. Всяка платформа за онлайн магазини предлага различни възможности. Нашето ръководство за други онлайн магазини изброява методите, които ROASaurus използва за всяка платформа.

Изпращане на събитието

Накрая сървърът изпраща покупката към API на всяка платформа. Събитието включва стойността на поръчката, click ID и данни за клиента, които помагат на платформата да намери човека, който е кликнал. Ако платформата не работи или върне грешка, добрата настройка опитва отново по-късно, така че покупката да не се загуби.

Какво съдържа едно събитие от сървъра?

Всяка платформа има свои имена на полетата, но събитието за покупка навсякъде носи един и същи вид данни. Ето съкратен пример за Meta Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Хеширането превръща имейл адреса във фиксиран низ от знаци. Един и същ адрес винаги дава един и същ низ, но низът не разкрива адреса. Платформата използва хешираните стойности само за да търси съвпадение сред собствените си потребители. Така една покупка може да бъде свързана с човека, който е видял рекламата или е кликнал върху нея, дори когато браузърът му е блокирал пиксела.

Как работи дедупликацията?

Когато пикселът и сървърът изпращат една и съща покупка, платформата трябва да я отчете веднъж. И двете копия носят едно и също име на събитие и един и същ ID на събитието, например order-1042. Meta сравнява двойката и запазва едно копие, стига второто копие да пристигне в рамките на 48 часа след първото.

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

Server-side tagging срещу изпращане от данните на поръчката

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

Server-side tagging, например сървърните контейнери на Google Tag Manager

При server-side tagging браузърът изпраща събитията си към вашия собствен сървър, а не към всеки доставчик поотделно. Сървърният контейнер на Google Tag Manager е добре познат пример. Той работи във вашия собствен проект в Google Cloud или в друга среда по ваш избор. Получава заявки от браузъра, а таговете му препращат данните към Google Analytics, Meta и други доставчици. Вие решавате какви данни къде да отидат, а сървърът може да работи на поддомейн на вашия сайт.

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

Изпращане от данните на поръчката

Вторият подход започва покупката от записа на поръчката във вашия магазин. Магазинът съобщава платената поръчка на сървъра чрез webhook или API, а сървърът я изпраща към всяка свързана платформа. Браузърът е нужен само по-рано, за да запази click ID, когато купувачът пристигне.

Двата подхода могат да се комбинират. Много магазини събират прегледите на страници и добавянията в количката в браузъра, а покупката изпращат от данните на поръчката. Покупката е събитието, което рекламните платформи използват, за да отчитат ROAS и да оптимизират наддаването, затова именно то най-много има нужда да бъде пълно.

Какво оправя проследяването от страна на сървъра и какво не оправя?

Съгласието все още важи

Проследяването от страна на сървъра е начин за доставяне на данни, а не начин за заобикаляне на правилата за поверителност. Когато законът изисква съгласие за маркетингови бисквитки или проследяване, това изискване обхваща данните, които събирате, независимо по какъв път стигат до платформата. Преместването на тракер на вашия сървър не променя това, с което посетителят се е съгласил.

Атрибуцията остава специфична за всяка платформа

Всяка платформа все още приписва покупките със собствени прозорци и правила. Събитията от сървъра дават на всяка платформа по-добри данни, но сборът от Meta, TikTok и Google пак може да надхвърли приходите на вашия магазин. За да сравнявате каналите по едни и същи правила, използвайте един модел на атрибуция за всички тях, например моделите в атрибуцията на ROASaurus.

Нужно ли е на вашия магазин проследяване от страна на сървъра?

Магазин, който харчи значителен бюджет за платени реклами в социалните мрежи или в търсачките, обикновено печели от това. Случаят е най-категоричен, когато са верни няколко от следните точки:

• Рекламната платформа получава ясно по-малко събития за покупка, отколкото уеб поръчки има вашият магазин. Нашето ръководство за блокерите на реклами и проследяването показва как да измерите тази разлика.
• Много от посетителите ви използват Safari на iPhone или Mac, където бисквитките, зададени от скриптове, траят най-много 7 дни. Вижте Safari ITP и проследяването на реклами.
• Купувачите често купуват дни след първото кликване върху реклама.
• Плащането приключва извън вашия сайт или поръчките се плащат по-късно, както при плащане при доставка или банков превод.
• Оптимизирате кампаниите за покупки или за стойност на покупките, така че платформата има нужда от всяка продажба, за да се учи от нея.

Ето как една разлика променя решенията на практика. Примерен магазин има 1,000 уеб поръчки за един месец. Неговият пиксел на Meta е отчел 820 събития Purchase, така че 18% от поръчките никога не са стигнали до Meta от браузъра.

ROAS на точката на рентабилност на магазина е 2.5, а Ads Manager показва ROAS 2.3 по данните от пиксела. При тези числа кампаниите губят пари. Ако поръчките, дошли от реклами, са пропускани със същия дял от 18%, реалният ROAS е около 2.3 ÷ 0.82 = 2.8, което е над точката на рентабилност. Това е горна оценка, защото не всяка липсваща поръчка е дошла от реклама. Въпреки това показва как една разлика в проследяването може да накара печеливша кампания да изглежда като губеща.

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

Как ROASaurus изпраща събития от страна на сървъра

ROASaurus улавя 19 click ID-та и шест UTM полета при пристигането на посетителя и ги записва заедно с first-party ID на посетител. Изпраща всяка покупка от платените поръчки на вашия магазин към Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll и Outbrain. В Shopify конверсиите за Google Ads се изпращат от страницата за плащане на Shopify. Пикселите в браузъра могат да работят заедно със събитията от сървъра със същия ID на събитието, а Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin и Spotify ги дедупликират. Всяко изпращане и отговорът на платформата са изброени в Event log.

Прочетете повече на страницата за проследяване от страна на сървъра или намерете своя онлайн магазин на страницата за интеграции.

Източници

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

В ROASaurus

• Проследяване от страна на сървъра в ROASaurus
• Съгласие и поверителност
• Избягване на двойното отчитане

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