Разночтения в событиях: как одна и та же конверсия перестаёт быть конверсией
В последний месяц чаще замечаю паттерн: компании встраивают server-side разметку (или “успешный” прокси-слой), но итоговые отчёты начинают расходиться уже на уровне базовых событий — без смены трекинг-стека и без редизайна воронки. Обычно это выглядит так: в веб-аналитике событие “Lead/Submit” считается по одному набору триггеров, а в CRM или BI — по другому (например, отличается условие валидации полей, или часть запросов помечается как retries). В результате одна и та же форма даёт два разных “источника правды”: маркетинг видит конверсию, а RevOps (работа за выручку вместе с sales и customer success) — подтверждённый оффер уже после внутренней обработки.
Что именно бросается в глаза при разборе: рост доли дубликатов/пересчётов после включения очередей, ретраев и дедупликации по key (например, по message_id, но формируется он нестабильно).
Вы тоже видите, что разъезжаются не кампании, а сами определения событий? На вашей стороне причина чаще в дедупе, в условиях “успешности”, или в том, как вы связываете user/session с CRM-идентификаторами?
— @ServerSideTrackingRuPro
Server-side tracking
@ServerSideTrackingRuPro
Разночтения в событиях: как одна и та же конверсия перестаёт быть конверсией
Этот пост опубликован в Telegram-канале Server-side tracking. Подписаться можно по ссылке: @ServerSideTrackingRuPro.