У контроля доступа в перформанс-маркетинге плохая репутация. Звучит как что-то, придуманное отделом комплаенса, чтобы тормозить байеров, и в быстро выросших командах его обычно просто пропускали: один общий логин, одна общая таблица, все видят всё, поехали.
Так работает ровно до тех пор, пока не перестаёт, и ломается это никогда не постепенно. Ниже — аргументы за ролевой доступ в баинг-команде, изложенные с операционной, а не с регламентной стороны.
Настоящий аргумент
RBAC — в первую очередь не про доверие. Формулировка «мы не доверяем байерам» — самый быстрый способ получить отказ, и она к тому же неверна. Три причины получше:
Он ограничивает радиус поражения. Каждый доступ — это потенциальный инцидент. Когда один аккаунт скомпрометирован или один человек ошибся, ущерб ограничен тем, до чего дотягивалась эта личность. Когда у всех есть всё, любая ошибка — ошибка масштаба портфеля.
Он делает атрибуцию возможной. Если логин делят трое, вы не ответите на вопрос «кто изменил этот бюджет» или «кто выгрузил этот отчёт». Не потому, что кто-то прячется, — потому что информацию никто не записывал. Из-за этого любой разбор инцидента становится гаданием, а любой разговор о результате — спором.
Он снижает когнитивную нагрузку. Именно эту причину байеры начинают ценить, когда попробуют. Байер, который видит 300 чужих аккаунтов, вынужден мысленно фильтровать перед любой работой. Байер, который видит свои 18, начинает работать сразу. Ограниченный доступ — это лучший интерфейс, а не только более безопасный.
Четвёртая причина приходит позже, но приходит стабильно: партнёры, сети и аудиты спрашивают, у кого какой доступ. Команда, которая отвечает на это одним экраном, находится в совсем другом положении, чем та, которая отвечает «да у всех, в общем-то».
Четыре роли
Большинство баинг-команд чисто раскладывается на четыре роли. Больше четырёх — и модель перестаёт держаться в голове; меньше — и вы постоянно раздаёте исключения.
Администратор организации
Отвечает за: всю организацию. Каждую команду, каждый аккаунт, каждую политику, а также сами роли.
Должен видеть: всё. Результат по всему портфелю, всех байеров, все финансы, все подключения аккаунтов, журнал действий.
Не должен: быть ролью по умолчанию «чтобы не возиться». Самый частый провал RBAC на практике — когда администраторами становятся шестеро, потому что это проще, чем один раз подумать о правах. Если администратор — это большая часть команды, у вас не RBAC, а название роли. Держите количество таких мест сознательно малым и пересматривайте его ежемесячно.
Тимлид
Отвечает за: результат определённой группы байеров.
Должен видеть: все аккаунты своих байеров, сравнительный результат по каждому из них, оповещения по своей группе, бюджеты и темп в пределах своей зоны доступа.
Не должен видеть: результат байеров из других команд и финансовую детализацию уровня организации — например, выплаты людям, которыми он не руководит. Видимость результатов других команд на удивление часто становится источником трения: сравнительные цифры без контекста используют как оружие, а не как информацию.
Именно роль лида чаще всего моделируют плохо. Лиду нужна видимость, достаточная, чтобы вмешаться до того, как расход у байера поплывёт, а это значит детализацию по аккаунтам, а не сводную плитку. Лид, который вынужден просить детали у кого-то другого, не может управлять цифрой, за которую отвечает.
Байер
Отвечает за: свои аккаунты.
Должен видеть: назначенные ему аккаунты целиком — расход, доход, ROAS, CPA, статусы модерации и ограничения по политикам, связанные домены и оповещения по этим аккаунтам. А также собственную историю результата, потому что человек управляет тем, что может о себе измерить.
Не должен видеть: аккаунты и результат других байеров, финансы уровня организации, структуру выплат других людей и доступы к аккаунтам, которые ему не нужны.
Последний пункт стоит развернуть. Есть настоящая разница между «может смотреть данные по этому аккаунту» и «может зайти в этот аккаунт». Смешение этих двух вещей — то, из-за чего уходящий байер уносит с собой живой доступ к двадцати аккаунтам. Видимость результата и доступ к учётным данным — разные права, и моделировать их надо раздельно.
Финансы / администратор
Отвечает за: денежную сторону — доход, сверку расхода, издержки, выплаты.
Должен видеть: финансовые данные по всей организации. Расход по аккаунтам и байерам, доход через постбэки, ручные издержки, P&L, состояние оплаты.
Не должен: иметь операционного контроля над кампаниями и настройками аккаунта. Финансам нужно читать цифры, а не трогать рычаги. Это же и та роль, где принцип «только для чтения» очевиднее всего верен: ничто из работы финансов не требует возможности изменить кампанию.
Во сколько на самом деле обходятся общие логины
Общие учётные данные — состояние по умолчанию для команды, которая не приняла решение. Сценарии отказа тут конкретны и повторяются от команды к команде.
Атрибуция исчезает. Кто-то меняет бюджет, расход за ночь утраивается, и установить, кто это сделал и что имел в виду, невозможно. Разбор превращается в совещание, где трое по очереди говорят, что это не они, — вероятно, честно, — и никто ничему не учится. Через месяц тот же инцидент повторяется.
Отключение доступов становится ручным аудитом. Когда человек уходит, вы не можете просто отозвать его личность, потому что его личность — общая. Приходится менять учётные данные везде и надеяться, что нашли все. На практике что-то всегда пропускают, и доступ живёт ещё месяцами после ухода.
Одна компрометация — компрометация всего. Общий доступ на личном устройстве, в переписке, в экспорте менеджера паролей — это одна утечка от того, чтобы открыть весь портфель. С разграниченными личностями та же утечка открывает набор аккаунтов одного байера.
Оповещения перестают вести к действию. Если у аккаунтов нет опознаваемых владельцев, оповещения рассылаются группе. Групповые оповещения не читает никто, потому что каждый считает, что этим занят кто-то другой. Именно владение превращает уведомление в действие, а общие логины делают владение невыразимым.
Избыточная открытость данных становится постоянной. Все видят выплаты, маржу и результат других байеров. У этого есть эффекты второго порядка для отношений в команде, которые трудно отмотать назад, и последующий переход к разграниченному доступу воспринимается как понижение, а не как исправление.
Как это работает на практике
Моделируйте владение аккаунтами явно. RBAC в баинг-команде — это по сути вопрос о том, какие аккаунты чьи. Сделайте карту владения правильно, и права выведутся из неё сами. Группировка аккаунтов по байерам — несущая конструкция: она задаёт и представление байера, и зону доступа лида, и маршрутизацию оповещений разом.
Разделяйте чтение и запись и предпочитайте чтение. Большинству людей нужно видеть данные; менять что-либо нужно куда меньшему числу. Именно поэтому инструмент, который только наблюдает, — не ограничение: система, которая никогда не заходит в ваш рекламный аккаунт и чей путь на запись ограничен по устройству — общий выключатель на всю организацию, пауза между срабатываниями правила, дневной лимит команд и потолок открытых команд, — не может увести ваши кампании, кто бы в неё ни зашёл.
Маршрутизируйте оповещения по владению, а не по каналу. Оповещение должно доходить до владельца затронутого аккаунта, а при критической важности — ещё и до его лида. Всё остальное — шум, который приучает людей оповещения игнорировать.
Пересматривайте доступы по расписанию. Раза в месяц достаточно. Проверьте ушедших, сменивших команду, права, выданные «временно» полгода назад, и разрастание числа администраторов. Обзор доступов никогда не кажется срочным, и ровно поэтому ему нужна дата, а не намерение.
Выдавайте минимум, потом чините жалобами. Начать со строгого и ослаблять по запросу даёт более плотное итоговое состояние, чем начать со свободного и пытаться отобрать. Заодно это показывает, что людям действительно нужно, а не что им кажется нужным.
Возражение, на которое стоит ответить
«Это нас тормозит». Иногда тормозит — немного, в первый день. Убирает оно больше: пятнадцать минут, которые байер каждое утро тратит на фильтрацию до своих аккаунтов, совещание по восстановлению того, кто что изменил, лихорадочную смену паролей после чьего-то ухода и хвостовой риск того, что один утёкший логин достаёт до всего.
Ожесточённее всего сопротивляются RBAC обычно те команды, которые выросли настолько быстро, что все ещё помнят времена, когда всем управляли трое. Эта память и есть проблема. Модель доступов, рабочая для трёх человек, для тридцати уже откровенно опасна, и переход обходится значительно дешевле до инцидента, чем после.
AdsTracker поддерживает три из этих ролей напрямую — администратор организации, тимлид и байер — с группировкой аккаунтов по байерам и маршрутизацией оповещений владельцу аккаунта; финансовая функция здесь скорее отчётный срез, чем четвёртый логин. Доступы Google система не хранит и в аккаунт не заходит, а каждое изменение выполняет ваш собственный скрипт в пределах, которые задали вы, — так что доступ на чтение можно раздавать свободно, не превращая систему в путь к случайным изменениям в кампаниях.