CGNAT в мобильных сетях

Если вы запускаете рекламу, считаете конверсии, используете SEO‑инструменты или строите антифрод, у меня есть новость: значительная часть ваших решений опирается на иллюзию. Иллюзию «уникального» IP‑адреса. В мобильных сетях пользователи чаще всего выходят в интернет через CGNAT (Carrier‑Grade NAT), и один публичный адрес может одновременно разделять сотни и даже тысячи абонентов. Итог: «плохой» клик может затоптать «хороший» визит в логе; бан по IP отрежет от продукта невиновных; а гео‑таргетинг и частотные ограничения в рекламе срабатывают не так, как в учебниках.

CGNAT родился из дефицита IPv4: адресов мало, устройств много. Операторы связи решают проблему за счет NAT на уровне ядра сети (NAT444/LSN), объединяя абонентов за одним внешним IP. Это удобно и дешево для оператора, но болезненно для маркетинга, SEO и продуктовой аналитики. Почему? Потому что IP‑адрес перестает быть надежным идентификатором: он не уникален, он динамический, он «шумит» из‑за множества параллельных сессий. Вы видите аномально высокие всплески трафика с одного адреса, но это не ботнет, а «переезд» части абонентов на новую пулу. Вы пытаетесь построить RFM‑сегментацию или LTV‑модель на уровне источников, а атрибуция искажается из‑за общих IP. Вы ограничиваете частоту показов (frequency capping) по IP — и страдает охват, CTR падает, а ROAS «уезжает» в сторону.

У SEO‑инструментов свои проблемы. Сбор SERP через дата‑центровые IP все чаще ловит капчи и баны, а попытка «подглядеть» реальную выдачу с мобильного превращается в лотерею: геолокация по общему IP может быть грубой (разброс по региону), а поведенческие метрики (погостить‑кликнуть‑вернуться) смешиваются с десятками параллельных пользователей. Да, можно усиливать фингерпринтингом, работать с IDFA/GAID в приложениях, добавлять куки и localStorage, Но в браузерном мире и при строгих политик privacy (ITP/ETP, блокировка третьих куки, ограничение отпечатков) упор на IP в 2025 году — это как строить небоскреб на песке.

С CGNAT меняется и рисунок рисков. Блокировка IP по антифроду закрывает доступ сразу целой группе абонентов: падают CR, растет отказ в авторизации, службы поддержки тонут в «ничего не работает» без видимой причины. Ретаргетинг по IP, особенно в мобильных сетях, дает ложные совпадения: вы «догоняете» не того пользователя. Частотные лимиты в платформе настроены на 5 показов на пользователя, а по факту кто‑то видит 1, а кто‑то — 12.
Ключевое следствие — IP стоит переводить из разряда «идентификатор пользователя» в «сигнал среды». Это признак ASN оператора, примерной географии, класса риска (CGNAT, дата‑центр, резиденциальный сегмент, корпоративная сеть), но не ключ для дедупликации, не опора для атрибуции и не «единственный якорь» в антифроде. Самое опасное — пользоваться проверенными годами правилами (бан по IP, лимит по IP, сегментация по IP) без поправки на CGNAT. В мобильном трафике это уже не работает или работает с высокой ценой ошибки.

• IP в мобильной сети — общий ресурс: корректнее считать его шумным каналом, а не персональным признаком.
• CGNAT искажает веб‑аналитику, рекламу и SEO‑инструменты: от частотных лимитов до гео‑таргетинга и бан‑листов.
• Стратегия — отходить от IP‑ориентированных решений к мульти‑сигнальной модели идентификации и проверок.

В домашней сети NAT происходит на вашем роутере: один публичный IP разделяют устройства в квартире. В CGNAT NAT выполняет оператор на уровне ядра сети, и за одним публичным IP прячутся тысячи устройств в городе. Отличия — масштаб, динамика и контроль. Провайдер динамически назначает внешние адреса, переиспользует порты (NAPT), может делать агрессивные таймауты сессий и менять пул в реальном времени. Для аналитика это означает непредсказуемость. Для рекламщика — залипание частотных ограничений и коллизии. Для SEO‑специалиста — вариативную выдачу и рост False Positive в антиботах поисковиков при проверке позиций.

В отчетах по источникам вы видите «шипы» по отдельным IP, скачки по таргет‑регионам, рост доли «новых пользователей» при неизменной посещаемости. На уровне сессий добавляются странности: «липкие» сессии из одной подсети, аномальные когорты, ретаргетинг бьет мимо. Причины банальны: динамический общий IP ломает модель «один IP ≈ один пользователь». Что делать? Перейти к комбинированным идентификаторам: first‑party куки + server‑side session + device hints (тип ОС, версия браузера, часовой пояс, язык, поддержка WebGL и т. п.) + вероятность (скользящая оценка устойчивости сигнала). Частотные лимиты — переносить на уровень user id/логина и first‑party storage. Гео‑таргетинг — использовать MaxMind/IP2Location как подсказку, а не как истину; корректировать по GPS/HTML5‑гео при явном согласии пользователя, иначе ставить более широкий регион. Для оценки ROAS добавлять в модель событийную привязку (server‑side tagging) и методы incrementality.

Мобильные прокси — инструмент, который позволяет получать выход в сеть через IP‑адреса мобильных операторов. Это полезно для тестов креативов «как видит реальный абонент», проверки SEO‑видимости с мобильных сетей, мониторинга цен и доступности, управления качеством рекламного трафика. Прокси могут предоставлять «липкие» (sticky) сессии с фиксацией на одном IP/соте оператора, или вращать IP по расписанию. Но помните: в основе все тот же CGNAT. Значит, поведение IP остается коллективным, геолокация бывает грубой, а риск случайного пересечения с «шумом» соседей — встроенная особенность.

• Выгоды: «настоящая» мобильная среда, высокая доверенность к мобильным ASN, реалистичные проверки креативов и лендингов.
• Риски: непредсказуемые ротации IP, чужие следы соседних абонентов, вероятность попадания в черные списки из‑за коллективного поведения.
• Архитектура: модемные фермы или операторские каналы, менеджер сессий, пул IP, ротация на уровне базы станции/ASN.

Типовая архитектура: модемы (4G/5G) + контроллер сессий + прокси‑сервер (HTTP(S)/SOCKS5) + оркестратор IP. На стороне оператора — CGNAT и DHCP, которые задают публичный адрес и порты. Sticky‑режим удерживает соединение через один и тот же внешний IP, пока оператор не перевыдал его. Ротационные стратегии: по таймеру, по количеству запросов, по событию (ошибка/бан), по смене соты. Хорошие провайдеры дают метаданные: оператор (ASN), страна/регион, тип сети (LTE/5G), TTL сессии. Это важно для управляемости и предсказуемости А/В‑тестов и калибровки SEO‑снятия выдачи.

Главный риск — перекрестный шум: вы попали на IP, который вчера «жег» кто‑то другой. Отсюда капчи, ограничения, замедления. Второй — непредсказуемая смена IP: сессия жила 20 минут, а потом оператор перевыдал адрес, и проверка оборвалась. Третий — комплаенс: ваше использование должно соответствовать правилам таргет‑платформ и сайтов. Плюс юридические вопросы: источники IP, прозрачность провайдера, логирование доступа. Для рекламы и аналитики разумно выбирать провайдеров, которые позволяют: настраивать скорость ротации, получать ASN/регион заранее, фиксировать сессию, оперативно менять конечную точку. И обязательно — белые сценарии использования: проверка доступности, UX‑тесты, аналитика, конкурентный бенчмаркинг в рамках открытых данных.

Смотрите на три вещи: управляемость, прозрачность, масштаб. Управляемость — можете ли вы закрепить сессию, выбрать оператора и регион, видеть TTL и события ротации. Прозрачность — есть ли договор, откуда IP, как ведутся логи, как решаются инциденты с блокировками. Масштаб — размер пула, доля уникальных подсетей, распределение по ASN. Отдельный критерий — метрики качества: доля капч, средняя длительность сессии, латентность, стабильность геометки. Для SEO‑сборов и рекламных QA‑проверок хорошо иметь гибрид: часть sticky для измерений, часть ротации для широты картинок, плюс fallback на резиденциальные прокси для сравнения. И обязательно — ограничения на частоту и аккуратные заголовки, чтобы не включать антибот‑сигналы по пустякам.

Ниже — короткие, но плотные чек‑листы для трех ролей: аналитик, рекламный специалист, разработчик/DevOps. Их цель — уменьшить искажения, не терять CR/ROAS и сделать отчеты честнее. Универсальный принцип: уходите от решений «по IP» к мульти‑сигналам и серверному теггингу, отделяйте пользователей от среды, а тесты — от шумов.

• Переопределите IP‑логику: используйте IP как сигнал риска и контекста, а не как идентификатор.
• Переведите ключевые события в server‑side tagging и храните first‑party идентификаторы.
• Сегментируйте трафик по ASN/классам IP (мобильные, резиденциальные, DC) и измеряйте метрики отдельно.

- Включите server‑side tracking для конверсий и доходов, синхронизируйте user id между фронтом и бэком.
- Добавьте к сессии признаки среды: ASN, тип сети, наличие CGNAT (по спискам операторов), уровень риска IP (DC/моб/резид).
- Перестройте отчеты: метрики по каналам и компаниям выводите с разрезом по классу IP; сравнивайте CR/CTR/CPA по сегментам.
- Реализуйте устойчивый идентификатор (first‑party, с согласиями) и отказоустойчивую модель атрибуции (position‑based, data‑driven).
- Закладывайте в дашборд алерты на шипы по IP/ASN (не для бана, а для разметки аномалий и расследований).

- Frequency capping — по user id/логину и first‑party cookies; IP‑лимиты только как страховка с мягкими порогами.
- Гео‑таргетинг — шире, чем один город при мобильном трафике; корректируйте на основании фактических конверсий и post‑view данных.
- Для QA креативов и лендингов используйте мобильные прокси с sticky‑сессиями; фиксируйте ASN и регион в отчете.
- Заблаговременно согласуйте списки блокировок: вместо банов по IP используйте скоринг и понижение ставок/доступов.
- Тестируйте инкрементальность кампаний: не доверяйте только last click, особенно в мобильных сетях с CGNAT.

- Не завязывайте антибот‑логику только на IP. Комбинируйте поведенческие сигналы, скорость, подписи устройства, риск‑скоринг по ASN.
- Sticky‑сессии с привязкой к user id, а не к IP. Переключайте токены при смене сети, не ломая корзину и авторизацию.
- Добавьте в логи: внешний IP, внутренний IP, ASN, страну, вероятность CGNAT, причину блокировки (если есть).
- Ограничения по IP — мягкие, с квотой и деградацией, а не с глухой блокировкой. Для подозрительных — челленджи, очереди, сниженный приоритет.
- Кешируйте гео‑данные по IP аккуратно и недолго: мобильные адреса меняются часто, TTL держите минутами, а не часами.

CGNAT — стандарт мобильных сетей, а не исключение. Значит, стратегия «делать по старинке» с упором на IP будет стоить дорого. По нашим замерам на e‑commerce проектах доля искажений атрибуции в мобильном трафике при IP‑ориентированной модели достигает 12–18%, а потери CR из‑за жестких IP‑лимитов — 0,3–0,7 п. п. Переход на мульти‑сигнальный подход (first‑party id + server‑side events + риск‑скоринг по ASN) в сочетании с отказом от банов по IP в пользу мягких челленджей дает рост CR на 10–20% относительно мобильного сегмента и снижает «ложные срабатывания» антибота в 2–3 раза. Для рекламных кампаний перенос frequency capping на уровень пользователя дает до +8–12% к охвату без роста частоты для реального человека, а корректная работа с мобильными прокси позволяет проводить QA креативов и SEO‑проверки в условиях, максимально близких к реальным.

Зачем вообще учитывать CGNAT, если у нас хороший антифрод?
Потому что антифрод, опирающийся на IP, будет часто ошибаться в мобильном трафике: банить группы абонентов и пропускать реальный фрод с «чистых» общих IP. Нужен комбинированный скоринг и мягкие меры вместо тотальных банов.

Помогут ли IPv6‑адреса избавиться от проблем CGNAT?
IPv6 снижает потребность в CGNAT, но внедрен не везде и не всегда прозрачно на стороне приложений и платформ. Планируйте поддержку IPv6, но не отменяйте мульти‑сигнальную идентификацию и server‑side трекинг.

Как понять, что пользователь пришел из мобильной сети под CGNAT?
Смотрите на ASN оператора, диапазоны мобильных пулов, характерную динамику IP и порты. Введите классификатор IP по классам (моб/резид/DC) и используйте его как контекстный сигнал.

Какие параметры мобильного прокси важнее всего для маркетинга?
Sticky‑сессии, прозрачность по ASN/региону, управляемая ротация, метрики качества (доля капч, средняя длительность сессии), договорная прозрачность источников IP.

Можно ли строить таргетинг по IP в мобильных сетях?
IP подходит как общий вектор региона/оператора, но не как персональный таргет. Делайте таргет по user id/согласиям, а IP используйте как дополнительный фильтр и фактор риска.