Комментарии

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

Попробую пояснить.
При разработке больших проектов достаточно сложно сразу спроектировать и предусмотреть всё, вплоть до мелочей. Во-первых, это может занять слишком много времени. Во-вторых, данные могут потерять актуальность в процессе работы. В-третьих, на выходе можно получить такое многотомное ТЗ, что ни заказчик, ни прочие участники проекта, не смогут в нем разобраться.
Но без ТЗ начинать работу нельзя.
Где золотая середина?:)

Например, есть у вас задача сделать агрегатор объявлений по продаже автомобилей. С поиском, отзывами, импортом/экспортом объявлений и прочими клевыми штуками.
Можно указать в ТЗ, что одна из характеристик авто — объем двигателя. Потом разобраться глубже и узнать, что на разных сайтах люди указывают данную характеристику по-разному: где-то в литрах, где-то в кубических сантиметрах. Изучаем дальше — выясняем, что привычнее для людей искать именно по литрам, то есть необходимо будет конвертировать для одних объявлений и оставлять как есть для других.
Стоит ли углубятся в такие детали сразу при проектировании или решать их уже в процессе?

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

Попробую пояснить.
При разработке больших проектов достаточно сложно сразу спроектировать и предусмотреть всё, вплоть до мелочей. Во-первых, это может занять слишком много времени. Во-вторых, данные могут потерять актуальность в процессе работы. В-третьих, на выходе можно получить такое многотомное ТЗ, что ни заказчик, ни прочие участники проекта, не смогут в нем разобраться.
Но без ТЗ начинать работу нельзя.
Где золотая середина?:)

Например, есть у вас задача сделать агрегатор объявлений по продаже автомобилей. С поиском, отзывами, импортом/экспортом объявлений и прочими клевыми штуками.
Можно указать в ТЗ, что одна из характеристик авто — объем двигателя. Потом разобраться глубже и узнать, что на разных сайтах люди указывают данную характеристику по-разному: где-то в литрах, где-то в кубических сантиметрах. Изучаем дальше — выясняем, что привычнее для людей искать именно по литрам, то есть необходимо будет конвертировать для одних объявлений и оставлять как есть для других.
Стоит ли углубятся в такие детали сразу при проектировании или решать их уже в процессе?

Конечно, любое продвижение учитывается в задачах.

Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…

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

Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.

Конечно, любое продвижение учитывается в задачах.

Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…

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

Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.

Стоит добавить, что если клиент планирует в будущем продвигать свой сайт (SEO), то необходимо и это учитывать при проектировании. Как минимум предусмотреть оптимальные точки входа (страницы) по основным группам запросов.

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

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

Или про разработку больших проектов (если есть опыт), где только этап исследования занимает от 2-3 месяцев.

Стоит добавить, что если клиент планирует в будущем продвигать свой сайт (SEO), то необходимо и это учитывать при проектировании. Как минимум предусмотреть оптимальные точки входа (страницы) по основным группам запросов.

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

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

Или про разработку больших проектов (если есть опыт), где только этап исследования занимает от 2-3 месяцев.

Проектирование — этот, возможно, ключевой этап создания интернет-сайта, отвечает нам на следующие вопросы:

— Каковы наши цели — зачем мы делаем сайт? Как мы реализуем поставленные цели?
— Как сайт будет выглядеть и работать?

О пользе проектирования

Проектирование даёт сайту очень много:

— Сильно повышает гарантию достижения результата.
— Только четко сформулировав задачи, определив целевую аудиторию сайта и её потребности, смоделировав взаимодействие сайта и его пользователей, мы можем быть уверены — мы получим то, что нужно.
— Экономит время и деньги.
— Исправить ошибку на этапе проектирования довольно просто: меняем несколько кусков текста и схем. Сделать это на этапе разработки дизайна или вёрстки будет уже дороже. Если ошибка обнаруживается на этапе программирования, её исправление может стоить многие тысячи (десятки, сотни тысяч) рублей и занять месяцы, а то и годы.
— Позволяет эффективно разделять работу.
— Проектное задание — это вполне самодостаточный документ. Получив его, клиент может сделать сайт своими силами или нанять другую команду, которая, по его мнению, лучше справится с непосредственно разработкой (у нас есть такой опыт, когда мы выполняли только проектирование, а клиент разрабатывал сайт своими силами).

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

Исключение, пожалуй, составляют недорогие сайты — с бюджетом 5-15 тысяч рублей — где проектирование становится нерентабельным, увы.

Как проектировать сайт

Проектирование можно условно разбить на четыре основные части:

— Целеполагание,
— Исследование контекста,
— Создание концепции,
— Моделирование.

Целеполагание

Целеполагание необходимо для определения того, зачем мы делаем сайт и каких именно результатов хотим достичь. Это служит ориентиром для всей дальнейшей работы: что бы мы ни делали — будь то моделирование, создание интерфейсов, добавление новых функций или изменение старых — всё это должно соответствовать целям.

В будущем они же помогают оценить успешность проекта.

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

Исследование контекста

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

— Целевая аудитория и её потребности,
— Характеристика и тенденции области,
— Конкуренты и их деятельность,
— Опыт других проектов,
— Законодательные или иные ограничения,
— Другие факторы влияния, в зависимости от тематики проекта.

Польза исследования контекста

Контекст проекта помогает нам понять целевую аудиторию и то, каким нужно сделать сайт: как его позиционировать, какая информация на нём должна быть и на каком языке он должен говорить с ЦА (это называют коммуникативной стратегией), как он будет отличаться от конкурентов (естественно, в выгодную сторону).

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

Лучше всего, конечно, исследование помогает понять аудиторию:

— Как с ней общаться: какие слова использовать в «разговоре» с ней, как называть свой продукт или услугу (возможно, нужно использовать профессиональный сленг, или наоборот, нарочито упрощённую терминологию), обращаться ли к ней на «вы» или на «ты».
— Каковы её потребности: что приоритетно, что необязательно, но желаемо, что нельзя делать ни в коем случае.

Где брать данные

В идеале, данные о контексте мы должны получить от клиента, но если таких данных у клиента нет, то исследование контекста предстоит провести самим.

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

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

Предвижу комментарии: дескать, самостоятельное исследование рядом не стояло с профессиональными маркетинговыми исследованиями — так зачем тратить время и ресурсы? На то есть несколько причин:

— Без данных о контексте ваши шансы сделать хорошо пользователю стремятся к нулю.
— Даже самостоятельное исследование даёт полезную информацию, пусть и в меньшем объёме, нежели профессиональное.
— И даже если вы настолько неумело проводите исследование (что маловероятно), что не можете получить ответы на вышеобозначенные вопросы, вы всё равно погружатаетесь в контекст проекта и хотя бы подсознательно улавливаете что-то полезное.

Могу сказать по собственному опыту: нам исследование помогало всегда, в любом проекте.

Создание концепции сайта

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

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

Концепция задаёт направление проектированию и помогает, аналогично видению, ещё раз состыковать точки зрения на проект — нашу и клиента.

Моделирование сайта

Моделирование — это создание модели сайта, которая описывает функциональные возможности и информационную структуру.

Функциональная часть модели

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

Информационная структура

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

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

— Задачи — какие из ранее поставленных задач решает раздел. Например, раздел «Фотографии» в социальной сети решает задачу обмена информацией между друзьями и последующего общения;
— Сообщения — это в буквальном смысле сообщения, которые раздел или его часть передаёт посетителю. Например, сообщение приветствия «Привет, ты на портале ХХХ! Мы рады видеть тебя здесь» или «Эй, это наш лучший товар — попробуй, закажи сейчас и убедись в этом сам!».
— Сообщения бывают разных типов; наиболее часто встречающиеся: рекламные, призывы к действию, уведомления и имиджевые сообщения.
— Функциональные элементы — элементы интерфейса, дающие возможность посетителю выполнить какую-то операцию. Например, функциональным элементом является форма для ввода сообщения, позволяющая отправить сообщение, или кнопка в интерфейсе, сохраняющая сделанные изменения.
— Варианты поведения посетителя — предположения о том, что посетитель сайта может или должен сделать после изучения интерфейса или отдельных его частей.

Мы обычно делаем такие схемы в виде mind maps — очень удобно, надо сказать.

Резюме

Как обычно, краткие выводы:

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

P.S.: Статья эта, очевидно, обзорная, для затравки, поскольку тему проектирования раскрыть в одной статье нереально. Практически любая мысль из этой статьи была неоднократно подтверждена нашим личным опытом, и обо всём мы расскажем позже, подробнее и с примерами.

Проектирование — этот, возможно, ключевой этап создания интернет-сайта, отвечает нам на следующие вопросы:

— Каковы наши цели — зачем мы делаем сайт? Как мы реализуем поставленные цели?
— Как сайт будет выглядеть и работать?

О пользе проектирования

Проектирование даёт сайту очень много:

— Сильно повышает гарантию достижения результата.
— Только четко сформулировав задачи, определив целевую аудиторию сайта и её потребности, смоделировав взаимодействие сайта и его пользователей, мы можем быть уверены — мы получим то, что нужно.
— Экономит время и деньги.
— Исправить ошибку на этапе проектирования довольно просто: меняем несколько кусков текста и схем. Сделать это на этапе разработки дизайна или вёрстки будет уже дороже. Если ошибка обнаруживается на этапе программирования, её исправление может стоить многие тысячи (десятки, сотни тысяч) рублей и занять месяцы, а то и годы.
— Позволяет эффективно разделять работу.
— Проектное задание — это вполне самодостаточный документ. Получив его, клиент может сделать сайт своими силами или нанять другую команду, которая, по его мнению, лучше справится с непосредственно разработкой (у нас есть такой опыт, когда мы выполняли только проектирование, а клиент разрабатывал сайт своими силами).

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

Исключение, пожалуй, составляют недорогие сайты — с бюджетом 5-15 тысяч рублей — где проектирование становится нерентабельным, увы.

Как проектировать сайт

Проектирование можно условно разбить на четыре основные части:

— Целеполагание,
— Исследование контекста,
— Создание концепции,
— Моделирование.

Целеполагание

Целеполагание необходимо для определения того, зачем мы делаем сайт и каких именно результатов хотим достичь. Это служит ориентиром для всей дальнейшей работы: что бы мы ни делали — будь то моделирование, создание интерфейсов, добавление новых функций или изменение старых — всё это должно соответствовать целям.

В будущем они же помогают оценить успешность проекта.

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

Исследование контекста

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

— Целевая аудитория и её потребности,
— Характеристика и тенденции области,
— Конкуренты и их деятельность,
— Опыт других проектов,
— Законодательные или иные ограничения,
— Другие факторы влияния, в зависимости от тематики проекта.

Польза исследования контекста

Контекст проекта помогает нам понять целевую аудиторию и то, каким нужно сделать сайт: как его позиционировать, какая информация на нём должна быть и на каком языке он должен говорить с ЦА (это называют коммуникативной стратегией), как он будет отличаться от конкурентов (естественно, в выгодную сторону).

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

Лучше всего, конечно, исследование помогает понять аудиторию:

— Как с ней общаться: какие слова использовать в «разговоре» с ней, как называть свой продукт или услугу (возможно, нужно использовать профессиональный сленг, или наоборот, нарочито упрощённую терминологию), обращаться ли к ней на «вы» или на «ты».
— Каковы её потребности: что приоритетно, что необязательно, но желаемо, что нельзя делать ни в коем случае.

Где брать данные

В идеале, данные о контексте мы должны получить от клиента, но если таких данных у клиента нет, то исследование контекста предстоит провести самим.

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

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

Предвижу комментарии: дескать, самостоятельное исследование рядом не стояло с профессиональными маркетинговыми исследованиями — так зачем тратить время и ресурсы? На то есть несколько причин:

— Без данных о контексте ваши шансы сделать хорошо пользователю стремятся к нулю.
— Даже самостоятельное исследование даёт полезную информацию, пусть и в меньшем объёме, нежели профессиональное.
— И даже если вы настолько неумело проводите исследование (что маловероятно), что не можете получить ответы на вышеобозначенные вопросы, вы всё равно погружатаетесь в контекст проекта и хотя бы подсознательно улавливаете что-то полезное.

Могу сказать по собственному опыту: нам исследование помогало всегда, в любом проекте.

Создание концепции сайта

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

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

Концепция задаёт направление проектированию и помогает, аналогично видению, ещё раз состыковать точки зрения на проект — нашу и клиента.

Моделирование сайта

Моделирование — это создание модели сайта, которая описывает функциональные возможности и информационную структуру.

Функциональная часть модели

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

Информационная структура

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

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

— Задачи — какие из ранее поставленных задач решает раздел. Например, раздел «Фотографии» в социальной сети решает задачу обмена информацией между друзьями и последующего общения;
— Сообщения — это в буквальном смысле сообщения, которые раздел или его часть передаёт посетителю. Например, сообщение приветствия «Привет, ты на портале ХХХ! Мы рады видеть тебя здесь» или «Эй, это наш лучший товар — попробуй, закажи сейчас и убедись в этом сам!».
— Сообщения бывают разных типов; наиболее часто встречающиеся: рекламные, призывы к действию, уведомления и имиджевые сообщения.
— Функциональные элементы — элементы интерфейса, дающие возможность посетителю выполнить какую-то операцию. Например, функциональным элементом является форма для ввода сообщения, позволяющая отправить сообщение, или кнопка в интерфейсе, сохраняющая сделанные изменения.
— Варианты поведения посетителя — предположения о том, что посетитель сайта может или должен сделать после изучения интерфейса или отдельных его частей.

Мы обычно делаем такие схемы в виде mind maps — очень удобно, надо сказать.

Резюме

Как обычно, краткие выводы:

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

P.S.: Статья эта, очевидно, обзорная, для затравки, поскольку тему проектирования раскрыть в одной статье нереально. Практически любая мысль из этой статьи была неоднократно подтверждена нашим личным опытом, и обо всём мы расскажем позже, подробнее и с примерами.

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

Основываться только на поло-возрастных признаках клиентов

Это, по моему мнению, самая большая ошибка, которую можно допускать при сегментации — делать выводы исключительно на основании возраста и пола потребителей. Редко удается найти корреляцию демографических показателей и поведения пользователя. Единственный релевантный пример был получен нами при выявлении закономерности в поведении собственной аудитории. Мы считали отношение клиентов, совершающих транзакции, по возрасту и полу к общему количеству клиентов данного возраста и пола, процент кратно уменьшался для женщин от 35 лет, у мужчин спад был не так значителен. На основании этого было принято решение создавать обучающие видеоролики по совершению онлайн-покупок на Lamoda и Aliexpress.

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

Не обрабатывать данные

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

Не ограничивать период и географию

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

Не проводить тестирование

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

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

Не учитывать активность клиентов

Представим, что аналитик провел достаточно сложный кластерный анализ и нашел сегмент клиентов — владельцев кошек — по принципу регулярных покупок кошачьего корма. Он рад и счастлив, идет с этим инсайтом к директору по маркетингу, в итоге компания отправляет рассылку этим клиентам с акцией на новый премиум-корм со скидкой 50%. Но в результате конверсия в переход по ссылке из письма ниже ожидаемой. Все из-за того, что при формирования списка email-аналитик не учел факт, что анализ он проводил по данным за 3 года, и 50% покупателей более года не совершали покупки.

В первом пункте я приводила пример про интернет-магазин продуктов — это был «Утконос». Живя в Москве, я была предельно к нему лояльна, мне нравился их ассортимент, удобное время доставки: они могли доставлять еду даже в 3 ночи. Учитывая мой прежний график, это было весьма кстати, заказы я совершала минимум раз в месяц. Но вот уже 4 месяца я живу в Санкт-Петербурге, а SMS-сообщения от любимого когда-то «Утконоса», осуществляющего доставку продуктов только по Москве, мне продолжают приходить. Отсутствие заказов в течение срока, в четыре раза превышающий мой средний интервал, их не смущает, они тратят впустую бюджет на рассылки, а у меня фактически нет возможности совершить повторный заказ.

Не обновлять сегментацию

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

Использовать сегментацию только с целью определения ЦА

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

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

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

Основываться только на поло-возрастных признаках клиентов

Это, по моему мнению, самая большая ошибка, которую можно допускать при сегментации — делать выводы исключительно на основании возраста и пола потребителей. Редко удается найти корреляцию демографических показателей и поведения пользователя. Единственный релевантный пример был получен нами при выявлении закономерности в поведении собственной аудитории. Мы считали отношение клиентов, совершающих транзакции, по возрасту и полу к общему количеству клиентов данного возраста и пола, процент кратно уменьшался для женщин от 35 лет, у мужчин спад был не так значителен. На основании этого было принято решение создавать обучающие видеоролики по совершению онлайн-покупок на Lamoda и Aliexpress.

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

Не обрабатывать данные

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

Не ограничивать период и географию

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

Не проводить тестирование

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

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

Не учитывать активность клиентов

Представим, что аналитик провел достаточно сложный кластерный анализ и нашел сегмент клиентов — владельцев кошек — по принципу регулярных покупок кошачьего корма. Он рад и счастлив, идет с этим инсайтом к директору по маркетингу, в итоге компания отправляет рассылку этим клиентам с акцией на новый премиум-корм со скидкой 50%. Но в результате конверсия в переход по ссылке из письма ниже ожидаемой. Все из-за того, что при формирования списка email-аналитик не учел факт, что анализ он проводил по данным за 3 года, и 50% покупателей более года не совершали покупки.

В первом пункте я приводила пример про интернет-магазин продуктов — это был «Утконос». Живя в Москве, я была предельно к нему лояльна, мне нравился их ассортимент, удобное время доставки: они могли доставлять еду даже в 3 ночи. Учитывая мой прежний график, это было весьма кстати, заказы я совершала минимум раз в месяц. Но вот уже 4 месяца я живу в Санкт-Петербурге, а SMS-сообщения от любимого когда-то «Утконоса», осуществляющего доставку продуктов только по Москве, мне продолжают приходить. Отсутствие заказов в течение срока, в четыре раза превышающий мой средний интервал, их не смущает, они тратят впустую бюджет на рассылки, а у меня фактически нет возможности совершить повторный заказ.

Не обновлять сегментацию

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

Использовать сегментацию только с целью определения ЦА

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

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

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

Главный метод определения целевой аудитории в современном маркетинге — сегментация. Сегментация — это разделение клиентов на группы по заданным параметрам.

Для чего нужно сегментировать аудиторию?

Во-первых, чтобы понимать, кто ваш клиент, какие у него потребности, и на основании этого правильно позиционировать компанию.

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

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

По данным Website builder, 44% людей, получавших таргетированные письма, совершили как минимум одну покупку по содержащимся в них предложениям.

— В среднем, сегментация повышает open rate на 14,69%, а click rate — на 60%.

При проведении исследования 52% опрошенных маркетологов сказали о необходимости сегментации базы данных в email-рассылках, так как индивидуальные предложения приносят в 18 раз больше доходов, чем широковещательные.

Какие данные сегментировать

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

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

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

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

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

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

Важные принципы проведения опросов

— Опрашивайте клиентов, у которых уже есть опыт использования вашего продукта или схожего продукта конкурентов.
— Задавайте открытые вопросы. Например, «Сколько бы вы заплатили за этот продукт?» вместо «Вы заплатили бы 100, 200 или 300 рублей?» или «Заплатили бы вы 500 рублей за этот продукт?». В противном случае срабатывает «эффект якоря» и человек будет отталкиваться от обозначенной суммы при ответе.
— Если вопрос относится к проблеме или боли клиента, то спросите, как он ее решает. Если в ответ последует «никак», то приоритет у этой проблемы не так высок, как это описывает интервьюируемый.
— Избегайте обобщений. Вместо формулировки «Как часто вы пользуетесь сервисом?» используете «Сколько раз в месяц вы пользуетесь сервисом?».
— Для подтверждения позитивной позиции клиента попросите его совершить конкретное действие здесь и сейчас: подписаться на группу в соцсетях, заплатить за продукт, оставить контакты. Если он не готов этого совершить, то вряд ли он действительно купит продукт в будущем.
— Задавайте уточняющие вопросы. Если клиент говорит, что часто сталкивается с обозначенной проблемой, спросите, когда он сталкивался с ней в последний раз, после чего ответ может измениться.

Как сегментировать

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

Сегментацию можно проводить даже в Excel, для более сложной аналитики и большого объема данных можно использовать методы машинного обучения, языки Python, R, Scala, набирающий популярность Julia и другие.

— Существует два крупных типа сегментаций: на основании статических и динамических данных.

Статические данные — критерии пользователей, которые не зависят от его действий, не меняются или меняются редко. К показателям статической сегментации относят: пол, возраст, географические данные.

Динамические показатели — те, что формируются на основании поведения пользователя относительно других пользователей: RFM-кластеризация, размер среднего чека, частота покупок и так далее. Границы сегментов, сформированных на основании поведения, динамические и меняются при совершении каждой новой покупки.

Пошаговое руководство проведения сегментации

1. Определить цель сегментации:

— кто будет использовать результаты сегментации;
— для чего они будут использоваться.

2. Выбрать один из методов сегментации или создать собственный алгоритм вычисления.

3. Понять, какие данные необходимы:

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

4. Обработать и подготовить данные:

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

— — посчитать стандартное отклонение. Факт его значительного отличия от среднего значения говорит о том, что в выборке присутствуют выбросы;
— — вычислить медиану — величину, находящуюся в середине набора данных, упорядоченного по возрастанию или убыванию. Если количество членов нечетное, то она принимает значение суммы двух срединных членов, деленной на два;
— — вычислить верхнюю и нижнюю границу квартиля — величин, за пределами которых (выше и ниже соответственно) находится 25% значений;
— — все, что лежит выше суммы (разности) верхней (нижней) границы квартиля и межквартильного расстояния, умноженного на 1,5, является выбросами.

Выше я говорила о том, что данные опросов, как и количественные данные, можно сегментировать, но прежде их надо обработать:

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

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

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

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

Давайте теперь разберем несколько методологий проведения сегментации.

RFM-анализ

RFM-анализ — это анализ по трем показателям:

— Recency — показатель активности, вычисляется как давность последнего действия клиента (покупки, авторизации в личном кабинете, открытия email-рассылки и др.).
— Frequency — количество покупок (других действий) клиента.
— Monetary — Lifetime value, жизненная ценность клиента, равна сумме его покупок или прибыли.

Часто при проведении RFM-анализа клиентов по каждому из параметров делят на группы по равным интервалам от минимального до максимального значения. Например, давность (recency) последней покупки до 1 недели, до 2 недель, до 3 недель.

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

Индексы 1 и 3 в рамках RFM-анализа характеры для исключительных клиентов с различными особенностями поведения. Так, клиенты кластера r1m3 (при любом значении f) — это покупатели, которые ранее были доходны для компании, но перестали совершать покупки, причину чего необходимо выяснить с помощью опросов.

Кластер r3f3m1 является потенциальным для увеличения LTV (monetary), так как клиенты проявляют лояльность, но при этом совершают покупки на небольшие суммы. В такой ситуации следует предложить покупателям скидку при покупке на сумму от N рублей, либо порекомендовать сопутствующие товары на основании истории их покупок.

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

Кластерный анализ

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

Мы чаще всего используем одну из разновидностей кластерного анализа — k-means.

Алгоритм анализа следующий.

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

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

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

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

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

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

Также данный вид сегментации можно использовать для анализа опросов. Но так как текстовые данные сложно преобразовать в числовые индексы, тем более, если речь идет о тысячах анкетируемых, то мы рекомендуем задавать вопросы формата «Оцените важность/качество/ величину… от 1 до 5».

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

Владельцы дебетовых карт:

— экономные — наивысшие оценки были поставлены фактору «стоимость годового обслуживания»;
— используют карту для переводов — важен размер комиссии за переводы на карты других банков;
— конформисты — оценили важность факторов «репутация бренда» и «отзывы» на 5 из 5, «стоимость обслуживания» — на 4.

Юридические лица, регулярно совершающие расчетно-кассовые операции:

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

Анализ ассоциативных правил

Анализ ассоциативных правил (анализ рыночной корзины) — анализ, который используется для нахождения устойчивых сочетаний товаров в покупках. Для его вычисления есть множество алгоритмов, первый из них — AIS — был разработан в 1993 году. Для анализа необходима база данных покупок, каждая покупка должна иметь уникальный идентификатор (часто в этой роли выступает номер чека) и позиции, которые входят в него.

Что в этих случаях делать компаниям, которые не входят в сегмент FMCG? Мы предлагаем использовать и используем в собственном бизнесе вместо номера чека уникальный id клиента. Таким образом мы вычисляем устойчивые паттерны в поведении клиентов относительно истории их покупок, на основании которых строим рекомендательную систему.

Допустим, покупки на Aviasales совершили 3 тысячи человек, на Booking — 1 тысяча. Клиентов, которые совершили покупки как на Aviasales, так и на Booking — 500. Объем клиентской базы равен 5 тысячам клиентов.

На основании этих данных высчитываются два показателя: достоверность (confidence) и поддержка (support) правила.

Поддержка — доля клиентов, совершивших транзакции у обоих партнеров от общего числа транзакций, то есть 10%.

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

Достоверность, как вы уже поняли, имеет два значения, в нашем случае для Booking она равна 50%, для Aviasales — 16,7%. Это означает, что клиент вероятнее совершает покупку на Booking и потом совершает на Aviasales, чем наоборот.

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

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

Главный метод определения целевой аудитории в современном маркетинге — сегментация. Сегментация — это разделение клиентов на группы по заданным параметрам.

Для чего нужно сегментировать аудиторию?

Во-первых, чтобы понимать, кто ваш клиент, какие у него потребности, и на основании этого правильно позиционировать компанию.

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

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

По данным Website builder, 44% людей, получавших таргетированные письма, совершили как минимум одну покупку по содержащимся в них предложениям.

— В среднем, сегментация повышает open rate на 14,69%, а click rate — на 60%.

При проведении исследования 52% опрошенных маркетологов сказали о необходимости сегментации базы данных в email-рассылках, так как индивидуальные предложения приносят в 18 раз больше доходов, чем широковещательные.

Какие данные сегментировать

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

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

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

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

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

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

Важные принципы проведения опросов

— Опрашивайте клиентов, у которых уже есть опыт использования вашего продукта или схожего продукта конкурентов.
— Задавайте открытые вопросы. Например, «Сколько бы вы заплатили за этот продукт?» вместо «Вы заплатили бы 100, 200 или 300 рублей?» или «Заплатили бы вы 500 рублей за этот продукт?». В противном случае срабатывает «эффект якоря» и человек будет отталкиваться от обозначенной суммы при ответе.
— Если вопрос относится к проблеме или боли клиента, то спросите, как он ее решает. Если в ответ последует «никак», то приоритет у этой проблемы не так высок, как это описывает интервьюируемый.
— Избегайте обобщений. Вместо формулировки «Как часто вы пользуетесь сервисом?» используете «Сколько раз в месяц вы пользуетесь сервисом?».
— Для подтверждения позитивной позиции клиента попросите его совершить конкретное действие здесь и сейчас: подписаться на группу в соцсетях, заплатить за продукт, оставить контакты. Если он не готов этого совершить, то вряд ли он действительно купит продукт в будущем.
— Задавайте уточняющие вопросы. Если клиент говорит, что часто сталкивается с обозначенной проблемой, спросите, когда он сталкивался с ней в последний раз, после чего ответ может измениться.

Как сегментировать

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

Сегментацию можно проводить даже в Excel, для более сложной аналитики и большого объема данных можно использовать методы машинного обучения, языки Python, R, Scala, набирающий популярность Julia и другие.

— Существует два крупных типа сегментаций: на основании статических и динамических данных.

Статические данные — критерии пользователей, которые не зависят от его действий, не меняются или меняются редко. К показателям статической сегментации относят: пол, возраст, географические данные.

Динамические показатели — те, что формируются на основании поведения пользователя относительно других пользователей: RFM-кластеризация, размер среднего чека, частота покупок и так далее. Границы сегментов, сформированных на основании поведения, динамические и меняются при совершении каждой новой покупки.

Пошаговое руководство проведения сегментации

1. Определить цель сегментации:

— кто будет использовать результаты сегментации;
— для чего они будут использоваться.

2. Выбрать один из методов сегментации или создать собственный алгоритм вычисления.

3. Понять, какие данные необходимы:

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

4. Обработать и подготовить данные:

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

— — посчитать стандартное отклонение. Факт его значительного отличия от среднего значения говорит о том, что в выборке присутствуют выбросы;
— — вычислить медиану — величину, находящуюся в середине набора данных, упорядоченного по возрастанию или убыванию. Если количество членов нечетное, то она принимает значение суммы двух срединных членов, деленной на два;
— — вычислить верхнюю и нижнюю границу квартиля — величин, за пределами которых (выше и ниже соответственно) находится 25% значений;
— — все, что лежит выше суммы (разности) верхней (нижней) границы квартиля и межквартильного расстояния, умноженного на 1,5, является выбросами.

Выше я говорила о том, что данные опросов, как и количественные данные, можно сегментировать, но прежде их надо обработать:

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

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

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

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

Давайте теперь разберем несколько методологий проведения сегментации.

RFM-анализ

RFM-анализ — это анализ по трем показателям:

— Recency — показатель активности, вычисляется как давность последнего действия клиента (покупки, авторизации в личном кабинете, открытия email-рассылки и др.).
— Frequency — количество покупок (других действий) клиента.
— Monetary — Lifetime value, жизненная ценность клиента, равна сумме его покупок или прибыли.

Часто при проведении RFM-анализа клиентов по каждому из параметров делят на группы по равным интервалам от минимального до максимального значения. Например, давность (recency) последней покупки до 1 недели, до 2 недель, до 3 недель.

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

Индексы 1 и 3 в рамках RFM-анализа характеры для исключительных клиентов с различными особенностями поведения. Так, клиенты кластера r1m3 (при любом значении f) — это покупатели, которые ранее были доходны для компании, но перестали совершать покупки, причину чего необходимо выяснить с помощью опросов.

Кластер r3f3m1 является потенциальным для увеличения LTV (monetary), так как клиенты проявляют лояльность, но при этом совершают покупки на небольшие суммы. В такой ситуации следует предложить покупателям скидку при покупке на сумму от N рублей, либо порекомендовать сопутствующие товары на основании истории их покупок.

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

Кластерный анализ

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

Мы чаще всего используем одну из разновидностей кластерного анализа — k-means.

Алгоритм анализа следующий.

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

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

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

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

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

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

Также данный вид сегментации можно использовать для анализа опросов. Но так как текстовые данные сложно преобразовать в числовые индексы, тем более, если речь идет о тысячах анкетируемых, то мы рекомендуем задавать вопросы формата «Оцените важность/качество/ величину… от 1 до 5».

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

Владельцы дебетовых карт:

— экономные — наивысшие оценки были поставлены фактору «стоимость годового обслуживания»;
— используют карту для переводов — важен размер комиссии за переводы на карты других банков;
— конформисты — оценили важность факторов «репутация бренда» и «отзывы» на 5 из 5, «стоимость обслуживания» — на 4.

Юридические лица, регулярно совершающие расчетно-кассовые операции:

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

Анализ ассоциативных правил

Анализ ассоциативных правил (анализ рыночной корзины) — анализ, который используется для нахождения устойчивых сочетаний товаров в покупках. Для его вычисления есть множество алгоритмов, первый из них — AIS — был разработан в 1993 году. Для анализа необходима база данных покупок, каждая покупка должна иметь уникальный идентификатор (часто в этой роли выступает номер чека) и позиции, которые входят в него.

Что в этих случаях делать компаниям, которые не входят в сегмент FMCG? Мы предлагаем использовать и используем в собственном бизнесе вместо номера чека уникальный id клиента. Таким образом мы вычисляем устойчивые паттерны в поведении клиентов относительно истории их покупок, на основании которых строим рекомендательную систему.

Допустим, покупки на Aviasales совершили 3 тысячи человек, на Booking — 1 тысяча. Клиентов, которые совершили покупки как на Aviasales, так и на Booking — 500. Объем клиентской базы равен 5 тысячам клиентов.

На основании этих данных высчитываются два показателя: достоверность (confidence) и поддержка (support) правила.

Поддержка — доля клиентов, совершивших транзакции у обоих партнеров от общего числа транзакций, то есть 10%.

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

Достоверность, как вы уже поняли, имеет два значения, в нашем случае для Booking она равна 50%, для Aviasales — 16,7%. Это означает, что клиент вероятнее совершает покупку на Booking и потом совершает на Aviasales, чем наоборот.

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

Любое приложение пишется для решения конкретной задачи. Софт под задачи бизнеса должен гибко реагировать на изменения, и чем проще и меньше время реакции, тем больше софт жизнеспособен в конкретной среде.

Соответственно, разработчик (и руководитель проекта, и владелец продукта, и конечный потребитель) должен с самого начала осознать — что и зачем.

Без ответов на эти вопросы приступать к разработке глупо.

Быстрые прототипы и мгновенная обратная связь с заказчиком

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

Тут хорошо показывают себя Ruby on Rails/Laravel/Nest.js/Django. Подобные вещи помогают сохранять высокий темп разработки. Иначе бизнес может поменять концепцию, сократить бюджет или даже закрыть проект. А участники разработки без очевидных результатов рискуют просто перегореть.

Про окружение

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

Сейчас верстка под разные экраны — самая незначительная забота. Мы живём в то время, когда уже нет той боли в эпоху IE6-7-8-9. Сегодня гораздо проще работать с интерфейсами, особенно с повсеместным переходом браузеров на WebKit.

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

Говоря о логике построения интерфейсов, стоит помнить, что несмотря на обилие различных фреймворков (Angular, React, Vue), предлагающих упростить разработку фронтенда, по неопытности строят монструозные системы, не думая, нужен ли этот код на странице. Страница оказывается перегружена, долго отрисовывается, плохо работает на мобильных устройствах. Как следствие, пользователи отказываются от приложения, бизнес теряет клиентов и деньги.
Помним про безопасность

Сегодня много спорят, как обмениваться данными — REST / SOAP / GraphQL — и при этом передают важную информацию в незашифрованном виде. Буквально недавно мы столкнулись с проектом, который получили на доработку, и обнаружили, что если в момент аутентификации отключить интернет, то приложение выдаёт ошибку «ERROR» и показывает пару логин/пароль.

Про декомпозицию

Если говорить об организации процессов, то всегда нужно иметь в виду, что должно быть продакшн-окружение и тестовое окружение, где можно все протестировать, проверить. И да, бэкапы нужны всего и всегда. Создание софта всегда следует декомпозировать на отдельные участки, на каждом выполняется своя работа — бэкенд, фронтенд, тестирование, не говоря про аналитиков, UX & UI designer, devops инженера.

Full-stack — это круто, но рискованно, использовать можно и нужно, но дозированно. Фронт и бэк всё-таки стоит разделять, иначе люди быстро сгорают или темп проекта замедляется, особенно когда идёт работа над большим приложением.

Про важное

Не так важно, MVC или MVP.

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

Важно говорить на одном внятном языке.

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

Важно знать свои инструменты.

Изолируйте, что можете. Поверьте, будет меньше боли.

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

Помните про 12 факторов

Всё, что я рассказал, и даже больше содержатся в принципах 12-факторного приложения — открытой методике создания веб-сервисов, которая содержит общие декларации разработки софта, вне зависимости от платформы, языка разработки, назначения и т.п. Эти 12 факторов и есть 12 правил правильного написания приложений.

К сожалению, вот эти 12 факторов чаще всего открывают для себя на позиции middle/senior, когда уже обжигаются на ошибках, которых можно было бы избежать. Используйте это как направляющую в любых проектах!

Любое приложение пишется для решения конкретной задачи. Софт под задачи бизнеса должен гибко реагировать на изменения, и чем проще и меньше время реакции, тем больше софт жизнеспособен в конкретной среде.

Соответственно, разработчик (и руководитель проекта, и владелец продукта, и конечный потребитель) должен с самого начала осознать — что и зачем.

Без ответов на эти вопросы приступать к разработке глупо.

Быстрые прототипы и мгновенная обратная связь с заказчиком

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

Тут хорошо показывают себя Ruby on Rails/Laravel/Nest.js/Django. Подобные вещи помогают сохранять высокий темп разработки. Иначе бизнес может поменять концепцию, сократить бюджет или даже закрыть проект. А участники разработки без очевидных результатов рискуют просто перегореть.

Про окружение

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

Сейчас верстка под разные экраны — самая незначительная забота. Мы живём в то время, когда уже нет той боли в эпоху IE6-7-8-9. Сегодня гораздо проще работать с интерфейсами, особенно с повсеместным переходом браузеров на WebKit.

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

Говоря о логике построения интерфейсов, стоит помнить, что несмотря на обилие различных фреймворков (Angular, React, Vue), предлагающих упростить разработку фронтенда, по неопытности строят монструозные системы, не думая, нужен ли этот код на странице. Страница оказывается перегружена, долго отрисовывается, плохо работает на мобильных устройствах. Как следствие, пользователи отказываются от приложения, бизнес теряет клиентов и деньги.
Помним про безопасность

Сегодня много спорят, как обмениваться данными — REST / SOAP / GraphQL — и при этом передают важную информацию в незашифрованном виде. Буквально недавно мы столкнулись с проектом, который получили на доработку, и обнаружили, что если в момент аутентификации отключить интернет, то приложение выдаёт ошибку «ERROR» и показывает пару логин/пароль.

Про декомпозицию

Если говорить об организации процессов, то всегда нужно иметь в виду, что должно быть продакшн-окружение и тестовое окружение, где можно все протестировать, проверить. И да, бэкапы нужны всего и всегда. Создание софта всегда следует декомпозировать на отдельные участки, на каждом выполняется своя работа — бэкенд, фронтенд, тестирование, не говоря про аналитиков, UX & UI designer, devops инженера.

Full-stack — это круто, но рискованно, использовать можно и нужно, но дозированно. Фронт и бэк всё-таки стоит разделять, иначе люди быстро сгорают или темп проекта замедляется, особенно когда идёт работа над большим приложением.

Про важное

Не так важно, MVC или MVP.

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

Важно говорить на одном внятном языке.

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

Важно знать свои инструменты.

Изолируйте, что можете. Поверьте, будет меньше боли.

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

Помните про 12 факторов

Всё, что я рассказал, и даже больше содержатся в принципах 12-факторного приложения — открытой методике создания веб-сервисов, которая содержит общие декларации разработки софта, вне зависимости от платформы, языка разработки, назначения и т.п. Эти 12 факторов и есть 12 правил правильного написания приложений.

К сожалению, вот эти 12 факторов чаще всего открывают для себя на позиции middle/senior, когда уже обжигаются на ошибках, которых можно было бы избежать. Используйте это как направляющую в любых проектах!

Любое приложение пишется для решения конкретной задачи. Софт под задачи бизнеса должен гибко реагировать на изменения, и чем проще и меньше время реакции, тем больше софт жизнеспособен в конкретной среде.

Соответственно, разработчик (и руководитель проекта, и владелец продукта, и конечный потребитель) должен с самого начала осознать — что и зачем.

Без ответов на эти вопросы приступать к разработке глупо.

Быстрые прототипы и мгновенная обратная связь с заказчиком

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

Тут хорошо показывают себя Ruby on Rails/Laravel/Nest.js/Django. Подобные вещи помогают сохранять высокий темп разработки. Иначе бизнес может поменять концепцию, сократить бюджет или даже закрыть проект. А участники разработки без очевидных результатов рискуют просто перегореть.

Про окружение

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

Сейчас верстка под разные экраны — самая незначительная забота. Мы живём в то время, когда уже нет той боли в эпоху IE6-7-8-9. Сегодня гораздо проще работать с интерфейсами, особенно с повсеместным переходом браузеров на WebKit.

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

Говоря о логике построения интерфейсов, стоит помнить, что несмотря на обилие различных фреймворков (Angular, React, Vue), предлагающих упростить разработку фронтенда, по неопытности строят монструозные системы, не думая, нужен ли этот код на странице. Страница оказывается перегружена, долго отрисовывается, плохо работает на мобильных устройствах. Как следствие, пользователи отказываются от приложения, бизнес теряет клиентов и деньги.
Помним про безопасность

Сегодня много спорят, как обмениваться данными — REST / SOAP / GraphQL — и при этом передают важную информацию в незашифрованном виде. Буквально недавно мы столкнулись с проектом, который получили на доработку, и обнаружили, что если в момент аутентификации отключить интернет, то приложение выдаёт ошибку «ERROR» и показывает пару логин/пароль.

Про декомпозицию

Если говорить об организации процессов, то всегда нужно иметь в виду, что должно быть продакшн-окружение и тестовое окружение, где можно все протестировать, проверить. И да, бэкапы нужны всего и всегда. Создание софта всегда следует декомпозировать на отдельные участки, на каждом выполняется своя работа — бэкенд, фронтенд, тестирование, не говоря про аналитиков, UX & UI designer, devops инженера.

Full-stack — это круто, но рискованно, использовать можно и нужно, но дозированно. Фронт и бэк всё-таки стоит разделять, иначе люди быстро сгорают или темп проекта замедляется, особенно когда идёт работа над большим приложением.

Про важное

Не так важно, MVC или MVP.

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

Важно говорить на одном внятном языке.

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

Важно знать свои инструменты.

Изолируйте, что можете. Поверьте, будет меньше боли.

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

Помните про 12 факторов

Всё, что я рассказал, и даже больше содержатся в принципах 12-факторного приложения — открытой методике создания веб-сервисов, которая содержит общие декларации разработки софта, вне зависимости от платформы, языка разработки, назначения и т.п. Эти 12 факторов и есть 12 правил правильного написания приложений.

К сожалению, вот эти 12 факторов чаще всего открывают для себя на позиции middle/senior, когда уже обжигаются на ошибках, которых можно было бы избежать. Используйте это как направляющую в любых проектах!

Любое приложение пишется для решения конкретной задачи. Софт под задачи бизнеса должен гибко реагировать на изменения, и чем проще и меньше время реакции, тем больше софт жизнеспособен в конкретной среде.

Соответственно, разработчик (и руководитель проекта, и владелец продукта, и конечный потребитель) должен с самого начала осознать — что и зачем.

Без ответов на эти вопросы приступать к разработке глупо.

Быстрые прототипы и мгновенная обратная связь с заказчиком

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

Тут хорошо показывают себя Ruby on Rails/Laravel/Nest.js/Django. Подобные вещи помогают сохранять высокий темп разработки. Иначе бизнес может поменять концепцию, сократить бюджет или даже закрыть проект. А участники разработки без очевидных результатов рискуют просто перегореть.

Про окружение

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

Сейчас верстка под разные экраны — самая незначительная забота. Мы живём в то время, когда уже нет той боли в эпоху IE6-7-8-9. Сегодня гораздо проще работать с интерфейсами, особенно с повсеместным переходом браузеров на WebKit.

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

Говоря о логике построения интерфейсов, стоит помнить, что несмотря на обилие различных фреймворков (Angular, React, Vue), предлагающих упростить разработку фронтенда, по неопытности строят монструозные системы, не думая, нужен ли этот код на странице. Страница оказывается перегружена, долго отрисовывается, плохо работает на мобильных устройствах. Как следствие, пользователи отказываются от приложения, бизнес теряет клиентов и деньги.
Помним про безопасность

Сегодня много спорят, как обмениваться данными — REST / SOAP / GraphQL — и при этом передают важную информацию в незашифрованном виде. Буквально недавно мы столкнулись с проектом, который получили на доработку, и обнаружили, что если в момент аутентификации отключить интернет, то приложение выдаёт ошибку «ERROR» и показывает пару логин/пароль.

Про декомпозицию

Если говорить об организации процессов, то всегда нужно иметь в виду, что должно быть продакшн-окружение и тестовое окружение, где можно все протестировать, проверить. И да, бэкапы нужны всего и всегда. Создание софта всегда следует декомпозировать на отдельные участки, на каждом выполняется своя работа — бэкенд, фронтенд, тестирование, не говоря про аналитиков, UX & UI designer, devops инженера.

Full-stack — это круто, но рискованно, использовать можно и нужно, но дозированно. Фронт и бэк всё-таки стоит разделять, иначе люди быстро сгорают или темп проекта замедляется, особенно когда идёт работа над большим приложением.

Про важное

Не так важно, MVC или MVP.

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

Важно говорить на одном внятном языке.

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

Важно знать свои инструменты.

Изолируйте, что можете. Поверьте, будет меньше боли.

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

Помните про 12 факторов

Всё, что я рассказал, и даже больше содержатся в принципах 12-факторного приложения — открытой методике создания веб-сервисов, которая содержит общие декларации разработки софта, вне зависимости от платформы, языка разработки, назначения и т.п. Эти 12 факторов и есть 12 правил правильного написания приложений.

К сожалению, вот эти 12 факторов чаще всего открывают для себя на позиции middle/senior, когда уже обжигаются на ошибках, которых можно было бы избежать. Используйте это как направляющую в любых проектах!

Существует множество способов разработки веб-приложения. Одним из самых современных считается реализация фронтенда как SPA (single page application), где взаимодействие с бэкендом происходит через REST API. Рассмотрим каждый из компонентов этой схемы детально.

Бэкенд

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

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

Тут всё не так однозначно. Если не так важна производительность, то можно реализовывать на NodeJS (фреймворки ExpressJS, KoaJS, GatsbyJS), Python (фреймворки Django, Flask), Ruby (фреймворки Ruby on Rails, Grape). Если важна скорость — используйте Golang (фреймворки Gingonic, Beego, Revel). Думаю, самое верное решение — писать на том языке, который знаете. Мне, например, очень нравится Ruby и фреймворк Ruby on Rails.

Как реализовывать

Придерживайтесь паттерна MVC, и в какой-то момент вы заметите, что усложняется бизнес-логика. И дальше возникнет вопрос: где её реализовывать? В контроллерах или моделях? Один из наиболее простых и удобных способов — использовать интеракторы и презентеры.

Тестирование бэкенда

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

Сваггер

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

Фронтенд

Тут всё не так просто, так как фреймворков очень много. Сейчас в основном используют AngularJS, ReactJS, VueJS. У каждого есть свои достоинства и недостатки. Я бы выбрал ReactJS: он достаточно простой и гибкий.

Тестирование фронтенда

Для фронтенда есть два основных типа тестов — тесты на логику и тесты на отображение. Первые проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы контент демонстрировался пользователю в задуманном виде. Можно использовать следующие фреймворки: Mocha, Chai, Jest, Ava, Enzyme, Jest.

Отслеживание качества контента

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

Существует множество способов разработки веб-приложения. Одним из самых современных считается реализация фронтенда как SPA (single page application), где взаимодействие с бэкендом происходит через REST API. Рассмотрим каждый из компонентов этой схемы детально.

Бэкенд

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

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

Тут всё не так однозначно. Если не так важна производительность, то можно реализовывать на NodeJS (фреймворки ExpressJS, KoaJS, GatsbyJS), Python (фреймворки Django, Flask), Ruby (фреймворки Ruby on Rails, Grape). Если важна скорость — используйте Golang (фреймворки Gingonic, Beego, Revel). Думаю, самое верное решение — писать на том языке, который знаете. Мне, например, очень нравится Ruby и фреймворк Ruby on Rails.

Как реализовывать

Придерживайтесь паттерна MVC, и в какой-то момент вы заметите, что усложняется бизнес-логика. И дальше возникнет вопрос: где её реализовывать? В контроллерах или моделях? Один из наиболее простых и удобных способов — использовать интеракторы и презентеры.

Тестирование бэкенда

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

Сваггер

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

Фронтенд

Тут всё не так просто, так как фреймворков очень много. Сейчас в основном используют AngularJS, ReactJS, VueJS. У каждого есть свои достоинства и недостатки. Я бы выбрал ReactJS: он достаточно простой и гибкий.

Тестирование фронтенда

Для фронтенда есть два основных типа тестов — тесты на логику и тесты на отображение. Первые проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы контент демонстрировался пользователю в задуманном виде. Можно использовать следующие фреймворки: Mocha, Chai, Jest, Ava, Enzyme, Jest.

Отслеживание качества контента

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

Существует множество способов разработки веб-приложения. Одним из самых современных считается реализация фронтенда как SPA (single page application), где взаимодействие с бэкендом происходит через REST API. Рассмотрим каждый из компонентов этой схемы детально.

Бэкенд

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

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

Тут всё не так однозначно. Если не так важна производительность, то можно реализовывать на NodeJS (фреймворки ExpressJS, KoaJS, GatsbyJS), Python (фреймворки Django, Flask), Ruby (фреймворки Ruby on Rails, Grape). Если важна скорость — используйте Golang (фреймворки Gingonic, Beego, Revel). Думаю, самое верное решение — писать на том языке, который знаете. Мне, например, очень нравится Ruby и фреймворк Ruby on Rails.

Как реализовывать

Придерживайтесь паттерна MVC, и в какой-то момент вы заметите, что усложняется бизнес-логика. И дальше возникнет вопрос: где её реализовывать? В контроллерах или моделях? Один из наиболее простых и удобных способов — использовать интеракторы и презентеры.

Тестирование бэкенда

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

Сваггер

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

Фронтенд

Тут всё не так просто, так как фреймворков очень много. Сейчас в основном используют AngularJS, ReactJS, VueJS. У каждого есть свои достоинства и недостатки. Я бы выбрал ReactJS: он достаточно простой и гибкий.

Тестирование фронтенда

Для фронтенда есть два основных типа тестов — тесты на логику и тесты на отображение. Первые проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы контент демонстрировался пользователю в задуманном виде. Можно использовать следующие фреймворки: Mocha, Chai, Jest, Ava, Enzyme, Jest.

Отслеживание качества контента

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

Существует множество способов разработки веб-приложения. Одним из самых современных считается реализация фронтенда как SPA (single page application), где взаимодействие с бэкендом происходит через REST API. Рассмотрим каждый из компонентов этой схемы детально.

Бэкенд

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

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

Тут всё не так однозначно. Если не так важна производительность, то можно реализовывать на NodeJS (фреймворки ExpressJS, KoaJS, GatsbyJS), Python (фреймворки Django, Flask), Ruby (фреймворки Ruby on Rails, Grape). Если важна скорость — используйте Golang (фреймворки Gingonic, Beego, Revel). Думаю, самое верное решение — писать на том языке, который знаете. Мне, например, очень нравится Ruby и фреймворк Ruby on Rails.

Как реализовывать

Придерживайтесь паттерна MVC, и в какой-то момент вы заметите, что усложняется бизнес-логика. И дальше возникнет вопрос: где её реализовывать? В контроллерах или моделях? Один из наиболее простых и удобных способов — использовать интеракторы и презентеры.

Тестирование бэкенда

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

Сваггер

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

Фронтенд

Тут всё не так просто, так как фреймворков очень много. Сейчас в основном используют AngularJS, ReactJS, VueJS. У каждого есть свои достоинства и недостатки. Я бы выбрал ReactJS: он достаточно простой и гибкий.

Тестирование фронтенда

Для фронтенда есть два основных типа тестов — тесты на логику и тесты на отображение. Первые проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы контент демонстрировался пользователю в задуманном виде. Можно использовать следующие фреймворки: Mocha, Chai, Jest, Ava, Enzyme, Jest.

Отслеживание качества контента

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