Привлечение tinkoff.ru

У каждого продукта — карты, страховки, ипотеки или инвестиций — есть план привлечения. Product owner распределяет бюджет между каналами, специалисты запускают кампании, потенциальный клиент попадает на публичную страницу и заполняет форму. Чтобы управлять процессом, нужно без релиза собирать страницы и рекламные лендинги, проводить A/B- и многовариантные тесты, персонализировать контент и отслеживать, где пользователь остановился. Затем онлайн-события объединяются с банковскими данными в сквозной аналитике, и продукт меняет бюджеты, ставки, контент или сам процесс.

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

В performance marketing процесс разделили на сбор данных и управление рекламными кампаниями. Интеграции получали статистику из Яндекса и Google, аналитики строили витрины и отчёты, а отдельный контур помогал работать с семантикой, кластеризацией и ставками. Архитектура подсказала структуру из двух команд, а минимальный стек — Python, Postgres, очередь задач, простой внутренний интерфейс и Metabase — позволил быстро замкнуть обратную связь без собственной тяжёлой BI-платформы.

Публичный frontend Tinkoff.ru стал платформой доставки изменений для всех бизнес-направлений. Продуктовые приложения оставили тонкими: страницы, сценарии и контент конкретного бизнеса строились на общих блоках, формах и трекинге. Общие движки и правила перенесли в backend и reusable-библиотеки. Core-команда отвечала за движок страниц, формы, трекинг, инфраструктуру и контракты, продуктовые команды — за гипотезы, метрики и функциональность своего направления. Core не остался исследовательской группой: вместе с инструментом он создавал документацию, процессы выпуска и способ безопасно обновлять зависимые продукты.

SEO показало ограничение короткого цикла обратной связи. Между изменением страницы и позицией в поиске проходят недели, алгоритмы поисковиков непрозрачны, а запрос специалиста может пересекать сразу frontend и backend. Персонализация и тесты добавили другую сложность: решение принимается на пути каждого пользователя, использует много источников сегментов, требует статистики в реальном времени и создаёт большой поток событий. В результате появились похожие, но не одинаковые системы, сложная data-платформа и незаменимые универсальные специалисты — идеальное отражение архитектуры в командах стало недостижимым.

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