Как агентство онбордило 80 клиентских аккаунтов без единого общего логина
Davide Ferraro
Руководитель операций агентства
Точка слома пришла, как обычно, в виде таблицы. Агентство медиабаинга, выросшее с горстки клиентов до раскинувшегося портфеля, держало вкладку под названием «Логины» — по строке на клиента, столбцы для имени пользователя, пароля, резервного 2FA и даты последнего изменения. В день, когда эта таблица перевалила за восемьдесят строк, операционный директор перестал прокручивать и признал очевидное: это была не система, это была угроза со строкой поиска. Это история о том, как агентство научилось онбордить клиентский рекламный аккаунт без передачи логина вообще — один токен System-User, введённый однажды, авто-обнаружение, показывающее каждый аккаунт, и внутренние роли вместо паролей.
Краткий ответ: Вместо сбора имени пользователя и пароля Meta каждого клиента агентство подключало аккаунты через токен System-User, введённый один раз. Авто-обнаружение через business_id показывало каждый Business Manager и рекламный аккаунт, до которого этот токен мог дотянуться, а байеры работали через внутренний доступ на основе ролей. Никто никогда не держал прямой логин Meta, так что онбординг перестал быть передачей учётных данных, а офбординг стал одним кликом.
Это собирательный случай по распространённым агентским паттернам, но сам сбой и его исправление реальны. Точные цифры иллюстративны; разрастание учётных данных и то, как оно становится опасным по мере масштабирования агентства, — нет.
Точка слома: логин на каждого клиента
Первые несколько лет агентство онбордило клиентов единственным известным ему способом. Новый клиент подписывался, и кикофф-звонок заканчивался той же неловкой просьбой: «Можете передать свой логин Meta, чтобы мы зашли в рекламный аккаунт?» Иногда клиент передавал свой личный пароль Facebook. Иногда они создавали одноразового пользователя с правами админа. В любом случае агентство уходило ещё с одними учётными данными для хранения, и вкладка «Логины» прирастала ещё строкой.
На десяти клиентах это раздражало. На восьмидесяти это было полноценным риском на полную ставку. Каждый пароль, изменённый на стороне клиента, тихо ломал доступ, пока кампания не устаревала. Каждый 2FA-запрос приземлялся на телефон, принадлежащий одному человеку, который становился единственной точкой отказа для всей книги бизнеса. И никто не мог ответить на вопрос, у которого должен быть односложный ответ: у кого именно есть доступ к аккаунту этого клиента прямо сейчас?
Агентство не чувствует цены общих логинов на пяти клиентах. Оно чувствует её всю сразу где-то после пятидесяти, когда список учётных данных становится угрозой, которой никто не владеет, и каждый новый клиент делает её хуже. Модель, что вас запустила, — это модель, что вас ограничивает.
Почему общие логины были настоящим риском
Агентство предполагало, что его риск живёт в перформансе — плохая неделя, упущенная цель. Реальной уязвимостью была таблица логинов. Как мы излагаем в почему общие логины убивают ваше рекламное агентство, общие учётные данные — худшее из всех миров сразу: их нельзя атрибутировать, нельзя безопасно отозвать и нельзя проаудировать.
Три сбоя накладывались. Первый, 2FA-ключи и пароли жили в менеджере паролей, так что доступ к одному хранилищу был доступом к восьмидесяти клиентам — поверхность взлома, которую ни один клиент бы не одобрил. Второй, джуниоры имели полный доступ по умолчанию, потому что у общего логина нет понятия ролей; вручить новому байеру «пароль» значило вручить ему всё. Третий, офбординг был ручной охотой: когда байер уходил, кто-то должен был вспомнить каждый Business Manager, которого тот байер касался, и вытянуть доступ вручную, аккаунт за аккаунтом, надеясь, что ничего не упущено.
Этот последний не давал операционному директору спать. Уходящий байер с тлеющим доступом по десяткам клиентских Business Manager — это исход по умолчанию модели общего логина — ровно тот вид бреши, что каталогизирован в нашем разборе ошибок разрешений рекламных аккаунтов агентства.
Опасность общего логина не в том, что кто-то его угадает. В том, что вы никогда не сможете чисто доказать, у кого он есть, сузить его или забрать. Для агентства, держащего доверие восьмидесяти клиентов, «мы не вполне уверены, у кого ещё есть доступ» — это фраза, что заканчивает отношения.
Сдвиг: подключайся токеном, а не паролем
Перемена была не столько новым инструментом, сколько новой ментальной моделью: перестать относиться к доступу к аккаунту как к учётным данным для сбора и начать относиться к нему как к подключению, устанавливаемому однажды. Агентство перевело свой портфель на Wevion и подключило клиентские аккаунты через токен System-User, а не личный логин.
Механика была почти антиклиматичной. Для каждого клиента агентство устанавливало токен System-User против Business Manager клиента — санкционированное, машинного уровня подключение, не зависящее ни от чьего личного пароля или 2FA. Токен вводился один раз. Затем авто-обнаружение делало ту часть, что раньше занимала послеобеденное время: читая business_id, оно показывало каждый рекламный аккаунт и Business Manager, до которого этот токен мог дотянуться, и подтягивало их в рабочее пространство автоматически — без копирования ID аккаунтов между экранами, без аккаунтов, обнаруженных три недели спустя.
Общий логин — это секрет, который вы должны защищать вечно. Токен System-User — это подключение, которое вы устанавливаете однажды, а затем управляете им — различие, исследованное в отдельные логины против мультибрендового операционного слоя. Агентство больше не было в бизнесе хранения паролей. Оно было в бизнесе выдачи доступа.
Когда вы подключаете аккаунт токеном вместо пароля, онбординг перестаёт быть передачей секретов и становится установлением управляемого подключения. Вы подключаетесь один раз; вы никогда больше не циркулируете учётные данные. Эта единственная инверсия — то, что делает следующие восемьдесят клиентов масштабируемыми, а не накапливающимися.
Сопоставление команды ролям, а не учётным данным
С подключёнными аккаунтами агентство столкнулось с вопросом, который эпоха общих логинов никогда не давала задать чисто: кто в команде должен иметь возможность делать что и на каком клиенте?
Внутренний доступ на основе ролей сделал это конфигурацией, а не учётными данными. Каждому байеру давалась роль, ограниченная аккаунтами, над которыми он реально работал. Сениор на корпоративном списке получал широкий доступ там и никакого на книге малого бизнеса. Джуниор получал ровно назначенные ему аккаунты и ничего больше. Принципиально, выдача этого доступа никогда не включала передачу логина Meta — базовый токен оставался у агентства, а байер просто работал внутри рабочего пространства под своей именованной ролью.
Это та половина системы, что общие логины делают невозможной. Пароль нельзя ограничить — его можно только дать или удержать. Роли позволяют агентству выдать точный доступ, который человеку нужен, и не более — что является предпосылкой за дисциплинированным потоком онбординга, который мы описываем в плейбуке онбординга клиента агентством в первую неделю. Доступ стал тем, что вы назначаете, проверяете и корректируете — а не секретом, который вы надеетесь удержать.
Выдача доступа по роли вместо пароля меняет то, чем онбординг вообще является. Вы перестаёте спрашивать «должен ли этот человек получить логин» — бинарный вопрос «всё-или-ничего» — и начинаете спрашивать «что этот человек должен иметь возможность делать здесь», что является вопросом, на который реальной операции всё равно нужно ответить.
Онбординг следующего клиента в первую неделю
Доказательство проявилось в следующий раз, когда агентство подписало клиента. В старой модели онбординг нового аккаунта был многодневным, напряжённым делом: гнаться за клиентом ради учётных данных, хранить их, тестировать доступ, обнаружить субаккаунт, о котором никто не упомянул, гнаться снова, наконец заставить байера работать к концу второй недели.
Новый поток это свернул. Агентство устанавливало токен System-User, авто-обнаружение показывало аккаунты и Business Manager клиента за один проход, и операционный директор назначал байерам их роли. Байер работал внутри рабочего пространства в первую неделю — не ожидая сброса пароля, не заблокированный 2FA-запросом, направленным кому-то в отпуске. Клиент, со своей стороны, был рад не передавать свой личный пароль Facebook сторонней агентству, превращая неуютную кикофф-просьбу в точку уверенности.
Самый ясный сигнал, что модель онбординга сломана, — это сколько времени уходит на то, чтобы байер продуктивно заработал на новом аккаунте. Когда это падает с напряжённых двух недель до чистой первой недели, вы не просто сэкономили время — вы убрали ту часть онбординга, что нервировала и агентство, и клиента.
Что изменилось для безопасности и аудита
История безопасности была той частью, которую операционный директор не вполне предвидел. Две вещи стали драматически лучше сразу.
Офбординг превратился из охоты в клик. Когда байер уходил, не было списка Business Manager для прочёсывания и общего пароля для сброса по восьмидесяти клиентам. Роль байера отзывалась в рабочем пространстве, и его доступ заканчивался везде сразу — по сути одним действием. Тревога «мы всё забрали?» исчезла, потому что доступ никогда и не был разбросан по учётным данным в первую очередь.
И агентство наконец могло ответить на вопрос о доступе. Поскольку каждый байер работал под именованной ролью, а не общей идентичностью, у агентства была ясная картина того, кто к чему мог прикоснуться, и запись того, кто это сделал — разрешения решают, кто может изменить аккаунт, а след записывает, что они изменили. Агентство, ведущее портфель таким образом, может сказать любому клиенту точно, у кого есть доступ и что они сделали, что является другим разговором, чем «мы думаем, это был один из наших байеров».
Тихая отдача подключения токеном и выдачи ролей в том, что два сложнейших агентских вопроса — у кого есть доступ и насколько быстро мы можем его убрать — оба получают лёгкие ответы. Онбординг стал быстрее, но офбординг стал безопасным, а для агентства, держащего аккаунты многих клиентов, безопасность стоит больше.
Представление портфеля: одно рабочее пространство, шесть платформ
Модель «токен-и-роли» была не Meta-only удобством. Тот же принцип — подключи аккаунт один раз, выдай внутренние роли, никогда не циркулируй учётные данные — распространяется на шесть платформ, которые поддерживает рабочее пространство: Meta, Google, TikTok, Taboola, Snapchat и Outbrain. Клиент, ведущий Meta, TikTok и немного Taboola, больше не был тремя проблемами логина. Это был один подключённый клиент в одном рабочем пространстве, с байерами агентства, работающими над каждым каналом под той же ролью, что у них уже была.
Эта консолидация наконец отправила вкладку «Логины» на покой навсегда. Агентство не управляло восемьюдесятью паролями по шести платформам — числом, что добралось бы до сотен учётных данных. Оно управляло одним портфелем, управляемым ролями, подключённым токенами, видимым в одном месте. Остальной операционный плейбук живёт в хабе agency tools.
По ценам модель масштабируется с портфелем, а не с командой: места безлимитны на каждом плане, так что добавление байеров никогда не стоит больше, а параллельные аккаунты масштабируются с трёх на постоянном уровне Free (€0) через Starter за €99/мес и Pro за €499/мес до безлимита на Plus за €1 499/мес (€1 199 в год при годовой оплате со скидкой −20%), с Enterprise как индивидуальным тарифом. Каждый платный уровень включает 14-дневный триал, который сосуществует с бесплатным планом.
Смысл представления портфеля не в более красивой панели. В том, что модель доступа — подключи один раз, выдай роли, отзови в клик — работает идентично, ведёт ли клиент одну платформу или все шесть. Агентство перестало иметь проблему логина на канал и начало иметь одну управляемую операцию.
Урок: отделите операционный слой от учётных данных
На вопрос, что бы они сказали более молодой версии агентства, операционный директор прям: ошибкой было относиться к доступу к аккаунту и операционному инструменту как к одному и тому же. Это не так. Учётные данные — пароль, 2FA-ключ — принадлежат клиенту. Операционный слой, где ваши байеры запускают, редактируют и отчитываются, — ваш. Эпоха общих логинов слила их, и это слияние было источником каждой проблемы: разрастания, охот при офбординге, неотвечаемого вопроса о доступе.
Их разделение — всё исправление. Подключите аккаунт один раз через токен System-User, дайте авто-обнаружению показать всё, до чего этот токен может дотянуться, и дайте своей команде внутренние роли вместо паролей. Сделайте это, и онбординг восемьдесят первого клиента выглядит как онбординг первого — установленное подключение и несколько назначенных ролей — вместо ещё одной строки в таблице, что должна была перестать расти давным-давно. Агентство, которое может онбордить клиентский аккаунт без передачи логина, — это то, которое может продолжать добавлять клиентов, не накапливая риск вместе с ними.
Часто задаваемые вопросы
The Ad Signal
Еженедельные инсайты для медиабайеров, которые отказываются гадать. Одно письмо. Только суть.
Похожие статьи
Общие логины тихо убивают ваше рекламное агентство: почему нужны ролевые места
Один общий пароль казался удобным на трёх клиентах. На тридцати — это операционный долг: нет подотчётности, нет безопасности, нет защитимой записи. Вот как семь уровней разрешений с ограниченной областью раз и навсегда заменяют общий логин.
Отдельные логины под каждый магазин vs единый операционный слой
Управлять портфелем магазинов можно двумя способами: прыгать между отдельными логинами под каждый бренд или вести их все из одного слоя. Это честное сравнение двух моделей бок о бок — трудозатраты, риск ошибок, переиспользование, отчётность и один вопрос, который их разделяет: может ли инструмент реально запускать кампании или только смотреть на них?
Как Агентство Подключает Новый Клиентский Аккаунт за Первую Неделю с Wevion
Новый ретейнер подписывается в понедельник. Большинство агентств проводят первую неделю в хаосе — разрозненные запросы доступа, теги на лету, паника с первым отчётом. Вот как одно агентство проводит весь онбординг как единую последовательность и заканчивает пятницу с уже работающими ролями, UTM и запланированным отчётом.