9 ошибок настройки трекера, которые тихо убивают ваши конверсии
Riccardo Iovine
Аналитик по аффилиатам и трекингу
У самых опасных ошибок настройки трекера в партнёрском маркетинге одна общая черта: ни одна из них не выдаёт ошибку. Неправильно сопоставленная переменная, макрос с опечаткой, неверно выставленное окно — все они дают один и тот же тихий симптом: конверсии исчезают или приходят без атрибуции, пока спенд выглядит совершенно нормально. Это каталог из девяти ошибок, которые обходятся арбитражникам дороже всего, и для каждой — тихий симптом, который она вызывает, быстрое решение и тест, который ловит её до того, как за неё заплатит реальный бюджет.
Краткий ответ: девять ошибок настройки трекера тихо ломают атрибуцию — несовпадение переменной ClickID, опечатки в макросах SubID, ошибки URL-кодирования, несопоставленная переменная выплаты, несовпадение окна атрибуции, отсутствие тестовой конверсии, двойной подсчёт, захардкоженные значения между офферами и пропуск повторного теста после изменений. Каждая даёт здоровый на вид спенд при сломанных данных по конверсиям, и каждая ловится двухминутной рутиной предзапускового теста.
Это тактический справочник по уровню трекера, и честная рамка держится на протяжении всего текста: трекер — это отдельный слой вашего стека, и его правильная настройка — ваша задача. О проблеме, которая стоит за этими ошибками, читайте в материале о скрытом налоге на настройку каждого партнёрского оффера; о рутине, которая их ловит, — в QA-протоколе для отлова сломанных постбэков. Всё это собрано в нашем хабе по партнёрскому маркетингу.
1. Несовпадение переменной ClickID
У сети и у трекера свой плейсхолдер для идентификатора клика, и называются они редко одинаково. Если ваш постбэк сопоставляет ClickID сети не с тем параметром трекера, постбэки уходят в пустоту — они приходят, но не находят ни одного клика.
Несовпадение переменной ClickID — самый частый тихий убийца, потому что оно ломает единственную связку, на которой держится вся система. Всё остальное может быть идеальным, но если конверсия не может найти свой клик, вы получаете конверсии без атрибуции или вовсе ничего, и ничто в дашборде не подскажет причину. Решение — сверить точное имя переменной с обеих сторон до запуска.
Решение: прочитайте документацию и сети, и трекера на предмет точного токена ClickID, сопоставьте их осознанно и отправьте тестовую конверсию, чтобы убедиться в совпадении. Серверные постбэки существуют именно потому, что браузерное отслеживание стало ненадёжным после развёртывания App Tracking Transparency в iOS 14.5 (Apple, апрель 2021), которое срезало сигнал с трафика внутри приложений, — так что сломанный постбэк ломает тот самый канал, который вы взяли ради надёжности.
2. Опечатки или неправильный синтаксис в макросах SubID
SubID несут данные о кампании, группе объявлений и объявлении в конверсию. Макрос с опечаткой, неправильным синтаксисом скобок или токеном, специфичным для платформы, который рекламная система не распознаёт, просто возвращает пустоту — и каждая конверсия приходит без данных кампании.
Решение: кликните по ссылке трекера и проверьте лог кликов. Если SubID там пустые — значит макрос неверный; исправьте синтаксис и кликните снова. Никогда не доверяйте SubID, который вы не видели заполненным в реальном клике.
Пустой SubID — это не мелкая проблема, это полная потеря атрибуции по этому измерению. Конверсия без привязки к кампании говорит вам, что вы заработали комиссию, но не говорит, какое объявление её заработало, — а это ровно те данные, ради которых вы и поставили трекер. Поймать пустые SubID в логе кликов занимает секунды и спасает данные по всему офферу.
3. Ошибки URL-кодирования в постбэке или ссылке трекера
Спецсимволы, вложенные параметры и динамические токены должны быть корректно URL-кодированы, иначе принимающая система разберёт их неправильно. Незакодированный амперсанд может обрезать постбэк; дважды закодированное значение может прийти искажённым.
Решение: кодируйте значения так, как ожидает принимающая система, протестируйте реальной конверсией и проверьте сырые значения, которые приземлились в трекере, вместо того чтобы предполагать, что они дошли в целости.
4. Несопоставленная или отсутствующая переменная выплаты
Конверсия может сопоставиться идеально и всё равно быть бесполезной, если приходит с нулевым значением. Так бывает, когда переменная выплаты сети не сопоставлена с вашим постбэком: конверсии считаются, но не несут выручки — и каждый расчёт рентабельности, который вы делаете, оказывается неверным.
Конверсия без выплаты выглядит как успех, а ведёт себя как провал. Счётчик конверсий верный, поэтому кажется, что всё работает, но выручка нулевая, а вся ваша математика по ROAS — мусор. Переменную выплаты проще всего забыть, потому что конверсия всё равно появляется, — именно поэтому она так часто проскакивает в живой трафик.
Решение: перед запуском убедитесь, что сопоставленная тестовая конверсия показывает правильное значение выплаты, а не ноль. Стандартные переменные мы сопоставляем в руководстве по интеграции трекера.
5. Несовпадение окна атрибуции
Сети обычно используют окна cookie 30–60 дней; ваш трекер или рекламная платформа могут по умолчанию ставить что-то намного короче. Если окно трекера короче, чем у сети, конверсии с большой задержкой выпадают за его пределы и исчезают, из-за чего офферы с более медленным циклом конверсии выглядят убыточными, хотя таковыми не являются.
Решение: выставьте окно атрибуции трекера под окно cookie сети для учёта комиссионных и держите отдельное более короткое окно для оптимизации рекламной части. Отчитывайтесь по обоим и сверяйте. Эта работа по сверке — часть того, почему анализ Nielsen 2024 года показал, что маркетологи по-прежнему тратят примерно половину времени на ручной сбор данных, а не на решения (Nielsen Annual Marketing Report, 2024), — а тихое несовпадение окна вдобавок делает эти собранные данные неверными.
6. Запуск без тестовой конверсии
Ошибка, которая пропускает все остальные. Настроить оффер и запустить его, не отправив ни одной тестовой конверсии, означает, что первым «тестом» становится реальный трафик, тратящий реальные деньги, — и если что-то выше сломано, вы узнаете об этом из плохого отчёта.
Пропуск тестовой конверсии — это мета-ошибка, потому что именно тест ловит все остальные ошибки из этого списка. Он стоит две минуты и превращает хрупкий запуск на надежде в проверенный. Арбитражники, которые теряют деньги на сломанном трекинге, почти всегда те, кто запустился исходя из предположения, что связка работает.
Решение: сделайте тестовую конверсию обязательной на каждом оффере. Рутина из четырёх проверок в QA-протоколе построена ровно вокруг этого.
7. Двойной подсчёт от одновременного срабатывания пикселя и постбэка
Если вы используете и браузерный пиксель, и серверный постбэк без дедупликации, одна и та же конверсия может посчитаться дважды. Цифры раздуваются, отображаемый ROAS врёт в большую сторону, и вы масштабируете оффер на фантомных результатах.
Решение: настройте дедупликацию событий с общим Event ID или зафиксируйте один метод как источник истины, чтобы каждая конверсия считалась ровно один раз.
8. Захардкоженные значения, которые должны быть динамическими
Переиспользовать ссылку трекера от прошлого оффера и забыть поменять захардкоженное гео, код оффера или кастомный SubID — это тихая ошибка отравления данных. Конверсии атрибутируются, но к неправильной метке — и ваш исторический анализ незаметно смешивает два оффера.
Захардкоженные остатки коварны тем, что данные выглядят чистыми. Конверсии сопоставляются, выплаты приходят, SubID заполняются — просто заполняются значением прошлого оффера. Ничто на это не указывает, и порча прячется в отчётности, пока вы не попытаетесь сравнить офферы и цифры не перестанут сходиться. Шаблонизация с осознанными полями под каждый оффер это предотвращает.
Решение: собирайте офферы из чистого шаблона с пустыми полями под конкретный оффер, чтобы каждый раз заполнять их заново, а не наследовать вчерашние значения.
9. Отсутствие повторного теста после изменения
Настройка, которая прошла тест на запуске, может сломаться позже, когда вы редактируете оффер, меняете сеть, добавляете аккаунт или открываете новое гео. Каждое изменение может обнулить параметр, и работающая настройка никогда не безопасна навсегда.
Решение: привяжите повторный тест к каждому триггеру изменения, а не к расписанию. Разрастание аккаунтов и сетей, которое умножает эти триггеры, разобрано в материале о настройке мультиаккаунтной рекламы Facebook для арбитражников.
Работающая настройка — не постоянная настройка. Каждая правка оффера, смена сети, новый аккаунт или новое гео — это свежий шанс для связки тихо сломаться, поэтому повторный тест принадлежит изменению, а не календарю. Тестируйте на запуске, перетестируйте на изменении — и у тихих сбоев почти не остаётся места, где спрятаться.
Один тест, который ловит все девять
Прочитайте решения подряд — и проступает закономерность: каждая из этих ошибок даёт видимый сбой в одном и том же двухминутном предзапусковом тесте. Кликните по ссылке и убедитесь, что SubID записались. Отправьте тестовую конверсию. Проверьте, что она сопоставилась с вашим кликом и с правильной выплатой. Убедитесь, что ID кампании прикреплены. Ошибки с первой по восьмую всплывают в этой рутине, а девятая — это просто запуск её заново после изменения.
Вам не нужно запоминать девять ошибок — вам нужна одна привычка. Фиксированный предзапусковый тест прогоняет всю цепочку из конца в конец, так что какое бы звено ни было сломано, тест падает видимо вместо того, чтобы оффер тихо падал на живом трафике. Дисциплина всегда тестировать стоит больше, чем знание каждого отдельного режима сбоя.
Где здесь место рекламной платформы
Если по-честному: ни одно из этих решений не относится к платформе управления рекламой. Связка трекера и постбэка живёт на уровне трекера, который остаётся в вашем стеке и которым вам настраивать и проверять. Платформа, которая запускает и ведёт вашу рекламу, не настраивает ваши постбэки, и стоит с недоверием относиться к любой, что заявляет, будто полностью заменяет трекер.
Чем занимается Wevion — это сторона запуска и ведения: она собирает и отгружает кампании по аккаунтам через подключение по официальному API, так что повторяющаяся рекламная работа идёт быстрее, пока ваш трекер продолжает атрибутировать рядом. Для пользователей Keitaro это сосуществование — задуманный паттерн, а не конкуренция. Полное честное сравнение стека трекера и рекламной платформы на официальном API — затраты, риски и что именно делает каждая — смотрите в материале о стеке трекера в сравнении с Wevion.
Чините связку на трекере, доведите тестирование до рефлекса, а половину с запуском рекламы отдайте инструменту, созданному для этого. Чтобы ускорить сторону запуска, пока ваш трекер и эти исправления держат атрибуцию честной, начните 14-дневный пробный период — постоянный бесплатный тариф позволяет попробовать сторону управления рекламой, не трогая настройку вашего трекера.
Часто задаваемые вопросы
The Ad Signal
Еженедельные инсайты для медиабайеров, которые отказываются гадать. Одно письмо. Только суть.
Похожие статьи
Скрытый «налог на настройку» каждого нового оффера
Каждый новый оффер — это очередной круг постбэк URL, макросов SubID и S2S-связки. Стоит ошибиться в одном параметре — ошибки не будет, конверсии просто молча исчезнут. Это скрытый налог на скорость арбитража: почему он ломается без предупреждения и как его уменьшить.
QA-протокол: ловим сломанные постбэки до того, как они сольют бюджет
Связка трекера ломается без единой ошибки, поэтому вы замечаете проблему, только когда цифры выглядят странно. Это повторяемый QA-протокол — тест перед запуском плюс лёгкий ежедневный контроль — который ловит сломанные постбэки рано, чтобы вы никогда не оптимизировали живой оффер по атрибуции, которая тихо умерла.
Как интегрировать партнёрский трекер с рекламой Facebook
Пошаговое руководство по интеграции партнёрского трекера с рекламой Facebook: настройка постбэк URL, конфигурация SubID, серверное отслеживание для точности после iOS 14+, согласование окон атрибуции и настройка отчётности, связывающей расходы на рекламу с данными о комиссионных.