Як додати серверний трекінг до послуг вашої агенції

Більшість агенцій втрачають проєкт із серверного трекінгу не через ціну. Вони втрачають його протягом сорока п'яти секунд після того, як потенційний клієнт запитує: «То що саме я купую?», а відповідь починається зі слів «по суті».

Я бачив, як щиро зацікавлений потенційний клієнт замовкав, поки хтось у Zoom демонстрував екран із блоком під назвою «контейнер», потім показував другий блок, а потім пояснював різницю між цими двома блоками людині, яку насправді цікавило лише те, скільки це коштує і який буде результат.

Серверний тегінг важко продати не тому, що він технічно складний. Його важко продати, бо більшість із нас так і не навчилися добре пояснювати, у чому полягає послуга.

Приділіть хвилинку й подивіться, як ви зараз описуєте це в комерційній пропозиції. Я зачекаю.

Якщо ви схожі на більшість агенцій, то маєте пояснення архітектури з числом, прикріпленим в кінці. Дані йдуть із браузера на ваш тегінг-сервер, далі в GA4, Meta та куди завгодно, і все це коштуватиме $14,000.

Це не послуга. Це малюнок із доданим цінником.

У послуги є початок, кінець, перелік того, що ви передасте, перелік того, чого не передасте, і чітка відповідь на запитання «що буде на сьомий місяць?». Клієнти купують послуги. Ніхто не хоче купувати рішення, про яке не має жодного уявлення.

Вихід – чіткіше пояснювати результати.

Перш ніж сформувати пакет послуг, розкладіть усе на складові. Серверний трекінг – це три окремі покупки, які агенції зазвичай зводять в одну суму:

• Інфраструктура: сам тегінг-сервер. Регулярні витрати на платформу, як на хостинг, бо це і є хостинг.
• Впровадження: налаштування контейнера, кастомний домен, маршрутизація згоди, підключення платформ, QA. Проєкт із датою завершення.
• Підтримка: хтось, хто стежить за системою, виправляє її, коли постачальник непомітно змінює API, і повідомляє вам, коли дані перестають надходити. Постійна послуга.

Клієнти зазвичай питають про впровадження, але майже ніколи – про підтримку, а саме вона визначить, чи все це ще працюватиме через рік. Порушити це питання – ваше завдання: поясніть, чому за підтримку варто регулярно платити, і зробіть це заздалегідь. Так ви не станете крайніми на сьомий місяць.

Щойно ви розділите ці три складники, можна формувати пакет.

Що входить: інвентаризація поточного тегінгу, налаштувань згоди, платформ, які справді важливі для цього бізнесу, організації процесу релізів у команди розробників, а також базовий рівень того, що втрачається просто зараз. Саме останній пункт і вирішує все. Коефіцієнт конверсії клієнта в Safari поруч із коефіцієнтом конверсії в Chrome – найкращий слайд, щоб показати цінність проєкту, і я майже не брав участі в його створенні. Більшу частину роботи зробив ITP.

Це захистить вас пізніше, коли ви перейдете до впровадження.

Пропишіть, що входить у послугу, а не просто «впровадження серверного трекінгу»:

• Розгортання серверного контейнера, власний піддомен, передача DNS;
• Рефакторинг вебконтейнера для маршрутизації подій на сервер;
• Серверне налаштування GA4;
• Підключення Conversions API для зазначених платформ;
• Інтеграція Consent Mode з наявною CMP клієнта;
• Налаштування ID події та дедуплікації;
• QA у різних браузерах, зокрема на справжньому iPhone;
• Документація та сесія з передачі проєкту.

Справді називайте платформи, які додаватимете. Фраза «та інші платформи за потреби» змусить вас дев’ятому тижні пізно вночі безкоштовно налаштовувати TikTok Events API, переконуючи себе, що це інвестиція у стосунки з клієнтом.

Потім пропишіть, що не входить у послугу, тим самим розміром шрифту, що й те, що входить. Постійний моніторинг. Нові платформи. Редизайн сайту. Імпорт офлайн-конверсій. Інтеграція з CRM, про яку клієнт запитає на третьому тижні так, ніби це дрібниця.

Обов'язково поясніть, як виглядає завершена робота, бо тоді можна переходити до подальшого продажу послуги.

Це складно, бо це правда, але ніхто не хоче її чути.

Тегінг ніколи не буває «завершеним»; хтось має його підтримувати. Мене запрошували провести аудит трекінгу, який роками ніхто не підтримував, і картина там жахлива. Зламані теги. 600 тригерів, які не використовуються. Якість даних, від якої аж пересмикує.

Оцінюйте вартість послуги з огляду на те, що вона забезпечує, а не на кількість ваших робочих годин. Клієнт, який витрачає $40,000 на місяць на платну рекламу, купує страховку на $480,000 рекламного бюджету на рік. Якщо подати це так, абонентська плата явно невисока. (Якщо ж подати це як «дванадцять годин QA тегів», ваша послуга ніколи, ну ніколи не здаватиметься недорогою)

Три речі, які варто зафіксувати письмово, щоб сформувати чіткі очікування:

Стеля очікувань. Класичні браузерні системи трекінгу зазвичай втрачають десь у діапазоні 15–40% залежно від структури трафіку. Ви скорочуєте цей розрив, а не усуваєте його. Переконайтеся, що клієнт розуміє: це не вирішить 100% проблеми втрати трафіку й конверсій, але суттєво допоможе.

Те, що це не засіб обходу згоди. Серверний трекінг повертає конверсії від людей, які вже погодилися на збір даних і чий тег однаково заблокували. Якщо хтось каже «ні», це й надалі означає «ні». Якщо ваша конфігурація працює інакше, це не функція, а проблема з дотриманням вимог.

Розмова про розбіжності. Приблизно на шостому тижні кількість зафіксованих конверсій стрибне, і щомісячні звіти вашого клієнта виглядатимуть неправильними в ретроспективі, бо такими вони й були весь час до впровадження. Це делікатна річ, яку доведеться пояснювати віцепрезидентові, який весь рік звітував про ці цифри керівництву. Стрибок конверсій – це чудовий результат і жахлива несподіванка.

Вам не потрібні нові компетенції, щоб додати серверний трекінг до своїх послуг; достатньо зрозуміло його пояснювати.

Пропишіть три послуги – аудит, впровадження та постійну підтримку – і визначте ціну для кожної окремо.

Наступного разу, коли потенційний клієнт запитає: «То що саме я купую?», дайте йому результати, а не технічне пояснення.