Кейс: один ClientID попал в 18 заявок — продажи приписали одному посетителю

Восемнадцать людей получили один цифровой паспорт

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

В учебной модели разработчик получил ClientID один раз, сохранил значение в серверном шаблоне и затем отдал его всем новым посетителям. Видимое поле телефона менялось, скрытое поле источника — нет.

Форма при этом работала без ошибки: отправки приходили, менеджеры видели контакты, цель срабатывала. Поломка стала заметна только после сверки скрытых полей.

Красивый ROMI построили на чужом визите

Когда CRM отправила оплаченные статусы обратно, система искала визиты по переданному идентификатору. Для всех 18 строк использовался один и тот же ClientID.

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

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

Повтор ClientID — не всегда ошибка

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

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

Официальная справка Яндекс Метрики рекомендует получать ClientID методом getClientID и записывать его в скрытое поле формы для последующей передачи в CRM. Для данных из CRM этот идентификатор даёт наиболее точную привязку к визиту.

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

Пятнадцатиминутный тест сильнее недельного отчёта

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

В CRM сравните ClientID, YCLID, UTM, страницу входа и внутренний ID лида. Если разные браузеры получили один ClientID, проблема воспроизводится до рекламного кабинета.

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

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

Защита должна ловить невозможные совпадения

• сохраняйте ClientID, YCLID, UTM и страницу входа вместе с ID каждой заявки;
• получайте ClientID в браузере посетителя после готовности счётчика;
• не кэшируйте скрытое поле формы на сервере или CDN;
• ставьте предупреждение, если один ClientID встречается у многих разных телефонов за короткое время;
• передавайте устойчивый ID заказа, чтобы повторная выгрузка не создавала дубли;
• до изменения бюджета сверяйте несколько продаж от клика до записи в отчёте.

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

Чек-лист: проверьте ClientID до оптимизации

• Есть ли ClientID в каждой новой карточке CRM?
• Отличаются ли значения у заявок из двух разных браузеров?
• Не повторяется ли один идентификатор у разных телефонов и email?
• Считывается ли ClientID после загрузки Метрики, а не при сборке страницы?
• Хранятся ли рядом YCLID, UTM, URL входа и ID заказа?
• Проверена ли привязка нескольких реальных сделок вручную?

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