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

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

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

Первый пример, где принципы сработали, — performance-маркетинг на контексте. Владелец продукта приходит к контекст-специалисту: нужно пять тысяч новых пользователей, вот бюджет. Специалист берёт семантическое ядро и заводит кампании в Яндекс.Директе и Google AdWords; чтобы понять, что сработало, приходится самим писать интеграции с API Яндекса и Google и забирать статистику по кампаниям, их параметрам и потраченному бюджету. Данные ложатся в базу, аналитик строит витрины, специалист смотрит отчёты — цикл замкнулся. Абстракция подсказала разделить систему надвое: сбор данных из внешних источников, включая Wordstat, и управление кампаниями — кластеризация семантики, помощь в создании объявлений, собственное управление ставками вместо внешнего движка. Отсюда выросли две команды без общего решения, которого никто не просил, и намеренно на разных стеках: интеграции на Python с очередью задач, админки на React и Material UI, а отчётность оставили в Metabase, пока не упрутся в его пределы.

Второй пример — публичный frontend tinkoff.ru, главный канал общения с теми, кто ещё не стал клиентом; заказчики изменений — все бизнес-юниты банка. Сайт делится на личный кабинет и неавторизованную часть, и именно вторая работает на привлечение, поэтому её решили делать тонкой: минимум логики, разбиение по продуктам, максимум общего инструментария. Логика уезжает в бэкенд, который когда-то был монолитом, а потом разъехался на сервисы в контейнерах. Фронтенд свёлся к трём вещам: движку страниц, рендерящему приходящую с бэкенда конфигурацию, библиотеке трекинга, которая видит клики и скорость заполнения полей, и движку форм с описанием структуры, полей и DSL взаимодействий. К такой структуре шли около двух лет: продуктовые команды со своими владельцами и core-команда с архитектором, отвечающая за три движка. Отвечая на вопрос из зала, Александр уточнил: core начиналась как исследование, но выпустила прототип формы на порядок быстрее прежней, а затем документацию, внутренние библиотеки и релизный процесс с прогоном тестов зависимых команд.

Два примера, где принципами пришлось поступиться, устроены по-разному. В SEO рвётся обратная связь: между правкой контента и позицией в выдаче проходит неделя и больше, устройство поисковика непрозрачно — упали то ли из-за неверно прочитанного алгоритма, то ли из-за слабой технической реализации, — а запросы SEO-специалиста, вроде микроразметки или единой страницы вместо продуктовой и рекламной ради поведенческих факторов, идут сквозняком через backend и frontend, и отдельной архитектуры под них не построить. Персонализация и тесты ломают другие принципы: их гоняют на всей аудитории с множеством вариантов, то есть это highload; в основании лежит статистика с доверительными интервалами, критериями остановки и прилипанием вариантов, которую разработчику трудно перевести в код; логов рождается столько, что их отправляют в Kafka и лямбда-архитектуру с real-time-статистикой на Scala и Cassandra. Рядом с рекламной DSP живёт почти такая же система контент-персонализации — прямое нарушение бритвы Оккама, а людей, способных писать такие системы, в разы меньше, чем самих систем.

Вывод Александра: принципы работают, но внутри проектного треугольника времени, денег и объёма — деньги здесь редко блокер, а сроки и объём давят всегда, и когда нельзя сказать «нет», сознательно берёшь кредит, который становится техническим долгом. Долг растёт, и однажды его уже не выплатить: приходит вторая версия системы, потом третья, и всё это с обратной совместимостью. Гасить долг лучше параллельно: монолитный backend переписывали около полутора лет, отпиливая сервис за сервисом, пока этой осенью в монолите не остался один микросервис. На вопросы из зала Александр ответил, что разработку фич при этом не останавливают — расширяют команду, а руководителю объясняют рост стоимости изменений на пальцах: то, что делалось за час, начнёт делаться за день, дальше нелинейно. Новое решение проверяют сплит-тестом и сквозной воронкой: важна не форма, а активированная карта, и бывает, что вариант режет конверсию на втором шаге, но доводит до конца лучше.