fbclid в арбитраже: разбор 323 089 кликов Keitaro и бот с 57 IP на одной метке

fbclid это идентификатор клика, который Meta сама дописывает в адрес сайта, когда человек нажимает на рекламу в Facebook или Instagram. Для арбитражника метка решает две задачи: связывает заявку с кликом для Conversions API и выдаёт ботов, которые ходят по одной и той же ссылке с десятков адресов. Ниже разберём формат метки по документации Meta, покажем, что с ней делают браузеры и трекер, и выложим свой разбор: 323 089 кликов с настоящим fbclid из Keitaro за 14 суток, 178 474 уникальные метки и одна из них с 57 IP-адресами и 20 заявками без единого апрува. В конце порог для фильтра, расчёт потерь и порядок настройки счётчика.

Данные сняты 28 октября 2026 года с одного трекера Keitaro на ClickHouse, окно 14 суток до 27 октября 22:00 UTC. Это трафик одной команды, в основном лидогенерация с Facebook и Instagram. Офферы, партнёрские сети, гео и адреса в статье не называем. Цифры нельзя переносить на весь рынок: они показывают, как выглядит повтор метки и что с ним делать, а не долю ботов в арбитраже вообще.

Как устроена метка fbclid и зачем её хранить

По документации Meta о ClickID (обновлена 9 января 2026, проверена 28.10.2026) метка добавляется к URL рекламодателя при клике по объявлению и помогает атрибуции и оптимизации. Значение чувствительно к регистру, менять его нельзя. Если на сайте стоит пиксель, он сам кладёт метку в cookie _fbc в формате fb.1.<время в мс>.<fbclid>. Meta рекомендует ставить cookie на 90 дней и обновлять её, когда в адресе пришла новая метка.

В примере из документации метка начинается с IwAR2 и занимает около 60 символов. В нашей выборке таких почти нет: 268 592 клика пришли с префиксом IwZX, 38 454 с PAZX, 12 484 с IwY2, а средняя длина значения 163-177 символов. Это важно для трекера на MySQL: по справке Keitaro о ClickHouse именно переход на ClickHouse снял ограничение в 255 символов для sub_id_1-30. Если метки обрезаются, отправка fbc в Conversions API ломается молча.

Зачем метку хранить, объясняет список параметров Conversions API: поле fbc передаётся без хеширования, вместе с ним Meta просит реальный IP и User-Agent клиента для сопоставления события. Без fbc событие из CRM Meta сопоставляет хуже, а значит хуже оптимизирует кампанию под лиды. Как собрать такую передачу на практике, описано в разборе Keitaro и CAPI.

Метки других площадок устроены похоже, поэтому логика ниже переносится на gclid и yclid, а Brave в своём списке называет ещё и msclkid Microsoft. Общие правила для UTM и параметров в ссылке собраны в статье про UTM-метки, а синтаксис строки запроса задаёт RFC 3986, раздел 3.4.

Что с меткой делают браузеры и трекер

Часть кликов приходит без fbclid, и это не всегда бот. Brave по умолчанию вырезает известные трекинговые параметры, прямо называя fbclid, gclid и msclkid. Safari в приватном режиме удаляет подмножество параметров, которые определены как средство межсайтового отслеживания, но оставляет параметры кампании вроде campaign. Firefox с версии 102 делает то же самое при строгом режиме защиты от отслеживания. Все три документа проверены 28.10.2026. По той же записи WebKit сторонние скрипты на странице в приватном режиме получают адрес вообще без параметров, так что клиентский пиксель метку не увидит, даже если в навигации она уцелела.

Клик без метки из обычного браузера бывает и у живых людей: в нашей выборке 77 777 кликов из 446 461 пришли с пустым sub_id_26 и дали 579 заявок. Рубить их по одному признаку отсутствия метки нельзя. Что будет с fbclid и gclid в новых версиях Safari, мы разбирали в новости про iOS 27 и Safari 27.

Вторая потеря происходит уже в трекере. Справка Keitaro по интеграции Facebook Conversions на 28.10.2026 пишет дословно: «fbclid формируется автоматически и не передается макросом от источника. Наличие fbclid={fbclid} в ссылке мешает записи метки в трекер». Если в Ads Manager в параметрах URL вписан fbclid={fbclid}, трекер получает буквальную строку вместо значения.

Мы проверили это на своих данных. Из 368 684 кликов с непустым sub_id_26 ровно 45 595, или 12,4%, содержат буквальную строку {fbclid}. Это 28 кампаний из 120, где параметр вообще заполнялся, и в 25 из них рядом есть клики с настоящей меткой: ссылку исправили не везде или не во всех объявлениях. На эти 45 595 кликов пришлось 480 заявок из 5 757 за период, то есть 8,3% всех конверсий ушли в CRM без fbc. Сколько это стоило в оптимизации Meta, по нашим данным посчитать нельзя, но сама документация Meta называет fbc способом увеличить объём сопоставленных конверсий.

Разобрали 323 089 кликов: как часто метка повторяется

Для разбора мы взяли все клики трекера с настоящим fbclid за 14 суток и сгруппировали их по значению метки. Для каждой метки посчитали число уникальных IP-адресов, кликов, заявок и их статусов. Запрос выполнялся напрямую в ClickHouse трекера функцией uniqExact, без выборочных оценок. Скрипт запроса лежит в папке подготовки статьи, в текст идут только агрегаты.

Итог: 178 474 уникальные метки. У 175 243 из них, то есть 98,2%, все клики пришли с одного адреса. У 3 051 метки адресов два, это 1,7%. И только 180 меток, 0,1%, видели три адреса и больше. Один повтор с другого адреса это норма, а не бот: у 2 309 меток из 3 051 оба адреса принадлежат одному провайдеру, 3 049 остались в одной стране, а 1 323 второй клик сделали в пределах пяти минут. Так выглядит переход телефона с мобильной сети на Wi-Fi или смена адреса у оператора.

Группа от трёх адресов ведёт себя иначе. Из 180 меток только 99 остались в рамках одного провайдера, медианный разброс между первым и последним кликом 9,1 часа, у 66 меток больше половины кликов пришли с пустым referrer. Ниже сравнение групп по заявкам. Апрув здесь считаем как долю продаж среди заявок с решённым статусом: sale делим на сумму sale и rejected. Заявки в статусе lead ещё ждут решения.

Конверсия в заявку у группы «6 и больше» почти в шесть раз выше средней, апрув нулевой. Это и есть сигнатура бот-лидов: скрипт нажимает кнопку заявки гораздо охотнее человека, а колл-центр потом не дозванивается. Как проверять такие номера до отправки в сеть, мы писали в материале про проверку номеров по API, а что происходит с заявкой дальше, в статье про путь лида от клика до выплаты.

Обратная сторона: 130 244 адреса принесли по одной метке, 13 474 по две, а семь адресов дали больше 20 меток каждый, 311 кликов и ни одной заявки в статусе lead. Так выглядят выходы операторских NAT и прокси, и фильтр по адресу их не отличит от людей. Считать нужно адреса на метку, а не метки на адрес.

Один fbclid, 57 адресов, 20 заявок: портрет бота

Самая повторяемая метка прожила 31 час: с 09:00 UTC 26 октября до 16:00 UTC 27 октября. За это время 58 кликов с 57 разных адресов, четырёх провайдеров, восьми регионов и шестнадцати городов одной страны. Интервал между соседними кликами почти постоянный: медиана 1 308 секунд, четверть кликов в пределах 1 144 секунд, три четверти в пределах 1 456. Человек так не ходит, у скрипта стоит пауза около 20 минут с небольшим разбросом.

Из 58 кликов вышло 20 заявок: 13 в статусе lead и 7 уже отклонены партнёрской сетью, продаж ноль. По логу конверсий 19 из 20 постбеков пришли 27 октября между 00:00 и 06:59 UTC, ещё один 26 октября в 15:52. Медианное время от клика до постбека у этой метки 98 секунд против 185 секунд по всем заявкам трекера за период: скрипт заполняет форму быстрее людей. Трекер при этом не поставил ни одной отметки бота и ни одной отметки прокси: встроенная проверка Keitaro смотрит на списки адресов и User-Agent, а здесь адреса принадлежали четырём обычным провайдерам, 40 кликов трекер отнёс к Wi-Fi и 17 к мобильной сети, отметок прокси нет, а User-Agent выглядел как Chrome. Какие признаки отличают эту метку от нормальных кликов, видно в таблице. Для масштаба: за 27 октября трекер записал 436 постбеков по всем кампаниям, и 19 из них, 4,4%, пришли с одной этой метки. Ни один не стал продажей.

Ещё одна деталь: у этой метки четыре версии Chrome Mobile, 141, 144, 147 и 152, и один клик с Windows и Chrome 155. На дату проверки стабильная версия Chrome для Android по данным Chromium Dash была 156.0.8078.73. Живой телефон обновляет браузер сам и редко отстаёт на 15 версий, а здесь версии явно крутятся по списку. Один клик с версией из прошлого года ничего не значит, четыре разных версии на одной метке значат многое.

Откуда у скрипта чужая метка. fbclid появляется только при клике по объявлению, значит один настоящий клик был: его сделал оператор бота, спай-сервис или конкурент, а адрес с меткой скопировали из строки браузера и раздали на 57 устройств или прокси. Деньги ушли только на исходный показ и клик: в кампании, куда бил скрипт, импортированный расход в пересчёте на клик около $0,02 (по трекеру в среднем $0,09). Остальные 57 обращений рекламодателю ничего не стоили, зато принесли 20 заявок, которые колл-центр обзванивал впустую, и ноль продаж. В отчёте Keitaro при этом на клики бота легло $2,46 расхода, по $0,04 на клик: трекер разносит импортированные затраты по дням и объявлениям, а 27 октября кампания открутила вдвое больше обычного. За сами клики бота Meta денег не списывала, и видимая цена живых кликов из-за этого чуть занижена. Чем такой поток заканчивается в партнёрской сети, мы разбирали в материале про нулевой апрув в Keitaro.

Почему пустой referrer и «Android 10; K» сами по себе не приговор

Взять три признака бота и рубить по ним нельзя. По документации Privacy Sandbox о сокращении User-Agent, проверенной 28.10.2026, Chrome на Android теперь отдаёт в строке только название браузера, версию, признак мобильного устройства и платформу. Модель телефона и версия Android заменены на постоянные значения, и в примере из документа это буквально «Android 10; K». Такую строку присылает каждый обычный Chrome на Android.

То же с referrer. По справочнику MDN заголовок Referer содержит адрес страницы со ссылкой, но политика Referrer-Policy со значением no-referrer убирает его полностью. Внутренний браузер приложения Facebook отправляет заголовок, а системный Chrome после перехода из приложения может его потерять. Заголовок X-Requested-With, по документации AndroidX WebView, исторически отправлялся на все запросы из WebView с именем пакета приложения. Его нет у любого клика, открытого во внешнем браузере.

Мы проверили сочетание всех трёх признаков на выборке. Клики с пустым referrer, без X-Requested-With и с «Android 10; K» одновременно: 8 971 из 323 089, это 2,8%. Они принесли 116 заявок. Отсечь их целиком значит выбросить сотню живых заявок ради одного бота. Поэтому признаки клика годятся как добавка к весу, а решающим сигналом остаётся повтор метки с разных адресов.

Флаг navigator.webdriver из спецификации WebDriver тоже не спасает: скрипт на лендинге проверит его только после загрузки страницы, а заявка прямым POST на обработчик формы страницу не загружает. Повтор fbclid виден ещё на редиректе трекера, а та же проверка в обработчике формы закрывает прямой POST: об этом шаг 8 ниже.

Чем отсекать повторы и какой порог ставить: бэктест на 323 089 кликах

По описанию отчёта Thales Bad Bot Report 2026 на сайте Imperva, проверенному 28.10.2026, боты составляют большинство мирового веб-трафика по данным за 2025 год, так что свой слой фильтрации нужен в любом случае. Площадки защищают только свой счёт. Справка Google Ads о недействительном трафике на 28.10.2026 описывает автоматические проверки за последние 60 дней и возврат денег за недействительные клики корректировками в истории платежей. Заявки на вашем лендинге в эту проверку не входят. Правила обхода системы и программа Ad Traffic Quality касаются кликов по объявлениям. Заявки, которые скрипт отправил на ваш лендинг, площадка не видит и не компенсирует.

У Meta похоже. Стандарты рекламы Meta и отчёт о фейковых аккаунтах говорят о блокировке миллионов попыток создать поддельные аккаунты ежедневно, а советы по лид-формам предупреждают, что тысячи заявок за короткое время перегружают колл-центр. В мгновенных формах есть проверка номера одноразовым кодом и проверка рабочего email для B2B: против скрипта первая полезнее. Но лендинг на своём домене с формой защищает только владелец лендинга.

Поэтому фильтрация стоит на своей стороне, и начинать её лучше до трекера. Первый слой в нашей связке это KLO: сервис стоит перед трекером, проверяет адрес, сеть, заголовки и поведение запроса и уводит в вайт дата-центры, краулеры площадок и подменённые User-Agent ещё до того, как клик попадёт в статистику. Как устроен такой контур целиком, описано в разборе клоакинга и в настройке клоаки под Meta. Но бот из нашего примера шёл с адресов обычных провайдеров и с правдоподобным браузером, и его выдал именно повтор метки. Этот сигнал считается уже внутри трекера, где метка записана.

Внутри Keitaro три штатных инструмента, проверены 28.10.2026: списки ботов с дополнительными UA и IP, спам-ботами и переключателем «Пустой User Agent считать признаком бота»; фильтры потоков с отношением И/ИЛИ и примером перехватывающего потока для ботов; чёрные и белые списки по значению любого параметра.

Расширенный счётчик пишется как пользовательский фильтр Keitaro: класс в каталоге /var/www/keitaro/var/filters/ с методами getModes, getTemplate и isPass, который получает объект клика и возвращает, прошёл ли он. Для хранения счётчика подходит Redis: SADD кладёт адрес в множество метки, SCARD считает адреса в нём, а EXPIRE задаёт срок жизни ключа в секундах.

Порог проверили бэктестом на той же выборке. Правило простое: клик блокируется, если он приносит метке N-й новый адрес или любой следующий. Мы проиграли все клики по времени для N от 2 до 6 и посчитали, что ушло бы в перехват. Окно взяли на все 14 суток, это строже суточного, так что потери живых заявок здесь оценены сверху.

Порог 2 режет 5 продаж и 31 живую заявку ради тех же 20 ботовых: это смена адреса у людей. Порог 3 снимает все 20 заявок скрипта, ни одной продажи и всего 683 клика из 323 089, то есть 0,2%. Пороги 4-6 ловят те же заявки, но пропускают в статистику больше ботовых кликов. Группа 3-5 адресов со своими 16 заявками и 5 продажами фильтр не задела: эти заявки пришли с первого или второго адреса метки. Оговорка: все 20 пойманных заявок принадлежат одному скрипту, других ботов такого типа в выборке за две недели не было, так что порог проверен на одном случае. Недельный порог 5 адресов нужен для медленных ботов: из 179 меток с тремя и больше адресами, не считая самого бота, 60 растянуты дольше суток, а 32 дольше трёх суток, и суточное окно их не увидит.

Сколько стоит бот-лид: расчёт на наших цифрах

Сначала настоящая кампания, в которую бил скрипт, за те же 14 суток: 11 863 клика, 370 заявок, из них 18 продаж, 244 отклонены (7 от бота) и 108 ждут решения (13 от бота). Апрув среди решённых 18 из 262, то есть 6,9%. Без заявок бота он был бы 18 из 255, 7,1%. Если 13 ждущих заявок скрипта тоже отклонят, апрув станет 18 из 275, 6,5%. Бот сдвинул апрув этой кампании на полпункта, и это не главный ущерб.

Главные деньги прячутся в отчёте трекера. Пока заявка висит в статусе lead, Keitaro показывает по ней ожидаемую выплату: у метки с 57 адресами это 13 заявок по $23, итого $299 в графе lead_revenue, при $2,46 расхода, которые трекер разнёс на её клики. Подтверждённая выручка всей кампании за две недели $576, то есть одна метка нарисовала в отчёте ложных ожиданий на 52% от реальных денег, а по собственным кликам показала ROI больше чем в сто раз: 299 делим на 2,46. Всего в кампании висит $2 538 ожидаемой выручки по 108 ждущим заявкам, доля бота в них 12%; остальное ложным ожиданием делает низкий апрув самой кампании, а не скрипт. Байер, который смотрит на lead_revenue, масштабирует связку, которую кормит скрипт.

Третий расход это время колл-центра: 19 заявок пришли с 00:00 до 06:59 UTC и к утру лежали в очереди на дозвон, 20 пустых попыток с повторами. Цены минуты оператора у нас нет, подставьте свою. Как считать апрув, холд и EPC, разобрано в материале про метрики арбитража.

Ниже модель для кампании с нормальным апрувом, чтобы оценить тот же скрипт на здоровой связке. Средняя выплата за подтверждённую заявку в выборке около $27,8, медиана по трекеру $26. Берём кампанию с 200 решёнными заявками и 56 продажами, апрув ровно 28%. Бот добавляет 20 заявок, и все они отклоняются. Новый апрув: 56 делим на 220, 25,5%, падение на 2,5 пункта за 31 час. Формула для своей кампании: новый апрув равен S делить на сумму L и B, где S продажи, L решённые заявки, B заявки бота. В столбце «с порогом» ноль заявок и ноль звонков, потому что на бэктесте первые два клика этой метки заявок не дали; для другого бота худший случай это две заявки с первых двух адресов.

Что стоят сами инструменты, сняли с сайтов 28 октября 2026 года. Для счётчика повторов хватает Redis на том же сервере и тарифа Keitaro с пользовательскими фильтрами; Cloudflare и KLO это слои до трекера.

Цены Cloudflare зависят от периода оплаты, у KLO годовая оплата даёт скидку 20%, поэтому в таблице обе цифры; помесячную цену Keitaro мы не снимали, на странице она открывается отдельным переключателем. Тарифы не включают сам фильтр: это скелет в дюжину строк плюс подключение к Redis и обработка ошибок.

Счётчик повторов fbclid: пошагово

Порядок ниже рассчитан на Keitaro на ClickHouse, но подойдёт любому трекеру с пользовательскими фильтрами и Redis. Все действия на тестовой кампании и на копии потока, прод трогаем после проверки.

1. Убедитесь, что метка пишется. Откройте лог кликов и добавьте колонку с параметром, куда попадает fbclid. Значения должны начинаться с Iw или PA и быть длиннее 100 символов. Если видите строку {fbclid}, уберите макрос из параметров URL в Ads Manager, как требует справка Keitaro. У нас так были потеряны 45 595 кликов.
2. Снимите базовую картину. Запросом к ClickHouse сгруппируйте клики по метке и посчитайте уникальные адреса. Ожидаемый результат: больше 95% меток с одним адресом, доли процента с тремя и больше. Если у вас 10% меток с тремя адресами, сначала ищите ошибку в ссылке или прокси у аудитории, а не включайте фильтр. Запрос для Keitaro на ClickHouse ниже, он только читает таблицу кликов.
3. Создайте фильтр. Файл в /var/www/keitaro/var/filters/ по шаблону из документации. В isPass читайте метку и адрес клика методами getSubIdN и getIpString из описания RawClick, добавляйте адрес в множество ключа с префиксом по хешу метки и держите второе множество на 7 суток. Срок жизни ставьте только новому ключу, иначе каждый клик будет продлевать окно. Повтором считайте третий адрес за сутки или пятый за неделю. По справке true в isPass значит «клик прошёл на поток», поэтому результат возвращайте с учётом режима: режим читайте через getMode, как в примере из документации, но инверсию для режима «Нет» пишите сами, в примере справки её нет. В режиме «Да» на поток идут повторы, в режиме «Нет» все остальные. Клики без метки и с {fbclid} считайте не повтором в обоих режимах. Вызовы Redis оберните в try/catch: при ошибке считайте клик не повтором и пишите в лог, иначе упавший Redis сломает редирект всей кампании.
4. Прогрейте счётчик историей до включения перехвата. Новый ключ в Redis ничего не знает о вчерашних кликах, и первые часы фильтр слеп. Загрузите пары метка-адрес за последние 7 суток из ClickHouse, иначе бот, который уже ходит, получит ещё два бесплатных клика после включения.
5. Поставьте перехватывающий поток. По схеме фильтров первый поток с типом перехвата получает наш фильтр в режиме «Да»: на этот поток попадают только повторы, и он ведёт на белую страницу. Остальной трафик идёт по потокам ниже как раньше. Для тестовой кампании сделайте второй поток без фильтра, чтобы сравнить статистику.
6. Проверьте первые сутки. В логе кликов отфильтруйте поток перехвата: туда должны попадать только метки с тремя адресами и больше. Сверьте, что заявки из этого потока не доходят до партнёрской сети, а апрув остальных не упал. Бот из нашего примера был бы остановлен на третьем клике, во второй час работы скрипта утром 26 октября.
7. Договоритесь о статусах. Заявки, которые бот успел отправить до включения, пометьте в своей базе как дубликаты и не отправляйте повторно. Правила отсечения дублей на самой форме есть в статье про защиту формы от повторной отправки.
8. Закройте прямой POST. Скрипт может слать заявку сразу в обработчик формы, минуя редирект. По справке о параметрах кампании локальный лендинг получает все входящие параметры клика POST-запросом, а для лендинга на другом хостинге их отдаёт Click API. Обработчик формы читает subid и метку, сам добавляет адрес запроса в то же множество в Redis и для метки-повтора показывает страницу «спасибо», не отправляя заявку в сеть. Заявку с subid, которого трекер не видел, тоже не отправляйте: так отсекается скрипт, который вообще не ходит через редирект. Проверять без Admin API просто: фильтр при каждом клике кладёт subid в Redis ключом со сроком жизни сутки и меткой в значении, а обработчик формы проверяет наличие ключа и берёт из него метку. Subid кладите для каждого клика, в том числе без метки и с {fbclid}, до проверки повтора: иначе форма отбросит живые заявки без fbclid, а их в нашей выборке 1 059. Один счётчик закрывает и редирект, и форму.

Схема из документации повторяет этот порядок: перехват сверху забирает ботов и клики без источника, остальной трафик идёт ниже. Фильтр повторов в режиме «Да» добавляет в перехват ещё одно условие.

SELECT multiIf(n = 1, '1', n = 2, '2', n <= 5, '3-5', '6+') AS ips_per_fbclid,
       count() AS fbclids, sum(c) AS clicks, sum(l) AS conversions
FROM (SELECT sub_id_26, uniqExact(ip) AS n, count() AS c,
             countIf(is_lead = 1 OR is_sale = 1 OR is_rejected = 1) AS l
      FROM keitaro.keitaro_clicks FINAL
      WHERE sign = 1 AND datetime >= subtractDays(now(), 14)
        AND sub_id_26 != '' AND sub_id_26 != '{fbclid}'
      GROUP BY sub_id_26)
GROUP BY ips_per_fbclid ORDER BY ips_per_fbclid;

Номер sub_id подставьте свой: он виден в параметрах кампании. Условие по полю sign и слово FINAL нужны из-за того, как Keitaro хранит обновления кликов в ClickHouse; без них повторы посчитаются дважды. Запрос на 446 тысячах кликов у нас отработал за секунды и не нагрузил трекер. Результат сохраните: через месяц сравните, не выросла ли доля повторов после смены офферов или аудиторий.

Код самого фильтра короткий. Ниже скелет проверки внутри isPass: это иллюстрация логики, не готовый модуль, обработку ошибок Redis и настройки подключения добавьте под свой сервер.

$fbclid = $rawClick->getSubIdN(26);
// subid пишем для всех кликов, до проверки метки: иначе форма отбросит живые заявки без fbclid
$redis->set('fbrb:sid:' . $rawClick->getSubId(), $fbclid, ['ex' => 86400]);
// без метки или с плейсхолдером клик не повтор ни в одном режиме
if ($fbclid === '' || $fbclid === '{fbclid}') { return $filter->getMode() != StreamFilter::ACCEPT; }
$key = 'fbrb:' . md5($fbclid);
$ip = $rawClick->getIpString();
$week = $key . ':w';
$redis->sAdd($key, $ip);
if ($redis->ttl($key) < 0) { $redis->expire($key, 86400); }    // окно сутки, только новому ключу
$redis->sAdd($week, $ip);
if ($redis->ttl($week) < 0) { $redis->expire($week, 604800); } // окно неделя
// третий адрес за сутки или пятый за неделю считаем повтором
$isRepeat = $redis->sCard($key) >= 3 || $redis->sCard($week) >= 5;
// режим «Да» на перехватывающем потоке пропускает на него именно повторы; инверсию для «Нет» пишем сами
return $filter->getMode() == StreamFilter::ACCEPT ? $isRepeat : !$isRepeat;

Обратите внимание на проверку метки: клики без метки и с плейсхолдером не считаем повтором, их фильтрует другой слой. Иначе все 45 595 кликов с {fbclid} из нашей выборки попали бы в один ключ и улетели в вайт целиком вместе с 480 живыми заявками.

Что проверить перед запуском

• В Ads Manager в параметрах URL нет fbclid={fbclid}; в логе кликов метка длиннее 100 символов и начинается с Iw или PA.
• Трекер хранит метку целиком: на ClickHouse по справке лимита 255 символов нет.
• Пиксель и Conversions API получают fbc из cookie _fbc или из метки, как описано в документации Meta; почему события могут не доходить, разобрано в статье про пиксель Facebook.
• Базовая доля меток с тремя адресами и больше снята до включения фильтра и записана: у нас 0,1%.
• Порог 3 адреса в сутки и 5 в неделю, окно живёт в Redis с EXPIRE, счётчик прогрет историей за 7 суток.
• Клики без метки не попадают под счётчик и фильтруются отдельно: у нас это 77 777 кликов и 579 заявок.
• Поток перехвата ведёт на белую страницу, а не на ошибку 403: бот не должен понять, что его поймали.
• Через сутки сверены апрув основного потока и список меток в перехвате; при ложных срабатываниях сначала поднимаем порог, а не выключаем фильтр.

Частые вопросы

Что в итоге

fbclid это не мусор в ссылке, а ключ, который связывает заявку с кликом и выдаёт ботов. Первым делом уберите fbclid={fbclid} из параметров URL: у нас эта ошибка оставила без метки 12,4% кликов с заполненным параметром и 8,3% всех заявок. Затем посчитайте адреса на метку в своём трекере: норма 98% меток с одним адресом и доли процента с тремя. Метка с 57 адресами и 20 заявками без апрува прошла все встроенные проверки Keitaro, и поймал её только счётчик повторов. Ставьте порог 3 адреса в сутки и 5 в неделю: на бэктесте он снял все 20 бот-заявок, ни одной продажи и 0,2% кликов. Прогревайте счётчик историей, уводите перехват в вайт, проверяйте метку и на форме, сверяйте апрув через сутки. Первый слой перед трекером оставьте за фильтром вроде KLO: он снимает дата-центры и краулеры, а повтор метки добивает тех, кто прошёл.