Как настроить передачу лидов между байером и аналитиком без потерь и дублей

Как настроить передачу лидов между байером и аналитиком без потерь и дублей

Передача лидов ломается не на трекере, а на договорённости. У байера одно поле называется «лид», у аналитика — «контакт», у CRM — «заявка», и в итоге одинаковые события считаются по-разному. Чтобы не спорить потом о цифрах, заранее зафиксируйте: какой статус считается лидом, в какой момент он уходит дальше и кто отвечает за финальную проверку.

Схема должна быть простой:
• один источник истины по ID лида;
• один набор обязательных полей: оффер, поток, креатив, дата, статус;
• одно правило дедупликации: по телефону, почте или внешнему ID, но не сразу по всему;
• один канал передачи ошибок, чтобы не терять битые заявки в переписке.

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

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

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