Дирижабль: контроль лигалов в рекламе недвижимости
Кейс

Дирижабль: контроль лигалов в рекламе недвижимости

Мелкий шрифт внизу рекламного баннера — за него прилетает штраф от ФАС. В рекламе недвижимости юридические дисклеймеры зависят от проекта, типа предложения, канала размещения и десятков переменных. Ошибка в одном символе — весь тираж наружки идёт на замену.

Этот кейс — про систему горизонтальной координации между отделами девелопера Дирижабль: юристами, брендменеджерами, маркетологами. У каждого своя зона ответственности, но все работают с одними и теми же данными — лигалами, статусами, рекламными кампаниями по десяткам ЖК.

Про масштаб

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

В процесс вовлечены несколько отделов. Юристы готовят и обновляют дисклеймеры. Брендменеджеры запускают кампании и контролируют размещение. Маркетологи формируют предложения и акции. Каждый работает со своими данными, но результат — один рекламный материал, в котором всё должно быть актуально и согласовано.

Почему руками — опасно

Проблема не в объёме работы. Проблема в том, что между отделами нет горизонтальной связи.

Лигалы меняются постоянно. У каждого ЖК свои дисклеймеры — номер разрешения на строительство, проектная декларация, условия рассрочки или ипотеки. Меняется один параметр — все рекламные материалы, где он фигурирует, нужно обновить. При 30 проектах и 4–5 каналах на каждый — это десятки обновлений за раз.

Отделы работают параллельно, но в разных файлах. Юрист обновил лигал у себя. Брендменеджер взял старую версию из своего документа. Маркетолог запустил акцию, не зная, что условия уже изменились. Без единого источника данных такие рассинхроны неизбежны.

Отследить изменения нечем. Юридический текст обновился — кто-то должен пройти по всем макетам и проверить, везде ли подставлена новая версия. Вручную. При десятках кампаний в разных каналах это нереально.

Наружка — отдельная история. У щитов жёсткие ограничения по длине текста. Дисклеймер, который помещается в контекстную рекламу, может не влезть на щит 3×6. При сокращении иногда терялся юридически значимый фрагмент.

Цена бездействия

Конкретный сценарий. Выходит новое разрешение на строительство по одному из ЖК. Юрист обновляет данные у себя. Но брендменеджер уже отправил макеты с прошлой версией дисклеймера в печать — он просто не знал об изменении. Тираж наружки — несколько десятков щитов. Замена — это деньги, репутация и нервы.

Ещё — акции с ограниченным сроком. Закончилась рассрочка, а в рекламе она всё ещё фигурирует. Покупатель приходит в офис продаж, а ему говорят: «Это уже неактуально».

Что мы построили

Систему горизонтальной связи между отделами — на Google Sheets с Apps Script. Основной учёт и конструирование рекламных кампаний идёт в своих процессах у каждого отдела. А в нашу таблицу выносятся идеи, предварительные согласования и контроль актуальности данных. Все отделы и так работают в таблицах — отдельный инструмент означал бы месяцы обучения и сопротивление.

У каждого отдела — свой лист с нужными ему данными. Пять взаимосвязанных листов:

«Проекты» — база всех ЖК с юридической информацией: разрешения на строительство, проектные декларации, застройщик, адрес. Заполняется юристами.

«Предложения» — рекламные акции: рассрочки, ипотечные программы, скидки. Каждое привязано к проекту и имеет свои юридические условия.

«Конструктор лигалов» — шаблоны для автоматического формирования дисклеймеров. Набор правил: проект + предложение + канал → готовый текст.

«Веб» и «Наружка» — сводные листы для двух категорий рекламы. Ответственный выбирает проект и предложение — система сама подставляет нужный дисклеймер с учётом канала.

Под капотом шесть модулей Apps Script:

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

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

  • Валидация длины. Для наружки критично — система проверяет, что текст укладывается в гайдлайны по длине для конкретного формата.

  • Архивация. Ежемесячная автоматическая архивация с возможностью восстановления. Через полгода можно посмотреть, какие лигалы были актуальны в конкретном месяце.

Что изменилось

Горизонтальная связь между отделами. Юрист обновил данные — брендменеджер видит это сразу, а не через неделю. Все работают с одной таблицей, каждый на своём листе. Вопрос «у кого актуальная версия лигала?» исчез.

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

Изменения не теряются. Раньше юрист обновлял данные у себя, а брендменеджер узнавал об этом через день или неделю — когда макет уже ушёл в печать. Теперь изменился номер проектной декларации — все связанные записи в «Веб» и «Наружке» автоматически получают статус «взять в работу».

Архив. Вопрос «что мы рекламировали в сентябре и с какими условиями?» закрывается за минуту.

Технический стек

КомпонентТехнология
ПлатформаGoogle Apps Script (V8 runtime)
ДанныеGoogle Sheets — 5 взаимосвязанных листов
Генерация текстаШаблонизатор на GAS: проект + предложение + канал → дисклеймер
Отслеживание измененийТеневые копии данных, сравнение при изменении статуса
ВалидацияПроверка длины текста по гайдлайнам формата (веб / наружка)
АрхивацияЕжемесячный автоматический бэкап с возможностью восстановления
flowchart TD A["Юрист\nобновляет данные проекта"] --> B["Лист «Проекты»\nРазрешения, декларации"] C["Маркетолог\nсоздаёт предложение"] --> D["Лист «Предложения»\nАкции, рассрочки"] B --> E["Конструктор лигалов\nШаблоны + правила"] D --> E E --> F["Лист «Веб»\nДисклеймеры для digital"] E --> G["Лист «Наружка»\nДисклеймеры для щитов"] F --> H{"Данные\nизменились?"} G --> H H -->|Да| I["Статус → «взять в работу»\nПодсветка изменений"] H -->|Нет| J["Статус остаётся «готово»"]

Чего не скрываем

Google Sheets — не CRM. При очень большом количестве одновременных кампаний (сотни строк в сводных листах) таблица может замедляться. Для текущего масштаба это не проблема, но при кратном росте может потребоваться миграция.

Шаблоны лигалов надо поддерживать. Конструктор работает по правилам. Появился новый тип предложения или канал размещения — нужно добавить правило. Несложно, но требует понимания логики системы.

Нет связи с дизайнерскими инструментами. Текст дисклеймера генерируется и контролируется. Вставка в макет — пока ручная. Связать таблицу с Figma — можно, но это следующий шаг.

Читайте также


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

С вами была команда GoogleSheets.ru, мы превращаем разрозненные таблицы в управляемые системы.

Не хотите разбираться сами?

Если читали статью и поняли, что руками уже не справляетесь — напишите. Оценим задачу бесплатно и предложим решение.

140+ реализованных проектов
Google Products Expert в команде

Хотите такой же результат?

Расскажите о задаче — предложим решение и покажем релевантные кейсы.

Написать в Telegram

Подписывайтесь — делимся скриптами, кейсами и лайфхаками