Как TDS внутри Smartlink выбирает оффер и где чаще всего ломается логика

Как TDS внутри Smartlink выбирает оффер и где чаще всего ломается логика

TDS в smartlink — это не «рандомная раздача», а последовательность правил: гео, устройство, ОС, язык, источник, sub_id, скорость ответа и статус оффера. Если хотя бы один слой настроен криво, алгоритм обучается на мусоре и начинает распределять трафик не по качеству, а по шуму.

Базовая схема такая: запрос приходит в TDS, дальше идет матчинг по приоритетам, затем проверка доступности оффера, потом выбор по весам или правилам ротации. Если у вас не прокинут postback, вы не видите финальный аппрув и сравниваете клики с пустой воронкой. Алгоритм обучается на ваших данных, не мешайте ему шумом.

Что обязательно контролировать:
— корректный sub_id на каждом уровне цепочки;
— единый нейминг источников и площадок;
— дедупликацию повторных кликов;
— таймауты ответа офферов и fallback-ветки;
— раздельный анализ EPC по сегментам и операторам.

Ошибка номер один — смешивать разные типы трафика в одной ротации. Ошибка номер два — менять правила слишком часто: TDS не успевает накопить статистику, и вы сами ломаете распределение. Сплит-тест — единственный объективный судья в арбитраже, особенно когда нужно понять, где проседает CR: на преленде, в TDS или уже на стороне оффера.

Смотрим на EPC в разрезе сегментов и операторов, прокидываем sub_id для глубокой аналитики воронки, а потом уже режем нерелевантные ветки. Трафик не терпит кривых настроек postback-запросов: если трекинг сломан, любая «оптимизация» превращается в гадание.