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

Позволь мне объяснить.

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

Надлежащий стек PLG должен позволить компаниям организовать беспрепятственный путь пользователя от посещения веб-сайта до пробы продукта и, наконец, его использования.

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

По моему опыту, есть три основных требования к эффективному стеку технологий PLG:

1. Возможность единой регистрации и входа на всех веб-ресурсах компании.

2. Возможность фиксировать все детали поведения пользователей по нескольким каналам (веб-сайт, приложение и т. д.).

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

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

Давайте рассмотрим каждое из этих требований, рассмотрим архитектуру и некоторые варианты.

1. Уровень представления — веб-сайт

В моем прошлом опыте я видел много веб-сайтов, основанных на архитектуре, в которой код и контент тесно связаны. Эта архитектура становится проблематичной, когда на вашем сайте больше страниц и дополнительных языков, и в конечном итоге появляются мини-приложения, например, портал сообщества, портал событий и т. д. Поэтому мы решили использовать архитектуру стека JAM, которая взаимодействует с безголовой CMS. Это позволило нам разделить код и контент. Разработчики используют свою IDE по своему выбору и могут вносить изменения в код непосредственно в репозиторий кода, а с помощью нашего конвейера CI/CD мы можем выпускать выпуски кода так часто, как захотим. С другой стороны, авторы контента работают непосредственно в безголовой системе управления контентом WYSIWYG, которая запускает сборку веб-сайта в нашем конвейере CI/CD, поэтому любые изменения в коде или контенте могут быть развернуты на нашем сайте разработки, промежуточной стадии и, в конечном итоге, на нашем рабочем сайте без любые простои.

2. Уровень данных — идентификация пользователя и аутентификация

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

В некоторых отношениях это можно представить как пользовательский объект с базой данных временных рядов для событий, связанных с пользователем.

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

На изображении ниже представлен общий обзор этой архитектуры данных и некоторые готовые варианты.

3. Оркестрационный слой

Наконец, нам нужна была эффективная система рабочего процесса, которая позволяла бы нам взаимодействовать с нашими пользователями по нескольким каналам, таким как электронная почта, SMS и т. д. Первоначально мы сделали это с помощью функциональной платформы Lambda с открытым исходным кодом, которая позволяла нам прослушивать события веб-перехватчиков и инициировать действия через API, такие как отправка электронных писем через Sendgrid. Совсем недавно мы начали строить наш рабочий процесс для наших клиентов и нас, который является гораздо более гибким и адаптируемым.

Для связи с нашими пользователями в режиме реального времени мы используем одну из функций нашего продукта PLuG. PLuG активируется непосредственно в нашем сообществе, вошедшем в систему. Это позволяет нам взаимодействовать с нашими клиентами в режиме реального времени. Затем каждый разговор подключается к нашей базе данных идентификаторов пользователей, с одной стороны, и функциям и возможностям нашего продукта — с другой. Это означает, что по мере возникновения проблем и вопросов наши сотрудники могут своевременно помочь нашим пользователям.

Сводка

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

Это сообщение изначально было опубликовано на PlainEnglish.io/blog.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Посетите наш Community Discord и присоединитесь к нашему Коллективу талантов.