Управление рекламой по звонкам

Кирилл Выймов

Управление рекламой по звонкам

Глава 1. Единица результата: как перестать покупать активность

Единица результата – это правило, по которому реклама перестаёт оцениваться «по активности» и начинает управляться по проверяемому обращению. Пока правило не описано и не закреплено в данных, любые выводы по кампаниям будут спорными и плохо воспроизводимыми.

Зачем вводить единицу результата

В бизнесе, где обращения начинаются со звонков, дефицит спроса бывает – особенно в сезонных и перегретых тематиках. Но на практике чаще всего «ломается» не спрос, а измеримость: в поток попадают повторы, короткие обращения «мимо услуги», ошибочные привязки и потери из‑за недоступности линии.

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

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

Дальше фиксируются границы ответственности: реклама отвечает за привлечение и корректную фиксацию обращения, а процесс обработки – за доступность линии, перезвон и конверсию в выручку. Если это не разделено, спор по качеству быстро превращается в спор «кто виноват».

Правила результата нельзя переписывать каждую неделю «под графики». Иначе исчезает сопоставимость периодов и вы теряете причинность. Любое изменение (порог качества, окно уникальности, исключения) вводится с датой и фиксируется в журнале изменений.

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

В отчётности разделяйте два уровня: клиенту – выводы и следующий шаг, внутренняя отчётность – причины, качество сигнала и риски по процессу. Это снимает лишние споры и помогает принимать решения по фактам.

Чек-лист: фиксируем единицу результата

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

Отдельно задайте порог качества: минимальная длительность, допустимые сценарии (запрос услуги, уточнение цены, запись), а также признаки заведомо нецелевых обращений.

Разведите «учёт потока» и «сигнал для оптимизации»: в учёте оставляйте всё, а в сигнал допускайте только то, что проходит фильтр качества и подтверждается правилами.

Проверьте воспроизводимость разметки: возьмите 20–30 звонков и разметьте их по классификатору (статус + причина нецелевого). Повторите разметку через несколько дней – либо попросите любого второго человека (партнёра/подрядчика/клиента) сделать это независимо. Совпадения подтверждают однозначность правил, расхождения – места, которые нужно дописать.

Закрепите окно уникальности и повторов: что вы считаете новым обращением, а что – продолжением диалога (например, повторный звонок в течение N часов/дней).

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

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

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

Сверьте правило результата с оффером и реальностью: расхождение условий между сайтом и сценариями приёма звонка (кто бы его ни принимал) разрушает сигнал быстрее любой ошибки трекинга.

В отчётах разделяйте управленческий вывод и цифры: клиенту – решение и план действий, вам – качество сигнала и причины отклонений.

1. Описать единицу результата и список исключений в одном документе на 1–2 страницы.

2. Прогнать правило на контрольной выборке и выписать спорные примеры с решением.

3. Закрепить порог качества и окно уникальности, указав, где это отражается в учёте.

4. Настроить ритм проверки (еженедельно/раз в две недели) и ответственного за сверку.

5. Вести журнал изменений правил с датами и причиной пересмотра.

Симптомы перекоса результата и что проверить

Если «результатов» стало больше, но выручка не изменилась, начните с проверки порога качества: чаще всего в сигнал попали короткие и нецелевые звонки.

Если результаты «скачут» неделя к неделе без понятных причин, проверьте, не менялись ли правила, окно уникальности или дисциплина проставления статусов.

Если у клиента ощущение «слива», а у вас «всё по цифрам», вы, вероятно, смешали учёт и сигнал: в отчёт ушёл поток, а не подтверждённые обращения.

Если доля «неизвестно/без статуса» растёт, это не проблема рекламы: это провал операционного контура, который делает оптимизацию недостоверной.

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

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

Если конверсия в результат резко выросла после смены менеджера, проверьте, не изменился ли подход к классификации и не появились ли «удобные» статусы.

Если звонки «перетекают» между периодами, зафиксируйте правило, что считается результатом по дате: по факту звонка или по факту обработки.

Если клиент требует «платить только за продажи», зафиксируйте границу: реклама отвечает за обращение, а продажа – за обработку и закрытие.

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

• Ошибка «размытый результат»: нет порога качества и понятных исключений.

• Ошибка «смешали поток и сигнал»: в оптимизацию попали нецелевые обращения.

• Ошибка «нет дисциплины статусов»: решения принимаются по неполному учёту.

• Ошибка «ретро-правила»: критерии меняются задним числом, теряется сопоставимость.

• Ошибка «конфликт ответственности»: ожидания клиента выходят за пределы рекламы.

Договорённости о результате: формулировки и границы ответственности

Согласование начинается с определения: результат – это обращение, которое проходит заданный порог качества и соответствует офферу, а не «любая активность по телефону».

Отдельно фиксируется порог качества (например, длительность и/или сценарий), а также перечень исключений: ошиблись номером, спам, повтор в рамках окна и т. п.

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

Разделите зоны ответственности: исполнитель отвечает за корректную фиксацию звонка и соблюдение правил учёта; клиент – за доступность линии и своевременную обработку.

Определите правила статусов: кто проставляет, в какие сроки, что считается «необработано», и как решаются спорные случаи (например, через выборочную аудиозапись).

Зафиксируйте правило изменения критериев: изменение порога качества или окна уникальности возможно только по согласованию и с датой вступления.

Установите ритм контроля: периодические созвоны/отчёты, выборка для проверки и формат протокола решений на следующий период.

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

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

Наконец, закрепите принцип «не спорим о терминах»: любые разночтения решаются через правило и пример, а не через интерпретации задним числом.

Глава 2. Звонок как система событий: качество, уникальность, статус

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

Рамка данных: из чего состоит звонок

Звонок – это не «одна строка с длительностью». Минимальная модель включает попытку дозвона, факт ответа/пропуска, длительность разговора, запись (если есть), время ожидания ответа, направление (входящий/исходящий), а также связку с рекламным визитом или маркером намерения.

Отдельно живут две сущности: событие звонка и обращение клиента. Один клиент может сделать несколько попыток подряд, перезвонить через час или вернуться завтра – и это разные управленческие сценарии. Поэтому в учёте важно фиксировать цепочку событий, а в «результат» выводить итог по правилам уникальности.

Статус звонка должен описывать не эмоцию исполнителя, а факт, который можно проверить: «целевой/нецелевой/пропущен/перезвон выполнен/не удалось связаться/спам». Для нецелевых нужен короткий справочник причин, иначе анализ превращается в субъективные комментарии.

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

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

Настройка статусов: что считать качественным звонком

Начните с классификатора: какие статусы существуют (целевой, нецелевой, пропущен, перезвон, в работе) и что означает каждый статус на практике.

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

Задайте минимальные критерии качества: длительность сама по себе не равна качеству, поэтому добавьте признаки сценария (вопрос по услуге, условиям, цене, записи).

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

Согласуйте правила для «серой зоны»: консультация без заявки, запрос «на будущее», уточнение адреса – заранее решите, к каким статусам это относится.

Сведите качество к данным: кто фиксирует причину нецелевого и где хранится эта причина, чтобы она была доступна для анализа, а не «в голове менеджера».

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

Заложите контроль по выборке: регулярная проверка 10–20 звонков помогает удерживать единый стандарт качества и снижает долю спорных случаев.

Согласуйте правила для пропущенных: пропущенный звонок не может стать «результатом» без зафиксированного перезвона и подтверждения контакта.

В отчётах показывайте структуру: не только количество целевых, но и причины нецелевых и долю «без статуса» как индикатор дисциплины.

1. Утвердить список статусов и их определения на уровне проекта.

2. Ввести обязательное поле «причина нецелевого» и короткий справочник причин.

3. Настроить правило для повторов и перезвонов (окна, приоритеты, исключения).

4. Определить срок проставления статуса и ответственного со стороны клиента.

5. Ввести еженедельную выборочную проверку с фиксацией выводов.

Сбои в статусах и качестве: как диагностировать

Если «целевых» много, но менеджеры говорят, что «звонят не те», проверьте определение статуса: часто целевым делают любой разговор, чтобы «не портить отчёт».

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

Если статусы отличаются у разных людей, принимающих звонки, значит нет единого стандарта и примеров; в этом случае цифры не сравнимы даже внутри одного месяца.

Если причины нецелевых «размазаны» (всё «не подошло»), справочник причин не работает: он должен помогать находить решения, а не закрывать вопрос формально.

Если повторные звонки попадают в «новые», вы завышаете результат и искажаете оптимизацию; проверьте окно уникальности и логику объединения цепочек.

Если целевые звонки «всплывают» спустя недели, это не рост качества, а задержка в проставлении статусов; фиксируйте дедлайны и контроль по просрочкам.

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

Если спорят о каждом звонке, заведите «эталонные примеры» и закрепите правило: пример важнее интерпретации.

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

Если качество «падает» после отпусков/смен, это признак отсутствия стандарта; нужен регламент и короткое обучение.

• Ошибка «статусы без определений»: названия есть, смысла нет.

• Ошибка «нет причин»: нецелевые нельзя разложить и исправить.

• Ошибка «повторы как новые»: результат завышается, оптимизация ломается.

• Ошибка «пропущенные скрыты»: потери бюджета не видны в отчёте.

• Ошибка «статусы задним числом»: исчезает сопоставимость периодов.

Согласование статусов: правила для клиента и тех, кто принимает звонки

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

Отдельно пропишите критерии «качественного звонка»: минимальный порог и признаки сценария, а также случаи, которые никогда не считаются результатом.

Укажите обязанность клиента проставлять статусы в установленный срок (например, в течение 24–48 часов) и ответственность за «без статуса».

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

Опишите правило уникальности и повторов: окно, приоритет цепочки, исключения (например, разные услуги или разные номера внутри проекта).

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

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

Зафиксируйте, что изменения в критериях качества и статусах не применяются задним числом без отдельного согласования.

Определите формат отчётности: структура статусов, причины нецелевых, доля пропущенных и «без статуса», а также перечень действий на следующий период.

Глава 3. Привязка звонка к рекламе: границы доказательности

Привязка звонка к рекламе – это не бинарное «с рекламы/не с рекламы», а степень доказательности. В этой главе мы задаём правила атрибуции и честно отделяем подтверждённые привязки от вероятностных и недоказуемых.

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

У звонков есть особенность: клиент может набрать номер без клика, вернуться по сохранённому контакту или позвонить после нескольких касаний в разных каналах. Поэтому «привязать любой звонок к кампании» технически невозможно – можно лишь установить правила доказательности.

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

Правило атрибуции описывает окно по времени, приоритеты источников и одноразовость маркеров намерения (например, клик по номеру не должен «кормить» несколько обращений). Чем прозрачнее правило, тем меньше споров и тем устойчивее оптимизация.

Техническая основа привязки – журнал событий: визит, параметры кампании, идентификаторы, действие пользователя и сам звонок. Если цепочку нельзя восстановить по данным, это сигнал не «додумывать источник», а улучшать сбор и хранение событий.

Доказательная привязка: что считаем фактом

Раздел «Доказательная привязка: что считаем фактом» задаёт контекст и точки контроля, чтобы по теме можно было принимать решения, а не спорить о трактовках.

Проверяемая привязка: где заканчивается атрибуция

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

Разведите «вероятностную атрибуцию» и «доказательную связку»: для управления бюджетом нужен второй вариант, иначе вы оптимизируете по предположениям.

Задайте допустимые окна связки: сколько времени может пройти между действием пользователя и звонком, и почему именно так (по поведению в нише).

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

Если используется «клик по номеру» как ключевой маркер, закрепите правило одноразовости: один клик не должен «кормить» несколько звонков.

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

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

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

Регулярно сопоставляйте данные разных систем: расхождения по времени, по идентификаторам и по количеству – ранний признак того, что связка деградирует.

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

1. Описать, какие сигналы допускаются для связки и в каком порядке приоритетов.

2. Утвердить окна атрибуции и правило для повторов (внутри окна и вне окна).

3. Определить обработку неопределённых звонков и запрет «притягивания» источника.

4. Ввести одноразовость ключевого маркера (если используется клик по номеру).

5. Настроить регулярную сверку расхождений между системами и журнал инцидентов.

Когда привязка врёт: признаки и проверки

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

Если источник «прыгает» между каналами, вероятна проблема с UTM/метками или с редиректами: один и тот же визит может переписываться другой системой.

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

Если звонки с сохранённого номера массово попадают в рекламу, значит используется слишком мягкая логика «по времени» без достаточного доказательства.

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

Если после изменения сайта атрибуция «сломалась», проверьте порядок подключения скриптов, работу событий клика и условия SPA/ленивой загрузки.

Если «органика» исчезла, а «платный» вырос, это часто не рост рекламы, а неправильное распределение неопределённых по умолчанию.

Если клиент видит звонок как результат, но он без источника, не пытайтесь «достроить» источник – зафиксируйте правило и объясните границу доказательности.

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

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

• Ошибка «слишком широкое окно»: источник приписывается по совпадению времени.

• Ошибка «нет одноразовости»: один сигнал намерения учитывается многократно.

• Ошибка «метки живут своей жизнью»: UTM/редиректы искажают канал.

• Ошибка «неопределённые принудительно распределяют»: цифры красивее, а управляемость ниже.

• Ошибка «нет лога связки»: спор невозможно решить фактами.

Как описать привязку в правилах проекта

В правилах проекта закрепите, что считается доказательной связкой: перечень сигналов, их приоритет и условия засчитывания источника.

Опишите окна атрибуции и правило повторов: что относится к одному обращению, а что к новому, и как поступать со звонками вне окна.

Если используется клик по номеру, прямо зафиксируйте принцип: один клик – максимум один звонок, иначе метрика становится уязвимой для повторов.

Согласуйте обработку неопределённых: они не «раскидываются» по каналам автоматически и не включаются в оплату, если это противоречит модели.

Укажите технические требования к сайту: сохранность меток, корректная работа событий, отсутствие изменений, которые ломают сбор данных без уведомления.

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

Закрепите, что изменения в логике атрибуции согласуются заранее и вступают в силу с определённой даты, чтобы не терять сопоставимость.

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

Добавьте пункт о границах: атрибуция не заменяет работу продаж и не подтверждает выручку; она подтверждает источник обращения в рамках правил.

Глава 4. Дедупликация и анти-шум: как не покупать повторы

Дедупликация отвечает на простой вопрос: сколько обращений вы реально купили, а сколько раз один и тот же клиент пытался дозвониться. Без анти‑дублей бюджет искажается, а оптимизация начинает «любить» шум.

Снижение шума: зачем нужна дедупликация

Повтор – не всегда проблема клиента и не всегда проблема рекламы. Повторы бывают поведенческие (передумал, не дозвонился, уточняет) и технические (повторная отправка события, ошибки интеграции). Эти два типа нужно разводить: первые управляются правилами уникальности, вторые – контролем данных.

Начните с определения «обращения»: это может быть один успешный разговор или цепочка «пропущен → перезвон → контакт». Важно, чтобы итог по цепочке был один, иначе вы платите и оптимизируете по попыткам, а не по результату.

Окно уникальности задаётся не «по вкусу», а по поведению клиентов в конкретной услуге. Для срочных услуг окно обычно короче, для плановых – длиннее. Главное – зафиксировать правило и не менять его задним числом.

Технически сохраняйте первичные события. Даже если вы объединяете повторы в одно обращение, исходные звонки должны оставаться в логе для проверки и разбора конфликтов.

Анти-дубли: правила, которые держат сигнал чистым

Дедупликация начинается с определения «одного обращения»: это не всегда один звонок, иногда это цепочка попыток связаться и перезвонов.

Выберите ключи совпадения: номер телефона, время, идентификатор звонка, клиентский идентификатор – и заранее решите, что является главным.

Определите окно, внутри которого повторы считаются одним обращением, и отдельно – исключения, когда повтор всё же считается новым (другая услуга, другой город).

Разведите «дубли данных» и «повторы поведения»: первые устраняются технически, вторые – правилами и статусами.

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