Что нужно знать о пользователе и бренде, чтобы сэкономить на разработке?

Меня зовут Мила, я веду проекты в команде web-production Ailove. Мне обычно достаются сложные задачи: я разбираюсь с бизнес-задачами клиента, собираю команду разработки и модерации, настраиваю процессы. Последние три месяца мы с коллегами наблюдаем, как растет спрос на разработку: одни переходят в онлайн, другие мигрируют из Instagram (признан экстремистским и запрещен в РФ) и разрабатывают ботов, а третьи оптимизирует затраты на программистов в горизонте 3+ лет. В связи с этим ко мне пришла команда PR и попросила рассказать, зачем нужен продакшен и какие сейчас есть тренды. А также ответить на наиболее часто встречающиеся вопросы. Вместе с тимлидом разработки Ильёй Портным, мы решили собрать ликбез для тех, кому срочно нужен сайт. Или соцсети. Или бот в Telegram. Или приложение. И совершенно неясно, с чего начать.

Сайт, боты, работы с CRM ― что бы мы ни строили, мы автоматизируем уже сложившиеся бизнес-процессы в компании и помогаем им работать. Автоматизировать процессы можно по-разному. Например: ― табачная компания для продвижения использует сайт с большим каталогом игр. Пользователи туда приходят (в том числе) ради бесплатных хорошо проработанных игрушек. И готовы пройти сложную регистрацию, чтобы играть без риска потерять деньги или подцепить вирус. Бренду это дает долгий контакт с пользователем и возможность контакта со своим потребителем. У такого сайта продуктовые задачи: он нужен, чтобы люди провели на нем максимум времени, потому что их привлекли качественные игры. Разработчики должны позаботиться о том, чтобы играть было удобно ― kpi разработки этого сайта мало отличается от kpi разработки компьютерных игр. ― производитель специй использует для продвижения кулинарный портал. Пользователи часто ищут рецепты в поиске и приходят за ним на сайт, готовят и уходят. Разработка ориентируется на эту аудиторию, поэтому в проекте многие задачи поступают от команды SEO и связаны с оптимизацией их работы. ― для интернет-магазина, торгующего детскими товарами, важна возможность удержать клиента, поэтому большое внимание необходимо уделять сегментации аудитории и регулярному анализу трафика. Например, аналитик видит, что люди, переставшие покупать, раньше брали подгузники. И тогда он проверяет не только то, насколько удобно покупать товары этой категории, но и есть ли ассортиментная линейка для детей постарше. ― для сайта крупного производителя мяса большое значение имеют контент и удобство обратной связи. Клиенты легко находят сайт в поиске (конкуренция небольшая). Поэтому текстов нужно немного, но очень важно, чтобы посетитель понял свой запрос и попал в нужный департамент: от этого зависит скорость обработки заказа. На этапе разработки аккаунт-менеджер постоянно общается с департаментами финансов, закупок, продаж и партнёрских сетей заказчика, чтобы отразить их процессы и правильно настроить формы. Продакшен учитывает клиентский опыт так же, как и остальные команды. Чтобы сделать сайт, приносящий прибыль, нам важно попасть в бизнес-процессы и стать их частью.

1. Какие задачи человек решит с помощью сайта?

2. Как он решит эти задачи?

3. Какой это человек, с какого девайса и из какой точки мира он заходит (это про ЦА и соцдем)?4. Какой путь проделает перед тем, как оказаться на сайте/в приложении, и какие действия произойдут после использования сайта или приложения (заказал еду в приложении доставки, приезжает еда)?

― тех, кто пришел на сайт посмотреть рецепт/прочитать статью;

― тех, кто пришел посмотреть продукты и то, где он может их купить по акции;

― seo-команды, которая пришла внести метатеги;

― трейд-маркетолога, который сверяет продукты с актуальной линейкой.

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

По сути, нам нужна выдержка из CJM, касающаяся нашего блока работ. И тут часто появляется типовая проблема ― у маркетолога есть только такие данные:

ЦА

• Женщины, 18-45, города миллионники

• Москвичи с доходом 90 т.р. и выше

• Маша, 30 лет, замужем, двое маленьких детей. Живет в Москве, читает новости, сортирует мусор.

Заказывает продукты и всё необходимое с доставкой на дом на семью из 4 человек.

Быть хорошей мамой, тратить мало времени на рутину и чтобы дети были сыты, чисты и здоровы.

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

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

Важно держать в голове, что сайты при этом могут быть ориентированы на разные цели:

- на трафик из поисковых систем (например, сайты с рецептами от производителя специй),

- на сценарии использования продукта (Алиса «Яндекса»),

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

Ярким примером тут будет Gmail ― это дорогой сервис, который не столько приносит деньги, сколько образует саму экосистему.

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

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

Что это означает на практике:

― маркетплейсам важны сделки: поездки в такси, забронированные ночи в отелях;

― магазинам важен средний чек и количество заказов;

― тем, кто монетизирует трафик рекламой, от авто.ру и «Летидора» до Facebook (признан экстремистским и запрещен в РФ), важна активность пользователей в день/месяц: DAU, MAU, среднее время использования сайта или приложения;

― для экосистем («Яндекс», «Сбер», Google) важен LTV (lifetime value), пожизненная ценность клиентов — доход с привлеченного пользователя за всю историю взаимоотношений с ним. Показатель учитывает активность пользователей в кросс-сервисных сценариях. Именно он показывает окупаемость сервисов вроде Gmail.

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

Определившись с метрикой, детализируем маршрут. Выбираем гипотезы: как именно мы добьемся роста, например, количества броней номеров в отеле? Перепишем текст? Упростим интерфейс? Построим партнерскую программу? Как будем собирать обратную связь? И что именно нужно бизнесу?

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

Деньги. Сколько мы хотим сэкономить/заработать на сайте?

Например, ИТ-компания, которая продавала энтерпрайз-решения для нишевого бизнеса, решила сделать SAAS-версию и продавать подписки. Если энтерпрайз-клиентов было 5, вложения в маркетинг, разработку и продвижение станут инвестицией. Окупится она или нет, зависит от успешности продукта. Быстрой окупаемости не будет, это важно понимать сразу.

Сайты и приложения ― средство автоматизации продаж. Если продаж мало, на автоматизацию можно потратить больше денег, чем ожидается прибыли.

В процессе расчетов можно понять, что лучше не заниматься разработкой, а сделать лендинг на Tilda или YouTube-канал под техподдержку. И расти постепенно.

Есть и обратные кейсы: продаж много, они держатся на сайте, и от этого строятся сценарии разработки. Последнее время так работают, например, «Вкусвилл» или X5. Тут в оптимизацию вкладываются огромные деньги, и окупаются они быстро.

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

Избавиться от человеческого фактора на том или ином участке

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

Выиграть каннских львов

Пиар, слава, звездочки на фюзеляже. Такие задачи редко работают на окупаемость, но часто― на знание и виральность. Подключаем креатив.

А теперь немного откатимся к началу: какие вопросы мы чаще всего задаем на старте и почему нам сложно на них ответить, не зная бизнес клиента?

Спойлер: user first

А что, собственно, делать? С чего начинать проектирование?

Для начала нужно узнать, кто тут у нас юзер и какой набор технических решений ему подойдет. И (например) понять, что сайт не нужен вообще.

Если мы делаем новый сайт для уже знакомой аудитории, заходим в Google Analytics или «Яндекс.Метрику», смотрим отчет по устройствам и определяем, какой тип устройств для нас важен. Клиенту, у которого 80% трафика приходит с мобильных устройств, для сайта мы предложим подход mobile first. Но, кроме того, сайт у него контентный, а бюджет ограниченный. Поэтому мы делаем сайт и pwa-версию вместо мобильного приложения. Получается примерно в 5 раз дешевле.

А есть другой клиент, b2b. К нему 70% клиентов приходят с десктопа из разных стран, и все эти люди пользуются разными браузерами. И экраны у них разных размеров. Тут надо больше сосредоточиться на том, чтобы работал CDN (штука, которая кэширует контент и быстро загружает его для пользователей независимо от их географического положения).

Очень важно смотреть на погрешности сбора данных, чтобы не уйти в ошибку выжившего и замкнутый круг («Прыщи на лице ― нет секса ― прыщи на лице ― замкнутый круг!»(с)) Здесь нам помогает команда BI: они смотрят конкурентов, проводят кастдевы, пересматривают UX, CJM. Возвращаясь к началу, мы уточняем бизнес-процессы клиента.

Выбираем по текущему уровню цифровизации.

1. Дешёвые шаблоны готовых решений, где разработка включается минимально.

Если нам нужно просто дать какой-то текст, картинки/видео и форму обратной связи, подойдут конструкторы. Кроме того, они эффективны для тестирования гипотез уже сложившегося бизнеса, так как это просто, быстро и дешево. Tilda, Wix, Ucoz, Umi и другие, их очень много. Я люблю «Тильду».

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

2. Готовые решения, где разработка адаптирует сборку под вас.

Если вам нужен типовой, но персонализированный под вас дизайн, у вас есть задача синхронизировать CMS со внутренней IT-системой или использовать сторонние автоматизированные сервисы (API), лучше подойдет единый пакет CMS + Framework и монолитная конструкция сайта.

Примеры: Drupal, WordPress, Битрикс и Adobe Experience Manager (AEM) или Adobe Commerce (бывш. Adobe Magento); раньше популярных было значительно больше ― Joomla, Typo3 и т.д.)

Эти решения уже требуют постоянной поддержки и обновления версий, чтобы соответствовать стандартам безопасности. Причина ― они самые популярные, а значит, подвержены массовым взломам. Мировым чемпионом по популярности является WordPress, и взломать его пытаются чаще других.

3. Нетиповые решения для работы с данными уже или шире стандартных. Разработка глубоко погружается в бизнес-процессы клиента.

Иногда рентабельнее разработать решение под себя.

Это нужно:

― для персонализированных выборок (например, предлагать корма для животных в зависимости от возраста питомца),

― для сервисов записи, если нет информационной системы (например, для фитнес-клуба или больницы),

― если есть потребность усилить безопасность из-за частых атак/взломов.

Такое решение необходимо, когда есть потребность в регулярном обмене данными (например? для записи пациентов в больницу, отправки персонализированных уведомлений и рассылок покупателям и т.п.). Тогда можно:

— выбрать готовую информационную систему/сrm, выбрать готовую cms и связать их по api/ настроить обмен json или другими файлами (тогда возвращаемся к п.2.);

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

— написать под свои задачи CMS.

Хорошее решение — API Backend + Frontend + административная панель или CMS. Собираем набор из нескольких приложений: одно отвечает за отображение картинки пользователю и выполняется в его браузере, другое исполняется на сервере и работает с данными, базой, CRM и поставляет данные для первого. Для удобства управления снабжается административной панелью или CMS.

Типичный пример такого стека ― Vue.JS + Laravel + OctoberCMS, или Angular + Django + Django CMS. Так как тут нет монолитной конструкции, набор подбирается по конкретным нуждам каждого бизнеса.

Собственное решение (своя разработка) в подавляющем большинстве случаев — дольше, сложнее, дороже и имеет большее число недокументированных особенностей работы системы и дефектов (и особенности, и дефекты часто называют “багами”, хотя это и не совсем верно). У собственного решения обычно ниже интенсивность разработки и беднее документация. Но иногда два ее плюса способны перекрыть все минусы: это гибкость (то есть можно реализовать любые потребности бизнеса, даже необычные) и бизнес-надёжность — аренда может закончиться, контракт не продлиться, партнёр закрыть или продать бизнес, а собственность компании останется с ней.

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

Для IT-проектов, бизнес которых полностью онлайн (Okko, IVI, Lamoda, OZON и других), используют сразу несколько фреймворков, собственные фреймворки и т.д. Их строят внутри IT-компании. Агентство в этом случае нанимать не советуем.

Когда мы выберем техстек, вариантов CMS останется буквально 1-5. И можно будет сравнить.

Критерии те же:

― Ответы на те самые вопросы об использовании сайта, где actor ― команда контент-менеджеров, администраторов и модераторов: какие задачи человек решит с помощью сайта, как он решит эти задачи, какой это человек, с какого девайса он придет, из какой точки мира, как он окажется на сайте/в приложении.

― Бюджет: CMS могут быть платными и бесплатными, с разной стоимостью программной поддержки.

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

Чаще всего для начала нужно понять:

1. Что вы продаете? Какие ваши задачи?

2. Каков масштаб вашего бизнеса?

3. Какие задачи должен решить пользователь на сайте или в приложении

4. Как сайт/приложение окупается?

5. Локализация бизнеса: какова география ваших клиентов?

6. Есть ли у вас информация о том, с какой вероятностью ваш сервер будут атаковать?

7. Откуда приходит пользователь? (Например, с мобильного по дороге на работу или с десктопа и в офисе)

8. Нужна ли CRM и какая?

Дальше разработка задаст немало дополнительных вопросов. Но даже на этом этапе мы сможем сэкономить.

Бонус. Алгоритм от Ильи:

1. Выяснить, чем занимается клиент и что его в этом занятии раздражает (что можно улучшить)?

2. Действовать по обстоятельствам:)