Buenos dias, amigos! Эта статья, по большей части, компиляция из здравого смысла и уже опубликованных постов из моего ТГ-канала и паблика ВК, решил собрать воедино всю информацию по такому важному вопросу, как уменьшение кол-ва невалидных лидов. 

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

По ходу пьесы я также предполагаю, что вы собираете лиды у себя в трекере, а в случае, если лид – это невалид или дубль, не записываете его в стату и не показываете пиксель фэбэ на спасибо. Итак, погнали!

Предварительные шаги

Перво-наперво проверьте все данные по вашему офферу. В частности нас интересуют четыре вещи:

1. Форм-фактор товара. Если это гель, а на проклах у вас таблетки, то это плохо. Всегда подгоняйте ваши промо-материалы под нужный формат!
2. Список регионов, в которые нет доставки. Если на оффере таковой список присутствует, обязательно озаботьтесь составлением блэк или вайт-листа регионов в источнике трафика.
3. Цена – если скачали проклу из спаев, очевидно, что цену нужно поменять на корректную, ну! И выделить её жирным 100500м шрифтом.
4. Таргетинг – непременно уточните у менеджера ПП, кто лучше выкупает товар. Мужчины это или женщины? 25+ или 40+? Ставьте в источнике трафика только требуемый таргетинг хотя бы на этапе теста. Потом уже можете поэкспериментировать и расширить.

После всего это приступаем к техничке.

Проверки в браузере

Добавляем Required

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

Пример: <input type="text" name="name" required/>

Добавляем type=”tel” и “autocomplete”

До сих пор частенько встречаются ПП, которые вместо специально придуманного типа поля tel используют text. Не надо так! Тип tel существует для того, чтобы у юзера, зашедшего к вам на ленд с мобильного телефона, высвечивалась ТОЛЬКО цифровая клавиатура, без букв. Что гораздо удобнее при наборе номера и ведёт к тому, что кол-во неправильно введённых номеров снижается.

Пример: <input type="tel" name="phone" required/>

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

Скрин 1. В поле ввода имени в выпадающем меню подсказок куча какого-то мусора.

Скрин 2. В поле ввода телефона тоже полно не пойми чего.

Скрин 3. В подсказке мне сразу же показыватся моё имя и мой телефон

Скрин 4. Результат тапа на подсказку: ВСЕ поля сразу же заполнены валидными данными!

Так как же сделать, чтобы выдавалась такая подсказка, как на 3м скрине? Всё дело в атрибуте autocomplete. Для поля с именем нужно прописать autocomplete="name", а для телефона autocomplete="tel".

Полный код для всех вышеперечисленных пунктов:

<input type="name" required autocomplete="name" name="name"/>

<input type="tel" required autocomplete="tel" name="phone"/>

Добавляем в поля атрибут minlength

Очевидно, что помимо того, что все данные в форме должны быть заполнены, эти данные ещё должны быть определённой длины. Для поля имя это хотя бы 3 символа, для телефонов – от 5 и выше, в зависимости от страны.

Чтобы добавить проверку на длину поля, ему нужно прописать атрибут minlength:

<input type="name" minlength="3" required name="name"/>

<input type="tel" minlength="5" required name="phone"/>

Также длину можно проверять с помощью атрибута pattern, о чём чуть ниже.

Добавляем pattern, маску и библиотеку intlTypeNum

Pattern

Есть несколько способов проверять, что за хрень навводил пользователь в поля формы и не давать ему вводить дичь. И первым будет встроенный в HTML5 атрибут pattern, он же по-русски = шаблон.

С помощью него можно проверить практически всё, что угодно, например:

• кол-во необходимых символов – полезно для поля name, чтобы не вводили, например 1 символ и всё или наоборот, чтобы не писали в поле целую поэму;
• набор доступных символов – для name только буквы, для phone, соответственно, только цифры.

А вот как это будет выглядеть в коде:

1. Пример для поля name: делаем его длину от двух до двадцати символов и разрешаем вводить только латинские буквы и пробелы. Любые значения меньше или больше указанных приведут к тому, что форма не будет отправляться.

<input type="text" name="name" pattern="^[A-Z a-z]{2,20}$"/>

2. Пример для поля phone: разрешаем вводить только цифры и делаем длину ровно в 9 символов.

<input type="tel" name="phone" pattern="^\d{9}$"/>

“Так а что это за странные символы внутри шаблона?”,- спросите вы. “Все вот эти вот слеши, скобки и т.п.?”. И я вам с удовольствием отвечу: “Это называется регулярное выражение. Любой мало-мальски продвинутый технарь должен их знать и уметь, в них великая сила!”🙃 Если технарь – это вы, то найдите себе учебник или почитайте пару статей в интернетах, и вы быстро поймёте, что регулярки – это маст хев.

Маски

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

В разных библиотеках маски пишутся по-разному, мы с вами рассмотрим вариант для самой популярной из них – InputMask.

Например, для номеров РФ нужно написать вот такую вот конструкцию:

+7-\999-999-99-99

Почему так? Потому что в InputMask девятка обозначает ЛЮБУЮ цифру. И для того чтобы сама первая девятка была именно цифрой 9, а не любой, мы ставим перед ней слеш. Больше вам в целом знать о формате ничего не нужно.

Пример кода, который установит для всех полей с типом tel вышеуказанную маску вы найдёте вот тут.

LibPhoneNum

Прекрасное решение проблемы проверки валидности номеров от великого и ужасного Google Inc. Писал про него (и про маски) подробно вот тут, не будем повторяться.

Проверяем скорость загрузки ленда через прокси ГЕО

Штука вот в чём: если ваш трекер находится где-то далеко-далеко от того ГЕО, на которое вы льёте трафик, то, когда пользователь нажмёт на кнопку “Заказать”, его браузеру придётся доолго ждать, пока запрос дойдёт до скрипта обработки заявок. Иногда это пара секунд, а может быть и секунд 5-8. Всё это время нетерпеливый любитель писькокремов может в исступлении жать на расчудесную кнопку. И таким образом увеличивать кол-во треша.

Если вы зашли с прокси нужного ГЕО и увидели вышеописанную проблему, то у вас есть 3 решения:

1. Перенести ваш трекер на сервак, с которого это ГЕО грузится гораздо быстрее. Решение радикальное, но если вы плотно работаете с выбранным регионом, а остальные побоку, то оно очень даже имеет место быть.
2. Захостить лендинг где-то поблизости с нужным ГЕО, а трекер подключить к нему по API. Решение попроще, но всё равно требует возни с настройкой API + ко всему, скрипт отправки лидов также должен быть на хостинге ГЕО, что усложняет процесс управления хоть сколько-нибудь большим кол-вом лендов.
3. Смотри следующий пункт 🙃

Добавляем скрипт, убирающий кнопку “Заказать”

Идея скрипта была изложена на канале у Адама, вкратце суть такова: когда юзер нажимает на кнопку “Заказать”, кнопка пропадает и вместо неё появляется текст: “Подождите, идёт отправка заявки”.

Таким образом, пока идёт отправка лида в ПП и загрузка “Спасибо”, юзер не может наплодить ещё с десяток лидов.

Сам скрипт в виде макроса для Кейтаро лежит тут, если хотите чистую JS-версию, возьмите у автора.

Проверки на сервере

Плавно переходим к той части, где вам потребуется уметь в PHP. Проверять лиды на сервере гораздо веселее, чем в браузере у клиента. Почему? Всё просто: если юзер сильно хочет нафродить, а мы ему этого не даём и показываем ему, что именно он сделал не так, то будьте уверенны, он подберёт нужную маску телефона, заполнит полностью имя, короче сделает всё так, чтобы лид ушёл в ПП. Вам это надо? Мне – точно нет. Поэтому, добавляем проверки на сервере и, если что не так, – редирект на голую спасибо без пикселя, без записывания лида в базу трекера и без отсылки в ПП. А юзер об этом ничего не узнает, пусть сидит и впустую тыкает кнопки. Изи!

Добавляем куки с номером телефона

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

Добавляем куки с кол-вом заявок

Идея, похожая на предыдущую, но только на этот раз мы будет добавлять юзеру куки, которая считает, сколько он оставил заявок. Если таковых больше двух (а вторую ему надо позволять оставить, ибо он мог завтыкать и оставить некорректный номер), то мы не шлём лид в ПП и показываем стр. “Спасибо” без пикселя Facebook.

Вот код из моего Кейтаро, который осуществляет две вышеприведённые проверки:

Обрабатываем результаты отправки лида в ПП

Возможно, это будет для вас сюрпризом, но довольно многие партнёрки сразу же после того, как вы отправили им лид, говорят вам, валидный он или нет. Вот примеры, как это выглядит👇

Примеры валидных лидов от М1 Shop

А вот дубли оттуда же

Невалид от Shakes

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

У меня это сделано так: есть общий класс для абстрактной сущности “Партнёрка”, от него наследуются классы для каждой пп и переопределяют метод разбора ответа. Типа:

Проверяем лид по общему списку лидов

Если вы используете любой трекер (например, Кейтаро) и сохраняете в нём имена и телефоны пользователей, то вы можете запилить себе следующую штуку: как только кто-то оставляет новый лид, вы берёте данные лида и проверяете его по своей базе. В целом, достаточно будет проверки номера: если номер уже есть в трекере, то зачем нам ещё один такой же?

Для реализации подобного в Кейтаро чекайте в доках метод conversions/log + не забывайте делать выборку только за сегодняшний день, чтобы не нагружать трекер. Ну и смотрите, чтобы ваша проверка не занимала много времени, для этого для начала обзаведитесь хорошим хостингом.

Вот примерный код, где номер телефона у меня хранится в метке sub_id_15:

Проверяем номера телефонов

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

Ну а сама проверка весьма проста: указываем страну и номер, а библиотека выдаёт, корректный он по её мнению или нет.

ОСТОРОЖНЕЕ: не внедряйте этот метод бездумно, иначе вы можете потерять нормальные лиды. Например, по моим тестам, эта библиотека весьма неплохо работает с европейскими номерами, но довольно посредственно определяет номера из ЛатАма, скажем, из Чили. Поэтому, прежде чем использовать её по полной, внедрите её просто в виде логирования – записывайте, что она думает по поводу вашего трафика, а потом возьмите все невалидные с её точки зрения лиды и проверьте их по трекеру!!

Резюме

Уфф, кажется, на этом всё! Совсем не обязательно внедрять все-все-все вышеприведённые решения. Во-первых, на разных ГЕО разное кол-во любителей тыкать по 20 раз в кнопку “Заказать”, в Европе поменьше, в Африке на порядок больше. А во-вторых, возможность оставить ОДНУ повторную заявку у пользователя должна быть: мало ли он ошибся и ввёл неправильный телефон? Для этого, кстати, неплохо показывать номер телефона и имя на странице “Спасибо”, чтобы юзер видел, что он там навводил. Поэтому начните с малого, и только если вас вконец задрали эти фродеры, приступайте к внедрению всего подряд 🙃

Кажется, ничего не забыл рассказать, но если, вдруг, вы знаете ещё годные способы снизить треш, то welcome в комментарии, дополним список вместе!

А с вами был Жёлтый Веб, лейте в плюс и до связи 🖐️