У перформансі в контролю доступів кепська репутація. Звучить як щось, що вигадав комплаєнс, аби гальмувати баєрів, і в командах, які росли швидко, цей крок зазвичай просто пропускали: один спільний логін, одна спільна таблиця, усі бачать усе, поїхали.
Це працює, поки не перестає працювати, і ламається воно ніколи не поступово. Нижче — аргументація на користь рольового доступу в баїнг-команді, побудована на операційних, а не на політичних підставах.
Справжній аргумент
RBAC — це передусім не про довіру. Формулювання «ми не довіряємо баєрам» — найшвидший спосіб отримати відмову, і воно ще й хибне. Три кращі причини:
Він обмежує радіус ураження. Кожен доступ — це потенційний інцидент. Коли один акаунт скомпрометовано або одна людина помилилась, шкода обмежена тим, до чого ця особа могла дотягнутись. Коли в усіх є все, кожна помилка автоматично портфельного масштабу.
Він робить атрибуцію можливою. Якщо логін ділять троє, ви не відповісте на питання «хто змінив цей бюджет» чи «хто вивантажив цей експорт». Не тому, що хтось ховається, — просто ця інформація ніколи не фіксувалась. Через це кожен розбір інциденту стає вгадуванням, а кожна розмова про результат — суперечкою.
Він знижує когнітивне навантаження. Це та причина, яку баєри реально цінують, коли відчують. Баєр, який бачить 300 акаунтів, з яких він не веде жодного, мусить фільтрувати подумки, перш ніж почати роботу. Баєр, який бачить свої 18, починає працювати одразу. Обмежений доступ — це кращий інтерфейс, а не лише безпечніший.
Четверта причина приходить пізніше, але приходить завжди: партнери, мережі й аудити питають, хто до чого має доступ. Команда, яка відповідає на це одним екраном, у зовсім іншій позиції, ніж та, що каже «ну, в принципі, всі».
Чотири ролі
Більшість баїнг-команд чисто розкладається на чотири ролі. Більше чотирьох — і модель перестає триматись у голові; менше — і ви постійно роздаєте винятки.
Адмін організації
Відповідає за: усю організацію. Кожну команду, кожен акаунт, кожну політику, а також самі ролі.
Має бачити: усе. Результат по всьому портфелю, всіх баєрів, усі фінанси, всі підключення акаунтів, журнал дій.
Не має: бути роллю за замовчуванням «щоб не морочитись». Найпоширеніший провал RBAC на практиці — коли адмінами стають шестеро, бо це простіше, ніж один раз подумати про права. Якщо адмін — це більша частина команди, у вас не RBAC, а назва ролі. Тримайте кількість таких місць свідомо малою і переглядайте її щомісяця.
Тімлід
Відповідає за: результат визначеної групи баєрів.
Має бачити: усі акаунти своїх баєрів, порівняльний результат по кожному, алерти по своїй групі, бюджети й темп у межах своєї зони.
Не має бачити: результат баєрів інших команд і фінансову деталізацію рівня організації — наприклад, виплати людям, якими він не керує. Видимість результатів інших команд напрочуд часто стає джерелом тертя: порівняльні цифри без контексту використовують як зброю, а не як інформацію.
Саме роль ліда найчастіше моделюють погано. Ліду потрібна видимість, достатня, щоб втрутитися до того, як спенд у баєра поплив, а це означає деталізацію по акаунтах, а не зведену плитку. Лід, який мусить просити деталі в когось іншого, не може керувати цифрою, за яку відповідає.
Баєр
Відповідає за: свої акаунти.
Має бачити: свої закріплені акаунти повністю — спенд, дохід, ROAS, CPA, апруви й обмеження за політиками, пов'язані домени й алерти по цих акаунтах. А також власну історію результату, бо люди керують тим, що можуть виміряти в собі.
Не має бачити: акаунти й результати інших баєрів, фінанси рівня організації, схеми виплат для інших людей, а також доступи до акаунтів, які йому не потрібні.
Останній пункт варто розгорнути. Є принципова різниця між «може бачити дані про результат цього акаунта» і «може зайти в цей акаунт». Саме через їх злипання баєр, що звільняється, виходить із дверей із живим доступом до двадцяти акаунтів. Видимість даних і доступ до облікових записів — це два різні права, і моделювати їх треба окремо.
Фінанси / адмін
Відповідає за: грошову частину — дохід, звірку спенду, витрати, виплати.
Має бачити: повні фінансові дані по всій організації. Спенд по акаунтах і баєрах, дохід через постбеки, ручні витрати, P&L, статус білінгу.
Не має: мати операційного контролю над кампаніями чи налаштуваннями акаунтів. Фінансам треба читати цифри, а не смикати важелі. Це ще й та роль, де принцип «тільки для читання» найочевидніше правильний: жодне завдання фінансів не потребує можливості змінити кампанію.
Скільки насправді коштують спільні логіни
Спільні доступи — це стан за замовчуванням у команди, яка не ухвалила рішення. Сценарії провалу конкретні й повторюються з команди в команду.
Зникає атрибуція. Хтось змінив бюджет, спенд за ніч потроївся, і встановити, хто це зробив і що мав на увазі, неможливо. Розбір перетворюється на нараду, де троє кажуть «це не я», ймовірно чесно, і ніхто нічого не виносить. Через місяць той самий інцидент повторюється.
Офбординг перетворюється на ручний аудит. Коли людина йде, ви не можете просто відкликати її доступ, бо її доступ — спільний. Треба ротувати паролі всюди й сподіватись, що знайшли все. На практиці щось завжди пропускають, і доступ живе ще місяці після звільнення.
Одна компрометація — це компрометація всього. Спільний логін на особистому пристрої, у чаті, в експорті з менеджера паролів — один витік від того, щоб відкрити весь портфель. З іменними доступами той самий витік відкриває набір акаунтів одного баєра.
Алерти перестають вести до дії. Якщо в акаунтів немає ідентифікованих власників, алерти летять у групу. Групові алерти не читає ніхто, бо кожен вважає, що цим займається хтось інший. Саме власність перетворює сповіщення на дію, а спільні логіни роблять власність невиразимою.
Надлишкова видимість стає незворотною. Усі бачать виплати, маржу й результати інших баєрів. Це має другорядні наслідки для динаміки в команді, які важко відмотати назад, і робить пізніший перехід до обмежених доступів схожим на пониження, а не на виправлення.
Як це працює на практиці
Явно опишіть власність акаунтів. RBAC у баїнг-команді за суттю — це про те, який акаунт закріплений за якою людиною. Правильна карта власності тягне за собою права. Групування акаунтів за баєрами — несуча конструкція: вона одночасно визначає екран баєра, зону ліда й маршрутизацію алертів.
Розділіть читання і запис, віддавайте перевагу читанню. Більшості людей треба бачити дані, і значно меншій частині — щось змінювати. Тому інструмент, який лише спостерігає, — не обмеження: платформа, яка взагалі не заходить у ваш рекламний акаунт і не має шляху змінити кампанію, у принципі не може стати джерелом випадкової зміни, хто б у ній не був залогінений. Радіус ураження всього інструменту обмежений за побудовою.
Маршрутизуйте алерти за власністю, а не за каналом. Алерт має доходити до власника відповідного акаунта плюс до його ліда — для критичного рівня. Усе інше є шумом, який привчає людей ігнорувати алерти.
Переглядайте доступи за розкладом. Раз на місяць достатньо. Перевіряйте тих, хто пішов, тих, хто змінив команду, права, видані «тимчасово» пів року тому, і розповзання кількості адмінів. Ревізія доступів ніколи не здається терміновою — саме тому їй потрібна дата, а не намір.
Видавайте мінімум і правте за скаргами. Стартувати обмежено й послаблювати за запитом дає щільніший кінцевий стан, ніж стартувати дозвільно й потім забирати назад. Заодно це показує, що людям треба насправді, а не що вони вважають потрібним.
Заперечення, на яке варто відповісти
«Це нас гальмує». Іноді гальмує — трохи, у перший день. Прибирає воно більше: п'ятнадцять хвилин, які баєр щоранку витрачає на фільтрацію до своїх акаунтів, нараду з реконструкції того, хто що змінив, гарячкову ротацію паролів після чийогось звільнення і хвостовий ризик того, що один злитий логін дістає до всього.
Найзапекліше опираються RBAC зазвичай ті команди, які виросли настільки швидко, що всі ще пам'ятають часи, коли всім керували троє. Ця пам'ять і є проблемою. Модель доступів, робоча для трьох людей, для тридцяти вже відверто небезпечна, і перехід коштує значно дешевше до інциденту, ніж після.
AdsTracker постачається з цими чотирма ролями з коробки — адмін організації, тімлід, баєр і фінанси, — з групуванням акаунтів за баєрами й маршрутизацією алертів до власника акаунта. AdsTracker за архітектурою не має способу щось змінити в Google Ads, тож систему можна використовувати для видимості, не перетворюючи її на шлях до випадкових змін у кампаніях.