Броят резервации в рекламния акаунт се различава от броя в хотелския календар. И двете числа могат да бъдат реални. Те наблюдават различни части от пътуването с различни средства, а ограниченията в браузъра правят разликата по-видима. Сървърното проследяване на реклами за хотел може да върне част от липсващото отчитане, но не превръща атрибуцията в копие на операциите.
Първата стъпка е да спрете да третирате всяка разлика като повредена кампания.
Какво се промени в браузъра
Традиционното проследяване разчита на pixel: скрипт в браузъра записва действие и го изпраща към рекламната или аналитичната платформа. Пътят зависи от това скриптът да работи, съответният идентификатор да остане достъпен и гостът да е дал изискваното съгласие.
Браузърите ограничават, блокират или съкращават живота на много механизми. Разширения спират скриптове. Банерът легитимно забранява маркетингово проследяване след отказ. Преминаването от телефон към лаптоп също може да скъса връзката между рекламата и потвърждението.
Резервацията продължава да се случва. Браузърът просто може да не я докладва.
Това не доказва, че някой крие прихода ви. Хотелският софтуер записва търговско събитие в обекта. Платформата брои само онова, което може да наблюдава и припише по своите правила.
Разделете три въпроса:
- Съществува ли резервацията в календара?
- Изпратено ли е събитие по допустим маршрут?
- Може ли платформата да го свърже с подходящо рекламно взаимодействие?
Отрицателният отговор на всеки означава различен проблем. Server-side tracking подобрява приемането и предаването на данни за събития (events), но не гарантира, че то може или трябва да бъде приписано.
Как работи сървърното проследяване за реклами на хотел
При browser tracking устройството на госта докладва действието. При Conversions API сървърът на хотела или резервационната платформа изпраща потвърдената резервация към рекламната система след създаването ѝ.
Този маршрут на информацията не зависи от същия скрипт на финалната страница. Хотелският софтуер знае, че резервацията е създадена, дори гостът да затвори таба, да използва ограничен браузър или плащането да не върне събитие правилно.
Сървърът може да знае и по-късна промяна.- например ако резервацията се модифицира или анулира след първоначалното потвърждение. Когато платформата и реализацията поддържат съответното събитие, може да бъде подадено развитие, което първоначалният pixel не е знаел.
Нужни са постоянни определения: име, време, стойност, валута и подходящ идентификатор за съпоставяне. Личните данни трябва да бъдат ограничени, защитени и обработени според целта и изискванията.
HotPilot поддържа Meta Pixel плюс Conversions API, server-side GA4 събития по фунията и TikTok Events API. Това са различни дестинации. „Покупка“ не бива да означава потвърждение в една и реализиран престой в друга.
Сървърният маршрут подобрява подаването на информация към платформата. Той не поправя объркана структура на кампании, счупен booking engine или лошо проектирано съгласие за обработване на данни.
Deduplication пази една резервация от двойно броене
Browser и server събития често работят едновременно. Pixel може успешно да докладва потвърждението, а сървърът да изпрати същата резервация по надеждния маршрут. Без разпознаване платформата брои две конверсии.
Двете версии трябва да споделят един идентификатор на събитието. Така платформата разбира, че описват една резервация, видяна по два пътя, и запазва една конверсия.
Това е deduplication.
Най-видимият дефект е внезапно подобрение, което изглежда прекалено добро. Докладваните резервации скачат след старта, но календарът не. Преди да празнувате успешната кампания, проверете дали двата маршрута използват общ и уникален за резервацията идентификатор.
Други потенциални проблеми:
- Нов идентификатор се създава при всяко презареждане.
- Няколко стаи в една резервация се третират непоследователно.
- Анулация се изпраща като нова покупка.
- Тестовите резервации остават в реалните отчети.
Сравнете събитията с календара за контролиран период и прегледайте примерни идентификатори, не личните данни на госта. Търсете една оперативна резервация към една отчетена конверсия след премахване на дубъла.
Не изключвайте pixel само за да скриете проблема. Двата сигнала могат да се допълват. Поправете общата самоличност и логиката.
Сървърното проследяване не заобикаля съгласието
Сървърното проследяване не е начин за заобикаляне на съгласието за обработване на данни. Ако гостът е отказал маркетингово проследяване, този избор трябва да пътува с резервацията и да определя дали събитието може да бъде изпратено за тази цел.
Преместването от браузъра към сървъра прави действието по-малко видимо за човека; не премахва правното и етично изискване. Който го продава като обход, предлага на хотела риск, не подобрение.
Изборът трябва да е наличен там, където сървърът решава какво да изпрати. Ако състоянието остане само в browser banner, то не може да ръководи последващото booking събитие, освен ако не бъде пренесено безопасно и запазено подходящо.
Разделяйте целите. Данните, нужни за създаване и обслужване на резервация, не са автоматично достъпни за рекламна атрибуция. Хотелът може да се нуждае от данните за престоя и да няма право да ги изпрати към маркетингова платформа.
Прегледайте със своя privacy консултант:
- Кое събитие стига до коя платформа?
- Каква цел и съгласие го позволяват?
- Кои полета напускат системата?
- Как се обработва оттегляне?
При неясен статус системата трябва да спира безопасно, а не да предполага, че мълчанието е разрешение.
Дедупликацията най-често се обърква, а активният рекламен профил не е място за експерименти. Преди да пуснете сървърно проследяване, разгледайте правилно свързана настройка.
Какво реалистично се възстановява
Сървърните събития могат да затворят част от пропуска от блокирани скриптове, краткотрайни идентификатори и ненадеждно връщане след плащане. След добра реализация платформата може да отчита повече от резервациите, които законно може да съпостави.
Няма да възстанови всичко.
Някои гости отказват. Някои резервации не се свързват с реклама. Cross-device пътувания остават непълни, attribution windows изключват пътища, а платформите прилагат свои модели. По-късната анулация също раздалечава потвърждението и реализирания приход.
Не обещавайте процент на възстановяване. Универсална стойност няма, защото изходният пропуск зависи от пазари, устройства, избори за съгласие, booking flow и старото качество.
Използвайте атрибуция и анализ на клиентското пътуване, за да сравните посоката преди и след, докато календарът остава източникът за резервациите. Следете дали разликата става по-стабилна и кампаниите получават последователен сигнал.
Идеалното съвпадение не е критерий. Ако платформата внезапно е равна на календара, проверете дали не се насилват недопустими, двойни или неприписани събития. Правилното и пълно измерване има граници.
Атрибуцията сравнява кампании, не брои приход
Хотелският софтуер брои резервации, промени, анулации и оперативна стойност. Счетоводството отчита заработения приход. Рекламната платформа отговаря на по-тесен въпрос: според наблюдавания и разрешен модел коя кампания допринася по-добре?
Това остава полезно. Ако две кампании предлагат сходни престои и едната последователно носи по-силни допустими сигнали при устойчив разход, имате основа за бюджет. И двете може да са отчетени под реалните им (най-често по-високи) резултати, но относителният модел да е информативен.
Поддържайте сравненията:
- еднаква дефиниция на конверсия;
- сходни периоди и пазарни условия;
- бележки за промени в tracking, consent и flow;
- проверка на анулации и стойност в календара.
Не представяйте attributed value като финален приход. Потвърждението може да бъде променено или анулирано и да съдържа компоненти, третирани различно в счетоводството.
Кампания за дълъг междинен престой не се сравнява само по брой с уикенд кампания. Престоят има различна стойност, момент на резервация и поведение на потребителя.
Атрибуцията е помощ за решение с липсваща информация. Опасна става, когато бъде объркана със счетоводна книга.
Да обобщим!
- Ограниченията и съгласието/несъгласието на потребителите да се обработват техни данни могат да спрат информацията за реална резервация да достигне рекламната платформа.
- Conversions API изпраща потвърждението от сървъра, вместо да зависи от браузъра.
- Browser и server версиите споделят идентификатор, за да не се броят два пъти.
- Server-side tracking не заобикаля consent; изборът на госта управлява и сървърното събитие.
- По-доброто отчитане затваря част от пропуска, без универсално обещание.
- Атрибуцията сравнява кампании, а календарът и счетоводството броят резервации и приход.
Ако смятате, че рекламните платформи и вашата резервационна система не отчитат коректно и искате да разберете къде може да се чупи връзката, свържете се с нас и поискайте демо.
