Как агентство поглотило 40 приобретённых аккаунтов без миграции

Сделка закрылась в пятницу. К следующему вторнику это агентство владело всей клиентской базой конкурента — и с ней сорока клиентскими рекламными аккаунтами, которых оно никогда не трогало, раскиданными по отдельным логинам и Business Manager. План, которому все предполагали последовать, был проектом миграции: собрать каждые учётные данные, войти в каждый аккаунт, ввести всё заново вручную за несколько мучительных недель. Что произошло на самом деле — тема этого кейса о том, как провести передачу при agency acquisition consolidate ad accounts, — потому что агентство подставило один приобретённый токен System-User, дало автообнаружению выявить каждый аккаунт и управляло обеими базами из одного рабочего пространства ещё до того, как миграция была вообще назначена.

Это собирательная история, основанная на том, как реальные агентства проводят консолидацию после поглощения. Имена и точные цифры иллюстративны; проблема передачи и форма решения — нет.

Сделка закрывается: теперь вы владеете клиентским портфелем конкурента

Приобретение агентства поменьше — нормальный способ нарастить клиентскую базу: вы покупаете клиентские отношения, ретейнеры и людей, которые их обслуживают. На бумаге агентство только что добавило сорок аккаунтов за ночь. На практике оно унаследовало клубок — приобретённая контора вела свои аккаунты так, как делает большинство агентств до того, как перерастает это: с разбросом логинов, парой Business Manager и знанием доступа, живущим в головах нескольких человек.

Собственный дом агентства был в порядке. Оно уже вело своих существующих клиентов через единый слой с именованными местами и ограниченными ролями — противоположность хаоса общих логинов, описанного в почему общие логины убивают ваше рекламное агентство. Проблема была в том, чтобы поглотить сорок аккаунтов, ведённых по чужим правилам, достаточно быстро, чтобы унаследованные клиенты не почувствовали шва. Поглощение передаёт контракты мгновенно, а операционную реальность медленно, и разрыв между «мы владеем этим» и «мы можем этим управлять» — это место, где буксуют передачи после поглощения.

Скрытая цена M&A: десятки аккаунтов за отдельными логинами

Пройдите по унаследованному портфелю — и цена старой структуры становится осязаемой. Сорок аккаунтов не означали сорок аккуратных записей. Это означало два Business Manager, заведённых в разное время, разброс аккаунтов, привязанных к каждому, несколько таких, до которых прежние владельцы дотягивались через выданные клиентом логины, и горстку, где единственный путь внутрь был общий пароль, который знали три бывших сотрудника.

Ничего из этого не необычно; так выглядит слой доступа агентства, когда оно растёт по одному клиенту за раз. Но это превращает каждое поглощение в археологический проект: прежде чем вести аккаунт, надо его найти, подтвердить, кто может до него дотянуться, и установить свой собственный путь внутрь — сорок раз, по нескольким платформам.

Обычный план: миграция по учётным данным, измеряемая неделями

Операционный лид агентства сначала прикинул очевидный подход. Перечислить каждый аккаунт; по каждому определить путь доступа, собрать учётные данные, войти, подтвердить надёжный путь внутрь, не зависящий от бывшего сотрудника, и переустановить его под собственной структурой агентства. Затем следующий аккаунт, и следующий, по двум Business Manager и нескольким платформам.

Честно оценённое, это недели хрупкой работы. Каждый общий пароль — единая точка отказа: если уходящий сотрудник его меняет или перестаёт отвечать, аккаунт гаснет. Каждый выданный клиентом логин надо переподтвердить, чтобы отношения пережили смену собственника. И всё время, пока идёт миграция, унаследованные клиенты в подвешенном состоянии: технически ответственность агентства, практически всё ещё наполовину ведутся через логины старой конторы. Команда проводила меньшие версии этого раньше — аврал первой недели, описанный в их собственном плейбуке по онбордингу нового клиентского аккаунта на первой неделе, — и на сорока аккаунтах этот аврал не масштабируется.

Короткий путь: подстановка приобретённого токена System-User

Короткий путь был, и он изменил форму всего проекта. Приобретённое агентство, как и большинство агентств, работающих в масштабе, выпустило токен System-User на уровне Business Manager для своих интеграций с платформами. Токен System-User — не личный логин, привязанный к одному сотруднику; это надёжные учётные данные бизнес-уровня, которые уже несут доступ к каждому рекламному аккаунту, которым управляет их Business Manager. Агентству не нужны были сорок учётных данных — ему нужен был токен, приобретённый вместе с бизнесом.

Так что вместо начала миграции операционный лид сделал одно: подставил токен System-User приобретённого агентства в операционный слой — тот же механизм подключения-один-раз, который агентство уже использовало, чтобы онбордить клиентский аккаунт, ни разу не передав логин Meta. Один токен, одна вставка — на аккаунты целого Business Manager. План миграции коснулся бы каждого аккаунта по отдельности; токен коснулся слоя, который уже держал их все.

Что выявило автообнаружение: каждый аккаунт и BM, без ручной инвентаризации

Что произошло дальше — вот почему проект миграции так и не запустился. Операционный слой прочитал токен, разрешил стоящий за ним business_id и автоматически перечислил аккаунты — каждый рекламный аккаунт под этим Business Manager, выявленный без того, чтобы кто-то печатал список. Второй Business Manager пришёл тем же образом со своим токеном, и между двумя бóльшая часть из сорока аккаунтов стала видна за один вечер.

Ручной инвентаризации не было, потому что токен уже знал инвентарь. Автообнаружение по business_id означало, что источником правды для «какие аккаунты существуют» был сам Business Manager, а не таблица, восстановленная из памяти бывших сотрудников. Горстка аккаунтов, державшихся через выданный клиентом доступ, а не через приобретённый BM, всё ещё требовала индивидуального переподтверждения, но они были коротким хвостом, а не всем проектом.

Раскладка унаследованной команды по внутренним ролям RBAC

Выявить аккаунты было половиной работы; другая половина — решить, кто может их трогать. Приобретённое агентство удержало часть байеров как часть сделки и отпустило других, и агентство вовсе не собиралось реплицировать разброс доступа старой конторы. Когда аккаунты теперь были внутри операционного слоя, управление тем, кто с ними работает, стало внутренним решением, а не свойством логинов платформы.

Операционный лид назначил ограниченные роли. Удержанные байеры получили именованные места, привязанные к аккаунтам, которые они продолжат обслуживать, так что клиентские отношения остались тёплыми через людей, которых клиенты уже знали; собственные лиды агентства получили надзор над обеими базами; уходящие сотрудники не получили ничего. Ничего не нужно было отзывать на нативных платформах, потому что ни один из унаследованных байеров никогда не работал через базовые логины. Они работали через внутренние роли над единым подключённым токеном — модель, которую агентство использует, чтобы не дать отдельным логинам стать операционным слоем. Управление доступом произошло один раз вместо сорока раз по нативным экранам прав.

Управление обеими базами из одного рабочего пространства уже на первой неделе

К концу первой недели агентство вело своих исходных клиентов и сорок унаследованных аккаунтов из одного рабочего пространства. Совещание по масштабированию, очередь запусков, отчётность — всё это покрывало обе базы сразу, в одном обзоре, а не переключаясь между собственной структурой агентства и двумя Business Manager старой конторы. Унаследованные клиенты получили стандартный ритм отчётности агентства сразу, а не после переходного квартала.

Клиенты не почувствовали ничего. Никаких сбросов паролей, никаких писем «мы мигрируем ваш аккаунт», никакого провала в управлении — агентство, купившее их старую контору, просто продолжило вести их рекламу. Недель наполовину-ведомого подвешенного состояния, которые создала бы миграция, никогда не существовало.

Урок: когда обнаружение делает токен, поглощение — это подключение

Спрошенный потом, что он сказал бы другому агентству перед поглощением, ответ операционного лида был конкретен: прежде чем прикидывать миграцию, проверьте, включает ли покупаемый вами доступ токен System-User уровня Business Manager. Если включает, вы не мигрируете сорок аккаунтов — вы подключаете два Business Manager и переподтверждаете короткий хвост выданных клиентом, а ваша настоящая работа — слой управления поверх.

Этот рефрейминг — весь урок. Миграция предполагает, что работа масштабируется с числом аккаунтов; подключение предполагает, что она масштабируется с числом путей доступа, — а токен System-User схлопывает целый Business Manager в один путь. Агентство консолидировало сорок аккаунтов за вечер, потому что автообнаружение по business_id уже сделало пер-аккаунтную работу. Тот же паттерн держится по всем шести рекламным платформам, которые поддерживает операционный слой, так что приобретённая база, охватывающая Meta, Google, TikTok, Taboola, Snapchat и Outbrain, приходит канал за каналом, а не аккаунт за аккаунтом.

Тарифы Wevion начинаются с постоянного бесплатного уровня (€0), затем Starter за €99/мес, Pro за €499/мес и Plus за €1 499/мес (€1 199 при годовой оплате, со счётом раз в год при −20%), с Enterprise в качестве индивидуального плана, и каждый платный уровень включает 14-дневный пробный период, сосуществующий с бесплатным планом. Подключение токена System-User и наблюдение за автообнаружением аккаунтов укладывается внутрь этого. Остальная часть плейбука живёт в кластере инструментов агентства.

Вывод обобщается на любое агентство, растущее через поглощения: размер передачи — это не число купленных вами аккаунтов, это число различных способов до них дотянуться. Унаследуйте токен, несущий весь Business Manager, дайте обнаружению сделать инвентаризацию, управляйте унаследованной командой через внутренние роли — и миграция, которой вы боялись, окажется шагом подключения.