<b>TDS ломает связку не чаще, чем его неправильно считают в трекере</b>

<b>TDS ломает связку не чаще, чем его неправильно считают в трекере</b>

TDS нужен не для «магии маршрутизации», а для контроля потока: куда уйдёт клик, какой сегмент получит оффер, и где теряется CR. Если распределение трафика не привязано к логике теста, вы сравниваете не связки, а шум.

Базовая схема простая:
— делите поток по GEO, устройству, времени и источнику;
— на каждый сегмент ставьте отдельный маршрут и отдельный postback;
— не смешивайте разные преленды в один маршрут, если хотите видеть реальный EPC;
— лимит на ветку задавайте не «на глаз», а через объём кликов, достаточный для статистики.

Ошибка №1 — отправлять весь трафик в один оффер и менять только ссылку в TDS. В этом случае вы не тестируете распределение, вы маскируете проблему. Ошибка №2 — делать редирект-цепочку слишком длинной: растёт latency, падает CTR на посадочной, и вы теряете часть конверсий до трекера.

Смысл TDS в том, чтобы изолировать переменные. Анализ показывает, что данные говорят сами за себя: если у сегмента выше EPC при сопоставимом CR, ему нужен отдельный маршрут, а не «общая корзина». Тестируем гипотезу через A/B-тесты, остальное — догадки.

Цифры в трекере — ваш единственный источник правды. Если TDS и аналитика не совпадают по кликам и конверсиям, сначала чините схему распределения, потом масштабируйте трафик.