Надёжность трекингового домена: DNS, TLS, редиректы и потерянные клики

Редакция mevrica

Трекинг4 мин чтения

Обновлено 3 августа 2026 г.

Трекинговый домен находится раньше лендинга, поэтому его сбой превращает оплаченный клик в пустой сетевой маршрут. При этом общий uptime приложения может оставаться зелёным: DNS отвечает не везде, сертификат истёк для части цепочки, Location ведёт на неожиданный домен или параметр click_id теряется на втором переходе. Контроль должен воспроизводить путь пользователя от разрешения имени до конечного URL.

Проверяйте маршрут, а не процесс

Работающий Node.js или nginx не доказывает доступность клика. SLI строится на внешнем end-to-end запросе из нескольких точек.

1. Инвентаризируйте зависимости

Registrar, authoritative DNS, CDN, сертификат, origin, маршрутизатор и конечный домен имеют разных владельцев и сроки. Для каждого храните контакт, дату продления, способ проверки и допустимый fallback.

Секреты и ключи не помещают в общий паспорт; указывают защищённое место и процедуру доступа.

2. Контролируйте DNS

Проверяйте authoritative ответы, ожидаемые A/AAAA/CNAME, TTL и результат из нескольких резолверов. NXDOMAIN, SERVFAIL и устаревшая запись требуют разных действий.

Локальный кеш на сервере не показывает, что видит пользователь в другом регионе.

3. Следите за TLS

Мониторинг проверяет цепочку доверия, hostname, срок действия и протокол рукопожатия. Алерт задают заранее до истечения, учитывая автоматическое продление и возможность его сбоя.

Успех HTTP-проверки с отключённой валидацией сертификата не является успехом пользовательского маршрута.

4. Разберите каждый redirect hop

Записывайте status, Location, latency и домен. Ограничьте максимальное число переходов и обнаруживайте цикл. Относительные URL нормализуются по стандартному алгоритму, а не конкатенацией строк.

Неожиданное появление нового домена считается изменением маршрута и требует проверки.

5. Проверяйте параметры

Синтетический click ID с test namespace должен дойти до ожидаемой границы в неизменном или документированно преобразованном виде. UTM/SubID проверяются отдельно.

Тестовый идентификатор исключается из продуктовой статистики и postback.

6. Измеряйте latency по компонентам

DNS, connect, TLS, time to first response и redirect duration помогают локализовать рост потерь. Один total скрывает, где возникла задержка.

Используйте распределение p50/p95/p99 и объём; редкие тяжёлые хвосты особенно важны для мобильного трафика.

7. Не создавайте реальные конверсии мониторингом

Health check ограничивается разрешёнными GET/HEAD и тестовым пространством. Он не отправляет формы, не регистрирует аккаунты и не имитирует финансовые действия.

Если HEAD ведёт себя иначе, используйте безопасный GET без прохождения целевого действия.

8. Сопоставляйте инфраструктуру и бизнес

Падение tracker requests при стабильных platform clicks подтверждает разрыв до трекера. Рост requests при падении landing views указывает дальше по цепочке.

Временная шкала изменений DNS, deploy и сертификата ускоряет postmortem.

9. Подготовьте переключение

Резервный домен заранее имеет DNS, TLS, конфигурацию, тесты параметров и допустимость в рекламных материалах. Нельзя впервые настраивать его во время инцидента.

Переключение учитывает кеш и уже опубликованные ссылки; часть трафика может продолжать старый маршрут.

10. Защитите доменное управление

Минимизируйте число владельцев, используйте сильную аутентификацию, журнал изменений и раздельные права для DNS и приложения. Не публикуйте токены управления в репозитории или URL.

Подозрительное изменение записи требует процедуры безопасности, а не обычного rollback без расследования.

Не обходите блокировки скрытым переключением

Резервная инфраструктура предназначена для технической отказоустойчивости в допустимых маршрутах, а не для обхода ограничений платформ, закона или решения пользователя.

11. SLO и бюджет ошибок

Определите успешный end-to-end маршрут и допустимый error budget. Алерт должен учитывать объём: минута отказа во время пика и ночью имеют разный финансовый impact, хотя технический SLI одинаков.

Runbook указывает остановку кампаний, если безопасное восстановление дольше допустимого окна.

Вывод

Надёжность трекингового домена измеряется от DNS до конечного назначения. Проверяйте TLS, каждый redirect, параметры и latency из внешних точек; связывайте технический разрыв с кликами и держите заранее проверенный план остановки или переключения.