Лог действий рекламного аккаунта: аудит для комплаенса в агентстве

Когда регулируемый рекламодатель просит своё агентство «покажите нам каждое изменение в наших кампаниях за последние 90 дней с именем того, кто его внёс», встроенная история изменений внутри Meta или Google не может ответить на этот вопрос. Она истекает слишком быстро, привязывает изменения к доступу уровня аккаунта вместо конкретных людей и не существует как единая запись, когда рекламодатель работает больше чем на одной платформе. Лог действий рекламного аккаунта как сценарий комплаенс-аудита — это то, как агентства, обслуживающие регулируемые отрасли, решают эту задачу: они ведут непрерывную, атрибутированную, доступную для поиска запись, которую можно передать проверяющему по запросу.

В этом гайде разберём, что делает лог действий пригодным для комплаенса, как агентства выстраивают workflow и как выглядит итоговый документ, когда регулируемому клиенту нужно продемонстрировать контроль над своим рекламным аккаунтом.

Почему встроенные истории изменений не закрывают требования комплаенса

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

Срок хранения. Встроенная история изменений Meta доступна 90 дней. История Google Ads хранится дольше, но практический доступ к ней в интерфейсе ограничен. Рекламодателю из финансовых услуг, подпадающему под проверку FCA, могут понадобиться записи за 12-24 месяца. Встроенная история такое окно не покроет.

Привязка к аккаунтам, а не к людям. Если три члена команды агентства имеют доступ к Business Manager клиента в Meta, и один из них меняет ставку в кампании, встроенная история фиксирует изменение под идентичностью Business Manager, а не под именем конкретного человека. По встроенному логу нельзя сказать, кто из команды внёс изменение. Для комплаенс-аудита, где возникает вопрос личной ответственности, это не ответ.

Фрагментация между платформами. У регулируемого рекламодателя, работающего в Meta и Google Ads, история изменений лежит в двух совершенно разных логах — с двумя разными схемами, двумя разными политиками хранения и без возможности увидеть их как единую хронологическую запись. Когда проверяющий просит «все изменения в рекламном аккаунте за третий квартал», ответ предполагает выгрузку из двух мест, нормализацию двух схем и сборку объединённой записи — которую большинству агентств приходится собирать вручную, увеличивая риск ошибки.

Согласно анализу Financial Conduct Authority (FCA) за 2025 год, цифровая реклама регулируемых финансовых фирм вошла в тройку главных категорий комплаенс-нарушений в ежегодном обзоре финансовых промо-материалов в Великобритании — при этом недостаточное ведение записей вокруг изменений кампаний прямо названо способствующим фактором в 31% рассмотренных случаев правоприменения. Регулируемым рекламодателям нужны не только записи о результатах — им нужны записи о процессе.

Что делает лог действий пригодным для комплаенса

Не каждый лог действий годится как аудит-трейл для комплаенса. Различие сводится к трём свойствам.

Привязка к конкретным людям. Лог должен фиксировать не только что изменилось, но и кто это изменил — под реальной именованной идентичностью, а не под общим аккаунтом или групповой ролью. Это требует, чтобы каждый член команды, заходящий в слой управления рекламой, делал это под собственной идентичностью, со своим местом. Общие логины делают комплаенс-документацию невозможной by design.

Неизменяемость. Запись должна отражать то, что реально произошло, а не версию событий, которую кто-то мог задним числом отредактировать. Аудит-трейлы для комплаенса должны генерироваться из системы учёта в момент каждого события, а не реконструироваться постфактум по памяти или заметкам.

Достаточное окно хранения. Лог должен храниться столько, сколько требует комплаенс-обязательство — 12 месяцев это частый минимум для регулируемых финансовых рекламодателей; 24 месяца типичны для фирм, подпадающих под периодическую проверку FCA или SEC. Система должна поддерживать выгрузку и хранение этих записей вне живого дашборда при необходимости.

Лог действий Wevion соответствует всем трём свойствам. Каждое изменение, зафиксированное на платформе, привязано к конкретному члену команды, который его внёс, генерируется из живого события в момент изменения и доступно для хранения в выгрузках за любой диапазон дат в истории подключённого аккаунта. Подключение к рекламным платформам идёт через официальные OAuth-API с синхронизацией примерно каждые 15 минут — это значит, что лог отражает то, что реально произошло в рекламном аккаунте, включая изменения, внесённые вне интерфейса Wevion: они появляются в записи как внешние изменения с соответствующей атрибуцией.

Как агентства выстраивают комплаенс-workflow

Агентства, обслуживающие регулируемых клиентов, обычно встраивают сценарий комплаенса в постоянный workflow из трёх компонентов.

Именованные места как фундамент

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

Для комплаенса это не опция. Это предпосылка. О механике настройки именованных мест с ролевым доступом читайте в нашем гайде про общие логины и сколько они стоят вашему агентству.

Непрерывный лог как операционная запись

Как только именованные места настроены, лог действий строится сам по мере работы команды. Каждый запуск, каждая правка, каждое изменение бюджета, каждая остановка фиксируются в логе с привязкой ко времени, с именем члена команды, который их сделал, с изменённым полем и значениями «до» и «после», где это применимо. Агентству не нужно вести отдельный журнал — лог это побочный продукт работы через платформу.

В этом структурное преимущество единого операционного слоя по сравнению с раздельным использованием платформ. Если команда запускает и ведёт кампании через Wevion, лог автоматически полон. Если команда заходит в Meta, Google и TikTok по отдельности, ей нужно собирать лог из трёх источников — и именно в сборке возникают ошибки и пробелы.

Квартальная выгрузка как итоговый документ

Большинство регулируемых рекламодателей запрашивают документацию по квартальному или годовому графику — часто это запускается комплаенс-проверкой или запросом регулятора, а не конкретным инцидентом. Агентство готовится к этому, устанавливая постоянный протокол квартальной выгрузки: в конце каждого квартала история аккаунта для каждого регулируемого клиента выгружается, фильтруется по нужному аккаунту и диапазону дат и подшивается в защищённую папку клиента.

Формат выгрузки читается как датированная, атрибутированная последовательность событий. Каждая запись в комплаенс-выгрузке обычно включает: дату и время (с точностью до минуты), имя и роль члена команды, затронутые аккаунт и кампанию, тип действия (правка, остановка, запуск, изменение бюджета, событие доступа) и значения «до» и «после» для изменённого поля.

Разбор того, как использовать историю действий для расследования инцидентов — более быстрого и тактического сценария того же лога — смотрите в материале как расследовать изменения в рекламном аккаунте.

Как выглядит итоговый документ комплаенс-аудита

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

Титульная сводка (одна страница):

• Имя клиента и идентификаторы аккаунта
• Охваченные платформы и диапазон дат
• Общее число зафиксированных изменений
• Именованные члены команды с их ролями, кто заходил в аккаунт или изменял его в период
• Сводка по типам изменений (X правок бюджета, Y замен креативов, Z корректировок стратегии ставок и т. д.)
• Любые необычные события доступа (добавлено новое место, изменены права, внешние входы)

Приложение — отфильтрованный лог: Сырой лог, отфильтрованный по периоду, отсортированный хронологически, где каждая запись показывает: время, имя члена команды, тип изменения, затронутые аккаунт/кампанию, значения «до» и «после».

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

Кейс из финансовых услуг: обзор за 90 дней

Паттерн становится конкретным в контексте финансовых услуг. Регулируемый финансовый рекламодатель, ведущий в Meta кампании по пенсионным продуктам, подпадает под надзор FCA за своими цифровыми промо-материалами. FCA может запросить документацию об изменениях кампаний за период проверки — обычно в ответ на жалобу или в рамках планового цикла надзора.

Без лога действий уровня комплаенса варианты у агентства такие: вытащить встроенную историю изменений Meta (истекает на 90 днях, без привязки к людям), реконструировать по памяти и внутренней переписке (недопустимо как комплаенс-запись) или признать, что документацию предоставить невозможно.

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

Кейс не теоретический. Отчёт ISBA о прозрачности агентств за 2025 год (опубликован в январе 2026) показал, что 44% рекламодателей в регулируемых категориях за предыдущие 12 месяцев сталкивались как минимум с одним комплаенс-запросом, связанным с изменениями в цифровой рекламе. Агентства, способные предоставить атрибутированную документацию, закрывали такие запросы в среднем за 3,1 дня; агентства, которые не могли, тратили в среднем 19 дней и чаще получали формальные предупреждения.

Как встроить комплаенс-сценарий в онбординг новых клиентов

Самый эффективный способ это внедрить — не дооснащать систему задним числом, когда приходит аудит, а сделать это стандартным элементом чек-листа онбординга для любого аккаунта в регулируемой категории.

В чек-листе три пункта:

1. Именованные места настроены до начала любой работы — никаких общих логинов, каждый член команды под собственной идентичностью с ограниченной ролью
2. Подключения к платформам авторизованы через официальные API — OAuth-подключение даёт корректную атрибуцию всех изменений, полученных через API
3. Установлена периодичность квартальной выгрузки — постоянная задача в системе управления проектами агентства: выгружать и подшивать лог действий в конце каждого квартала, не дожидаясь комплаенс-события

Это превращает комплаенс-документацию из реактивного аврала в постоянную операционную привычку. Для агентств, ведущих несколько регулируемых клиентов, предельная стоимость каждого дополнительного клиента близка к нулю, как только workflow налажен — один и тот же протокол выгрузки применяется ко всем аккаунтам.

Более широкий взгляд на аудит-трейл в нерегулируемых контекстах — как он работает как инструмент удержания и система внутренней ответственности — смотрите в материале про аудит-трейл клиентского аккаунта в агентстве. Полный плейбук по инструментам для агентств — в кластере инструментов для агентств, где разобран весь операционный стек.

Итог

Регулируемым рекламодателям нужны не просто лучшие результаты кампаний — им нужен доказуемый контроль над своими рекламными операциями. Лог действий рекламного аккаунта, который привязывает каждое изменение к конкретному человеку, хранит историю дольше встроенных 90 дней и охватывает платформы как единую запись, обеспечивает этот контроль в аудируемой форме.

Для агентств построить комплаенс-сценарий поверх лога действий, который они и так уже используют для операционных целей — расследования инцидентов, ответственности команды, коммуникации с клиентом — делает подготовку комплаенс-документа почти бесплатной. Лог работает всегда. Выгрузка занимает минуты. А способность передать проверяющему чистую, атрибутированную запись о том, кто, что, когда и почему изменил, — это та операционная дисциплина, ради которой регулируемые клиенты не уходят.