Ключевые действия пользователя определяющие его retention

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

Начну с того, что я выделяю 3 вида пользовательских действий в продукте:

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

В разных продуктах конфигурация и количество этих 3-х типов действий - разные. 

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

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

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

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

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

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

Первое целевое действие - нерегулярное (среднее время совершения такого действия = 57 дней).

Activation Matrix: Action 1 - `a1`.

Перед вами Activation Matrix.

По оси X: количество действий совершенных клиентом.
По оси Y: порядковый номер повторного действия
(первое действие имеет индекс `0`, повторные начинаются с индекса `1`)

Как мы видим, с ростом количества действий среднее количество времени между этими действиями (латентность) - изменяется не сильно. 

Так например, клиент, который совершил 3 действия, в среднем повторял их через 57 дней. 

В тоже время, клиент, который совершил 9 действий, в среднем повторял их через 53 дней

Второе целевое действие - регулярное (среднее время совершения такого действия = 10 дней).

Activation Matrix: Action 2 - `a2`.

Здесь, активность пользователя с ростом количества действий нарастает.

Клиент, который совершил 3 действия, в среднем повторял их через 13 дней. 

В тоже время, клиент, который совершил 9 действий, в среднем повторял их через 9 дней.

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

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

Для ответа на этот вопрос нам придется сделать специфические расчеты:

• по каждому пользователю рассчитать латентность между его действиями (ax_lat_avg)
• агрегировать по этой латентности пользователей, чтобы понять сколько пользователей ведут себя таким образом (sample)
• определить сколько пользователей из sample сделает еще 1+ ключевое действие через период Z (retained)
• рассчитать взвешенную конверсию перехода в период Z (impact)

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

Impact table: `a1`.

Что мы видим?

1. Самая большая выборка (sample) у нас это те, кто совершил повторное действие `a1` очень быстро - всего через 1 день. Из этой же выборки, в абсолютном выражении, больше всего клиентов было удержано. Однако взвешенный % удержанных клиентов самый маленький для этого действия (9.04%).
2. С точки зрения относительных цифр, самый эффективный предиктор по удержанию - это клиенты, которые совершают повторное действие `a1` через 7 дней. Здесь взвешенный % удержанных клиентов самый большой для этого действия (10.01%).

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

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

Impact table: `a2`.

Что мы видим здесь?

1. Самая большая выборка у нас это те, кто совершал повторные действия `a2` раз в 3 дня. Из этой же выборки, в абсолютном выражении, больше всего клиентов было удержано. Взвешенный % удержанных клиентов входит в тройку лучших для этого действия.
2. С точки зрения относительных цифр, самый эффективный предиктор по удержанию - это клиенты, которые совершают повторное действие `a2` через 5 дней (43.34%).

Очевидно, что целевое действие `a2` (повторяемое раз 5 дней) является ключевым в сравнении с действием `a1`.

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

Во-вторых, взвешенный % удержанных клиентов уже существенно выше (40+%).

Резюмируя, можно сказать, что более регулярные действия клиентов, обычно, имеют более высокое влияние (impact) на удержание. И частота совершения таких действий, как правило, является ключевым компонентом построения привычки. А привычка является базой для повторного пользования продукта, т.е. удержания клиента. Первым прокси для построения привычки является aha-момент.

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

Также отмечу, что, если частота пользования продуктом начинает замедляться, то весьма вероятно, что вам нужно: 

• запускать механики реактивации по повторному использованию продукта 
• разбираться почему клиент не смог получить value за этот промежуток времени (например: user flow стало сложнее или появился технический баг).