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

Полтора года назад я работал в B2C-продукте с командой около 150 человек. Маркетинг хотел запускать промо на сайте: баннеры, акции, сезонные кампании. Простая задача, на которую у нас ушло два с половиной года и шесть разных решений.

Эта статья про путь, который мы прошли. И про то, что я обнаружил, когда поговорил с другой командой внутри той же компании.

Шесть шагов

Шаг 1. Фриланс-вёрстка

Старт был очевидным. Дизайнер рисует баннер в Figma, мы отдаём вёрстку на фриланс. Тысяча рублей за баннер, шесть часов на работу, ещё день на ревью и доработку. Если что-то нужно было поправить через неделю, снова к фрилансеру, снова шесть часов, снова тысяча рублей.

Скорость 5–20 баннеров в месяц. Стоимость терпимая. Контроль нулевой, каждое изменение проходило через цепочку из трёх человек.

Через какое-то время стало понятно, что фриланс это плохая абстракция. Половина задач сводилась к «поменяй текст на этом баннере» или «сделай такой же, но с другим товаром». Платить за это 1000 рублей и ждать день было дорого и медленно.

Шаг 2. Я перевожу баннеры в React

Дальше я начал верстать промо-блоки сам, как React-компоненты внутри основного приложения. Это сократило время до 2–5 часов на баннер, убрало стоимость фриланса и дало нам гибкость. Баннер мог реагировать на состояние пользователя, подтягивать данные из API, делать что угодно, что умеет React.

Появилась новая проблема. Bottleneck переехал ко мне. Маркетинг занял очередь в моём календаре, и если у меня был релиз, баннер ждал неделю. Иногда две. Я был фрилансером, которого нельзя уволить.

Шаг 3. Простыня инпутов

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

Это было счастье. Две недели.

Шаг 4. Request creep

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

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

Стало понятно, что проблема не в количестве полей. Проблема в том, что мы пытаемся имитировать редактор через форму.

Шаг 5. Первый редактор

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

Шесть месяцев счастья. Дальше начались запросы вида «а нам для этой кампании нужен совсем другой layout, можно мы сами сверстаем?».

Шаг 6. Полноценный конструктор

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

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

Каждый из шести шагов я делал в свободные часы между основными задачами. И где‑то на шестом шаге я понял странную вещь.

Я построил платформу. Никто не садился и не говорил «давайте построим платформу для маркетинговых баннеров». Каждый шаг был рациональным ответом на конкретный pain. Платформа конденсировалась сама, через серию разумных решений.

И потом я узнал, что другая команда внутри той же компании прошла те же шаги. Они сейчас на шаге 2. Они не знают про мой редактор. Я не знал про их простыню инпутов до прошлого месяца.

Когда я начал спрашивать у фаундеров и CTO из других компаний, оказалось, что это не баг моей компании. Это паттерн.

Я не один

Ядумал, что это история моей компании. Локальная странность, которая выросла из конкретных людей и конкретных решений.

Потом я поговорил с коллегами из другой команды внутри той же компании. Они делают другой продукт. Другая аудитория, другой стек, другая growth‑команда. Я спросил, как у них устроена работа с промо‑блоками.

Они сейчас на шаге 2.

Кто‑то из инженеров переводит маркетинговые баннеры в React‑компоненты. Они обсуждают, не стоит ли сделать админку с шаблонами. Они не знают, что в соседнем кабинете я три года назад начал точно тот же путь и сейчас закрываю шестой шаг.

Они не искали готовое решение в моей команде. Я не предлагал. Не потому что мы плохо общаемся, мы общаемся нормально. Просто никто из нас не описывает эту работу одним словом, по которому можно было бы найти друг друга. В моём Notion это «редактор промо». В их Notion «админка баннеров». В Confluence одной команды «landing‑конструктор», другой «промо‑страницы». Один и тот же продукт под четырьмя именами не находится поиском.

Дальше я начал расспрашивать инженеров и CTO из других компаний. Не интервью, обычные разговоры в Telegram‑чатах, на митапах, в личных переписках. И в этих разговорах узнавался один и тот же сюжет в разных вариациях. Кто‑то на втором шаге, кто‑то на четвёртом, кто‑то застрял между третьим и пятым уже два года. Истории отличались по индустрии и масштабу, но геометрия пути совпадала.

Это не одна моя компания. Это воспроизводимая последовательность.

Самый явный публичный пример это статья Точка Банка на Хабре. Они описывают собственный визуальный конструктор страниц, который оформили как npm-пакет внутри своего стека. Цитата оттуда:

«Несколько недель работы с участием редактора, дизайнера, разработчика, тестировщика, верстальщика».

Это про одну SEO-страницу. У них таких страниц нужно было больше ста.

Я не знаю, что Точка пробовала до того, как построила своё, и какие конкретно требования у них не закрыли существующие инструменты. Но конечная точка пути узнаваема. Команда внутри крупной компании пришла к тому же решению, что и я: построить визуальный редактор изнутри. По сути они закрыли шаги с первого по шестой одной инженерной задачей.

Паттерн международный.

Tripadvisor публично описывал собственный инструмент под кодовым именем Baldur, конструктор страниц для не-инженеров, построенный изнутри. Naukri (крупный индийский HR-портал) держит собственную inhouse-CMS, потому что готовые headless-решения не закрывали их workflow. На Hacker News регулярно всплывают треды формата «we built our own page builder», в которых инженеры в комментариях узнают себя.

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

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

И вот тут возникает второй вопрос, более интересный, чем первый. Почему так происходит? Почему этот паттерн воспроизводится в каждом B2C-продукте, который растёт мимо 50 человек?

Анатомия паттерна

Если паттерн воспроизводится в десятках компаний независимо, у этого есть структурные причины. Я вижу три.

Причина первая. Каждый шаг рационален в моменте

Никто не садится утром на стендап и не говорит: «Давайте построим платформу для маркетинговых баннеров». Это был бы абсурд. У вас в бэклоге шестьдесят задач, маркетингу нужен баннер к среде, у инженерии релиз в пятницу. На разговор о платформе нет ни времени, ни мотивации.

Вместо этого каждое следующее решение выглядит как небольшой шаг вперёд. Фриланс дорог, переведём в React. React-баннеры держат меня в bottleneck, сделаем простыню инпутов. Простыня раздувается, построим редактор. Редактор слишком жёсткий, добавим произвольные шаблоны.

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

И только когда вы оборачиваетесь на пройденные шаги, видно, что в сумме вы построили платформу. Это называется request creep. Продукт конденсируется из последовательности разумных запросов, ни один из которых не был оформлен как «построить продукт». Это как варить лягушку: каждый градус выглядит как маленький, а в итоге у вас в кастрюле архитектура.

Причина вторая. У проблемы нет общего имени

Маркетинг называет эту работу «промо-баннеры». Продукт «онбординг-модалки» или «in-app messaging». Growth-команда «experimentation surface» или «эксперименты на главной». Дизайн «промо-композиции». Каждая роль использует свой термин, и этот термин описывает видимую ей часть слона.

Поэтому когда инженер в одной команде ищет в Confluence «как у нас устроены админки баннеров», он не находит документ из соседней команды, который называется «landing-конструктор». Поэтому когда фаундер спрашивает: «У нас же где-то это уже было решено?», ответ часто такой: «Да, кажется, было, но я не помню, как они это называли».

Причина третья. Существующие категории инструментов промахиваются мимо

На рынке полно инструментов, которые выглядят как ответ, но при ближайшем рассмотрении закрывают соседнюю проблему.

Tilda решает лендинги, отдельный сайт рядом с продуктом. Mindbox решает CDP и омниканальную коммуникацию: email, SMS, push, программа лояльности. VWO решает A/B-тестирование, но требует, чтобы у вас уже было что тестировать. Plasmic и Builder.io решают Figma-to-code, ускоряют разработку, но не отдают контроль маркетингу. PostHog и Statsig решают experimentation для инженеров, там без SQL запустить тест нельзя.

Каждый из этих инструментов хорош в своей категории. Но категория, которую я описал в шести шагах — место в продукте, которое маркетинг контролирует напрямую — между этими инструментами проваливается.

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

Прежде чем дать этой работе имя, посмотрим, что предлагает рынок прямо сейчас. Не одной строкой, как я сделал выше, а с честным разбором. Что каждый инструмент решает, что не решает, и когда он правильный выбор.

Карта существующих инструментов

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

Для каждой категории три вопроса. Что она решает, что не решает применительно к работе из шести шагов, и когда это правильный выбор. Последнее особенно важно. Многие из этих инструментов хороши в своей нише; претензия не к ним, а к попытке использовать их для соседней задачи.

Это таблица из категории «полезно один раз посмотреть и не возвращаться». Чтобы она не осталась поверхностной, пройду по каждой строке коротко.

Tilda и Webflow делают то, для чего их строили: публикацию страниц без участия разработчика. Они блестящи для marketing-сайта, портфолио, продающих лендингов. Но если ваш продукт это мобильное приложение или сложное веб-приложение со своим стеком, Tilda стоит снаружи и стучится в дверь. Она не сможет показать акцию пользователю, который уже авторизован в вашем приложении, на основе его поведения. Лендинг живёт рядом с продуктом, не внутри него. Это другой класс задач.

Yandex Varioqub бесплатный и привязан к Метрике, поэтому в РФ это часто первый инструмент, который команда пробует. У него есть фундаментальное ограничение. Он работает через CSS-injection по селекторам элементов. Если у вас SPA, и React перерисовывает DOM, изменения Varioqub пропадают. Если дизайнер поменял разметку, селектор больше не работает, тест ломается без явной ошибки. Для статичного сайта на jQuery это нормально. Для современного фронтенда это как клеить обои в комнате, в которой переставляют мебель каждое утро.

Mindbox мощный российский CDP. Если вам нужна программа лояльности, omnichannel-коммуникация, RFM-сегментация, триггерные email, Mindbox закрывает это серьёзнее большинства международных аналогов. Но это не про UI внутри продукта. Mindbox показывает попап через свой виджет, это работает, но это их виджет, их UI-движок, их ограничения композиции. Брендбук заканчивается там, где начинается виджет.

VWO, AB Tasty, Optimizely это enterprise-категория CRO. Они закрывают experimentation на серьёзном уровне: статистическая корректность, multivariate, segmentation. Цена входа от $30K в год, реальный медианный ACV (annual contract value) для AB Tasty по публичным данным $66K. Плюс санкции для РФ. Плюс цикл интеграции в несколько недель на onboarding. Это правильный выбор для mid-market команды, у которой experimentation уже процесс, а не «попробуем как-нибудь». До этого момента преждевременная инвестиция.

Plasmic и Builder.io — самая близкая к моим шести шагам категория и самая частая ошибка в выборе. Они оба декларируют, что отдают контроль не-инженерам, но реальная их сила в Figma-to-code. На выходе код, который инженер всё равно должен забрать к себе в репозиторий, проревьюить, собрать и задеплоить. Это ускорение разработки, не разгрузка инженерии от маркетинга. Разница принципиальная. Ускоренная разработка всё ещё идёт через инженеров. Разгрузка означает, что инженер узнаёт о новом баннере одновременно с пользователем, и это нормально.

PostHog, Statsig, GrowthBook для product engineering. PostHog лучший дев-инструмент в категории, $57M ARR, всё прекрасно. Но запустить там A/B-тест без feature flag в коде нельзя. Без SQL-запроса посмотреть результат сложно. Это инструмент, в котором маркетолог чувствует себя гостем в чужой системе. Что нормально, он не для него.

Inhouse-конструктор это то, что построили мы у себя, Точка Банк, Tripadvisor, Naukri и десятки других компаний. Это работает, потому что идеально подогнано под ваш стек, compliance и культуру. Это не работает, потому что один-два инженера навсегда на поддержке. Schema migrations при ребрендинге, browser compatibility при обновлении Chrome, security audit каждый год. Когда строили, это был героический проект и предмет гордости. Через два года это «вон тот легаси, который никто не хочет трогать», и про автора говорят шёпотом. Через три года автор уже работает в другой компании, где строит то же самое заново. Когда правильный выбор, обсудим в следующем разделе.

GTM Custom HTML это silent dominant, как я бы его назвал. Никто не пишет статей про то, что использует Google Tag Manager не как tag manager, а как deployment pipeline для маркетинговых HTML/JS-вставок. Но по моим наблюдениям и публичным гайдам это делают минимум треть e-com-команд в СНГ. Бесплатно, мгновенно, не требует деплоя продукта. Минусы есть. Он ломает Content Security Policy, конфликтует с security audit, и через год там скапливается несколько килобайт JavaScript, который никто не помнит, кто и зачем поставил. Правильный выбор: команда без compliance-блокеров, которой нужно показать акцию завтра.

Между этими восемью категориями есть дыра. Она не маленькая, в неё проваливается работа, которую я описал в шести шагах. И эта дыра это не «недостающая функция в Plasmic» или «дешёвый VWO». Это отдельная категория, у которой пока нет имени. И пока нет имени, каждая команда падает в эту дыру отдельно и в одиночку.

Имя

Мне кажется, у этой работы должно быть имя. Не для красоты, а чтобы команды могли находить друг друга в Confluence.

Когда я думал, как её назвать, я перепробовал несколько вариантов. «In-product builder» звучит технически, но не передаёт, кто владеет этим инструментом. «Marketer CMS» слишком привязано к категории CMS, которая уже занята headless-решениями. «Promo surface» слишком узко, теряются попапы и онбординг-модалки.

Тот вариант, к которому я сейчас прихожу, это marketer surface. Поверхность, которую маркетинг контролирует напрямую, без bottleneck'а на инженерии.

Слово surface здесь важнее, чем marketer. Это не «инструмент для маркетолога», таких десятки. Это место в продукте, выделенное как зона ответственности маркетинга.

Что попадает в marketer surface:

• промо-баннеры на главной и в разделах продукта

• попапы и in-app модалки (акции, опросы, объявления)

• онбординг-флоу маркетинговой стороны (welcome-карусели, hint'ы)

• A/B-тесты этих поверхностей

• таргетинг по гео, устройству, сегменту пользователя

• feature flags для маркетинговых кампаний (не для инженерных релизов)

Что не попадает:

• email, SMS, push, это коммуникационные каналы, их закрывает CDP (Mindbox)

• лендинги и marketing-сайт, это Tilda/Webflow, отдельный домен

• изменения core-продукта, которые требуют инженерной логики, это работа разработки, не маркетинга

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

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

Marketer surface сейчас в той же точке, в которой CDP был в 2013 году. Я могу ошибаться с конкретным названием. Я почти уверен, что у работы должно быть какое-то имя.

Когда строить самим — правильное решение

Я только что предложил термин и описал, что между восемью существующими категориями инструментов есть дыра. По логике следующий шаг это сказать «и поэтому всем нужен новый инструмент». Я этого делать не буду.

Есть три ситуации, в которых inhouse-конструктор это рациональный выбор, и переход на внешний инструмент будет ошибкой.

Ситуация первая. Маленькая команда с редкими запусками.

Если у вас 5–15 человек в инженерии и маркетинг запускает один-два баннера в квартал, любая SaaS-платформа будет overkill. Подписка от $99 в месяц на инструмент, который вы используете шесть раз в год, это $200+ за каждый запущенный баннер. Внутренняя admin-страница на двух React-компонентах решит задачу за неделю работы одного инженера и будет стоить вам ноль в эксплуатации.

Граница здесь не в размере компании, а в частоте запусков. Если маркетинг шипит меньше пяти штук в месяц, экономика внешнего инструмента не складывается. Если больше, складывается, и довольно быстро.

Ситуация вторая. Compliance-блок на third-party SaaS.

Если вы банк, госсектор, healthcare или edtech с данными несовершеннолетних, ваше compliance может запрещать передачу пользовательских данных третьим сторонам. Это не «не любим vendor lock-in», это архитектурное ограничение, прописанное в политике безопасности и проверяемое аудитом.

Никакой внешний инструмент это не лечит. Даже on-premise deployment SaaS-платформы редко закрывает все требования, там остаются вопросы про update channel, telemetry, наследуемые зависимости.

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

Если ваш CISO или DPO говорит «нет внешним инструментам, которые касаются UI пользователя», это конец разговора. Никакая SaaS-платформа этот аргумент не выиграет. Стройте своё.

Ситуация третья. Зрелая платформенная команда и сильная инженерная культура.

Если в вашей компании есть выделенная platform-команда из 5+ инженеров, которая исторически строит инструменты для других команд, и эта культура часть identity компании, переход на внешний инструмент будет восприниматься как поражение, а не как оптимизация.

Это не аргумент про технологию, это аргумент про политику. Я видел несколько компаний, где инженеры построили внутренний tooling настолько хорошо, что использовать чужой инструмент означало бы признать, что часть их работы была лишней. В таких командах внешнее решение не приживётся. Его будут саботировать на ревью, обходить в production, постепенно покрывать тонким слоем wrapper'ов, пока от него не останется ничего, кроме лицензионных платежей.

Если у вас такая культура, не пытайтесь её ломать инструментом. Ломать культуру значительно дороже, чем поддерживать собственный конструктор.

Эти три ситуации покрывают довольно узкий срез, может быть, 20–30% команд, которые я наблюдаю в индустрии. Для остального большинства картина другая. Они не банки и не госсектор, у них нет выделенной platform-команды для поддержки маркетинговых инструментов, и они запускают от пяти до пятидесяти промо в месяц.

Эти команды прямо сейчас находятся на втором, третьем или четвёртом шаге пути, который я описал в начале статьи. Вопрос для них не «строить или не строить», этот вопрос они уже решили строить, потому что других опций не видели. Вопрос для них в том, сколько ещё лет они будут строить, прежде чем поймут, что в соседней команде уже всё построено, а в соседней компании уже всё построено дважды.

И последнее

Если вы дочитали до сих пор, вернитесь мысленно к шести шагам в начале статьи. Полтора года эволюции, шесть итераций инструмента, два с половиной года календарного времени.

Заметили, что во всех шести шагах не было ни одного A/B-теста?

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

А когда инструмент наконец появляется, оказывается, что предыдущие два-три года команда шипила промо вслепую. Без проверки гипотез. На основе мнения того, кто громче в чате.

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

Если эта статья описала что-то, что вы узнали, у меня к вам три просьбы.

Первое. Напишите в комментариях, на каком шаге сейчас ваша команда. Только номер от 1 до 6, или «у нас вообще не было такой проблемы». Я хочу собрать карту по индустриям и через месяц написать вторую статью с результатами.

Второе. Если вам интересен более развёрнутый разговор, у меня есть короткий опрос на 4 минуты, 8 вопросов. Там подробнее: размер команды, тип продукта, сколько разных инструментов делают похожую работу в вашей компании, что болит больше всего. Ответы анонимны, агрегированные результаты я опубликую следующей статьёй.

👉 Пройти опрос

Третье. Если вы готовы 30 минут поговорить голосом, поставьте галочку в опросе. Я разбираюсь с marketer surface как с категорией работы, и мне ценны истории, которые не попадают в публичные статьи. Без продакт-питча, это разговор про ваш опыт, не про мой инструмент.

И спасибо, что дочитали. Двадцать пять тысяч знаков это не маленький запрос на внимание, особенно в индустрии, где у каждого свой шестой шаг прямо сейчас в спринте.