Техническая сторона продуктовой аналитики

Опубликовано: 05 мар 2021

Мнение автора блога о том, что стоит за продуктовой аналитикой в техническом плане и почему.

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

Сырые данные (raw data) в аналитическом хранилище данных (DWH)
SQL
Эксплораторный анализ: pandas, matplotlib и т. д.

Ниже я постараюсь обосновать свое мнение.

1. Сырые (не агрегированные) данные и аналитическое DWH

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

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

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

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

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

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

2. SQL

Одно из требований к DWH – это поддержка расширенного SQL, поскольку первичную выборку, формирование основного сегмента вы делаете именно с помощью SQL. Выделение сложного сегмента или когортный анализ подразумевает нетривиальные SQL запросы.

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

Второе — это оконные функции (window functions). Они очень упрощают работу в ряде сложных задач. Пример использования оконной функции row_number() в PostgreSQL для формирования когорт:

WITH a AS (
    SELECT * , row_number() OVER (PARTITION BY user_id ORDER BY dt) sess_num
    FROM sessions
), D0 as (
    SELECT 'D0' cohort, dt AS date, user_id FROM a
    WHERE sess_num=1
    AND dt = (SELECT MIN(dt) FROM sessions)
), D3 AS (
    SELECT 'D3' cohort, dt AS date, user_id FROM sessions
    WHERE dt = (SELECT MIN(dt) FROM sessions) + INTERVAL '2 day'
    AND user_id IN (SELECT DISTINCT user_id FROM D0)
), D7 AS (
    SELECT 'D7' cohort, dt AS date, user_id FROM sessions
    WHERE dt = (SELECT MIN(dt) FROM sessions) + INTERVAL '6 day'
    AND user_id IN (SELECT DISTINCT user_id FROM D0)
), D30 AS (
    SELECT 'D30' cohort, dt AS date, user_id FROM sessions
    WHERE dt = (SELECT MIN(dt) FROM sessions) + INTERVAL '29 day'
    AND user_id IN (SELECT DISTINCT user_id FROM D0)
)

Третье — это пользовательские функции (UDF). Наличие UDF даст вам дополнительную уверенность в решении сложных задач. Пример UDF функции в BigQuery для убирания повторяющихся значений в массиве данных:

CREATE TEMP FUNCTION dedup(val ANY TYPE) AS ((
  SELECT ARRAY_AGG(t.v)
  FROM (SELECT DISTINCT * FROM UNNEST(val) v ) t
));

3. Эксплораторный анализ: pandas, matplotlib и другие библиотеки

Итак с помощью SQL вы получили нужный вам сегмент данных, который не доступен в рамках стандартных отчетов вашей аналитической системы, но что делать с ним дальше?

Типичные сценарии — это анализ сегмента в разных плоскостях и срезах, либо дальнейшая кластеризация данных. И тут уже не обойтись без инструментов дата-аналитики. Классический пример таких инструментов — это Python, Pandas, Matplotlib и Jupyter notebook.

Пример создания функции на Pyhton и применения ее в Pandas dataframe для выделения кластера пользователей, которые посетили определенные разделы сайта внутри сформированного ранее сегмента:

def claster(a):
    return [x for x in a if x in ['/manager', '/order']]

df['exit_page'] = df.pages.apply(lambda a: claster(a))

Пример вывода полученных данных на график в Jupyter notebook:

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

Также наверное стоит упомянуть набор инструментов, которые используются специалистами для структуризации решений описанных выше задач. Чаще их используют организации, которые уже прошли определенный путь развития в плане процессов анализа данных. Это так называемые data processing tools. Два примера — это dbt и Databricks. Это достаточно интересные инструменты в том числе в плане философии, которую они продвигают, но я бы не назвал их обязательными, поэтому их описание остается за рамками данной статьи.

← Запускаем Jupyter notebook на GCP

Продуктовая аналитика главного меню сайта →