Что сломалось 15 июня 2026 и почему вы могли не заметить
Google тихо убрал Google Signals как fallback для рекламных данных. До 15 июня, если CMP (Consent Management Platform) не передавал сигнал ad_storage корректно, Google Ads мог подтянуть данные через Signals. Теперь ad_storage из CMP стал единственным gate. Если ваш баннер cookie-согласия не отправляет consent-сигнал правильно, Smart Bidding, remarketing и конверсии слепнут. Без предупреждения, без ошибки в интерфейсе, без алерта на почту.
Аналитика ломается тихо. Не падает с ошибкой, не шлёт алерт. Просто перестаёт собирать данные, и вы узнаёте об этом через неделю когда смотрите отчёт и видите ноль. У меня есть личный кейс: GTM на milakhin.studio не работал 5 дней на проде. Компонент GoogleTagManager лежал в layout, код правильный, локально всё работало. Проблема: переменная NEXT_PUBLIC_GTM_ID не была добавлена в Vercel ENV. Пять дней ноль событий в GA4. Никто не заметил. Обнаружили случайно, не через мониторинг.
Самый распространённый source тихих потерь: race condition между GTM и CMP. Google Tag срабатывает до того, как CMP выставит consent default. Без параметра wait_for_update:500 первый page_view улетает без consent state, и Google трактует его как denied. Это не edge case, это дефолтное поведение при типичной установке. Разработчик добавил баннер, маркетолог проверил что баннер есть, и оба успокоились. Никто не открыл Network tab и не посмотрел, что gtag('consent', 'update') реально отправляется с правильными параметрами.
По данным Privado AI за июнь 2026, 48% из топ-250 сайтов misconfigure Consent Mode. Половина рынка настроила инструмент неправильно. При этом данные утекают в Google Ads даже при Reject All. Одновременно и compliance breach, и false sense of security. Тема взаимоотношений маркетинга и cookie шире чем один consent-баннер: Google сделал инструмент настолько сложным, что половина рынка не может его правильно настроить. И при этом вся ответственность на рекламодателе.
Если вы не перепроверили настройку после 15 июня, вы не «возможно теряете» данные. Вы их теряете. Вопрос только в том, сколько именно.
Аудит за 15 минут: измерь сколько теряешь прямо сейчас
Чтобы понять масштаб потерь, не нужен аналитик на полный день. Нужен Chrome, 15 минут и этот чеклист.
Шаг 1: GA4 Exploration. Откройте GA4 → Explore → создайте Free-form report. Добавьте dimension «Browser» и metric «Sessions». Отфильтруйте по браузерам: Safari, Firefox. Сравните с Chrome. Если Safari и Firefox показывают аномально низкие конверсии по сравнению с Chrome (при схожем трафике), часть данных не доходит. Safari блокирует third-party cookies с 2020, Firefox с 2019. Около 35% трафика невидимо для пикселя. Но если разрыв слишком большой, проблема не только в cookies, но и в consent-настройке.
Шаг 2: DebugView. Откройте GA4 → Admin → DebugView. Установите расширение GA Debugger для Chrome. Теперь нажмите «Reject All» в баннере на своём сайте и походите по страницам. Если события продолжают появляться в DebugView с пометкой cookieless ping (без client_id, без session_id), ваш Consent Mode v2 работает в Advanced mode. Это хорошо: Google получает анонимные сигналы для моделирования. Если события пропали полностью, у вас Basic mode, и данные по отказавшимся пользователям просто исчезают.
Шаг 3: Network tab. В Chrome DevTools → Network. Нажмите Reject All. Ищите запросы к google-analytics.com или googleads.g.doubleclick.net. Если запросы идут, посмотрите на параметр gcs (Google Consent State). Значения G100 или G110 означают что consent denied, но пинг ушёл (Advanced mode). Если запросов нет вообще, всё заблокировано (Basic mode).
Шаг 4: чеклист порядка загрузки. Откройте Network tab, перезагрузите страницу, и посмотрите порядок загрузки скриптов. CMP должен загружаться ДО GTM. Если GTM грузится раньше, первый page_view улетает без consent state. Проверьте, что в настройках GTM стоит wait_for_update со значением не менее 500 мс. Без этого параметра GTM не ждёт ответа от CMP и трактует consent как denied.
Шаг 5: Google Ads Diagnostics. В Google Ads откройте Tools → Diagnostics → Consent. Здесь Google показывает coverage report: какой процент конверсий пришёл с полным consent-сигналом, какой без. Если coverage ниже 70%, ваш Smart Bidding работает на неполных данных и деградирует. Подробнее о том как аудит GA4 вскрывает реальную стоимость лида по ту сторону красивых дашбордов.
За 15 минут вы получите конкретную цифру: сколько процентов данных вы теряете. Не абстрактное «consent mode важен», а конкретное «37% моих конверсий невидимы для Google Ads».
Что Google моделирует за вас (и почему этому нельзя доверять на 100%)
Когда Consent Mode v2 работает в Advanced mode, Google получает cookieless пинги от пользователей, которые нажали Reject All. На основе этих пингов работает behavioral modeling: алгоритм смотрит на поведение consented-пользователей и экстраполирует конверсии на unconsented. В теории звучит разумно. На практике есть три проблемы.
Первая: порог включения. Modeling активируется только если у вас минимум 1000 daily users с granted consent и минимум 1000 событий в день с denied consent, причём это должно выполняться 7 из 28 дней. WooCommerce-магазин с 500 визитами в день никогда не дотянет до порога. Малый бизнес видит только consented конверсии, остальные просто исчезают. Не моделируются, не восстанавливаются. Для них consent mode не «немного обрезает данные», он создаёт слепое пятно, которое нечем закрыть.
Вторая: consented users конвертируются иначе. Человек, который жмёт Accept на баннере cookie, психологически отличается от того, кто жмёт Reject. По данным из разных источников, consented users конвертируются в 2-5 раз чаще, чем unconsented. Модель Google прикидывает по средним и экстраполирует поведение одной группы на другую. Это системная погрешность: модель завышает конверсии от unconsented пользователей, потому что калибруется на более «горячей» выборке.
Третья и самая неприятная: GA4 не маркирует, какие конверсии реальные, а какие modeled. В отчётах они смешаны. Вы смотрите на число 150 конверсий за неделю и не знаете, 120 из них настоящие или 80. Вы принимаете бюджетные решения на основе данных, часть которых буквально выдумана ML-моделью. Нет колонки «modeled», нет фильтра, нет способа разделить в стандартном интерфейсе. BigQuery export показывает флаг is_conversion_modeled, но его используют единицы.
Для бизнеса с трафиком ниже порога моделирования ситуация ещё жёстче. Enhanced Conversions (hashed email/phone матчинг с Google-аккаунтом) и first-party data collection через формы становятся единственным способом не терять атрибуцию. Это не замена моделированию, а workaround для тех, кому моделирование недоступно. Enhanced Conversions бесплатен, настраивается за час и даёт +5-30% восстановленных атрибуций. Для магазина с 500 визитами в день, это разница между «вижу 60% конверсий» и «вижу 80%».
Recovery-стек: три слоя восстановления с процентами
Потерянные данные можно частично вернуть. Не все и не полностью, но достаточно чтобы Smart Bidding и атрибуция работали адекватно. Recovery-стек состоит из трёх слоёв, каждый добавляет свой процент.
Слой 1: Consent Mode v2 Advanced mode. Даже при Reject All в cookie-баннере, в Google уходят анонимные cookieless-пинги. Без персональных данных, без cookie, но с базовой информацией о визите. Google берёт эти пинги и моделирует конверсии. Recovery: +15-25% через behavioral modeling. Это бесплатно, настраивается в GTM + CMP. Без Advanced mode remarketing-аудитории тают на 90-95%, Smart Bidding видит только тех кто нажал Accept.
Слой 2: Enhanced Conversions. Когда пользователь заполняет форму или оформляет заказ, хешированный email или телефон отправляется в Google вместе с конверсией. Google матчит хеш с аккаунтом пользователя и восстанавливает атрибуцию даже если cookie не было. Recovery: +5-30% атрибуций, в зависимости от того, сколько пользователей оставляют контактные данные. Настраивается за час в GTM, стоит ноль.
Слой 3: Server-side GTM. Данные идут через ваш сервер на вашем домене. Cookie ставится сервером, а не JavaScript, и Safari относится к ней как first-party. Lifetime вместо 7 дней (ITP) поднимается до 90-120 дней. Recovery: +10-20% сверху за счёт восстановления cross-session attribution для Safari/Firefox. Стоимость: setup 50-120 часов инженера, Stape $200-400/мес. Подробный разбор продакшен-настройки серверного GTM с алертами и мониторингом поможет оценить, готовы ли вы к этому слою. Окупается при рекламном бюджете от $10-15K/мес.
Итого best case: ~55% recovery от потерянных данных. Consent Mode восстанавливает часть через моделирование, Enhanced Conversions добавляет через direct matching, sGTM закрывает cookie-gap через first-party cookies. Остальные 45%+ потеряны безвозвратно. Это данные тех, кто зашёл через Safari без согласия, не оставил email и не вернулся. Ни один инструмент их не вернёт.
| Слой | Recovery | Сложность | Стоимость | Когда внедрять |
|---|---|---|---|---|
| Consent Mode v2 Advanced | +15-25% | Низкая (GTM + CMP) | $0 | Сейчас, первый приоритет |
| Enhanced Conversions | +5-30% | Низкая (GTM tag) | $0 | Сейчас, вместе с первым |
| Server-side GTM | +10-20% | Высокая (DevOps) | $200-400/мес | При бюджете от $10-15K/мес |
Для SMB есть альтернатива дешевле sGTM. Client-side GTM + Consent Mode v2 Advanced + Meta CAPI покрывает примерно 80% потребностей. Advanced mode даёт Google данные для моделирования, а серверная передача событий через CAPI даёт Meta данные, которые пиксель уже не достаёт. Два первых слоя плюс CAPI закрывают основные дыры при бюджете близком к нулю.
Каскад Smart Bidding: как потеря данных убивает performance
Consent Mode v2 подаётся как measurement problem. Потеряли часть данных, ну ладно, отчёт неточный. На самом деле это performance problem, и вот как работает каскад.
Smart Bidding (tROAS, tCPA) принимает решение о ставке на основе сигнала о конверсиях. Меньше видимых конверсий = алгоритм думает, что кампания работает хуже. Он занижает ставки. Заниженные ставки = падает impression share. Меньше показов = ещё меньше конверсий. Алгоритм занижает ещё. Это замкнутый круг, который начинается с одной неправильно настроенной consent-строчки и заканчивается кампанией, которая откручивает 10% бюджета.
Кейс FlyBox показывает вторую сторону проблемы. GA4 показывал CPL $4.42, дашборд зелёный, отчёт красивый. Из 150 заявок в реальные заказы конвертировались 8. Реальная стоимость клиента $88, разница в 20 раз. Все ключевые слова на BROAD match, 2 негатива на весь аккаунт. Самоконкуренция двух кампаний, бившихся за один Казахстан. MAXIMIZE_CONVERSIONS без tCPA означало, что алгоритм покупал самый дешёвый мусорный трафик. CPL без замыкания на CRM (заявка → сделка → деньги) это vanity metric. Красивое число, которое ни о чём не говорит.
Неполные данные о конверсиях усугубляют эту проблему. Когда consent mode обрезает 30% конверсий, алгоритм не знает, что они были. Он оптимизирует на искажённой выборке. tROAS видит revenue от 70% конверсий и считает что ROAS ниже, чем он есть. Занижает ставки на кампании, которые на самом деле работают хорошо. Вы теряете не только данные, вы теряете performance.
Google Ads требует полных данных о конверсиях для работы Smart Bidding, но Google же через Consent Mode режет эти данные. Алгоритм, который требует данных, продаётся тем же людям, у которых эти данные забрали. Без серверных событий вы не управляете рекламой. Вы покупаете трафик и надеетесь.
СНГ-ловушка: почему consent rate 90% опаснее чем 60%
В Европе средний consent rate 40-60%. Пользователи привыкли к баннерам, часть жмёт Reject, бизнес это знает и закладывает в стратегию. В Казахстане и России ситуация другая: consent rate 85-90%. Privacy-баннеры непривычны, большинство жмёт Accept не читая. Кажется, что проблема consent mode для СНГ минимальная. 90% дали согласие, данных почти не теряем. Это ловушка.
Проблема меньше по масштабу, но опаснее по незаметности. Когда consent rate 60%, маркетолог знает что теряет данные и строит recovery-стек. Когда consent rate 90%, никто не проверяет. Consent mode настроили «как было в гайде», баннер поставили, данные вроде идут. Но если CMP сломался, или race condition теряет сигнал, или wait_for_update не выставлен, потери невидимы на фоне высокого baseline. Было 1000 конверсий, стало 950. Минус 5%, флуктуация. А на самом деле consent-сигнал не дошёл у 50 пользователей, и Smart Bidding начал чуть-чуть деградировать. Через месяц это 8%, через два уже 15%, но каждый раз delta слишком маленькая чтобы поднять тревогу.
Ни один западный гайд по consent mode не даёт бенчмарков для СНГ. 30% consent rate в EU и 90% в KZ требуют разных стратегий recovery. В EU стратегия строится вокруг максимального восстановления потерянных 40-60% через modeling и Enhanced Conversions. В СНГ стратегия должна строиться вокруг мониторинга: убедиться, что те 90% данных, которые должны приходить, реально приходят. Не recovery, а insurance.
Мы живём в мире где у каждого браузера свои правила. Safari режет всё. Firefox режет всё. Chrome даёт выбор пользователю. И ваш маркетинговый стек должен работать во всех трёх сценариях одновременно. В Казахстане Safari занимает 25-30% мобильного трафика (iPhone популярен). Это четверть аудитории, которая по определению теряет cookie через 7 дней. При consent rate 90% эти потери растворяются в общем потоке и не вызывают подозрений.
Практический совет для СНГ-рекламодателя: не надейтесь на высокий consent rate как на защиту. Пройдите 15-минутный аудит из второй секции. Проверьте race condition. Настройте Enhanced Conversions. И раз в месяц открывайте Google Ads Diagnostics → Consent coverage. Это дешевле чем месяц деградировавшего Smart Bidding.
Что делать если бюджет меньше $10K/мес (без server-side GTM)
Server-side GTM начинает окупаться при рекламном бюджете от $10-15K/мес. Setup 50-120 часов инженера, Stape при среднем трафике $200-400/мес. Для подавляющего большинства малого и среднего бизнеса это overkill. Но это не значит, что нужно сидеть и терять данные.
Client-side GTM + Consent Mode v2 Advanced + Meta CAPI покрывает примерно 80% потребностей. Advanced mode даёт Google данные для моделирования, CAPI даёт Meta серверные события. Два бесплатных слоя recovery (Advanced mode + Enhanced Conversions) закрывают основные дыры.
Enhanced Conversions настраивается за час в GTM, стоит ноль, даёт +5-30% восстановленных атрибуций. Единственное требование: пользователь должен оставить email или телефон при конверсии. Для e-commerce это происходит автоматически при заказе. Для лидогенерации это форма заявки. Google хеширует данные на стороне клиента (SHA-256) и матчит с Google-аккаунтом. Никакие персональные данные не передаются в открытом виде.
First-party data становится главным активом. Email при заказе или лиде работает как anchor для всех платформ: Google матчит через Enhanced Conversions, Meta матчит через CAPI, и даже при полной блокировке cookies у вас есть deterministic attribution. Решение не в том чтобы лить больше трафика. Решение в том чтобы перестроить то, что происходит после клика.
Privacy tax: конфликт интересов которым никто не управляет
Google создал проблему: Consent Mode обрезает данные при отказе от cookie. Google продаёт решение: server-side GTM через Cloud Run на Google Cloud Platform. Это по сути налог на privacy для бизнеса. Хотите видеть свои же данные? Платите за серверную инфраструктуру Google. При этом сам Google получает cookieless пинги в Advanced mode. Ваши данные урезаны, его данные на месте.
Юридическая ответственность за consent переехала к маркетологам. После 15 июня 2026 CMP стал единственным gate для рекламных данных. Настраивают CMP те, чьи KPI reward granted state. Соблазн «случайно» настроить CMP так, чтобы Reject был менее заметен, огромен. 48% misconfigured сайтов из отчёта Privado AI не все «случайно» ошиблись.
Advanced mode по сути обходит отказ пользователя: при Reject All cookieless пинги всё равно уходят в Google. Пользователь думает что отказался от трекинга, а Google получает анонимизированные сигналы. GDPR grey zone, которую пока никто не оспорил в суде, но которая точно будет под вниманием регуляторов.
Инструмент показывает то, что вы ему сказали показывать. Если метрика настроена неправильно, красивый отчёт вредит больше чем отсутствие отчёта. Consent Mode v2 не «решает» проблему privacy. Он перекладывает её на вас, продаёт вам инструменты для частичного восстановления и оставляет ответственность за compliance на вашей стороне. Понимание этой механики не избавляет от необходимости её настраивать, но избавляет от иллюзии что «Google позаботился».