Server-side tracking: 5 мест, где «без куки» проект сливает данные в ноль

Server-side tracking: 5 мест, где «без куки» проект сливает данные в ноль

Server-side tracking — это не магия и не способ «обмануть privacy». Это просто перенос части сбора и передачи событий с браузера на свой сервер: меньше шума, больше контроля, но и больше ответственности за схему данных.

Самые частые провалы:
— дубли событий: браузер и сервер шлют одно и то же, атрибуция плывёт;
— нет стабильного event_id: дедупликация превращается в гадание на кофейной гуще;
— разные названия полей у CRM, аналитики и adtech-эндпойнтов;
— сервер шлёт «сырой» мусор без нормализации user agent, referrer, consent state;
— забывают про retry и логирование, а потом «потерянные» конверсии ищут по интуиции.

Правильная схема начинается не с пикселя, а с контракта данных: какие события, в каком порядке, с какими обязательными полями и кто источник истины. Если этого нет, server-side превращается в дорогой ретранслятор хаоса, а не в cookieless атрибуцию.

Отдельно проверь: consent должен ехать вместе с событием, PII — не гулять по пайплайну, а идентификаторы — быть предсказуемыми между каналами. Иначе privacy получится только на слайде для юристов.

Сначала нарисуйте схему, потом заводите серверный сбор. Иначе получите не новый стандарт, а ещё один релиз года, который красиво выглядит в демо и грустит в проде. Может, конечно, и не взлетит.