Этот пост - операционный план: как мы переносим клиента с Keitaro на TDS.SO так, чтобы он не потерял ни одного клика и ни одной конверсии. Цифра «24 часа» - не маркетинг, а реальный SLA, который держит наш менеджер миграции. Ниже разбираем процесс целиком: что делает менеджер, что делаете вы, какие есть risk-зоны и как мы их обходим.

TL;DR

Мы переносим домены, кампании, потоки и постбэки за один рабочий день. Менеджер ведёт процесс в Telegram. Click ID сохраняется - статистика партнёрки сходится. После миграции вы продолжаете работу как обычно, но в новой панели.

Почему именно 24 часа

Дольше - значит две недели «двойной бухгалтерии», когда часть трафика идёт через старую систему, часть - через новую, и в обоих местах что-то ломается. Быстрее - значит обещание, которое нельзя сдержать на реальных кампаниях с десятками доменов и сотнями потоков.

24 часа - это:

  • Утро (Москва) - звонок с менеджером, аудит текущей структуры в Keitaro.
  • День - авто-конвертер JSON-экспорта, сверка лендингов, импорт в TDS.
  • Вечер - переключение DNS, тестовые клики, проверка постбэков.
  • Ночь - мониторинг трафика на новой системе, dual-routing на случай отката.
  • Утро следующего дня - финальная сверка статистики, отключение старой системы.

Подготовка: что нужно от вас

Менеджер пришлёт вам короткий чек-лист в Telegram сразу после первого звонка. Если соберёте всё за полчаса - мы стартуем в этот же день.

  • Доступ к Keitaro (read-only пользователь или JSON-экспорт кампаний)
  • Список доменов и где они зарегистрированы (Cloudflare, Namecheap, GoDaddy и т.д.)
  • Партнёрки и постбэки: ссылки конверсии и формат click ID
  • Активные потоки трафика: какие источники, какие гео, какие лендинги
  • Окно даунтайма (если возможно - мы стараемся обойтись без него)

Перенос доменов: 5 минут на домен

Самая чувствительная часть. Если переключить DNS неправильно, вы теряете трафик на 1-24 часа в зависимости от TTL и кеша провайдеров.

Наш подход:

  1. За 24 часа до миграции снижаем TTL на DNS-записях до 60 секунд.
  2. Создаём CNAME к нашему edge-хостнейму (edge.tds.so), который умеет проксировать на оба бэкенда.
  3. Включаем dual-routing: 90% трафика идёт в Keitaro, 10% в TDS - для проверки.
  4. Через 30 минут проверяем статистику: если всё сходится, переключаем 100%.
# Пример: переключаем домен через Cloudflare API
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE/dns_records/$ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "CNAME",
    "name": "go.example.com",
    "content": "edge.tds.so",
    "ttl": 60,
    "proxied": true
  }'
SSL-сертификаты

Не нужно заранее генерировать или передавать. Наш edge выпускает Let's Encrypt-сертификат автоматически в момент привязки CNAME - обычно за 30-60 секунд.

Импорт кампаний: 10 минут на 100 потоков

У нас есть авто-конвертер Keitaro JSON → TDS-формат. Он понимает:

Сущность Keitaro Эквивалент TDS Заметки
Campaign Flow 1:1 маппинг
Stream Branch все 30+ параметров фильтров переносятся
Landing Landing URL и токены сохраняются
Offer Offer payout, click-cap, gates переносятся
Filter Pre-rule логика «если/то» перестраивается автоматически

Что не переносится автоматически и требует ручной проверки:

  • Кастомные PHP-скрипты в обработчиках Keitaro. Мы либо переписываем их в JS-функции (если простые), либо предлагаем альтернативу через webhook.
  • Sticky-сессии по cookie - на TDS они работают по-другому, нужно объяснить логику менеджеру.
  • Архивные кампании старше 90 дней - обычно их не переносим.

Переключение трафика

Самый стрессовый момент. Здесь мы не делаем «бах и переключили», а используем поэтапный flip:

  1. 10% → TDS, 90% → Keitaro. 30 минут наблюдения.
  2. 50% → TDS если статистика сходится. Ещё 1 час.
  3. 100% → TDS если конверсия не упала. Keitaro оставляем как fallback на 24 часа.
Что считается «ок»

CR (conversion rate) на TDS должен совпадать с CR Keitaro в пределах ±5%. Если расхождение больше - мы откатываемся и ищем причину. Чаще всего это разница в сегментации антибота: TDS отсеивает чуть больше «грязного» трафика, и это видно в логах.

Проверка: что мониторим в первые 24 часа

  • Click-to-conversion latency: должна быть ≤ 28 мс p95. Выше - алерт менеджеру.
  • Postback success rate: ожидаем 99.9%+. Падения - индикатор проблемы с маппингом click ID.
  • Bot detection rate: должен быть в той же ±10% диапазоне, что и до миграции.
  • HTTP-ошибки: 5xx > 0.1% - стоп-лосс, откат.

Что дальше

После 24 часов вы получаете:

  • Отчёт о миграции в Telegram: сколько потоков перенесено, какие сводки сходятся, где есть расхождения.
  • Доступ к панели TDS со всеми вашими кампаниями.
  • Прямой контакт с менеджером миграции на 7 дней - на случай вопросов и тонкостей.

Стоимость миграции - ноль. Мы не берём деньги за перенос: интерес в том, чтобы вы остались. Если в первый месяц что-то не сложилось, вернём оплату за подписку.