Как практики DevOps могут влиять на продажи и маркетинг

Добрый день. Я Андрей, и я девопс в DevOps-Service. Последние года три я ловлю себя на мысли, что могу точно угадать, когда закроется очередной проект (который, по идее, закрыться вовсе не должен). Команда, процессы — все прекрасно. Продукт имеет право на жизнь, не совсем «ужас-ужас». Но как-то все усилия бизнеса в итоге уходят в песок, с его деньгами и с нервами команды. Можно, конечно, считать, что ты «профессиональный наемник» (а так и есть), и тебе все равно, лишь бы платили. Но иногда наступает момент, когда хочется сказать себе и окружающим, что ты помогал создавать что-то действительно работающее, а не очередного кадавра. Причем в своей стране, что важно.

Поэтому давайте поговорим про локальный продукт.

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

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

В этой статье я хочу исследовать другую сторону продукта — продажи и маркетинг. Посмотрим на маркетинговые бизнес-метрики и на то, как мы, «айтишники» (DevOps, в частности), можем влиять на них.

Иллюстрация Алины Самолюк

«Детские болезни» продуктовой разработки

Почему-то у нас в «продукте» плохо считают. Вначале вообще ничего не считают. Когда начинают — считают не то, что надо, не тогда, когда надо, и когда уже не надо. Это очень обидно, особенно когда «играют на свои».

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

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

Не совсем «айтишный» пример из своей молодости. В Киеве в двухтысячные, когда везде был тотальный «купи/продай», на рынке систем видеонаблюдения появился сильный игрок. Появился довольно интересным образом — компания хотела «заниматься компьютерами», нашла в Германии поставщика, заказала контейнер с комплектующими. Немцы ошиблись — в контейнере оказались камеры видеонаблюдения и прочие сопутствующие товары. Договорились, что возвращать не будут, попробуют продать. И продали — быстро и с прибылью намного большей, чем ожидали от «компьютерного» бизнеса. «И завертелось».

Бизнес не обращает внимания на свое «здоровье». Ну, появилось легкое недомогание: отток подписчиков/клиентов, плохая вовлеченность пользователей, небольшое падение новых регистраций на сервисе... Ну ведь клиенты есть, деньги платят, «мы смогли», «стакан наполовину полон»... «Недомогание» — это то, что просто вышло наружу «организма». На самом деле, это, скорее всего, болезнь, которая уже подкосила бизнес, и надо принимать срочные меры. И это не только про ИТ.

Что мы имеем в 97% (сакральное число «умирающих» в первый год стартапов) случаев:

1. О вашем продукте не знают.
2. Если о вашем продукте знают, то не понимают, чем он отличается от конкурентов.
3. Если увидели отличия от конкурентов, то не пользуются всеми возможностями.
4. Если не пользуются всеми возможностями, то сидят на бесплатных аккаунтах/версиях, триалах, не платят и не собираются платить.
5. Если за продукт не платят — то...

Зачем вообще «технарям» надо знать об этих метриках? У них другая работа.

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

Маркетинговые и бизнес-метрики

Их вообще очень много для разных типов бизнеса, маркетинговой активности и т.д. Ниже приведены основные.

Важно! Эти метрики больше подходят к массовому B2C-сегменту. В B2B, где «длинные» сделки, проектные работы по внедрению ERP, CRM, заказная разработка и т.д., совсем другой маркетинг и метрики. Также заранее прошу прощения у профессиональных маркетологов — это попытка «технаря» разобраться в вопросе.

Метрика САС (Customer Acquisition Cost) — стоимость привлечения клиента. Синоним UAC (User Acquisition Cost) — стоимость нового пользователя. Считается за определенный период времени и для конкретной рекламной активности (лендинги, объявления, блоги, «попандеры», «кликандеры» и т.д.).

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

Показывает эффективность привлечения клиентов (рекомендуют считать только платящих клиентов) с помощью рекламных кампаний, каналов. Правда, не во всех случаях можно установить четкую связь между рекламной активностью и новым клиентом. Такой случай хорошо иллюстрирует контент-маркетинг. Статья может «выстрелить» и через год после публикации.

Рассчитывается по формуле: CAC=MCC/CA, где:

MCC — суммарная стоимость маркетинговых затрат, направленных на привлечение клиентов;

CA — суммарное количество привлеченных клиентов.

Вроде, ничего сложного, кроме того, что включать в MCC и как улучшить показатели.

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

CPM (Cost Per Millenium) — цена за тысячу показов коммерческой рекламы. Как правило, если не продумана стратегия (лендинги, A/B-тестирование, рекламные площадки), то это простое сжигание денег.

CPC (Cost per Click) — стоимость/цена за клик по объявлению или баннеру. Классический Google Adwords, который обычно хорошо работает, если он грамотно сделан, но есть опасность сlick fraud.

CPA (Cost Per Action) — оплата за определенное действие. Уже намного интереснее, может появиться вполне ощутимый результат. Существует целое направление — CPA-маркетинг, или «партнерский маркетинг», когда компания доверяет продвижение своего продукта партнеру. Если партнер привел пользователя, а тот совершил целевое действие, то партнер получает вознаграждение.

Один мой друг и учитель как-то начал создавать свой продукт. Дела шли не очень, а деньги надо было вкладывать в команду и инфраструктуру постоянно. Спустя какое-то время он попробовал поработать с сервисом (это не реклама) AppSumo, на котором продал много подписок с большой скидкой. В итоге он получил много регистраций и какой-то cash flow для дальнейшей работы. Поскольку новые клиенты были достаточно активными (хоть и со скидкой, но продукт они купили) и вредными, также фоном он получил еще и неявные выгоды в виде базы для маркетинга и обратной связи, востребованности новых фич, надежности инфраструктуры. Более полная история — здесь.

В CPA-маркетинге также есть свои подметрики:

• CPS (Cost per Sale) — оплата за продажу
• CPL (Cost per Lead) — оплата за лид
• CPO (Cost per Order) — оплата за заказ
• CPI (Cost per Install) — оплата за установку

Общие маркетинговые затраты, которые плюсуются один раз за расчетный период:

• зарплаты маркетологов
• оплата сторонних подрядчиков, если в штате нет своих
• инфраструктура и софт для маркетинга и рекламных кампаний

Стоимость инфраструктуры и поддержки для показов рекламы (плюсуются один раз за расчетный период):

• хостинг и поддержка инфраструктуры
• инструменты A/B-тестирования
• время разработчиков основной команды, если они привлекались для маркетинговых активностей

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

Метрика CRR (Customer Retention Rate) — коэффициент удержания клиентов. Известно, что привлечь нового клиента в несколько раз дороже и сложнее, чем удержать старого. Ключевое слово — «удержать».

Рассчитывается по формуле: CRR=(CE-CN) /CS*100%, где:

CE — суммарное количество клиентов на конец изучаемого интервала времени

CN — количество пришедших клиентов за период измерения

CS — количество клиентов в начале изучаемого интервала времени

Пример. Считаем за квартал. На начало квартала у сервиса было 1300 зарегистрированных пользователей. К концу квартала пришли еще 150 клиентов, но 350 клиентов удалили свои профили на сервисе.

CE: 1300+150-350=1100

CN: 150

CS: 1300

CRR: (1100-150) /1500*100%=63%

За квартал коэффициент удержания клиентов — 63%. Потом бизнес сравнивает данные по CRR за более ранние периоды и делает выводы.

«Удержание» — понятие несколько размытое. В разных ситуациях и сервисах «постоянный» клиент может вести себя по-разному.

Какие есть метрики «постоянства» клиентов

Метрика Repeat Customer Rate (RCR) — количество покупателей в процентном соотношении, сделавших повторную покупку за период времени.

Рассчитывается по формуле: RCR=RC/TC*100%, где:

RC — количество клиентов, совершивших повторные покупки за указанный период времени

TC — общее количество клиентов

Метрика Repeat Purchase Rate (RPR) — коэффициент повторных покупок: сколько покупателей совершили две и больше покупок, в процентном эквиваленте за указанный период времени. Используется для начисления скидок или предоставления льготных периодов подписки.

Вычисляется по формуле: RPR=RC2/RC1*100%, где:

RC2 — количество клиентов, которые сделали две и более покупок (или другое число в зависимости от типа бизнеса и задач расчета)

RC1 — количество клиентов, которые сделали одну покупку

Может показаться, что Repeat Customer Rate (RCR) и Repeat Purchase Rate (RPR) — это две одинаковые метрики, но это заблуждение. Repeat Customer Rate (RCR) показывают «молодых» клиентов, которые только начали пользоваться продуктом. Вероятность повторных покупок — как «встретить динозавра на улице — 50/50: могу встретить, могу не встретить». Repeat Purchase Rate (RPR) — это уже «сформировавшийся» клиент, который, возможно, заслужил поощрение в виде скидок. Естественно, в зависимости от периода измерений клиенты могут кочевать из категории «молодых» в категорию «сформировавшихся», и наоборот.

Метрика Redemption Rate (RR) — коэффициент использования вознаграждения (еще используется термин «коэффициент погашения»). Своего рода эффективность метрики Repeat Purchase Rate (RPR) — коэффициент повторных покупок. Компания предлагает лояльным пользователям «плюшки», которые они могут использовать, чтобы продолжать активно использовать продукт. Для бизнеса такие «подарки» — это, по сути, издержки и потери. Метрика коэффициент использования вознаграждения (RR) показывает нам целесообразность дальнейшей «раздачи подарков».

Считается по формуле за период: RR=PS/PU*100%, где:

PS — использованные бонусы

PU — начисленные бонусы

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

Метрика Net Promoter Score (NPS) — оценка рекомендателей. Измеряется с помощью опросов клиентов. Самый простой способ выяснить популярность продукта или его «фич». Полезна тем, что показывает точный интерес клиентов к продукту. Пусть даже это будет и отрицательное отношение, но если человек тратит время на опросы, значит, продукт ему небезразличен. Из этих пользователей потом можно составлять разные фокус-группы для тестирования новых «фич».

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

Считается по формуле: NPS=PN/PA*100%, где:

PN — количество «негативных» ответов участников

PA — общее количество участников

Метрика Customer Churn Rate (CCR) — коэффициент оттока клиентов за конкретный промежуток времени. Один из важнейших показателей успешности бизнеса. Очень хорошо подходит для SaaS-продуктов.

Считается по формуле: CCR=(CB-CE) /CB*100%, где:

CB — количество клиентов на начало периода

CE — количество клиентов на конец периода

Большой коэффициент оттока пользователей или динамику его увеличения маркетологи могут ехидно демонстрировать «технарям», поскольку пользователи уходят с продукта. Естественно, в этом не только их вина, но часто львиная доля оттока происходит как раз из-за технических факторов — доступности сервиса, UX/UI. Маркетологи свою задачу выполнили, привели зарегистрированного пользователя, а дальше уже «продукт продает сам себя».

Очень важные метрики

Метрика Customer Lifetime Value (CLTV) — пожизненная ценность клиента. Также называется LTV, CLV. Означает прибыль, которую компания получила от клиента за все время работы с ним. Иногда еще называют «качеством клиента». Подходит для корректировки продукта, ассортимента и маркетинговой политики. Один из показателей для расчета возврата инвестиций (ROI). Есть несколько формул для расчета. Они подробно описаны в этом материале.

Возьмем самую простую формулу для ознакомления: CLTV=IC-CAC, где:

IC — доход от одного клиента

CAC — стоимость привлечения клиента (помните?)

Метрика CLTV, на самом деле, огромная тема для изучения. И большинство инвесторов очень хотят знать эту метрику.

Метрика Return on Investment (ROI) — показатель возврата инвестиций (еще могут называть прибыль на инвестированный капитал, прибыль на инвестиции, возврат, доходность инвестированного капитала, норма доходности). Глобальный показатель, который может охватывать как весь бизнес в целом по всем параметрам учета — управленческого, бухгалтерского; так и отдельные бизнес-направления или бизнес-операции. Поскольку мы сейчас в основном описываем метрики маркетинга, то будет рассматривать ROI в этом ключе.

Для расчета эффективности маркетинга ROI можно разделить на две метрики ROMI — это показатель окупаемости инвестиций в маркетинг, ROAS — показатель рентабельности расходов на рекламу.

Метрика Return on Ad Spend (ROAS) — показатель рентабельности расходов на рекламном канале за период в процентах.

Вычисляется по формуле: ROAS=AD/AC*100%, где:

AD — доход от рекламы

AC — затраты на рекламу

Показывает эффективность работы конкретного рекламного канала.

Метрика Return On Marketing Investment (ROMI) — показатель окупаемости инвестиций в маркетинг. Измеряется общая эффективность маркетинга.

Вычисляется по формуле: ROMI=(AD-AC) /AC*100%, где:

AD — доход от рекламы

AC — затраты на рекламу

Результат менее 100% должен настораживать.

Самые главные метрики используются в основном для SaaS-сервисов.

Метрика Average Revenue Per User (ARPU) — средний доход на пользователя за период. Показывает финансовую эффективность сервиса. Период, как правило, берется в один месяц.

Считается по формуле: ARPU=MR/MU, где:

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

MU — общее количество пользователей за период. Всех пользователей, которые сидят на бесплатных и на платных аккаунтах

Метрика Average Revenue Per Paying User (ARPPU) — средний доход на одного платящего пользователя за период. Это и есть самый интересный показатель, он показывает, «дышит» вообще бизнес или нет.

Считается по формуле: ARPPU = MR/MPU, где:

MR — общий доход за период

MPU — количество платящих пользователей за период

Метрика Monthly Recurring Revenue (MRR) — регулярная месячная выручка, которая приведена к усредненному месячному значению. Рассматривается в динамике. Самый важный показатель для инвесторов.

Его величина в сфере вашего продукта показывает, будет ли вообще инвестор встречаться с вами или попросит перезвонить, когда ваш MRR достигнет общепринятой для типа продукта величины.

Считается по формуле: MRR=MU*ARPU, где:

MU — общее количество пользователей за период

ARPU — средний доход на пользователя за период

Метрика Annual Recurring Revenue (ARR) — годовой регулярный доход.

Считается по формуле: ARR=MRR*12, где:

MRR — регулярная месячная выручка

Это «венец» всех вышеперечисленных метрик. Не все стартапы смогут его просчитать, поскольку до константы «12» в формуле они могут не дожить.

Неутешительные, но честные выводы

1. Рынку все равно, какая у вас идея — идея ничего не стоит. Тут с идеей каждый первый, а с интересной идеей — каждый четвертый. Покажите воплощение вашей идеи или MVP.
2. Рынку все равно, какие у вас софтскиллы — какая у вас чудесная и дружная команда, как у вас «горят глаза» и как вы готовы вкалывать. Покажите RPR (коэффициент повторных покупок) и CCR (коэффициент оттока клиентов).
3. Рынку все равно, какие у вас хардскиллы — какая у вас стройная архитектура, сколько «сеньоров» в команде, как все всё рефакторят, покрывают код тестами, как всё отказоустойчиво и всё «летает». Покажите NPS (оценку рекомендателей).
4. Рынку все равно, что у вас есть продукт или прототип, какой он «убийца» кого-то, если у этого «кого-то» уже есть ARR, средний по его классу продуктов. В подавляющем большинстве случаев инвестор вложит деньги в этого «кого-то».
5. Рынку все равно, что у вашего продукта есть пользователи, и они даже платят или покупают. Пользователи — самые неблагодарные, капризные и непостоянные существа во вселенной. «Покажите свой ARPPU... мы с вами свяжемся».

Естественно, все не так плохо, рынок есть, продукты появляются. Цель статьи — не напугать или испортить настроение. Цель — показать «технарям», что иногда надо смотреть по сторонам и понимать, что продукт — это не только код. И таким, каким он задумывался на старте, он не будет. Маркетологи и «продажники», которые «выхватывают» вас из потока — это не надоедливые местные «непонятные люди», которые плохо продают продукт — это ваши напарники и партнеры.

Я догадываюсь, что «технари», которые дочитали до этого места, в очередной раз задают вопрос: «А мы тут при чем?»

Как можно повлиять на все это «безобразие»

Я как DevOps обязан думать про time to market, поэтому есть несколько идей. Направление маркетинга можно сделать внутренним ИТ-проектом. Обязательно со стадией исследования. Иначе вероятны статьи из серии «Как мы потеряли 100К долларов и полностью перезапустили отдел маркетинга». На выходе, в виде MVP, должен получиться тоже своего рода продукт в виде инструментов, инструкций и процессов, которые умеют:

• искать и привлекать клиентов
• просчитывать клиентов
• удерживать клиентов
• быть максимально автономными
• быть гибкими и масштабируемыми
• минимально мешать процессу разработки

Что это значит для маркетинговых метрик? Это значит, что мы уменьшаем метрику САС (Customer Acquisition Cost) — стоимость привлечения клиента. На начальном этапе такого проекта мы ее, конечно, сильно увеличим, поскольку будем включать в MCC (суммарная стоимость маркетинговых затрат на инфраструктуру и работы над этим проектом). Но на выходе у нас появятся прогнозируемые и минимальные затраты на будущие расчетные периоды.

Стадия исследования

Скорее всего, маркетологи будут хотеть нашу куртку и мотоцикл УТП (Уникальное Торговое Предложение), сквозную аналитику, CRM, с которой они умеют работать, и бюджеты на продвижение. В большинстве случаев им больше ничего не надо. Но у нас ИТ-продукт, который будет развиваться всю свою, надеюсь, долгую жизнь. Поэтому логично собрать требования и вопросы от «технарей»:

1. Как будут отслеживаться пути привлечения, какая будет нотация UTM-меток, как мы будем потом сегментировать новых клиентов, что надо иметь в нашей базе на эту тему, в каком виде вы хотите получать информацию (на email в виде xls, самостоятельные запросы к базе, только чтение или вы хотите вносить изменения в «свои» данные клиента в базе), визуализация — да/нет?
2. Какие свойства в профиле клиента на сервисе надо добавлять для дальнейшей работы с ним и по каким параметрам мы будем обсчитывать продуктовые метрики (вовлеченность, удовлетворенность и т.д.)? Надо ли нам подключать Hotjar или аналоги в кабинет клиента в сервисе? Что еще вам надо будет от профиля клиента, какие поля мы должны предусмотреть в базе? Или, может, вы уже решили использовать Amplitude или аналоги, и нам надо просто подключить их к проекту.
3. Дальнейшие маркетинговые взаимодействия (рассылки, чаты, смс) будем делать с помощью сторонних сервисов или надо делать в «админке» сервиса отдельную роль «маркетолог» и интегрировать все эти инструменты для него? Если будут сторонние сервисы, то как вы хотите получать данные для работы с ними (см. вопрос № 1)? Надо ли для вычисления метрики Net Promoter Score (NPS, оценка рекомендателей) предусмотреть для вас самостоятельный инструмент и функционал для создания опросов, после того как пользователь вошел в сервис?
4. С какими элементами фронтэнда сервиса вы хотите самостоятельно работать (слайдеры, CTA-блоки), как часто это планируется делать? Кто будет это делать — маркетинг/разработчики, если маркетинг, то каким вы видите функционал и как срочно он вам нужен?
5. Лендинги — вам настроить инструментарий и научить им пользоваться, или вы будете заказывать разработку у сторонних подрядчиков? Может, будете пользоваться специализированными сервисами?

Как видите, получилось больше про основной продукт, но и ответы на вопросы исследования могут показать, что особо напрягаться не надо: «дайте нам данные по таким-то параметрам в google sheets, а дальше мы сами». Если наоборот — тогда нас ждет ворох виртуалок с «почтовиком», копией базы, Kibana, Grafana и т. д. На данном этапе вопрос может быть закрыт. Но стороны будут иметь общее видение дальнейшей совместной работы, понимать цели, которых надо достичь.

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

1. Лендинги и их A/B-тестирование.
2. Выборку данных с сервиса.

Лендинги

Студия, специализированные сервисы или делаем сами?

Студия — по идее, имеет опыт и знание рынка. Сроки — по-разному, многое зависит от нас, от техзадания или брифа, от нашей организованности. Явно не «день в день».

Цены — беглый «гуглеж» дает нам от 200 до 500 долларов за страницу. Может, можно найти от 50 до 150, но сами понимаете...

Специализированные сервисы. Их сейчас огромное количество с разными ценами. Также все облачные CRM типа Hubspot, AgileCRM и т. д. имеют функцию создания лендингов. На бесплатных аккаунтах нет возможности привязать страницу к своему домену. Но платный вариант рассмотреть можно, поскольку CRM нам все равно придется использовать, причем расширенные версии. В любом случае, за перетаскивание мышкой элементов страницы на шаблон компания будет платить.

Сами. Если нет вдохновения и времени — Lapa Ninja, Land Book, TemplateMonster. Существует огромное количество бесплатных фотостоков. Эксклюзивность может быть не обязательна, все уже давно придумали за нас, и пользователям, в принципе, дизайн почти безразличен (большинство трафика уже с мобильных, а там не особо разгуляешься), лишь бы «кровь из глаз не текла». По сути, у вас есть 3 секунды, чтобы захватить внимание пользователя. И тут большее значение имеет структура страницы и правильные CTA (Call to Acrtion — побуждение к действию).

Поэтому качественный лендинг постоянно меняется и требует экспериментов и проверки гипотез. Как пример, какие sales triggers использовать? Что может лучше «зацепить» потенциального клиента — «на складе осталось три пары обуви ручной работы из кожи единорога 42 размера», «до конца акции со скидками в 90% остается 2 миллисекунды», «только сегодня бесплатный тариф на 30 лет»? Простор для фантазии огромный и требует методичной проверки лучших вариантов.

Хорошая иллюстрация исследования эффективности лендинга.

Поэтому может иметь смысл самостоятельная разработка. Анализировать сессии Hotjar и двигать блоки в Wordpress сможет любой продвинутый пользователь.

Инструменты — начиная от «от тюнингованного» Wordpress+Nginx+PHP-FPM+Varnish с Elementor, или Static Site Generators типа Jekil, Hugo. Или Figma c последующим экспортом и небольшой доработкой. Все это можно автоматизировать с помощью CI/CD, пустить тестировать по пути dev, stage, prod окружений и «поселить» на выделенном сервере за 70 евро в месяц+Cloudflare. Мы уже имеем постоянную величину затрат на хостинг и веб-дизайнера под чутким руководством маркетологов.

A/B-тестирование лендингов

Тема сложная, здесь есть свои методики и подходы. Можем на начальных этапах упростить. В большинстве случаев от лендинга мы ждем только нужного нам действия. Например, регистрации нового пользователя, которую мы уже можем отследить по UTM-меткам в базе на сервисе. Haproxy или Nginx, и хоть 5 вариантов лендинга за ним только со своими UTM-метками, Hotjar кодом и формами регистрации, которые мы отслеживаем.

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

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

Естественно, все манипуляции проводятся с копией рабочей базы. Заодно это «прокачает» автоматизацию бэкапа рабочих баз.

В качестве интересного решения можно посмотреть на проект Grouparoo (это не реклама!!!), который может делать выборку из базы данных и интегрировать ее со множеством других сервисов. Текущие интеграции также рекомендую посмотреть на их roadmap. Источником могут выступать MySQL, PostgreSQL, Amazon Redshift. Выгружать данные можно в Mailchimp, Zendesk, Hubspot, SalesForce, Google Sheets, CSV. Может отслеживать события на фронте (Page Viewed, Button Clicked, Session Created), которые помогут в дальнейшем использовать эти данные для продуктовых метрик. Это open source продукт, который позволит значительно сэкономить и подсказать направление в выборе CRM и сопутствующих сервисов.

Таким образом можно выстроить на определенный период финансово предсказуемую систему маркетингового отдела и почти безболезненно интегрировать ее с разработкой.

На какие метрики мы еще можем влиять

Customer Churn Rate (CCR) — коэффициент оттока клиентов. Прекрасная метрика для продукта. Надо разобраться, почему клиенты уходят. Например, продукт архитектурно идеальный, но он не решает проблем клиентов, поэтому он им не нужен, тем более за деньги. Но раз мы «запустились», то надеемся, что Market Research собственники провели, и дело в нас. Раз дело в нас, начнем искать причины.

Вариант с «настроить нормально инфраструктуру» не рассматривается, поскольку это должно быть выполнено изначально. Считаем, что все в этом направлении сделано.

Какие могут быть причины оттока пользователей

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

Процессы разработки. Может, плохо построен CI. Редкие, но объемные «мерджи» в мастер и плохо построено тестирование. Если копнуть глубже, то может выясниться, что используется неоптимальная система ветвления Git. Вот народ долго «ковыряет» feature или hotfix ветку в Git-flow, и потом при слиянии что-то ломается. Если разрабатывается именно сервис, то, может, лучше использовать Gitlab-flow. Вообще тема ветвления достаточно интересная и дискуссионная, и у команды должен быть четкий стандарт, которого все придерживаются.

Плохое взаимодействие с маркетологами. У них свои планы по «нагону» трафика и регистраций на сервис, у команды — свои планы по деплою в production. Когда-нибудь эти планы могут совпасть, и эти события произойдут одновременно. Со всеми вытекающими. Также стоит учесть резервирование мощностей для каких-то маркетинговых активностей как подготовку к повышенной нагрузке. Самое обидное, когда деньги в рекламу вбухали, а сервис «лег» под нагрузкой. Поэтому нужен четкий график и общий календарь активностей и важных деплоев. Можно это все свести в Jira.

Код «сырой», архитектура не продумана. Естественно, необходимо использовать систему агрегации и обработки логов (Graylog, ELK, Loki), обязательно APM-мониторинг (NewRelic, Datadog), системы отслеживания ошибок в коде типа Sentry, ну и, конечно, мониторинг инфраструктуры (Zabbix, Prometheus).

Хочется остановиться на Sentry. Имеет SDK для разных языков программирования. Может быть установлен на свой сервер, достаточно требователен к ресурсам (это касается всего вышеперечисленного софта). Позволяет «выхватывать» ошибки выполнения кода, интегрироваться с Jira и автоматически создавать тикет при ошибке. Что хорошо — можно видеть ошибки на фронтенде в браузерах пользователя, поэтому разработчикам не надо выяснять версию браузера, ОС и т.д. Если все вышеперечисленное настроить и уметь им пользоваться, то качество кода, устойчивость сервиса и скорость разработки существенно возрастут.

Что касается архитектуры. DevOps-ы тоже ведут активную «разработку» в своей области. Для этого у нас есть IaC (подход «инфраструктура как код»). Имея мощности для экспериментов и CI/CD, можно опробовать несколько вариантов архитектуры изменения сервиса и быстро мигрировать продакшен на оптимальный. Более того — изменение, улучшение и «тюнинг» инфраструктуры, в принципе, никогда не прекращаются.

Неоптимальный UX/UI. Часто камнем преткновения становятся формы регистрации. Это везде очень чувствительная тема. Изменение цвета шрифта (кто придумал светло-серый шрифт на белом фоне — гори в аду) может на порядок повысить конверсию регистраций. Самый надежный процесс — A/B-тестирование версий дизайна и алгоритмов регистраций. Как правило, переходы идут с лендингов, и можно пробовать разные формы регистраций именно на них, при этом пользователи будут добавляться в базу сервиса.

Что касается остального UX. Можно идти малыми шагами, фиксировать и считать события на фронте, все это куда-то писать и обрабатывать. Это придется и так делать, но для других вещей. Интерфейс вообще тема очень скользкая и не любит изменений (вспомним недавний новый интерфейс Faсebook). Поэтому имеет смысл потратить время и «вложиться» в его отшлифовку.

В этом могут помочь специализированные сервисы тестирования UX/UI, например, из этого списка. Суть этих сервисов — вы описываете действия, которые должны совершить пользователи на сайте/в сервисе/личном кабинете, «покупаете» себе N-ное количество участников теста, и они дисциплинированно выполняют все задачи. Вы можете смотреть видео экранов, видео участников (эмоции), ну и сам сервис дает основные UX-метрики: скорость выполнения задачи, тепловые карты, анализ посещаемости, время выполнения задачи, шкала удобства использования системы. Стоимость месяца исследований — 300 у.е. (сервис Loop11).

Сложно пользоваться, не хватает или слишком много «фич». Оставим за скобками вопрос компетентности UI/UX-дизайнера. Предположим, компания серьезно отнеслась к UX-тестированию, сделала выводы и внесла изменения.

Сложно пользоваться. Или мы не научили пользователей работать с сервисом, или они не хотят учиться. Сложность продукта означает его скорую смерть. Естественно, не ко всем продуктам это относится, но мы говорим преимущественно о B2C-сегменте, а там это основная жалоба. Поэтому продукт надо упрощать, а пользователей — учить. Для начала следует понять, что хорошая документация — это тоже продажи и маркетинг. В разрезе этого документация будет делиться на несколько важных частей:

• Руководство пользователя. Можно выяснить у маркетинга «портрет покупателя», для которого продукт разрабатывается. И, отталкиваясь от него, уже разрабатывать справочную систему. Может оказаться, что покупатель у нас настолько ленивый, что ему надо будет показать только видео или скринкасты, а не писать «простыни» текста. Или наоборот, разрабатывать интерактивную систему помощи прямо в самом сервисе, поскольку «покупатель» видео не смотрит. Руководство пользователя не должно быть объемным — надо просто описывать типовые действия «как загрузить файл», «как создать, удалить» и т. д.
• Повторные контакты. Всяческие рассылки и т. д. Это тоже документация, поскольку в рассылках надо показывать изменения и новые «фичи» продукта. А это release notes, исправленные баги, новые возможности. Маркетологи сами такое не напишут, они могут только «причесать» текст. Брать это можно из Git, но при этом должны быть четкие правила заполнения коммитов, которых все придерживаются.
• Понятная простому смертному внутренняя документация по продукту. Больше относится к автономности маркетинга. Они должны знать, из каких базовых вещей состоит сервис, термины и определения, которые все используют. Основные рабочие процессы — тестирование, «деплой» и т. д. Отдельно стоить описать, откуда и как они получают данные для своей работы — выгрузка из базы сервиса, интеграция с CRM, рассылками. Как это связано с ними. Если такие документы есть, то процесс онбординга маркетологов существенно сокращается.

В случае с документацией можно использовать Documentation as Code (DocOps) подход.

Все описывается в языках разметки типа Markdown, reStructuredText, Asciidoctor, версионируется, прогоняется линтерами, на выходе с помощью pandoc получается в любых форматах — pdf, html, можно автоматом публиковать в Confluence. Из одного источника получаем и красочный сайт, и ссылку на pdf. Документация и DocOps для разработки — это вообще материал для целой книги. О пользе подробной документации по проекту, я думаю, спорить никто не будет. Документация для пользователей может тестироваться на сервисах для тестирования UX/UI — это тоже своего рода интерфейс взаимодействия с пользователем.

Много или мало «фич». Собственно, скорость выпуска новых фич и есть time to market. Жаль, что нет понятия смысла выпуска новых фич — sense to market. Самое обидное — когда «фича» сделана, но она не нужна. Боль, депрессия, выгорание. Не делать «фичи» тоже нельзя.

Какая метрика может помочь в sense to market?

Метрика Net Promoter Score (NPS) — оценка рекомендателей. Измеряется с помощью опросов клиентов/пользователей. Также может быть в форме опросов в соцсетях, если у продукта есть там страницы, можно вставлять голосование в email-рассылки.

Может хорошо работать roadmap продукта на сайте с голосованием. Можно и нужно делать выборку по базе сервиса по разным параметрам — сколько раз в неделю логинится, время сессии и т.д. Это ваши преданные пользователи (но это не точно). Им можно включать во время логина опросы «Какие бы вы хотели видеть возможности у продукта, выберите 2 из списка», плюс CTA «Подпишитесь на рассылку и будете...» (помните, в начале статьи у маркетологов спрашивали про такой функционал).

Разработчикам стоит сразу подумать о feature toggle (feature flags) при проектировании архитектуры. И продумать механизм включения/отключения «фич» в продукте. Вначале нововведения можно включать для активных пользователей. Можно даже предложить им скидку за тестирование «фич» в работе.

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

Чтобы избавить себя от бесполезной работы, можно вместо создания «фич» вставлять их «моки» (прототипы) в интерфейс сервиса. Пользователь видит кнопку «запустить фичу», нажимает на нее и получает сообщение «Извините, ведутся работы». Если из 100 пользователей нажали 2, гипотеза выбрасывается, если 20 — ставится в роадмап, если 30 — начинаем разрабатывать, если 50 — приносим в офис спальные мешки и работаем.

Косвенно DevOps-подход влияет на ROI (возврат инвестиций).

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

По-хорошему, DevOps может придать скорость процессам разработки и доставки.

«Разгон» будет не сразу, диапазон работ и ответственности широкий, но при системном подходе можно добиться результата.

Как можно ускориться

Время сборки. Поскольку в типовом проекте есть NPM (Pip, Maven), Docker, то имеет смысл делать кэширующие приватные репозитории. При использовании такого кэша CI-сервер будет работать на порядок быстрее.

Грамотный CI/CD. Начиная с процессов — кто и как ведет себя при «поломанной» сборке, кто и как обрабатывает Merge Requests, частота слияний, система ветвления. Заканчивая безболезненным «деплоем» на все окружения — Docker, Kubernetes все это значительно облегчают.

Можно грамотно снизить расходы на эксплуатацию.

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

Если конкретно.

Если только начали проект — сесть и хорошо подумать насчет «облаков». Особенно если пока не используются специфические продукты типа AWS Lambda. С одной стороны, там мы платим только за то, что потребляем. С другой — мы почти ничего не знаем про нагрузку и про необходимые для продакшена мощности. И что вообще произойдет, если в нескольких модулях на продакшене под нагрузкой забудут выключить debag, и логи «потекут рекой». Поэтому можно вначале поработать в обычных дата-центрах и «посчитаться» под нагрузкой. Docker и Kubernetes могут быть не только у AWS, девопсы их тоже могут сами приготовить на bare-metal.

Миграция также не должна особо волновать — есть IaC, Blue/Green Deploy, и если вы думаете, что в AWS вы «архитектурно застынете», как древняя стрекоза в янтаре, то у меня для вас есть новости. Не застынете, и переделки инфраструктуры будут все время. Иногда лучше иметь прогнозируемые расходы, чем тратить ресурсы на их отслеживание и оптимизацию.

Но без облаков и сторонних сервисов не обойтись.

Что обязательно нужно арендовать — DNS (Route53, Cloudflare), WAF (AWS, Cloudflare), Anti-DdoS (Cloudflare), нет смысла тратить время на то, что другие уже давно успешно сделали.

Можно вынести «тяжелые», но не критичные для функционала проекта сервисы из облака на дешевые площадки. Для ELK стека (агрегация логов, обработка, хранение, визуализация) требуются достаточно большие ресурсы (иногда намного больше, чем для продакшена). Тот же Sentry тоже требует немалых ресурсов.

На AWS (Frankfurt) постоянно работающий инстанс t4g.2xlarge 32 GB ОЗУ, 8 ядер, EBS 4Tb стоит 407$ в месяц. 1 TB исходящего трафика из AWS обходится в 92$ в месяц.

На Leaseweb сервер Dell 2x Intel 12-Core Xeon, 128 GB ОЗУ, 4×4TB диска, 30 TB трафика обойдутся 220$ в месяц. Плюсуем 92$ за трафик из Amazon, получаем 312$ — на 80$ дешевле и в два раза больше мощности. Для обработки логов и данных мониторинга вполне приемлемо.

Аналогично можно поступать с приватными и кеширующими репозиториями, системами сборки.

Если принято решение быть полностью в «облаке», тогда надо «прокачать» стратегию и процессы по уменьшению и оптимизации бюджета — AWS Cost Management.

Для начала хорошо настроить AWS Budgets — установить месячные лимиты на dev, stage окружения, рекомендуется хорошо продумать теги ресурсов.

Периодически мониторить «зомби» — неиспользуемые инстансы, ELB, snapshots EBS, дорогущие тома EBS — после удаления виртуальной машины EC2 том EBS, который был к ней прикреплен, не удаляется, и компания за него платит.

Продумать систему хранения — некоторые данные, хранящиеся на S3, можно хранить в пределах одной availability zone, что даст экономию в 20%. Архивы, которые нужны редко и время восстановления не критично, можно хранить на Amazon Glacier.

Также придется серьезно продумать резервирование инстансов — предварительно выкупать какое-то количество мощностей по хорошей цене (на некоторые виды Amazon обещает экономию 70%), но стоит учесть, что даже если вы их не используете в течение месяца, деньги все равно «сгорят».

Резюме

1. Взаимодействие продаж и разработки — залог выживания компании. Пусть это иногда два разных мира, но ситуация именно такая.
2. Маркетинг — это уже огромный сплав ИТ-технологий. Некоторые сервисы самостоятельно не сделать и не заменить аналогами. Поэтому маркетинговый отдел легче всего рассматривать как ИТ-проект.
3. Метрики надо знать, считать и анализировать их еще на старте.
4. Маркетинговая активность, отработка маркетинговых гипотез — это может и должно быть частью спринтов разработки.
5. DevOps-подход приносит косвенную выгоду. И самая заметная — ускорение доставки новых «фич».