Pull to refresh

Как мы делаем Convead: от концепции до реализации — часть 1

Reading time9 min
Views3.4K
Сидели мы как-то выпивали, обсуждали проблемы eCommerce и жаловались друг другу на то, что все существующие аналитические сервисы либо не умеют чего-то очень важного, либо чересчур сложны в настройке, и часто приходится использовать связку из нескольких сервисов для достижения своих целей. Но это мы – люди, технически грамотные, а сколько народу мучается от того, что даже не могут понять, как передать эвент в Google Analytics?

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

А что наиболее важно для владельца магазина? Конечно хорошая конверсия! Низкий процент конверсии является основной головной болью подавляющего большинства интернет-магазинов. Именно за этот показатель бьются маркетологи и UX-дизайнеры, именно его отслеживают владельцы магазинов в качестве ключевого параметра эффективности.

Конечно, есть еще проблема низкой посещаемости, но на нее, в отличие от конверсии, мы не смогли бы повлиять. Да и степень ее важности, в конечном итоге, все равно сильно зависит от конверсии. Представим, что ваш маленький интернет-магазинчик посещают 100 человек в день (что очень мало), но конверсия у вас на уровне 30% (мечтать не вредно, ага), что дает вам 33 заказа в день! Неплохо для маленького магазинчика с мизерной посещаемостью?

В общем, рассудив таким образом, мы решили биться именно за конверсию! Так родилась идея сервиса Convead (сокращение от англ. «Convert your Lead»). Нашей основной идеей было создать сервис, который бы позволил интернет-магазину:

  • узнать своих посетителей и запомнить их;
  • правильно сегментировать их по каким-либо признакам;
  • увидеть наглядно, как работает интернет-магазин, где его узкие места, где отваливаются посетители (как в общем, так и отдельные их сегменты);
  • воздействовать на эти сегменты тем или иным образом, стимулируя их сделать покупку и повышая конверсию;
  • оценивать эффективность этих воздействий, корректировать их в случае необходимости — мы назвали эту фичу “Analytics And Actions Combined”.

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

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

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

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

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

Как мы делали Convead


Когда затеваешь любой новый проект, всегда приходится находить компромисс между своими хотелками и доступными ресурсами. В такие моменты я всегда представляю картинку, когда на одном плече сидит чёртик и шепчет в ухо: «Нужно больше функций! Никому не нужен сервис, который ничего не умеет! Делай крутой фронт, люди любят глазами!», а на другом – ангелок, и говорит: «Мы ограничены в деньгах. Нужно проверить гипотезу с минимальными затратами. Никто не умрет, если в MVP не будет экспорта в Excel и где-то будет подглючивать верстка!».

Мы решили поставить самим себе ограничение 1,5 – 2 месяца на разработку прототипа (он же MVP) и не более. В MVP решили включить только самое минимально необходимое:

  • сбор информации о посетителях и визитах;
  • сегментирование и аналитика.

Таким образом, в текущей версии Convead умеет собирать и анализировать информацию, но еще не умеет воздействовать на посетителей. Экспорт в Excel кстати все-таки сделали, чёрт уболтал :)

Когда мы задумывали Convead, то мы решили, что сосредоточим свое внимание на следующих бизнес-моделях веб-сайтов:

  • eCommerce
  • SaaS
  • Marketplace
  • Media

Предполагается, что каждый подключаемый сайт должен указать, по какой модели он работает. Зачем это нужно опишу ниже. В текущей beta-версии доступна только модель eCommerce.

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

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

Для модели eCommerce мы рассматриваем следующие ключевые страницы:

  • Карточка товара (каталог, поиск и т.д. — любая значимая страница входа)
  • Корзина
  • Чекаут
  • Подтверждение заказа

Схема работы eCommerce сайта представлена ниже:

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

В синих кругах сверху наглядно показано распределение входящего трафика:

  • Return – те, кого мы смогли вернуть в результате того или иного воздействия.
  • Paid – платные источники.
  • Direct – прямые заходы.
  • Search – заходы с поисковиков.
  • Viral – «вирусные» источники (пока упрощенно считаем, что это только соц. сети).

Все вместе эти источники составляют 100% ваших посетителей (Visits). На схеме видно, как посетители двигаются по нашему жизненному циклу. На определенных стадиях они отваливаются (уходят с сайта) и это служит сигналом для владельца сайта о том, что требуется что-то изменить в этой части сайта.

Чем меньше проценты под красными надписями на схеме – тем лучше. Васе будет легко разобраться.

Рядом со схемой еще есть простая табличка с основными показателями:

  • % конверсии
  • количество покупок
  • средний чек
  • общий доход

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

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

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

Возможности текущей beta-версии и планы на будущее


Нашей идеей было дать в первой версии возможность накапливать и анализировать данные (пассивная часть), а потом уже учить Convead производить воздействия, чтобы как-то изменить ситуацию (активная часть) и расширять возможности аналитики.

Поэтому MVP умеет пока немного:

  1. Определять и узнавать посетителей на сайте, отображать их онлайн-активность и запоминать историю взаимодействия с сайтом.
  2. Считать доход от каждого посетителя.
  3. Сегментировать посетителей.
  4. Отображать метрики по основным показателям вашего сайта как по всему трафику, так и в разрезе сегментов.


Пара скриншотов интерфейса (кликабельные):

Список посетителей (выбран сегмент «With Revenue»)
Карточка посетителя

Планы на будущее

Воздействия

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

Для начала мы решили остановиться на следующих каналах воздействия:

  1. Персонализация страницы: виджеты, замена частей страницы и пр. («онлайн-воздействия»).
  2. Email-сообщения («оффлайн-воздействия»).

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

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

Возможные кейсы применения воздействий:

  1. Выделить в отдельный сегмент всех посетителей, которые были на сайте в последний раз неделю назад, смотрели страницу товара, но ничего не купили. Отправить им email-сообщение «Вернись, я все прощу!», тут же на схеме жизненного цикла увидеть % людей, которых удалось вернуть таким образом.
  2. Создать онлайн-воздействие, которое будет модифицировать h1 на странице товара для того посетителя, которого мы знаем, вписывая туда его имя: «Аркадий, ну купите Утюг Philips GC 8620, ну пожалуйста!».
  3. Создать онлайн-воздействие, которое будет показывать виджет с промо-кодом для тех посетителей, которые попадают в определенный сегмент (например, у них сегодня день рождения или они заходят на сайт уже в третий раз, но ничего не покупают).

Автоматизированный сбор основных данных о посетителях

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

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

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

Мы продолжаем думать над тем, как легально собрать максимальное количество данных о пользователе, не затрудняя этим ни его самого, ни владельца магазина. В идеале нам хотелось бы видеть получение всех полезных для сегментирования данных о человеке (пол, возраст, семейное положение, работа, интересы и т.п.) максимально автоматизированным на стороне Convead. Очевидно, этому есть множество препятствий и конечно мы про них знаем. Но у нас есть кое-какие идеи на этот счет и, я надеюсь, мы сможем их реализовать. Если у кого-то есть хорошие предложения на эту тему – велкам в комментарии! :)

Интеграция

О, это волшебное слово «Интеграция»! У вас нет своего API? Да вы днище отсталый сервис! На самом деле, под «интеграцией» мы понимаем прежде всего не собственный публичный API (он тоже будет), а интеграцию Convead в наиболее распространенные CMS и SaaS-сервисы для eCommerce в виде плагинов.

Мы подумали: а почему собственно бедный Вася должен мучиться и настраивать жизненный цикл своего магазина, ключевые страницы, просить кого-то поставить JavaScript-сниппет, если подавляющее большинство таких Вась использует какие-то известные платформы или SaaS-сервисы? Так что, Вася, мучиться тебе осталось недолго – мы включили в наши ближайшие планы разработку плагинов под наиболее распространенные eCommerce-решения.

Улучшение существующих возможностей

Мы очень торопились выпустить beta-версию в установленный нами же срок, поэтому некоторыми удобствами все же пришлось пожертвовать.

В ближайшее время мы планируем:

  • улучшить возможности сегментирования (дать возможность создавать цепочки из условий);
  • расширить аналитику по Revenue (принимать не только сумму заказа, но и ключевые параметры – список брендов или категорий товаров в заказе);
  • добавить красивые (а для некоторых магазинов, к сожалению, не очень красивые) графики трендов основных показателей.

Заключение


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


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

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

В следующей части (если текущая часть будет интересна) я сделаю рассказ о том, с какими трудностями мы столкнулись, как принимали те или иные технические и организационные решения. Постараюсь дать максимум вкусных технических подробностей, используя слова Ruby-on-Rails, Postgres, Redis, Sidekiq, JavaScript, партицирование таблиц, нагрузочное тестирование и т.д. Пока идея изложить все это в формате «описание проблемы/ситуации – принятое решение», чтобы иметь возможность послушать более опытных товарищей и подискутировать на эту тему.

На самом деле планов и идей еще очень много. Гораздо больше, чем наших возможностей. Поэтому буду очень благодарен тем, кто попробует Convead и проголосует в нашем суппорт-форуме за ту или иную идею, или предложит свою.

С сегодняшнего дня проект вступает в стадию закрытого beta-тестирования. Получить доступ можно, оставив свой email на сайте http://convead.com в соответствующей форме.

P.S. Вообще, статью должен был опубликовать dlukyanov, как технический менеджер проекта, но у него нет для этого кармы.
Tags:
Hubs:
Total votes 14: ↑12 and ↓2+10
Comments4

Articles