Keitaro в self-hosted-стеке: что ставят рядом и где чаще всего ошибаются

Keitaro в self-hosted-стеке: что ставят рядом и где чаще всего ошибаются

Keitaro обычно берут как центральный трекер, а не как «всё в одном». Рабочий стек вокруг него строят так: трекер + домен + SSL + VPS + прокси/антидетект для тестов + отдельный канал для постбеков. Если один элемент слабый, дальше ломается атрибуция, а не только запуск.

Чаще всего проблемы не в самом трекере, а в связке:
— домен с плохой историей или без нормального DNS;
— сервер, который не держит пики и начинает тормозить редиректы;
— кривой postback: часть конверсий уходит в пустоту;
— один и тот же шаблон потоков для разных ГЕО и источников.

Что важно проверить до боевого запуска:
— логика потоков: источник, оффер, преленд, редирект, фильтры;
— раздельные кампании под разные источники трафика;
— резервный домен и запасной путь редиректа;
— UTM и subid без лишней «каши» в названиях.

Keitaro удобен там, где нужна прозрачная маршрутизация и быстрые правки без зависимости от внешнего SaaS. Но если у команды нет человека, который следит за логами, доменами и постбеками, трекер быстро превращается в склад ошибок.

Итог простой: Keitaro раскрывается не сам по себе, а в дисциплине стека. Сначала настраиваешь инфраструктуру и схему данных, потом уже крутишь трафик.