Как выбрать и внедрить защиту от скликивания: от критериев до результата
Содержание
Поделиться
Выбрать защиту от скликивания стоит по тому, что она делает с визитом, а не по обещанию «расход упадёт на процент». Binetro ставит на страницу скрипт. Скрипт собирает данные в браузере и отправляет один запрос на проверку. В ответ приходит решение по этому визиту: пропустить, дать вычислительную проверку в браузере или не пустить. Отдельно может быть поставлен запрет на повторный заход с этого адреса на этот сайт. У сайта есть режим наблюдения и режим защиты.
Скликивание этой схемой не отменяется и не измеряется «до и после». Документация не задаёт бюджет времени скрипта на загрузку страницы и не задаёт способ измерить эффект защиты по расходу рекламы до и после. Если скрипт не дождался ответа, визит пропускается. Ниже критерии и порядок внедрения без этих двух обещаний.
Критерий первый: один запрос на визит
Защита сайта от ботов и скликивания здесь устроена как одна проверка визита, не как постоянный опрос. Скрипт на странице, один запрос, одно решение. Кликфрод и скликивание остаются названиями проблемы. Критерий выбора — есть ли у продукта именно этот контур, а не набор лозунгов.
Если ответа нет, визит не зависает: его пропускают. Это граница, её стоит проговорить до включения, чтобы простой проверки не читали как «всех заблокировало».
Критерий второй: три решения
Пропустить — визит идёт дальше. Вычислительная проверка в браузере — посетителю даётся задача, по документу это отдельное решение, не то же самое, что сразу не пустить. Не пустить — визит не проходит. Запрет повторного захода с этого адреса на этот сайт может быть поставлен отдельно. Условия, при которых он ставится, в публичное описание не входят. Критерий честный, если вам называют три исхода и не обещают, что живой человек никогда не увидит проверку: такого обещания в этих документах нет.
Недействительные клики решает площадка. Скрипт не возвращает списанное и не участвует в расчёте кабинета. Возвращает ли Яндекс деньги остаётся вопросом к площадке.
Критерий третий: сначала наблюдение
В наблюдении проверка считается полностью, но наружу посетитель всегда пропускается, запрет на повторный заход не ставится, а в журнал попадает и фактический пропуск, и решение, которое было бы в защите. В защите решение применяется к визиту.
Для внедрения это главный практический шаг. Включать сразу защиту значит применять «не пустить» и вычислительную проверку к живым людям без предварительного журнала. Наблюдение даёт тот же расчёт и оставляет всех пропущенными. Журнал показывает, какое решение было бы. Это не замер расхода рекламы до и после: такого способа документация не задаёт.
Чего не требовать в договоре о результате
Не требуйте цифру «страница станет быстрее на столько-то»: бюджет времени скрипта на загрузку не задан. Не требуйте методику «CPA до и CPA после»: способ измерить эффект по расходу рекламы не задан. Отсутствие этих обещаний — граница утверждений, не скрытый замер. Кто скликивает не заполняет эту дыру процентом.
Результат, который можно принять: скрипт стоит, на визит уходит один запрос, в журнале наблюдения видны три класса решений, после перехода в защиту решения применяются, а при молчании проверки визит пропускается.
Порядок внедрения
Назовите, от чего защищаете сайт: боты и скликивание рекламы, одним скриптом и одним запросом на визит.
Зафиксируйте три решения и отдельную возможность запрета повторного захода. Условия запрета не выдумывайте.
Зафиксируйте пропуск, если ответ не пришёл.
Включите режим наблюдения. Убедитесь, что наружу все пропущены, запрет повтора не ставится, в журнале есть и пропуск, и решение, которое было бы в защите.
Разберите журнал без обещания, что доля «не пустить» равна доле фрода в кабинете. Документы эту долю не связывают с расходом.
Перейдите в защиту, когда журнал понятен. Тогда решение применяется к визиту.
Не подводите итог сравнением расхода рекламы до и после. Такого способа нет.
Не подводите итог скоростью страницы. Бюджета времени нет.
Пример двух недель
Учебный пример, не замер клиента.
Первую неделю сайт в наблюдении. На визиты уходит по одному запросу. Посетители пропущены все. В журнале у части визитов решение «было бы не пустить», у части — вычислительная проверка, у части — пропустить. Запрет повторного захода не появляется. Расход Директа за неделю с прошлой неделей не сравнивают как эффект: методика не задана. Скорость страницы не обещают.
Вторую неделю включают защиту. Те же три решения начинают применяться. Визит, на который проверка не ответила, пропускается. Запрет повторного захода может появиться; пример не назначает, на каких условиях, потому что условия в публичное описание не входят.
Итог, который пример имеет право сдать: режим сменился, журнал первой недели сохранён, расход «до и после» не предъявлен как результат продукта.
Чек-лист выбора
Есть скрипт и один запрос на визит.
Названы три решения: пропустить, вычислительная проверка, не пустить.
Запрет повторного захода не описан шире, чем «может быть поставлен».
Молчание проверки означает пропуск.
Сначала доступен режим наблюдения с журналом «что было бы».
В наблюдении наружу все пропущены и запрет повтора не ставится.
В защите решение применяется.
В критерии нет скорости страницы и нет расхода рекламы до и после.
Возврат денег не обещан скриптом.
Как читать журнал наблюдения
Журнал — единственный результат, который документы позволяют принять до перехода в защиту. Его читают по строкам, не по проценту бюджета.
Строка «пропустить» в журнале наблюдения означает и фактический пропуск, и то, что в защите визит тоже прошёл бы. Наружу человек и так пропущен. Менять режим из-за таких строк не нужно: они не накопят «не пустить».
Строка, где наружу пропуск, а решение «было бы не пустить», — повод смотреть визит глазами, не повод сразу включать защиту на весь сайт. Документы не связывают эту строку с суммой в кабинете. Кто скликивает может помочь назвать мотив, но не превратит строку журнала в недействительный клик площадки.
Строка «была бы вычислительная проверка» означает третье решение, не блокировку. В защите посетитель получит задачу в браузере. В наблюдении он её не получает: наружу все пропущены. Путать задачу с отказом нельзя уже на журнале, иначе после включения защиты всплеск проверок прочитают как всплеск отказов.
Запрет повторного захода в этих строках отсутствует, пока режим — наблюдение. Если в журнале он всё же отмечен, режим включён не тот. Это проверка внедрения, не спор о качестве трафика.
Молчание проверки в журнал «было бы не пустить» не превращается. Ответа нет — визит пропущен. В отчёте о внедрении такие визиты подписывают отдельно, чтобы простой не смешали с решением «не пустить».
Что сказать на внутренней приёмке
Приёмка звучит короткими пунктами. Скрипт на страницах, которые вы назвали. С визита уходит один запрос. Три решения названы и видны в журнале наблюдения. Наружу за неделю наблюдения отказов не было, потому что режим так устроен, а не потому что трафик оказался чистым. Запрет повтора не ставился. Срок загрузки страницы не принимается, его нет в документах. Расход рекламы этой и прошлой недели не принимается как эффект. Дата перехода в защиту записана отдельно, и с неё решение применяется.
Если кто-то на приёмке требует процент, ему возвращают границу: способ измерить эффект по расходу до и после не задан. Процент пришлось бы изобрести. Изобретённый процент нельзя подписать как результат Binetro.
Вторую неделю примера поэтому не сравнивают с первой деньгами. Сравнивают режим. В первой все наружу пропущены, журнал хранит «было бы». Во второй те же классы решений применяются, молчание по-прежнему пропускает, запрет повтора может появиться без публичного списка условий. Этого достаточно, чтобы считать внедрение состоявшимся. Недостаточно, чтобы отчитаться перед директором фразой «скликивание стоило нам меньше». Такой фразы документы не поддерживают, и чек-лист как раз не даёт её произнести.
Живой посетитель в этой схеме может встретить вычислительную проверку, когда режим уже защита. Обещания, что этого не случится, нет. Сомнение в пользу человека и пропуск при молчании — то, что можно сказать. «Ни одного живого на проверке» — нельзя. Критерий выбора, который требует абсолют, отсеивается на этом месте, до покупки, а не после жалобы.
Отдельно проговорите запрет повторного захода тем, кто боится «вечного бана». В наблюдении он не ставится. В защите он может быть поставлен с адреса на этот сайт, и условия остаются вне публичного описания. Нельзя обещать клиенту список причин бана и нельзя обещать, что бана не будет никогда. Можно обещать только то, что есть: три решения по визиту, отдельная возможность запрета, журнал в наблюдении и пропуск, если ответа нет.
Тот же разговор про скорость. Разработчик спросит, сколько миллисекунд скрипт имеет право занять. Ответ из документов: бюджет времени на загрузку не задан. Внедрение не принимают по Lighthouse и не отклоняют по нему. Если страница и так тяжёлая, это отдельная задача вёрстки, не критерий этой защиты. Смешивать её с «не пустить» значит оценивать продукт по оси, которой у него в документах нет.
И про деньги кабинета, третьим кругом. Директолог принесёт CPA двух недель. Рядом с журналом эта пара чисел может лежать как фон. Она не является результатом внедрения, потому что способ такого замера не задан. Фон подписывают «не эффект». Иначе через месяц спор будет не о режиме, а о том, чей процент настоящий. Настоящим в приёмке остаётся смена режима и применение решения к визиту.
Когда все три круга проговорены — бан, скорость, расход — выбор сделан по документам, а не по слогану. Дальше остаётся чек-лист и дата, когда наблюдение сменилось защитой. Без даты журнал «было бы» легко перепутают с уже применёнными отказами. Дата — часть внедрения, такая же, как сам скрипт.
На самой приёмке полезно открыть один визит из каждой строки журнала и проговорить его вслух. «Пропустить и было бы пропустить» — человек прошёл, в защите прошёл бы так же. «Пропустить, а было бы не пустить» — человек прошёл, потому что шло наблюдение. «Пропустить, а была бы вычислительная проверка» — человек прошёл без задачи в браузере. «Ответа не было» — человек прошёл по правилу молчания. Четыре фразы закрывают споры о том, что журнал «ничего не доказывает». Он доказывает режим и класс решения. Он не доказывает рубль. Этого разделения достаточно, чтобы внедрение не расползлось в отчёт о скликивании, для которого у скрипта нет методики «до и после».
На приёмке держите дату смены режима на первой строке журнала. Без неё «было бы не пустить» читают как уже случившийся отказ. С датой видно, до какого дня все были пропущены наружу. После даты решение применяется, а молчание проверки по-прежнему пропускает визит.