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

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

С чего всё началось

Владелец небольшой компании готовился к рекламному сезону. Сайт на ХостСМС недавно получил новую форму заявки: она стала короче, добавился выбор удобного способа связи и поле для комментария. Перед запуском рекламы нужно было убедиться, что заявки доходят до менеджеров, попадают в СРМ и фиксируются в Яндекс.Метрике как достижение цели. Поручили это одному из менеджеров, человеку аккуратному и ответственному.

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

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

Как тесты превратились в «клиентов»

Дальше сработала цепочка небольших упущений. Во-первых, счётчик Яндекс.Метрики не был настроен на исключение внутренних визитов: отправки шли с рабочего компьютера, но фильтра по сетевому адресу не существовало. Цель «заявка» срабатывала при каждой успешной отправке формы, без различия, кто её оставил. Во-вторых, тестовые обращения не имели единой метки: одни были с пометкой «тест», другие с вымышленным именем, третьи с настоящим телефоном менеджера. Автоматически их отличить было нельзя.

В-третьих, в СРМ заявки попали в общую воронку. Менеджер закрыл часть из них как «не обработано» или «ошибка», но не все: некоторые остались в статусе «в работе», а несколько были закрыты как «отказ клиента». А в итоговом отчёте по заявкам, который владелец смотрел раз в месяц, учитывались все созданные карточки независимо от статуса. Так «клиентами» в отчёте оказались люди, которых не существовало.

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

Как это заметили

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

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

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

Что сломалось в расчётах

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

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

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

К чему это привело

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

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

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

Как исправили

Сначала навели порядок в самих данных. Владелец вместе с менеджером поднял все записи за период проверки формы, пометил тестовые заявки единой пометкой в СРМ и вынес их в отдельный этап «тест». В отчёте по заявкам исключили этот этап и пересчитали стоимость обращения и долю дошедших до сделки. Цифры вернулись к реальным: стоимость заявки оказалась выше прежней, а конверсия в продажу — вполне нормальной.

Затем настроили Яндекс.Метрику. Внутренние визиты исключили двумя способами: по внешнему сетевому адресу офиса и по файлу браузера, который ставится на устройствах сотрудников при открытии служебной страницы на сайте. Добавили метки в ссылках для тестов, а форму доработали: в ХостСМС поле-маркер теперь заполняется автоматически, если форма открыта по тестовой ссылке, и такие обращения не попадают в основной поток уведомлений и СРМ.

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

Чек-перечень выводов словами

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

Третий вывод: цель в Яндекс.Метрике должна срабатывать не на любую отправку, а на успешную, и желательно иметь отдельную цель для тестовых отправок. Четвёртый: отчёт по заявкам нельзя строить на одном источнике данных. Сверяйте цели счётчика, карточки в СРМ и звонки, и если расхождение превышает пятую часть, ищите причину сразу, не дожидаясь конца месяца. Пятый: решения о перераспределении бюджета принимайте не по одной неделе и не по одному показателю, а по набору из числа заявок, доли целевых и оплаченных заказов.

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

Как это связано с продвижением «3 в 1»

История показывает, насколько важна честная картина по всем точкам, откуда приходят обращения. Мы строим продвижение по схеме «3 в 1»: заявки приходят из поиска (обычная выдача и ответы нейропоиска, для которых нужны понятная структура, прямые ответы на вопросы и факты о компании на сайте), из карточки в Яндекс.Справочнике, то есть в Яндекс Картах и Яндекс Бизнесе, и из карточки в 2ГИС. Если искажены данные по сайту, оценить вклад каждой точки невозможно, и вы начинаете вкладывать деньги туда, где якобы дешевле, а не туда, где реально приходят клиенты.

В описанной компании тестовые заявки поднимали показатели сайта, а звонки из карточек не учитывались вовсе: у них не было отдельных номеров. Если бы карточка в Яндекс Картах и карточка в 2ГИС имели собственные телефоны и метки в ссылках на сайт, владелец увидел бы, что обращения с карт стабильны, а скачок на сайте не сопровождается ростом звонков, и заподозрил бы неладное раньше. Работа только над одной точкой даёт неполный результат, а учёт только одной точки даёт неполную правду.

После случившегося компания завела три отдельных номера: для сайта, для Яндекс Бизнеса и для 2ГИС. Обращения с карт стали считать наравне с заявками с сайта. В карточках привели в порядок фотографии, услуги с ценами, часы работы и телефоны, начали отвечать на отзывы. Сравнение трёх источников теперь делается ежемесячно в одной таблице, и тестовые записи туда не попадают. Стоимость заявки по каждой точке и в сумме стала тем показателем, на который можно опираться.

Как проверить собственную статистику за десять минут

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

Затем сверьте число целей в Яндекс.Метрике с числом карточек в СРМ за тот же период. Небольшая разница нормальна, а вот расхождение в пятую часть и более требует разбора. Просмотрите последние сорок записей в СРМ и найдите среди них те, что оставлены сотрудниками либо подрядчиками. Если такие нашлись, отметьте их, и пересчитайте стоимость заявки без них. Результат нередко удивляет.

Наконец, спросите менеджеров, когда в последний раз проверяли форму, кто это делал и как помечал обращения. Если ответ звучит как «примерно в начале месяца, не помню, как помечали», значит, в регламенте есть пробел. Закройте его короткой инструкцией: что делать, кому сообщить и как отделять тесты. Такая памятка занимает полстраницы, а экономит недели ошибочных решений. Для сайтов на ХостСМС, 1С-Битрикс и ВордПресс принцип один и тот же: тесты помечены, внутренние визиты исключены, цели срабатывают на успешную отправку.

Вывод: тест формы нужен, но он не должен становиться «клиентом»

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

Если вы хотите, чтобы заявки со всех трёх точек — из поиска, из карточки в Яндекс.Справочнике и из карточки в 2ГИС — считались честно, а стоимость обращения отражала действительность, обратитесь за бесплатной консультацией к специалистам компании «Сайты Профессионально». Мы проверим настройки вашего счётчика и форм, поможем навести порядок в учёте обращений и составим понятную памятку для команды.