Типичная картина: сайт делает студия А, SEO ведёт фрилансер Б, контекстную рекламу крутит агентство В, аналитику «настраивал кто-то ещё», а поддержку латает четвёртая сторона. На еженедельных созвонах каждый показывает свои цифры, и каждый «в плюсе»: позиции растут, CTR в норме, uptime 99,9%, тикеты закрываются. Собственник смотрит в P&L, видит ровный отток денег и не понимает, почему при «зелёных» отчётах выручка либо стоит, либо растёт медленнее, чем должна. Это и есть симптом главной проблемы — у проекта нет единого владельца результата, есть только владельцы локальных метрик.
В статье разберём, почему «зоопарк подрядчиков» структурно проигрывает интегрированной модели даже при одинаковом суммарном бюджете. Покажем, как считать стоимость рассинхрона в деньгах и неделях, какие пять опор должны жить в общей логике, чем «единая система» отличается от модного слова «full-service», и предложим пошаговый план перехода за 90 дней — без остановки кампаний и без переезда CMS. Отдельный блок — антипаттерны, на которые наша команда натыкается, когда «подбирает» проекты после развалившейся мозаики из четырёх подрядчиков.
Опираемся на исследования McKinsey о совокупном эффекте интегрированного подхода к росту [1], материалы Google web.dev о связи технического качества сайта и доходности кампаний [2], бенчмарки конверсии Unbounce [3], принципы согласованности UX от Nielsen Norman Group [4], данные Baymard о потерях на стыке формы и CRM [5] и официальную документацию Google Analytics 4 по серверной отправке событий [6]. Все цифры по бюджетам — в белорусских рублях, ориентир — рынок Беларуси и СНГ.
TL;DR
Главное за 30 секунд
- В большинстве проектов с тремя и более независимыми подрядчиками разрыв между «лидами по GA» и «лидами в CRM» составляет 30–60% — и за этот разрыв не отвечает никто [3]
- Локальные оптимумы подрядчиков (позиции, CTR, uptime, tickets closed) не складываются в глобальный результат по выручке: каждый «в плюсе», а воронка теряет [1]
- Единая система — это не «всё у одного агентства любой ценой», а общая модель цели, общий словарь данных, общий бэклог и единый владелец воронки [4]
- Базовая инфраструктура единой логики — серверная отправка событий в GA4, единый словарь UTM и общий дашборд для собственника [6]
- При корректной интеграции CAC снижается на 20–35%, а time-to-test гипотезы сокращается с 3–6 недель до 3–7 дней — за счёт исчезновения потерь на стыках, а не «лучших специалистов» [2] [5]
- Если хотите оценить, сколько ваш бизнес теряет на рассинхроне подрядчиков — закажите аудит digital-системы у команды Ontop, мы покажем точки утечки бюджета в цифрах [4]
- Откуда берётся «зоопарк подрядчиков» и почему он дорого стоит
- Истинная стоимость рассинхрона: где течёт бюджет
- Единый источник истины по данным
- Пять опор системы
- Силосный подход против интегрированного
- Антипаттерны и как их исправить
- Как устроена работа в единой логике
- KPI единой системы
- План перехода за 90 дней
- Частые вопросы
- Выводы
Откуда берётся «зоопарк подрядчиков» и почему он дорого стоит
«Зоопарк подрядчиков» редко проектируют осознанно — он накапливается. Сначала появляется сайт от знакомой студии. Через полгода берут SEO-фрилансера, потому что «трафик не растёт». Ещё через квартал подключают агентство контекстной рекламы. Потом — аналитика, которую «настраивал один парень, теперь не отвечает». Поддержку отдают на разработчика по часам. На каждом шаге решение выглядит локально разумным: дешевле, быстрее, специалист «именно по этому». Через два года у бизнеса четыре подрядчика, четыре договора, четыре отчёта — и ноль ответственности за выручку.
Структурная проблема в том, что каждый подрядчик оптимизирует свою локальную метрику. SEO-специалист отчитывается позициями и видимостью. Контекстолог — CTR и стоимостью клика. Разработчик — uptime и скоростью релизов. Поддержка — количеством закрытых тикетов. Все эти метрики важны по отдельности, но ни одна из них не равна выручке. Когда позиции выросли, а заявок стало меньше — никто не виноват: SEO «сделало свою работу». Когда CTR в норме, а из 100 кликов в CRM попало 7 заявок — контекстолог тоже «сделал свою работу». Локальные оптимумы перестают складываться в глобальный, и ответственность размазывается по периметру [5].
Вторая проблема — стоимость менеджмента стыков. Каждый новый подрядчик добавляет коммуникационные накладные: созвоны, чаты, согласования, дублирующиеся ТЗ. По нашим наблюдениям на проектах из СНГ, при четырёх и более независимых подрядчиках до 15–25% времени собственника или маркетолога уходит на «синхронизацию», а не на работу с продуктом и рынком. Это скрытая статья расходов, которую никто не выносит в счёт, но за которую бизнес платит вниманием первого лица — самым дорогим ресурсом компании [1].
Третий слой — потеря скорости. В фрагментированной модели любая гипотеза («давайте протестируем новый оффер на посадочной для горячего сегмента») проходит через четыре цепочки: сформулировать, согласовать с разработчиком, согласовать с SEO, согласовать с контекстом, дождаться выкатки, дождаться разметки событий, дождаться накопления данных. Типичный лаг — 3–6 недель. В единой логике тот же тест занимает 3–7 дней, потому что бэклог общий, события уже размечены по словарю, а ответственный — один [3].
!
Каждый подрядчик честно делает свою часть и отчитывается «зелёными» метриками. Собственник видит четыре отчёта, в каждом всё хорошо, а выручка не растёт. Это не вопрос компетенций — это вопрос архитектуры: локальные оптимумы не складываются в глобальный результат, пока за всю воронку не отвечает один человек с правом приоритизировать поверх границ подрядчиков [3].
Истинная стоимость рассинхрона: где течёт бюджет
Чтобы перестать спорить «кто виноват», полезно один раз нарисовать сквозную воронку и подсветить звенья, в которых данные расходятся. Большинство собственников ни разу не видели свою воронку в одном представлении — они видят её в виде четырёх несвязанных отчётов от четырёх подрядчиков. Когда мы делаем такой свод на аудите, типичная картина выглядит так: реклама показывает 10 000 показов, агентство рапортует о 800 кликах, GA4 фиксирует 120 «заявок» по событию формы, а в CRM за тот же период пришло 47 лидов. Из 47 в работу взяли 28, продаж — 9. Между каждой парой цифр — потеря, и почти всегда есть как минимум одна, в которой никто не разбирается, потому что «это не моя зона» [2].
Самая болезненная утечка обычно сидит между «GA сказал 120 заявок» и «CRM получила 47 лидов». Она возникает из-за разрыва событий: на сайте фиксируется клик по кнопке «Отправить», а не реальная доставка лида в CRM. В итоге GA считает попытки, а CRM — успехи, и до 60% «заявок» не доезжают до отдела продаж по техническим причинам: упала валидация, отвалился webhook, формы дублируются, спам-боты пробивают капчу. Когда контекстолог отчитывается «120 лидов по 28 BYN», а собственник видит в CRM 47 лидов — реальная стоимость лида не 28, а 71 BYN. И это ещё без учёта качества: из 47 квалифицированных, скажем, 18, и реальный CPL качественного лида — уже 186 BYN [6].
Вторая системная утечка — на стыке «лид в CRM» и «продажа». Здесь обычно рассинхронизированы маркетинг и продажи: маркетинг считает любую заявку «лидом», продажи — только тех, кто прошёл квалификацию. Когда нет общего определения SQL и общей причинно-следственной разметки источников, маркетинг продолжает заливать бюджет в каналы, которые приносят формальные лиды, но не выручку. По данным Unbounce, разница в коэффициенте «лид → продажа» между лучшими и средними проектами в одной индустрии достигает 3–5×, и почти всегда дело не в продавцах, а в качестве и атрибуции лидов на входе [3].
Третья утечка — техническая, и её особенно часто недооценивают. Если сайт грузится 4–6 секунд на мобильных, до 30% потенциальных кликов отваливаются ещё до того, как агентство сможет их «обработать». При этом контекстолог не видит этих потерь в своих отчётах — он видит «клик», а не «успешную загрузку страницы». Google web.dev фиксирует, что задержка LCP с 2,5 до 4 секунд снижает конверсию в среднем на 20–30% — то есть техническое качество сайта и эффективность кампаний жёстко связаны, но в фрагментированной модели за эту связку не отвечает никто [2].
Между каждым шагом — потери, которыми никто не владеет. Контекстолог отчитывается «лид по 28 BYN», а реальная стоимость качественного лида — 186 BYN. Разница в 6–7× и есть «налог на рассинхрон» [2] [3].
Единый источник истины по данным
«Единый источник истины» звучит как BI-консультантский штамп, но за ним стоит очень конкретная инженерная задача: сделать так, чтобы любая цифра в любом отчёте имела одно определение, одно происхождение и одну точку ввода. Без этого любой разговор подрядчиков превращается в спор о терминах: «а что вы считаете лидом?», «а UTM у вас по какому формату?», «а событие "клик на кнопку" — это попытка отправки или успешная отправка?». Пока эти термины не определены централизованно — единой картины нет, и собрать её задним числом невозможно [6].
В нашей практике общая онтология данных обычно стоит на четырёх китах. Первый — словарь событий: жёсткий список того, что на сайте считается событием, с фиксированными именами (form_submit_success, а не submit или Отправка_формы). Второй — словарь идентификаторов: какой ID сшивает посетителя сайта, лид в CRM и сделку в продажах (client_id, crm_lead_id, deal_id). Третий — словарь сегментов: что такое «горячий лид», «B2B-лид», «повторный клиент» — с критериями, которые можно проверить программно. Четвёртый — словарь UTM: фиксированные значения utm_source, utm_medium, utm_campaign, под которые подрядчики обязаны размечать трафик [6].
Технически минимум, который должен быть на проекте, — это серверная отправка ключевых событий в GA4 через Measurement Protocol и одновременная их доставка в CRM. Это закрывает разрыв «GA считает клики, CRM получает лиды». Когда событие form_submit_success отправляется только после фактической записи лида в CRM, цифры в GA4 и CRM совпадают с точностью до 1–3% (расхождение объясняется блокировщиками и кросс-девайс-сценариями). Для рынка Беларуси разовая стоимость такой перепрошивки — обычно 2 500–6 000 BYN, в зависимости от сложности форм и CRM, а возвращается она первой же скорректированной кампанией [6].
RISK
RISK
MID
OK
i
Сначала — четыре словаря (события, ID, сегменты, UTM) и серверная отправка ключевых событий в GA4. Только после этого имеет смысл говорить про дашборды, ретро и общий бэклог: пока термины не зафиксированы, любая встреча подрядчиков будет спором о терминологии, а не о результате [6].
Пять опор системы
Когда мы говорим «единая система», важно понимать: это не про услуги, а про роли. Пять опор — это не «сайт + SEO + реклама + аналитика + поддержка», а пять ролей, которые должны существовать в проекте независимо от того, выполняют их один подрядчик или пять. В фрагментированной модели эти роли либо отсутствуют, либо размазаны по подрядчикам так, что никто не несёт за них персональной ответственности. В интегрированной — у каждой роли есть конкретный человек с именем, и этот человек принимает решения в своей зоне без оглядки на границы договоров [1].
Ключевая ошибка — путать «опору» с «функцией». Например, опора «владелец данных» — это не про человека, который «делает аналитику», а про того, кто принимает решения о словарях событий, сегментов и атрибуции, и чьё слово финальное в спорах между подрядчиками. Без такого человека любой словарь событий через полгода превращается в свалку, а атрибуция плывёт. То же касается опоры «владелец воронки»: это не маркетолог и не директор по продажам по отдельности, а человек, который отвечает за стык маркетинг↔продажи и имеет полномочия менять процессы по обе стороны [4].
Опорные роли можно совмещать — на проектах до определённого масштаба один человек может закрывать 2–3 роли. Главное правило: каждая опора должна быть явно назначена, и в команде все должны знать, кто отвечает за какую. Когда мы заходим на проект и спрашиваем «кто у вас владелец воронки», и в ответ начинается «ну, наверное, маркетолог… или директор… или вот этот подрядчик» — это диагноз. Опора либо есть, либо её нет; «наверное» означает «нет».
Один человек отвечает за описание целевого клиента (Ideal Customer Profile) и следит, чтобы SEO-семантика, рекламные группы, контент и продукт работали на один и тот же сегмент. Без этой роли SEO оптимизирует под «общий трафик», реклама — под «дешёвый клик», продажи закрывают «всех подряд», а маркетинг не понимает, почему LTV ниже плана [1].
Хранит и обновляет четыре словаря (события, ID, сегменты, UTM), принимает финальные решения в спорах о терминах, отвечает за работоспособность серверной отправки событий и за совпадение цифр в GA4 и CRM. Без этой роли любая интеграция через 3–6 месяцев деградирует до «у каждого свой Excel» [6].
Ведёт единый приоритизированный список задач для всей команды — не четыре отдельных Jira-проекта от подрядчиков, а одну доску с задачами по сайту, SEO, рекламе, аналитике и поддержке. Решает, какая задача важнее: техническая правка LCP или новый оффер для контекста. Без этой роли команды конкурируют за ресурсы и каждая делает «своё важное» [4].
Отвечает за стык маркетинг↔продажи: общие определения MQL/SQL, регламент передачи лидов, ретро по причинам отказа, обратная связь от продаж в маркетинг. Имеет право менять процессы по обе стороны. Без этой роли маркетинг заливает каналы, которые продажи ненавидят, а продажи продают «не тех», под кого настроена реклама [3].
Управляет ритмом изменений на сайте и инфраструктуре, фиксирует регламенты ответа поддержки (SLA: 4 часа на критический инцидент, 24 часа на запрос правки). Без этой роли релизы выкатываются «когда у разработчика будет время», а поддержка отвечает «когда увидит сообщение» — со всеми последствиями для конверсии и репутации [4].
Силосный подход против интегрированного: что меняется в цифрах
Разговор о «единой системе» часто звучит абстрактно, поэтому полезно перевести его в цифры. В таблице ниже — десять метрик, по которым силосная и интегрированная модели расходятся принципиально. Это не маркетинговые обещания «всё станет лучше», а наблюдения с проектов, которые мы переводили из фрагментированной модели в интегрированную за последние три года. Цифры приведены как диапазоны, потому что эффект сильно зависит от стартового состояния: на проектах с особенно болезненной фрагментацией экономия по CAC доходит до 35–40%, на изначально аккуратных — 10–15% [3] [5].
Главный системный эффект — не в том, что какая-то одна метрика «прыгает» в разы. Он в том, что метрики начинают меняться согласованно. В силосной модели улучшение в одном канале часто «съедается» ухудшением в другом: подняли скорость сайта — сломали разметку конверсий; перенастроили GA — поплыла атрибуция в Ads; запустили новую кампанию — поддержка не успевает обрабатывать лиды. В интегрированной модели изменения проектируются с учётом всей воронки, и эффекты складываются, а не вычитаются [2].
| Метрика | Силосный подход | Интегрированный | Эффект |
|---|---|---|---|
| CAC (стоимость привлечения клиента) | растёт из-за дублирующих кампаний и потерь на стыках | снижается на 20–35% за квартал | прямая экономия бюджета [3] |
| Time-to-test гипотезы | 3–6 недель (4 цепочки согласований) | 3–7 дней (общий бэклог) | в 5–10× больше тестов в год [1] |
| Совпадение SEO-семантики и рекламных групп | 30–50% (разные команды, разные списки) | 85–95% (общий ICP и словарь) | меньше дублей в выкупе трафика [1] |
| Единство UTM-разметки | 60–75% корректных меток | 95–99% | бюджеты по каналам считаются точно [6] |
| Mobile LCP / INP | подрядчик не видит и не отвечает | отслеживается, есть SLA на регресс | конверсия на мобильных +15–25% [2] |
| Связка «форма → CRM» | расхождение 30–60% | расхождение 1–3% | реальный CPL виден, бюджет идёт в работающие каналы [6] |
| Атрибуция «канал → продажа» | по последнему клику или вообще нет | мультиканальная, по client_id | видно, какие каналы реально дают выручку [3] |
| Ретро-цикл | у каждого подрядчика свой, или нет | раз в спринт, общее, по сквозной воронке | системное накопление знаний [4] |
| Затраты на менеджмент стыков | 15–25% времени собственника | 3–5% (один контакт) | возврат самого дорогого ресурса [1] |
| Прозрачность для собственника | 4 отчёта, ни одного итогового числа | один дашборд: выручка → CAC → каналы | управленческие решения за 5 минут, а не 5 часов [3] |
Антипаттерны и как их исправить
Большинство ошибок в фрагментированной модели — не про компетенции конкретных подрядчиков, а про устройство процесса. Сильный SEO-специалист в плохой системе будет приносить отчёты «позиции выросли» при падающей выручке — и формально он прав. Слабый SEO-специалист в хорошей системе будет вынужден работать в общую воронку и приносить пользу даже при средних навыках, потому что его задачи поставлены через приоритизацию выручки, а не позиций. Архитектура побеждает компетенции — это базовая интуиция, на которой строится переход к единой логике [5].
Самый частый антипаттерн — «каждый со своим отчётом». На еженедельном созвоне четыре подрядчика по очереди показывают четыре презентации, в каждой 15–20 слайдов, ни в одной нет цифры выручки. Собственник 90 минут слушает «всё хорошо» по локальным метрикам, потом смотрит в P&L и не видит роста. Лечится одним движением: вместо четырёх отчётов вводится один дашборд с пятью верхнеуровневыми числами (выручка, CAC, payback, доля канала, технический индикатор сайта), и встреча начинается с него. Локальные отчёты остаются у подрядчиков, но не определяют повестку [3].
Второй антипаттерн — «каждый со своим Jira». У SEO своя доска, у разработки своя, у поддержки своя, у контекста — Excel. Когда нужно протестировать гипотезу, требующую работы трёх команд (новая посадочная + новая кампания + разметка событий), задача застревает в трёх досках с разными приоритетами. Лечится общим бэклогом с одним приоритетным списком и одним владельцем приоритизации. Подрядчики продолжают вести свои внутренние доски, но «верхнеуровневая» доска — одна [4].
Третий антипаттерн — «каждый защищает свою территорию». Контекстолог не пускает разработчика в Ads, потому что «там можно всё сломать». Разработчик не пускает SEO в репозиторий по той же причине. SEO не делится семантикой с контекстом, потому что «мы это сами разрабатывали». В итоге доступы разрозненны, при уходе любого подрядчика часть данных теряется, а интеграция любой новой инициативы превращается в политическую переписку. Лечится через единый принцип: «доступы принадлежат бизнесу, а не подрядчику», и аудит доступов фиксируется в первый месяц работы [6].
Зоопарк подрядчиков
Каждый — со своим отчётом
SEO показывает рост позиций. Контекст показывает CTR в норме. Разработчик показывает 99,9% uptime. Поддержка показывает 95% закрытых тикетов. Все «зелёные», на встрече — взаимные комплименты. Собственник смотрит в P&L и видит, что выручка стоит. Никто не виноват: каждый «сделал свою работу».
Единая логика
Один дашборд на весь контур
Встреча начинается с пяти чисел: выручка, CAC, payback, доля канала, технический индикатор сайта. Разговор сразу идёт о том, что на этой неделе двигало воронку, а не о том, у кого CTR красивее. Локальные отчёты остаются, но они вторичны: главное — один взгляд на всю систему, и за этот взгляд отвечает один человек [5].
!
Сильный специалист в плохой архитектуре будет приносить локально «зелёные» отчёты при падающей выручке. Средний специалист в хорошей архитектуре будет вынужден работать в общую воронку и приносить системную пользу. Поэтому первый рычаг улучшения проекта — не «найти лучших», а «починить процесс» [6].
Как устроена работа в единой логике: роли, ритм, артефакты
Governance в единой системе строится на четырёх вещах: ролях (см. раздел «Пять опор»), ритуалах, артефактах и регламентах. Ритуалы — это регулярные встречи с фиксированной повесткой: weekly по операционке, biweekly по гипотезам, quarterly по стратегии и сквозной воронке. Артефакты — документы, которые живут между встречами: дашборд, бэклог, словари, ретро-протоколы. Регламенты — SLA на ответ, на выкатку, на обновление словарей. Без этих четырёх вещей «единая система» остаётся декларацией; с ними — становится повторяемым процессом [4].
Главный антипаттерн governance — попытка «договориться один раз и работать». Любая система, в которой нет регулярных ретро и регулярных пересмотров приоритетов, через 3–6 месяцев деградирует обратно в фрагментацию: подрядчики возвращаются к локальным метрикам, словари перестают обновляться, дашборд перестаёт отражать реальность. Поэтому ритуалы важнее, чем стартовая интеграция: без weekly с владельцем воронки даже идеально настроенная система через квартал перестаёт работать [1].
Ритм governance мы обычно рекомендуем такой: weekly 30 минут (что двигало воронку на этой неделе, что сломалось, что в работе), biweekly 60 минут (ретро по гипотезам, приоритизация бэклога на 2 недели вперёд), monthly 90 минут (сверка дашборда с CRM и финансами, корректировка KPI), quarterly 3 часа (стратегический пересмотр ICP, каналов, бюджета). Подрядчики приходят на weekly и biweekly; собственник — на monthly и quarterly. Это даёт первому лицу управляемость без выгорания на операционке [4].
Шаг 1
Аудит всех подрядчиков, доступов, метрик, событий и точек разрыва данных. Собирается «карта стэка»: кто за что отвечает, какие сервисы используются, где сшиваются и где расходятся цифры. Артефакт — единая карта стэка на одной странице A3 + список из 10–20 точек разрыва, отсортированный по влиянию на воронку.
Шаг 2
Перепрошивка GA4 на серверную отправку ключевых событий через Measurement Protocol, ввод единого словаря UTM и словаря событий. Сшивка client_id ↔ crm_lead_id ↔ deal_id. Артефакт — data dictionary на 3–5 страниц + работающий дашборд с пятью верхнеуровневыми числами [6].
Шаг 3
Запуск общего бэклога в одной системе (Jira / Linear / YouTrack — не принципиально), назначение владельца приоритизации, ввод weekly/biweekly/monthly с фиксированной повесткой. Артефакт — регламент на одну страницу: кто на каких встречах, какие решения принимаются, какие SLA на правки [4].
Шаг 4
Раз в квартал — стратегический пересмотр: что работает, что нет, какие гипотезы подтвердились, куда перераспределить бюджет, не пора ли менять состав подрядчиков или ролей. Артефакт — quarterly review-протокол на 3–5 страниц с решениями и ответственными на следующий квартал [1].
i
Weekly 30 минут с владельцем воронки, biweekly ретро по гипотезам, monthly сверка с CRM, quarterly стратегия. Один общий бэклог, один дашборд, четыре словаря. Без бюрократии и красивых слайдов — но с фиксированной повесткой и фиксированной ответственностью. Это даёт 80% эффекта «единой системы» при минимальной нагрузке на собственника [4].
KPI единой системы: что измерять и кому это нужно
Главная ошибка в KPI единой системы — попытка «измерять всё». На дашборд собственника лезет 30–50 метрик, через месяц никто на него не смотрит. Правильная архитектура KPI — трёхуровневая: на верхнем уровне 5–7 чисел для собственника (стратегические), на среднем — по 3–5 чисел на канал для маркетинг-руководителя, на нижнем — технические индикаторы для команды (LCP, INP, error-rate форм, время ответа поддержки). Каждый уровень видит только свой, и каждый уровень соединён с соседним через причинно-следственную цепочку [3].
Стратегический уровень — это LTV, CAC, payback, доля каналов, выручка по сегментам. Эти метрики меняются медленно (месяц–квартал) и нужны для решений «куда двигать бюджет» и «какие каналы держать». Канальный уровень — CPL, CR в SQL, CR в продажу, ROAS по каждому каналу — нужны для оперативного управления кампаниями и обновляются еженедельно. Технический уровень — Web Vitals, доступность форм, время ответа CRM-webhook — обновляется в реальном времени и нужен для того, чтобы технические регрессии не съедали маркетинговый бюджет [2].
Третий принцип — каждая метрика должна иметь владельца и пороговое значение. «LCP < 2,5 сек на 75-м перцентиле мобильных» — это владелец разработки, порог 2,5 сек, при превышении — задача в бэклог в течение 48 часов. «CR в SQL по каналу контекст ≥ 25%» — владелец маркетинг-руководитель, порог 25%, при падении — ретро на ближайшем biweekly. Без порогов и владельцев метрики становятся «отчётностью», а не инструментом управления [4].
OK
MID
RISK
i
Каждая метрика должна иметь владельца, пороговое значение и протокол реакции на превышение. Метрика без владельца — это отчётность; метрика с владельцем и порогом — инструмент управления. На дашборде собственника не должно быть больше 5–7 чисел: всё остальное живёт на уровнях ниже [3].
План перехода за 90 дней
Переход к единой системе пугает собственников по двум причинам: страх остановки кампаний на время «перепрошивки» и страх конфликта с действующими подрядчиками. Оба страха решаемы: грамотный переход не требует ни остановки рекламы, ни увольнения подрядчиков на старте. Все работы делаются параллельно с действующими процессами, а решения «оставлять / менять подрядчиков» принимаются на основе фактов, собранных в первые 30 дней, а не на старте [4].
Бюджеты на переход в реалиях рынка Беларуси — это, в среднем, 12 000–25 000 BYN на 90 дней для проекта с 4–6 подрядчиками и средней сложностью CRM/сайта. Из них 2 500–6 000 BYN — перепрошивка GA4 и серверная отправка событий, 2 000–4 000 BYN — настройка единого дашборда (Looker Studio / Metabase), 3 000–6 000 BYN — аудит и инвентаризация на первом этапе, остальное — координация и работа с подрядчиками. Это разовые инвестиции; операционная стоимость единой системы после перехода не выше суммарной стоимости фрагментированной [6].
Возврат инвестиций обычно виден в первый же квартал — за счёт перераспределения бюджета между каналами после получения честной картины CPL. Типичная экономия — 15–25% маркетингового бюджета, при сохранении или росте лидогенерации. На проектах с большим маркетинговым бюджетом (от 30 000 BYN/мес) экономия только за счёт перераспределения каналов окупает все 90-дневные инвестиции в первый месяц после завершения [3].
- Дни 1–10: аудит подрядчиков. Кто за что отвечает по договору, какие метрики считает своими, какие отчёты сдаёт. Артефакт — таблица «подрядчик → зона ответственности → метрики → ритм отчётности». Бюджет: 1 500–3 000 BYN.
- Дни 5–15: карта доступов. Полный инвентарь: GA4, Ads, CRM, хостинг, репозиторий, домены, почта, соцсети. Передача доступов на корпоративные ящики бизнеса. Артефакт — таблица доступов с владельцами и резервными контактами.
- Дни 10–20: сверка GA4 vs CRM за последние 3 месяца. Выгружаются лиды по дням из обеих систем, считается дельта. Артефакт — отчёт с величиной разрыва и гипотезами о его причинах. Это главный аргумент для собственника о размере утечки.
- Дни 15–30: словари (события, ID, сегменты, UTM). Совместная сессия с подрядчиками, 2–4 часа. Артефакт — data dictionary на 3–5 страниц, утверждённый всеми сторонами [6].
- Дни 25–45: перепрошивка GA4 на серверную отправку ключевых событий через Measurement Protocol. Сшивка client_id ↔ crm_lead_id. Бюджет: 2 500–6 000 BYN. После этого расхождение GA/CRM падает с 30–60% до 1–3%.
- Дни 30–50: единый дашборд для собственника. Looker Studio или Metabase с пятью верхнеуровневыми числами + детализация по каналам. Бюджет: 2 000–4 000 BYN. Артефакт — рабочий дашборд с автообновлением.
- Дни 40–60: единый бэклог. Перенос задач всех подрядчиков в одну систему (Jira/Linear/YouTrack), назначение владельца приоритизации. Артефакт — рабочий бэклог + регламент приоритизации на 1 странице.
- Дни 50–70: SLA поддержки и регламент релизов. Фиксация времени ответа на критические инциденты (4 часа), на запрос правок (24 часа), регламент выкатки изменений на сайт. Артефакт — SLA-документ на 1–2 страницы [4].
- Дни 60–80: запуск ритуалов governance. Первая weekly, первая biweekly с ретро по гипотезам, расписание monthly и quarterly. Артефакт — календарь встреч с фиксированной повесткой.
- Дни 80–90: первое quarterly-ревью. Сверка всех KPI по новой архитектуре, решения о составе подрядчиков на следующий квартал, перераспределение бюджета. Артефакт — quarterly-протокол с решениями и ответственными [1].
Как это решает Ontop
В команде Ontop единая система — это не маркетинговое позиционирование, а способ устройства проектов. У каждого нашего клиента есть один менеджер контура — человек, который владеет воронкой целиком: от первого касания в SEO до повторной продажи в CRM. Этот менеджер не «координирует подрядчиков», а принимает решения по приоритизации поверх границ направлений: что важнее на этой неделе — техническая правка LCP, новая SEO-страница или новый оффер для контекста. У каждого специалиста (SEO, разработка, контекст, аналитика, поддержка) есть свой бэклог, но приоритеты задаются из общего.
Технологически мы стандартизировали стэк: GA4 с серверной отправкой ключевых событий через Measurement Protocol, единый словарь UTM, общий бэклог в одной системе, дашборд в Looker Studio с пятью верхнеуровневыми числами для собственника. Это не «эксклюзивная методология», а минимально достаточная инфраструктура, без которой единая логика разваливается через 3–6 месяцев. Когда клиент приходит к нам после развалившейся мозаики из 4–5 подрядчиков, первые 30 дней мы тратим именно на восстановление этой инфраструктуры — потом уже идёт операционка.
Мы регулярно «подбираем» проекты, на которых единая логика не сложилась: четыре подрядчика, четыре отчёта, расхождение GA/CRM на 40–50%, никто не отвечает за выручку. На аудите такие проекты обычно показывают, что 25–40% маркетингового бюджета уходит в каналы, которые по реальному CPL давно убыточны — просто этого никто не видит. Первый эффект от перехода к единой системе — не «магия лучших специалистов», а исчезновение этих утечек: бюджет начинает работать на 100% в каналах, которые реально дают выручку, а не на 60% во всех.
Если вы узнаёте свою ситуацию в этой статье — закажите у нас аудит digital-системы. За 7–10 рабочих дней мы соберём сквозную карту вашей воронки, посчитаем разрыв «GA vs CRM» за последние 3 месяца, покажем точки утечки по этапам и предложим план перехода. Результатом будет рабочий документ с приоритетами и последовательностью действий, который можно использовать внутри команды или с любыми подрядчиками.
Мы проведём аудит вашей digital-системы, посчитаем разрыв между «GA-лидами» и «CRM-лидами» за последние 3 месяца и покажем, где именно бюджет теряется на стыках подрядчиков — в цифрах, не в общих словах.
Частые вопросы
Можно ли оставить часть подрядчиков и всё равно получить «единую логику»?
Да, и это самый частый сценарий перехода. «Единая логика» — это не «один подрядчик на всё», а единый владелец воронки, общая аналитика, общий бэклог и общие словари. Если действующие подрядчики готовы работать в этой архитектуре (использовать общий словарь UTM, отчитываться в общий дашборд, приходить на ритуалы governance) — их можно сохранять. Менять имеет смысл только тех, кто отказывается включаться в общий контур или чьё качество ниже требуемого порога [4].
Чем это отличается от full-service агентства «всё в одном»?
Full-service — это про услуги под одной крышей. Единая логика — это про архитектуру данных, ролей и ритуалов. Можно купить все услуги у одного агентства и при этом не иметь единой логики (например, если внутри агентства SEO, контекст и аналитика — три разных департамента с разными KPI и без общего владельца воронки). И наоборот — можно работать с тремя независимыми подрядчиками, но в единой логике, если есть общая аналитика, общий бэклог и единый менеджер контура [1].
Сколько стоит интеграция в BYN и что входит?
Для проекта с 4–6 подрядчиками и средней сложностью CRM/сайта — 12 000–25 000 BYN на 90 дней разовых инвестиций. Из них 2 500–6 000 BYN — перепрошивка GA4 и серверная отправка событий, 2 000–4 000 BYN — единый дашборд, 3 000–6 000 BYN — аудит и инвентаризация, остальное — координация и работа с подрядчиками. Операционная стоимость после перехода не выше суммарной стоимости фрагментированной модели — а часто ниже за счёт исчезновения дублирующих работ [6].
Что делать, если один из подрядчиков не отдаёт доступы?
Доступы по умолчанию должны принадлежать бизнесу, а не подрядчику. На этапе аудита первым делом инвентаризируется список доступов и владельцев аккаунтов. Если подрядчик отказывается передавать доступ, который должен принадлежать бизнесу (например, к рекламному кабинету Ads, оплачиваемому со счёта клиента), — это сигнал к смене подрядчика, и юридически такая позиция несостоятельна. На практике в 90% случаев вопрос решается мирно после фиксации регламента доступов [4].
Как не сломать рекламу при переходе?
Перепрошивка аналитики и ввод словарей делаются параллельно с действующими кампаниями, без остановки рекламы. Серверная отправка событий через Measurement Protocol дублирует, а не заменяет клиентскую отправку — на переходный период (2–4 недели) данные собираются обоими способами, потом старая разметка отключается. Кампании в Ads продолжают работать на старой атрибуции до момента подтверждённого совпадения цифр в новой схеме. Риск «сломать» при правильной последовательности — близок к нулю [6].
Нужно ли менять CMS или переезжать с готового сайта?
В 95% случаев — нет. Единая логика реализуется на любой современной CMS (Битрикс, Tilda, Wordpress, кастом) и любом стэке аналитики (GA4 + CRM любой). Менять CMS имеет смысл только если она физически не поддерживает требуемые интеграции (например, не позволяет встроить серверный обработчик форм или нет API для синхронизации с CRM). На рынке Беларуси такие случаи редки [2].
Кто становится владельцем данных после интеграции?
Бизнес. Все аккаунты (GA4, Ads, CRM, хостинг, домены, репозиторий) переводятся на корпоративные ящики бизнеса с правами «владелец». Подрядчики получают доступы уровня «редактор» или «администратор» по принципу минимальных необходимых прав. При уходе любого подрядчика бизнес сохраняет полный доступ ко всем данным и системам — это базовое требование единой логики и условие, при котором смена подрядчиков не приводит к потерям данных и кампаний [6].
Выводы
Пересборка вокруг единой воронки даёт измеримый эффект уже в первом квартале — и не за счёт «лучших специалистов», а за счёт исчезновения потерь на стыках. Когда четыре подрядчика смотрят в один дашборд, пользуются общим словарём событий и подчиняются одному владельцу воронки, бюджет перестаёт уходить в зазоры между договорами. Типичная экономия только за счёт корректной атрибуции и перераспределения каналов — 20–35% маркетингового бюджета при сохранении или росте лидогенерации. Это не маркетинговое обещание, а арифметика: исчезает разрыв «GA-лиды vs CRM-лиды», и собственник впервые видит реальную стоимость лида по каждому каналу.
Точка решения для собственника проста: пока за результат не отвечает кто-то один, и пока цифры в отчётах разных подрядчиков не сходятся в одном дашборде — любые деньги на маркетинг идут с КПД заметно ниже возможного. Это не вопрос компетенций подрядчиков и не вопрос «найти лучших». Это вопрос архитектуры: ролей, словарей, ритуалов и единого владельца воронки. 90 дней грамотного перехода и 12 000–25 000 BYN разовых инвестиций обычно окупаются за один квартал — и дальше работают на компанию годами, независимо от того, кто из подрядчиков остался в команде, а кого пришлось заменить.
Источники
- McKinsey — The growth triple play: creativity, analytics, and purpose — Исследование McKinsey о совокупном эффекте интегрированного подхода к маркетингу: компании, которые соединяют креатив, аналитику и единую цель, растут в 2–5× быстрее по сравнению с изолированными инициативами. Опорный источник для тезисов о единой архитектуре, ролях governance и quarterly-ритме пересмотра стратегии.: https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-growth-triple-play-creativity-analytics-and-purpose
- web.dev — Why does speed matter? — Первичный материал Google web.dev о связи скорости загрузки с конверсией, удержанием и доходом. База для тезисов о технических потерях на стыке «сайт ↔ кампания», о роли LCP/INP в воронке и о необходимости технических индикаторов на нижнем уровне KPI единой системы.: https://web.dev/articles/why-speed-matters
- Unbounce Conversion Benchmark Report — Медианные и квартильные показатели конверсии посадочных страниц по индустриям, включая разрыв между лучшими и средними проектами в 3–5×. База для сравнения «силосный vs интегрированный» и для тезисов о том, что разница в результатах редко объясняется навыками — обычно дело в архитектуре воронки.: https://unbounce.com/conversion-benchmark-report/
- Nielsen Norman Group — Consistency and Standards — UX-исследование о значимости системной согласованности: непоследовательный UX снижает доверие, ломает паттерны пользователя и снижает конверсию. Аргумент для секции «пять опор системы», для тезисов о согласованности словарей и для регламента governance.: https://www.nngroup.com/articles/consistency-and-standards/
- Baymard Institute — Cart Abandonment Rate Statistics — Данные о потерях на этапах формы и checkout: 70%+ корзин в e-commerce бросаются, и значительная часть потерь приходится на технические и UX-проблемы стыка «форма ↔ обработка». Прямая аналогия для потерь на стыке «сайт ↔ CRM» в B2B-воронке и для тезиса о роли единого владельца стыков.: https://baymard.com/lists/cart-abandonment-rate
- Google Developers — GA4 Measurement Protocol — Официальная документация Google по серверной отправке событий в GA4 через Measurement Protocol. Техническая основа для тезисов о едином источнике истины по данным, о перепрошивке аналитики и о схеме, при которой данные в GA4 и CRM совпадают с точностью до 1–3%.: https://developers.google.com/analytics/devguides/collection/protocol/ga4
