Коллтрекинг и Метрика: как считать реальные звонки вместо кликов по номеру

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

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

1. Определите, какое событие вы действительно считаете

В справке Яндекса по отслеживанию звонков описана схема, в которой сервис коллтрекинга передаёт телефонные данные в Метрику через API. Источником факта звонка здесь служит телефонная система, а браузерное нажатие остаётся отдельным событием.

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

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

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

2. Разделите статический и динамический коллтрекинг

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

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

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

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

3. Проверьте подмену во всех местах показа номера

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

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

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

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

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

4. Сохраните корректную связь с ClientID

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

Коллтрекер должен связать выданный номер с наблюдаемой сессией и корректным идентификатором. Для получения ClientID Яндекс рекомендует метод getClientID, описанный в механизме импорта офлайн-данных. Если используется UserID, он должен быть заранее связан с системой идентификаторов Метрики, а не просто существовать во внутренней базе компании.

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

Отсутствие привязки ещё не опровергает сам вызов. Возможны запись звонка без нужного идентификатора, отсутствие наблюдаемого визита или несовпадение времени. Разбирайте эти варианты отдельно. Одна только UTM-метка в названии кампании не заменяет идентификатор, необходимый выбранному способу сопоставления.

5. Согласуйте смысл передаваемых полей

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

Поле	Смысл в API	Что проверить
DateTime	Время события в Unix Timestamp, UTC+0	Не время повторной выгрузки
StaticCall	1 — статический, 0 — динамический	Соответствие реальной технологии
TalkDuration, HoldDuration	Разговор и ожидание в секундах	Не перепутаны ли показатели и единицы
CallMissed	1 — пропущен, 0 — отвечен	Правило определения ответа
FirstTimeCaller	1 — первичный, 0 — повторный	Правила поставщика для первичности
Tag	Метка результата или качества	Единый словарь значений
URL, CallTrackerURL	Связанная страница и ссылка в коллтрекер	Две разные ссылки

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

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

6. Разделите приём файла, обработку и привязку

Успешный HTTP-ответ на загрузку ещё не означает, что каждый звонок появился в нужном отчёте. В ответе API загрузки есть идентификатор пакета и сведения о нём. Документация указывает, что обработка может занимать до трёх часов после загрузки: мгновенного появления ожидать не следует.

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

По документации проверки загрузки, source_quantity — строки исходного файла, line_quantity — прошедшие валидацию. Статус PROCESSED обозначает успешную обработку загрузки; LINKAGE_FAILURE — отсутствие сопоставленных идентификаторов. Статические звонки при этом могут оставаться доступными в отчётах без привязки.

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

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

7. Учитывайте время обработки и область отчёта

В разделе о периоде дополнения визитов Яндекс описывает предел 21 день между последним визитом посетителя и моментом обработки файла с офлайн-данными. Для ClientID и UserID звонок относится к предшествовавшему ему визиту. Не рассчитывайте этот срок просто от даты звонка или нажатия кнопки загрузки; сведения лучше передавать своевременно.

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

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

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

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

8. Разделите пропуск, ответ и полезность разговора

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

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

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

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

9. Не путайте повторный звонок с дублем передачи

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

В детальном отчёте первичность описывается относительно номера звонящего. Уточните, какую историю использует поставщик и что происходит при скрытом номере. Первичный звонок не следует автоматически превращать в нового уникального человека или впервые привлечённого покупателя.

На стороне интеграции нужен устойчивый идентификатор исходного вызова и журнал попыток отправки. Если после таймаута неизвестен результат загрузки, сначала проверьте уже созданный пакет и состояние записи. Повторная отправка должна следовать документированному механизму поставщика, а не правилу «не увидели сразу — загрузили снова».

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

Для проверки выгрузки сравнивайте ID исходных событий, а не только телефоны. Два звонка с одного номера нельзя удалять как дубликаты лишь из-за совпадения номера; это может быть как раз важная повторная попытка дозвониться.

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

10. Проведите согласованный контрольный звонок

Выберите безопасный тестовый сценарий и предупредите принимающего сотрудника. Не используйте клиентские номера или реальные заявки для эксперимента. Откройте нужную страницу, например https://example.com/service/, из заранее выбранного источника и зафиксируйте время, браузер, показанный номер и идентификатор тестового посещения.

1. Проверьте совпадение видимого номера и назначения телефонной ссылки.
2. Позвоните и убедитесь, что вызов приходит ожидаемому получателю.
3. Найдите событие у коллтрекера и сверьте время, статус, ожидание и разговор.
4. Проверьте передачу в нужный счётчик, пакет загрузки и итог обработки.
5. Найдите запись в Метрике и оцените ожидаемую привязку с учётом типа звонка.

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

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

11. Учебный пример: сверьте звонки и знаменатели

Предположим, за выбранный период коллтрекер зарегистрировал 80 разных входящих вызовов. Повторные выгрузки исключены по ID исходных событий. Ниже несколько независимых разбиений одних и тех же 80 звонков; строки таблицы нельзя складывать между собой.

Признак	Разбиение	Проверка
Ответ	55 отвеченных, 25 пропущенных	55 + 25 = 80
Первичность	50 первичных, 30 повторных	50 + 30 = 80
Технология	60 динамических, 20 статических	60 + 20 = 80
Связь динамических	48 привязанных, 12 без связи	48 + 12 = 60

Доля пропущенных равна 25 / 80 = 31,25%. Доля привязки среди динамических — 48 / 60 = 80%. Если разделить 48 на все 80, получится 60%, но это другой показатель: он включает статические звонки, для которых привязка не предусмотрена.

Допустим, кликов по телефонным ссылкам было 120. Отношение 80 / 120 нельзя без связи событий объявлять конверсией людей из клика в звонок: часть вызовов могла быть набрана вручную, а один посетитель мог нажать несколько раз. Эти числа полезны рядом, но не образуют автоматически единую воронку.

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

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

12. Используйте результат для конкретных решений

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

Для анализа каналов используйте отчёт «Источники звонков», учитывая, что он также рассчитан на динамические звонки. Сравнивайте сопоставимые периоды и отдельно следите за долей установленной связи. Рост привязанных событий после ремонта интеграции ещё не означает роста реального спроса.

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

Подключите SiteGuard для внешнего HTTP-контроля доступности страниц с контактами. Подмену номеров и прохождение звонков проверяйте отдельно.