Почему MCC ломается после пятого клиента
Пока у тебя три клиента, Google Ads Manager Account (MCC) работает как задумано: один логин, три кабинета, переключение за секунду. Но где-то между пятым и десятым клиентом происходит сдвиг. Ты начинаешь утро не со стратегии, а с переключения между аккаунтами. К обеду успеваешь пройтись по половине, и рабочий день уже съеден операционкой.
Это не проблема головы и не проблема количества людей в команде. Это проблема операционной модели. У нас под MCC висит 51 аккаунт, из которых активно используется 6. Без выстроенной системы это было бы хаосом, а не рабочим инструментом.
Боль проявляется на трёх уровнях. Первый: naming mess. Когда аккаунтов больше десяти, ты тратишь время просто чтобы найти нужный. Второй: budget blindness. Нет нативного портфельного вида, где видно расход по всем клиентам разом. Третий: conversion chaos. Конверсии настроены по-разному в каждом аккаунте, метрики начинают врать, и ты принимаешь решения на кривых данных.
Все три проблемы решаемы, но ни одна не решается сама. Дальше разберу конкретно, что мы сделали на каждом уровне.
Иерархия и naming convention: дерево на 10-20 клиентов
Первый вопрос при масштабировании MCC: как группировать аккаунты. Есть два подхода, и выбор зависит от размера команды.
Группировка по вертикали (недвижка, логистика, спорт) работает когда один менеджер ведёт все аккаунты. Ты видишь конкурентную среду в рамках ниши, можешь переносить негативные списки между клиентами одной отрасли, бенчмарки внутри группы корректнее. Группировка по менеджеру работает когда в агентстве 3+ человек и каждый ведёт своих клиентов. Тогда sub-MCC на каждого менеджера, чтобы люди не путались в чужих кабинетах.
Мы используем вертикальную группировку, потому что агентство компактное. Один человек видит все аккаунты, и важнее кросс-клиентский контекст внутри ниши.
Naming convention на уровне кампаний единый для всех аккаунтов: [Client]-[Geo]-[Channel]-[Objective]. Примеры: GateCity-Almaty-Search-Leads, FlyBox-KZ-Search-Brand. Когда ты открываешь любой аккаунт, названия читаются одинаково. Это мелочь, которая экономит минуты каждый день, а за месяц складывается в часы.
Labels на уровне MCC: метки по статусу (active, paused, onboarding), по биллинг-модели (prepaid, postpaid), по менеджеру. Фильтрация по лейблам, которая есть в MCC UI, заменяет ручное переключение между аккаунтами.
Отдельная тема, которая даёт максимальный ROI при минимальных усилиях: shared negative lists на уровне MCC. Один список негативных ключевых слов применяется ко всем аккаунтам автоматически. Для рынка KZ/CIS это критично: конкуренты-бренды, госпрограммы, нерелевантные запросы (аренда, посуточно, работа) повторяются от клиента к клиенту. У нас shared negative list из 52 позиций защищает каждый новый аккаунт с первого дня. FlyBox до его внедрения имел 2 негатива на весь аккаунт, трафик был забит конкурентами (СДЭК, DHL, Казпочта), а CPL Kazakhstan после внедрения снизился до $3.5.
Онбординг нового клиента: чеклист с подводными камнями
Онбординг клиента в MCC кажется тривиальным: привязал аккаунт, пошёл работать. На практике именно здесь закладываются ошибки, которые потом месяцами портят данные.
Первый выбор: создать новый аккаунт под MCC или привязать существующий. Новый аккаунт проще: ты контролируешь всю структуру с нуля, конверсии настроены как надо, доступы чистые. Привязка существующего опаснее: в аккаунте могут быть чужие конверсии, старые кампании с кривыми настройками, непонятные пользователи с доступом. Если клиент уже крутил рекламу сам или через другое агентство, привязывай, но первым делом аудитируй конверсии и доступы.
Биллинг: consolidated billing через MCC выглядит удобно, но это ловушка. Когда клиент не платит, ты ешь расход. По нашему опыту, безопаснее требовать предоплату или настраивать отдельный биллинг на аккаунт клиента. Операционно это чуть сложнее, зато финансово предсказуемо.
Конверсии: решение «account-level vs MCC-level tracking» зависит от вертикали. Для агентства с разными нишами (недвижка + логистика + спорт) account-level tracking надёжнее. MCC-level создаёт единую точку отказа и ломается при offboarding клиента. Важный подводный камень: конверсии, импортированные из GA4, не дают conversion label для gtag-пикселя. Если тебе нужен пиксельный трекинг (а для лендингов он нужен), создавай нативную WEBPAGE-конверсию. Ставь её как вторичную, чтобы не сбить биддер основной. Тема выбора правильной модели атрибуции для казахстанского рынка заслуживает отдельного разбора, потому что GA4 data-driven attribution на малых объёмах работает иначе.
Негативные ключевые слова, и это не опциональный шаг, а обязательный. Без них Search-кампания в недвижке KZ за первые дни съедает бюджет на запросы конкурентов. Gate City в первые дни показывал CPL $16-27 из-за broad-match на «грин сити», «аспан сити», «maxima city», «krisha.kz». Один вечер, 34 негатива на уровне кампании плюс target CPA $7. День обучения ещё $27, но следующий день уже $3.35. Негативы для KZ рынка типовые: конкуренты-ЖК, порталы (krisha, baspana), госпрограммы (алматы жастары), нерелевантное (посуточно, аренда, снять).
Ставки и бюджеты: что ломается в первую неделю
Первая неделя новой кампании в Google Search для рынка KZ имеет свои правила. Они отличаются от того что пишут в гайдах для US/EU рынков.
MANUAL_CPC для KZ Search: начинай с $0.50-0.70 за клик, не с $0.20-0.30. Один из наших B2B-клиентов первые 7 дней крутил с ставками $0.15-0.35 и реально использовал 2% дневного бюджета. Кампания была невидима в аукционах, Google просто проигрывал за неё. Поднятие до $0.60 разблокировало показы, расход вырос в 3-5 раз при том же бюджете.
Target CPA для недвижки и коммерции в KZ: $7, это рабочий потолок. $2.40 задушит кампанию. У Gate City старая кампания с target CPA $2.40 откручивала 10% бюджета, Google не мог найти конверсии по такой цене и просто не показывал рекламу. Переключение на $7 дало день обучения с дорогим CPL, но дальше система заработала.
Переход на MAXIMIZE_CONVERSIONS: не раньше чем через 1-2 недели и только после 5+ конверсий. Smart bidding без данных не работает, он просто не знает за кого торговаться. Ручное управление в начале даёт Google обучающую выборку.
Weekend pause cron, отдельная тема для B2B-клиентов с одним менеджером на стороне заказчика. Если некому отвечать в выходные, лучше не платить за показы. Но побочный эффект: Smart bidding теряет обучение при паузе больше 24 часов. Первые 6-12 часов после возобновления CPL может быть в 2-3 раза выше. Нетто-выгода для B2B всё равно положительная, потому что альтернатива, платить за лиды которые никто не обработает, хуже.
И ещё одна вещь, которая кажется очевидной, но мы на ней обожглись: платформо-специфичные бенчмарки. Google Search и Meta Ads имеют принципиально разный «нормальный» CPL и CTR. Если ты меришь Google по меркам Meta, Google-кампании всегда будут красными. У нас в дашборде M.Sight Google-кампании месяцами показывались как «плохие» по CPL, потому что сравнивались с бенчмарками Meta. Это вводило в заблуждение и нас, и клиентов. Мы подробно описали этот инцидент в разборе аудита GA4, где CPL $4.42 выглядел нормально до тех пор, пока не пересчитали по реальным сделкам. Разделили бенчмарки по платформам, и картина стала адекватной.
UI, Scripts, API, MCP: когда агентству пора переходить
У автоматизации Google Ads для агентства есть четыре эпохи, и каждая начинается когда предыдущая перестаёт справляться.
До 5 клиентов хватает Ads Manager UI. Переключаешься между аккаунтами, руками правишь ставки, раз в неделю выгружаешь отчёт. Неэффективно, но терпимо.
На 5-10 клиентах начинают помогать Google Ads Scripts. Бюджетный мониторинг, автоматические алерты по аномалиям, ночные отчёты в Google Sheets. Scripts живут внутри аккаунта, пишутся на JavaScript, деплоятся за минуту. Для типовых задач этого достаточно.
На 10-15+ клиентах скрипты упираются в ограничения: нет нормальной кросс-аккаунтной логики, нет интеграции с внешними системами, ошибки глотаются. Мы перешли на REST API после 5 клиентов. Выкинули пакет google-ads-api@23, который тянул устаревший v17, весил 1378 строк зависимостей и глотал ошибки (показывал generic error вместо конкретного DEVELOPER_TOKEN_NOT_APPROVED). Написали клиент на чистом fetch к Google Ads REST v22. Стало видно нормальные сообщения об ошибках от Google, дебажить проще в разы.
Четвёртая эра, и мы в ней сейчас: MCP (Model Context Protocol). Claude подключён ко всем клиентским аккаунтам через MCP-сервер студии. 5 Google Ads tools: list_campaigns, get_campaign_insights, set_campaign_status, update_campaign_budget. Batch-операции по 10-20 аккаунтам за одну сессию. Спросил «что с бюджетом Gate City», получил ответ с цифрами, поправил, следующий клиент. Без единого клика в Ads Manager. Подробнее о том, как 29 MCP-инструментов заменили ежедневное переключение между платформами, мы писали в отдельном посте.
Consolidated reporting: Meta и Google в одном экране. Таблица «Клиент / Google / Instagram / Итого расход / Заявки / CPL за 30 дней». Из одной точки видно всю картину по всем клиентам и платформам разом. Это то, чего нет в нативном MCC UI и что невозможно собрать скриптами без внешнего хранилища.
Получение доступа к Google Ads API, к слову, не тривиально. Basic Access мы получили с третьей попытки за 2 недели. Первый отказ: личный gmail вместо корпоративного домена, размытое описание тулзы, отсутствие юрлица на сайте. Повторная заявка через hello@milakhin.studio, расширенный Design Document (4 страницы, явное READ-ONLY, конкретные API-методы), footer с «ИП Милахин Степан, Казахстан, Алматы». Approval за 3 рабочих дня.
Безопасность MCC и offboarding клиента
MCC phishing и hijack-атаки в 2025-2026 участились. Один скомпрометированный логин означает доступ ко всем клиентским бюджетам. Задокументированы случаи, когда $10K+ улетали на фродовый расход за одну ночь. Session hijacking обходит 2FA.
Разделение аккаунтов: milakhin.studio@gmail.com для всего Google (GCP, GA4, GTM, Ads MCC, Search Console), milakhin.bcc@gmail.com для всего Meta (Business Manager, Pages, Instagram, System Users). Путаница при OAuth = токен привязан не к тому scope. Это звучит как очевидный совет, но когда ты спешишь подключить нового клиента, легко залогиниться не в тот аккаунт.
CLIENT_SECRET живёт в 3 местах (корневой .env.local, Vercel production env, packages/mcp-studio/.env). При ротации забывают одно из трёх. У нас два инцидента из-за одной и той же причины: MCP падал с invalid_client, продакшен работал нормально, потому что читал другой .env. Вопрос экономики такого соло-оператора с AI-инструментами в том числе включает осознание, что меньше людей = меньше глаз на такие рассинхроны.
Offboarding клиента: отвязка аккаунта от MCC, передача ownership, аудит того что остаётся после ухода. Бывшие сотрудники и одноразовые подрядчики сохраняют доступ месяцами, если не делать квартальный аудит. Практика: раз в квартал проходись по списку пользователей каждого аккаунта в MCC и удаляй всех, кто не работает.
Ошибки масштабирования: три истории провалов и выводы
FlyBox: клиент платил $3K/мес за Google Ads, а все ключи были BROAD с 2 негативами на весь аккаунт. Трафик забит конкурентами: СДЭК, Рика, DHL, Казпочта, EMS. Они дёшево конвертили в GA4-Lead, но это были проходные заявки. Кампания «Алматы» дублировала «Kazakhstan» (самоконкуренция). Собрал shared negative list из 52 позиций, перебалансировал бюджет 70/30 (KZ/международка), добавил tCPA. CPL Kazakhstan упал до $3.5 (был $4.42 с мусором).
Gate City: broad-match на запросы конкурентов без негативов. CPL $16-27 первые дни. 34 негатива на уровне кампании + tCPA $7. День обучения $27 CPL. Следующий день $3.35. Всё решилось за один вечер, но если бы не поймали вовремя, клиент бы слил недельный бюджет на чужие бренды.
Truck Auto: 230 обращений через CTWA за $651, CPL $2.83. Выглядит идеально. Но 0 продаж. Разбор показал, что 57 диалогов (28%) были брошены нами: последнее слово за клиентом, ответа нет. Закрытие упиралось в отдел лизинга на стороне заказчика. Это не проблема MCC или настройки кампании. Это напоминание, что CPL без конверсии в сделку ничего не значит.
Meta CBO ловушка (не Google, но важно для кросс-платформенного управления): не мог снизить бюджет CBO-кампании с $10 до $5. Meta ругалась: «Суммарные минимальные затраты групп объявлений выше бюджета кампании». Корень: на ad-sets стояли daily_min_spend_target ($4 + $6 = $10 гарантированных). Обнулить min spend для всех ad-sets, после этого можно уменьшать campaign budget.
AI Max, PMax и Google-репы: что делать в 2026
Forced AI Max migration запланирована на сентябрь 2026. DSA и broad match кампании авто-апгрейдятся. Агентства, которые строили стратегию на ручном контроле структуры кампаний, потеряют этот контроль.
PMax для B2B систематически не работает. Январские независимые бенчмарки 2026 показывают: для e-commerce ROAS PMax работает, для B2B lead-gen проваливается. Но Google пушит PMax сильнее всего, потому что это их главный продукт автоматизации.
Google-репы не партнёры. Это sales с квотой, оптимизирующие выручку Google, не ROAS клиента. В 2026 зафиксированы случаи, когда репы шли напрямую к клиентам агентства с «optimization recommendations», подрывая отношения. Каждую рекомендацию от репа проверяй через свои данные, прежде чем применять.
Выживут агентства, построившие свой automation layer поверх Google. Когда Google убирает ручные контролы (а он их убирает последовательно), твоя собственная автоматизация через API и MCP остаётся. Scripts, привязанные к DSA-кампаниям, умрут вместе с DSA. REST API клиент, который управляет любым типом кампании, продолжит работать.