Как оценить эффект от защиты: до и после

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

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

Что собирает сквозная аналитика

Справка Метрики описывает сквозную аналитику как сравнение затрат на каналы с доходами этих каналов и как путь клиента от перехода с рекламы до заказа или покупки. Чтобы её собрать, нужно разметить объявления UTM, загрузить расходы по размеченным каналам за период, сохранить в CRM идентификатор ClientID, полученный методом getClientID, и передать в Метрику клиентов и заказы из CRM. ClientID справка этой страницы называет идентификатором уникального посетителя, который Метрика задаёт сама.

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

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

Наблюдение и защита

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

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

Итог проверки скрипт отдаёт странице. Если задан счётчик Яндекс Метрики, итог может уйти и в него. Эта отметка не является определением роботов самой Метрики и не переписывает отчёт рекламной системы. Рост или падение роботов в отчёте Метрики после включения защиты этим обещанием не объясняется.

Как не подменить одно сравнение другим

1. Соберите сквозную аналитику, если нужен доход канала: UTM, расходы за период, ClientID из getClientID, клиенты и заказы из CRM.

2. Читайте «Источники, расходы и ROI» как сравнение затрат и доходов. Колонки «боты» в названии отчёта нет, формулы ROI в описании отчёта нет.

3. Не вычитайте из этого отчёта возврат за клики. Проверка деньги не считает.

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

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

6. Отметку в счётчике Метрики не читайте как роботов Метрики и не как правку отчёта Директа.

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