Зоопарк сервисов: почему вход в воронку и оплата не сходятся

В проекте всё работает по отдельности: бот собирает заявки, платформа школы продаёт, рекламный кабинет льёт трафик. Аналитики нет, потому что вход и оплата живут в разных системах и не встречаются.

Это не проблема количества сервисов. Можно работать в двух системах и не иметь связи. Можно работать в пяти и иметь. Вопрос в том, есть ли поле, которое проходит путь человека от первого касания до платежа и записывается в обеих системах.

Почему «зоопарк» — это не про количество

Когда в проекте появляется новый сервис, его обычно оценивают по функциям: умеет ли он принимать заявки, отправлять письма, считать оплаты. Но для аналитики важнее другое: что происходит с человеком на стыке между сервисами.

Если бот знает человека по одному идентификатору, сайт — по другому, а платёжная система — по номеру заказа, то путь разрывается на три куска. Каждый кусок может быть красивым. Соединить их в один путь нельзя, пока нет общего ключа.

Поэтому «зоопарк» — это не про количество инструментов. Это про отсутствие договорённости, как один и тот же человек называется в каждой системе.

Почему два сервиса — уже зоопарк

Можно иметь бота и платформу школы — и уже потерять связь. Бот знает человека по внутреннему идентификатору, платформа — по email или номеру заказа. Если между ними нет общего поля, путь рвётся на входе.

И наоборот: можно иметь пять сервисов и одну сквозную связку, если ключ и правила согласованы. Количество само по себе ничего не решает.

Поэтому начинать нужно не с сокращения сервисов, а с вопроса: какое поле проходит путь человека через все системы? Если такого поля нет, сокращение не поможет.

Что ломается на стыках

• Пользователь опознаётся по-разному. В боте — идентификатор, на сайте — почта, в платежах — номер заказа. Без общего поля это три разных человека.
• Источник теряется при переходе. Клик был в рекламном кабинете, регистрация — в боте, оплата — в платформе. На каждом переходе часть метки может не дойти.
• Одна и та же покупка приходит дважды. Например, из платформы и из платёжной системы. Без правила дедупликации вы складываете разные отражения одной продажи.
• Часть заказов остаётся без источника. И это не одно и то же, что «неизвестный источник». В одном случае событие известно, но не назначено. В другом — источник потерян.
• Отчёт строится, но его нельзя проверить на конкретном человеке. Если вы не можете пройти путь одного заказа от входа до оплаты, отчёт пока не доказательство.

Каждый пункт — не техническая мелочь. Это разрыв в цепи, из-за которого конверсия между входом и оплатой перестаёт быть измеримой.

Как выглядит разрыв в отчёте

В отчёте это выглядит безобидно. Есть строка «заказы без источника», есть процент. Если он небольшой, его легко проигнорировать.

Но за этой строкой могут стоять разные люди: те, кто пришёл напрямую; те, у кого потерялась метка; те, кто зашёл через бота и не был сопоставлен с заказом. Пока вы не разделили эти группы, вы не знаете, что именно чинить.

И ещё: разрыв может быть не в источнике, а в оплате. Заказ есть, оплата есть, но между ними нет ключа. Тогда отчёт покажет продажу без привлечения, а на самом деле привлечение было.

Устойчивый ключ: что это

Устойчивый ключ — это поле, которое создаётся на первом событии и не меняется до оплаты.

Примеры: идентификатор пользователя в боте, внешний идентификатор заказа, номер заявки. Он должен записываться и там, где человек впервые появился, и там, где он платит.

Последний UTM в карточке — не ключ. Он может перезаписаться, потеряться или относиться к другой сессии. Если человек вернулся через месяц по другому объявлению, последняя метка затрёт первую, и вы потеряете источник привлечения.

Ключ должен быть:

• стабильным — не меняется при повторном входе;
• сквозным — записывается в обеих системах;
• проверяемым — его можно увидеть в конкретном заказе;
• понятным — команда знает, где он создаётся и кто за него отвечает.

Контракт события

Чтобы ключ не потерялся, его нужно закрепить в контракте события. Это короткий документ, где описано, какие поля и в какой момент пишутся.

Обычно в нём пять вещей: кто создал событие, когда оно произошло, к какому объекту относится, какой у него ключ и какой источник. Если хотя бы одно поле не заполняется, связь рвётся.

Контракт нужен не аналитику для отчёта. Он нужен команде и подрядчикам, чтобы каждый новый сервис писал данные по одним правилам. Без него через полгода появится ещё один «зоопарк».

Три состояния источника

Когда вы смотрите на заказы без источника, полезно разделить их на три группы.

1. Источник известен. Есть метка и правило, по которому она назначается. С этим можно работать. 2. Ссылка не классифицирована. Переход был, но кампания не сопоставлена с каталогом. Это не потеря, а неполная настройка. 3. Ссылки нет. Человек пришёл напрямую или данные не сохранились. Здесь другой диагноз и другие действия.

«Не распределено» — это известное событие без назначения. «Неизвестно» — потерянный источник. Если смешать эти категории, вы будете чинить не то.

Порядок действий: от ключа к отчёту

Первый шаг. Инвентаризация. Выпишите, где начинается путь, где человек платит и где лежат расходы. Не пропускайте ручные статьи и подрядчиков.

Второй шаг. Выберите ключ. Проверьте, что он есть в обеих системах и что его можно увидеть в конкретном заказе.

Третий шаг. Измерьте полноту связи. Посчитайте, у скольких заказов ключ заполнен. Это не «процент хороших данных», а метрика качества соединения.

Четвёртый шаг. Посмотрите несвязанный остаток. Что именно не соединилось: новые заказы, старые, конкретный канал, конкретный тип оплаты.

Пятый шаг. Только теперь стройте отчёт и считайте конверсии. Если пропустить третий шаг, отчёт будет красивым, а выводы — случайными.

Что делать, если ключа нет

Начинать писать его сегодня. История не восстановится, но через месяц появится связь для новых заказов.

Для старых периодов остаётся ручная сверка по конкретным заказам. Это дорого, но честно. Не обещайте восстановить то, что не сохранялось: это создаёт ложное доверие к отчёту.

И ещё: не начинайте с покупки нового сервиса. Сервис без ключа и правил добавит ещё один красивый экран, но не решит разрыв.

Пока связь не измерена, любая конверсия между входом и оплатой — это предположение. Сначала проверяется связь, потом считаются проценты.

А как аналитик скажу: пока расход не связан с платежом, вы обсуждаете не окупаемость, а стоимость клика. Это не одно и то же, хотя в отчётах они часто стоят рядом.

Что останется у вас после настройки

• Контракт события: какие поля, когда и где пишутся.
• Метрика полноты связи: сколько заказов соединено и сколько нет.
• Правило для несвязанного остатка: что с ним делать и кто отвечает.
• Отчёт, который проверяется на конкретном заказе.
• Ответственный за поддержку ключа при изменениях воронки.

Это важнее интерфейса. Интерфейс можно поменять, а разорванную связь придётся собирать заново.

Кто отвечает за связь

Отчёт не чинит связь сам. Нужен человек, который отвечает за ключ и полноту связи: обычно это аналитик или тот, кто владеет данными.

Его задачи простые: следить, чтобы новый сервис писал ключ; проверять полноту после изменений; разбирать несвязанный остаток; сообщать, когда связь просела.

Если такого человека нет, связь живёт до первого нового сервиса. А новый сервис появляется быстро.

Что сделать на этой неделе

• Выпишите все системы, через которые проходит путь от рекламы до оплаты.
• Найдите поле, которое есть в каждой из них.
• Проверьте на десяти заказах, заполняется ли оно.
• Разделите заказы без источника на «не распределено» и «неизвестно».
• Не считайте конверсии, пока не поймёте, какая часть пути соединена.