Коллтрекинг и CRM: три окна привязки звонка
Подменный номер живёт минуты, окно привязки — три недели, цикл сделки — месяцы. Разбираем, где эти сроки расходятся и что делать.
Коллтрекинг и CRM: три окна, из-за которых звонок теряет источник
Строки без источника в отчёте по звонкам — чаще не поломка, а следствие того, что три срока в связке коллтрекинга и CRM не совпадают между собой на порядки.
В этой статье разбираем каждый из трёх сроков: чем он задаётся, что происходит на его границе и что из этого поддаётся настройке. Речь только о телефонном канале — как источник теряется на формах, это отдельная механика и отдельный разбор.
Коротко: пять фактов, которые объясняют большинство «звонков без источника»
- 01
Подменный номер закреплён за посетителем порядка пятнадцати-тридцати минут, потом возвращается в пул и может достаться другому — это отраслевая практика, конкретные значения зависят от настроек вашего сервиса.
- 02
При нехватке номеров часть посетителей видит основной номер компании, и источник такого звонка не определяется вовсе.
- 03
Звонок не привяжется к визиту, если визит был раньше чем за 21 день до передачи данных в Яндекс Метрику или если визит произошёл уже после звонка — это правило загрузки офлайн-данных, у платформ со своей атрибуцией логика может отличаться.
- 04
Статический звонок к визитам посетителей не привязывается в принципе — он существует отдельно от сессий.
- 05
Три срока расходятся на порядки: минуты, три недели и месяцы. Большинство «звонков без источника» объясняется именно этим, а не поломкой.
Почему звонок без источника — это норма, а не сбой
Когда маркетолог или владелец бизнеса видит в отчёте строки без источника, первая реакция — искать, что сломалось. Иногда действительно сломалось. Но в большинстве случаев всё работает ровно так, как настроено, — просто никто не думал о том, что три временных окна в этой связке живут по разным законам.
Первое окно — время, в течение которого подменный номер закреплён за конкретным посетителем. Измеряется минутами. Второе — окно, в котором система аналитики соглашается связать звонок с визитом. Измеряется неделями. Третье — время от первого касания до появления сделки в системе учёта. Измеряется неделями или месяцами — в зависимости от того, что продаёт бизнес.
Первый срок примерно в тысячу раз короче второго. Третий в нишах с долгим выбором в несколько раз длиннее второго. Как устроен сам учёт звонков и что теряется без коллтрекинга — разобрано в отдельном материале. Здесь мы считаем, что он уже подключён, и разбираем только то, почему работающая связка всё равно не доводит звонок до сделки.
карта трёх окон
Где рвётся связка: шесть точек отказа
Первые два окна настраиваются деньгами и параметрами. Третье и четвёртое — правила, которые можно только учитывать. Пятое — выбор схемы. Шестое не настраивается вовсе.
Минуты: пока номер закреплён за посетителем
Логика первого окна простая. Посетитель зашёл на сайт — ему показали номер из пула. Номер держится за ним некоторое время. Позвонил в этот промежуток — связь есть. Позвонил позже — номер, возможно, уже показан другому человеку, и звонок уйдёт не туда или вовсе ни к чему.
Отсюда первое практическое решение: время удержания должно соответствовать тому, как долго люди в вашей нише думают. Для импульсной покупки хватит пятнадцати минут. Для услуги, где человек уходит посоветоваться с семьёй и звонит вечером, не хватит и часа. Конкретные значения и возможности настройки — в документации вашего сервиса коллтрекинга: у разных платформ диапазоны и дефолтные значения различаются.
Но удлинение удержания стоит номеров. Пока номер закреплён за одним посетителем, он недоступен остальным. Оценить нужный пул можно так: взять пиковую посещаемость в час, умножить на время удержания в долях часа и добавить запас около сорока процентов.
оценочный расчёт пула
Сколько номеров нужно: порядок величины
Расчёт модельный — важен порядок, а не точность. Пул, подобранный наугад, кончается в первый же удачный день.
Есть ещё одно замечание, которое стоит сделать отдельно — его часто спрашивают при обсуждении динамической подмены. Подмена происходит визуально, уже после загрузки страницы. Поисковые роботы Яндекса и Google видят основной номер компании, а не подменный. На поисковую видимость и позиции это не влияет. Гораздо более реальный риск — переполнение пула, при котором живые посетители тоже видят основной номер, и тогда источник этих звонков не определяется уже не по техническим причинам, а просто потому что номеров не хватило.
Три недели: окно привязки звонка к визиту
Когда данные о звонках передаются в аналитику, система пытается соотнести каждый звонок с визитом. Для динамического звонка она выбирает ближайший подходящий по времени визит. Статический звонок к визитам не привязывается вообще — он существует сам по себе, вне сессионной логики.
Для загрузки данных о звонках в Яндекс Метрику действуют три условия, при которых привязки не будет: если передан идентификатор посетителя, которого нет в базе; если визит произошёл после звонка; и если визит был раньше чем за 21 день до момента отправки данных. Из последнего следует практическое правило, о котором мало кто думает: данные о звонках нужно передавать регулярно. Если выгрузка делается раз в месяц, часть звонков придёт с опозданием относительно визитов и просто не свяжется ни с чем — при том что технически всё настроено правильно.
Важная оговорка: правило про 21 день относится именно к загрузке офлайн-данных в Яндекс Метрику. У платформ сквозной аналитики со своей моделью атрибуции — Roistat, Calltouch, CoMagic, K50 — логика может быть другой, и её нужно смотреть в документации своей системы. Не переносите чужое число на свой контур автоматически.
Месяцы: когда цикл сделки длиннее любого окна
Третий срок не настраивается ничем. Если в вашей нише человек выбирает подрядчика полтора месяца, а сделка в системе учёта появляется ещё позже, то к моменту её создания первое окно закрылось много недель назад, а второе, скорее всего, тоже.
Отсюда вывод, который стоит сказать прямо: в нишах с длинным выбором связка «подменный номер → сделка» не рвётся из-за ошибки — она просто не собирается. Цикл в три месяца длиннее окна привязки примерно вчетверо, и никакие настройки это соотношение не изменят.
Что из этого следует практически: ключом перестаёт быть номер. Им становится идентификатор обращения, который создаётся в момент звонка и живёт дальше вместе со сделкой — независимо от того, кто и когда её открыл в системе учёта. Номер в этой схеме остаётся способом связаться с клиентом, а не способом вспомнить, откуда он пришёл.
И вторая половина того же вывода: менеджер, который создаёт сделку руками по номеру клиента, разрывает цепочку, даже когда всё настроено правильно. Сделка, открытая заново, не знает ни о каком звонке. Та же задача в канале переписки — когда носителем источника выступает не номер, а идентификатор в ссылке — разобрана в отдельном материале про обращения из мессенджеров.
было / стало
Как меняется схема при длинном цикле сделки
Что проверить за один заход
Когда в отчёте появляются звонки без источника, важно не просто констатировать факт, а понять, какое именно окно не сработало. Это определяет, что делать дальше — и делать ли что-то вообще.
Три вещи, которые покажут причину. Первое — доля звонков без источника за месяц. Если она велика, смотрят, в какие часы эти звонки приходятся. Скопление в часы пиковой посещаемости почти всегда означает переполнение пула: в это время номеров не хватает, и часть посетителей видит основной номер.
Второе — распределение по времени от визита до звонка. Если заметная часть звонков приходит позже, чем держится номер, дело в удержании, а не в объёме пула. Увеличение пула здесь не поможет — нужно менять настройку удержания.
Третье — статус привязки в отчёте по офлайн-конверсиям. Там видно не только, привязался звонок или нет, но и причина непривязки. Это самый прямой способ отличить переполнение от выхода за окно или от проблемы с идентификатором. Как читать этот отчёт построчно — разобрано в отдельном материале по диагностике офлайн-конверсий в Метрике.
Перед тем как делать выводы по отчёту, стоит уточнить, какие правила атрибуции действуют именно в вашей системе. У Roistat, Calltouch, CoMagic и K50 — собственные модели и собственные сроки хранения связки. Число 21 день, о котором шла речь выше, относится к загрузке данных в Яндекс Метрику и не переносится на другие платформы автоматически.
Три ошибки, которые ломают связку даже при правильной настройке
Как это выглядит на практике
- Выгрузка данных о звонках делается раз в месяц «пакетом» — часть звонков к тому моменту уже выходит за окно привязки, и они не свяжутся ни с каким визитом.
- Менеджер видит пропущенный звонок, находит клиента по номеру телефона и создаёт сделку руками заново — цепочка от обращения к источнику обрывается в этот момент.
- Пул номеров подбирался по средней посещаемости, а не по пиковой — в загруженные часы номера заканчиваются, и часть посетителей видит основной номер без подмены.
Как это исправить
- 01
Настроить регулярную автоматическую передачу данных о звонках — не реже чем раз в несколько дней, а в идеале в режиме близком к реальному времени.
- 02
Договориться с отделом продаж: сделка должна создаваться из карточки обращения, а не заново по номеру клиента. Это организационное решение, не техническое.
- 03
Пересчитать пул по пиковому часу с запасом около сорока процентов и проверить, не кончаются ли номера в часы максимальной нагрузки.
Итог: три срока, одна причина
- 01
Первое окно — минуты удержания номера — настраивается, но требует пересчёта пула.
- 02
Второе окно — срок привязки звонка к визиту — диктуется правилами системы аналитики; для Яндекс Метрики это 21 день с момента отправки данных, у других платформ логика может отличаться.
- 03
Третье окно — цикл сделки — не настраивается ничем. В нишах с длинным выбором связка «номер → сделка» не собирается в принципе, и здесь нужна другая схема: идентификатор обращения вместо номера как ключа.
- 04
Регулярность передачи данных важнее точности разовой выгрузки: звонки, ушедшие за окно привязки из-за задержки, не восстановить.
- 05
Сделка, созданная менеджером заново по номеру клиента, разрывает цепочку — это организационная проблема, а не техническая.
Если вы видите в отчёте значимую долю звонков без источника — начните с трёх проверок: время поступления таких звонков относительно пиковых часов, распределение по задержке от визита до звонка и статус привязки в отчёте по офлайн-конверсиям. Эти три среза покажут, какое именно окно не срабатывает в вашем случае.
Часто задаваемые вопросы
Считается от пиковой посещаемости, а не от средней. Возьмите количество посетителей в самый загруженный час, умножьте на время удержания номера в долях часа и добавьте запас процентов на сорок. При трёхстах посетителях в час и удержании полчаса получается от двухсот десяти номеров. Расчёт оценочный, но порядок величины важнее точности: пул, подобранный наугад, кончается в первый же успешный день, и тогда часть посетителей видит обычный номер компании. Такие звонки приходят без источника, и выглядит это как поломка, хотя это переполнение.
Скорее всего человек позвонил после того, как время удержания номера истекло. Номер вернулся в пул, достался другому посетителю, и система соотнесла звонок с его визитом — как с ближайшим подходящим по времени. Решение лежит в настройке удержания: оно должно соответствовать тому, как долго в вашей нише принимают решение. Для импульсной покупки хватит пятнадцати минут, для услуги с обсуждением дома не хватит и часа. Но помните, что удлинение удержания требует большего пула: занятый номер недоступен остальным.
Принять, что связка «номер — сделка» в таком виде не соберётся, и перестать её чинить. Окно привязки звонка к визиту ограничено, и цикл в несколько месяцев в него не укладывается никакими настройками. Работающая схема другая: в момент звонка создаётся идентификатор обращения, который дальше живёт вместе со сделкой независимо от того, когда её открыли. Номер при этом остаётся способом связаться с клиентом, а не способом вспомнить источник. Отдельно стоит договориться с отделом продаж: сделка, созданная руками заново, теряет всю цепочку.
Нет. Подмена происходит визуально, уже после загрузки страницы, а поисковые роботы видят основной номер компании. Это одно из самых распространённых возражений против динамического коллтрекинга, и оно не подтверждается механикой работы. Гораздо более реальный риск в другом: если пул номеров мал, часть живых посетителей увидит основной номер вместо подменного, и вы потеряете источник у этих звонков. То есть экономия на количестве номеров вредит аналитике сильнее, чем любые опасения по поводу поиска.
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
