13 заметок с тегом

redash

Обзор дашборда в Redash

Время чтения текста – 2 минуты

О создании credentials и работе с Google Spreadsheets API мы рассказывали в материале «Собираем данные по рекламным кампаниям ВКонтакте»

В этот раз в цикле материалов по BI-системам рассмотрим Redash: open source инструмент, представляющий собой SQL-консоль, который можно совершенно бесплатно развернуть у себя на сервере и подключить в качестве датасорса множество баз данных (включая Clickhouse!) или другой источник по API, например, Google Sheets.

В видео обсудим плюсы и минусы Redash, посмотрим, как создавать отчёты и дашборды при помощи визуализаций запросов, подключить датасорсы, реализовать фактоиды, визуализацию Word Cloud и прочие аналогии графиков оригинального макета.

Внутри команды мы оценили дашборд в Redash и получили следующие средние оценки (1 — худшая оценка, 10 — лучшая):

  1. Отвечает ли заданным вопросам — 7,3
  2. Порог входа в инструмент — 7,5
  3. Функциональность инструмента — 5,5
  4. Удобство пользования — 7,5
  5. Соответствие результата макету — 6,0
  6. Визуальная составляющая — 5,2

Итог: дашборд получает 6,5 баллов из 10. Посмотрите на полученный результат.

 2 комментария    225   2020   bi   BI guide   BI-инструменты   redash

Разница между Retention на основе 24-часовых окон и календарных дней

Время чтения текста – 4 минуты

Вчера в Telegram мне написал читатель блога:

Допустим, сегодня понедельник, я сделал 187 установок, и хочу посмотреть Retention первого дня, в какой день недели это можно сделать?

Речь идет о посте про Retention. Дам некоторые пояснения на этот счёт. Retention можно считать как на основе календарных дней, так и на основе 24-часовых окон. Retention нулевого дня в данном случае будет понедельник, а первого дня — вторник. Но здесь есть небольшая загвоздка.

К примеру, если вы начали продвижение в понедельник 5 октября в 23:59, то все установки этой минуты через пару минут будут иметь Retention первого дня. Это проблема календарного исчисления. Для решения этой проблемы некоторые аналитики измеряют Retention не только по календарю, но и по 24-часовым окнам.

Приложим эту идею к вышеописанному случаю:

  • Retention нулевых суток в таком случае — все инсталлы с 5 октября 23:59 по 6 октября 23:59
  • Retention первого дня: с 6 октября 23:59 по 7 октября 23:59
  • И так далее со сдвигом 24-часового окна.

Как рассчитать Retention на основе 24-часовых окон с использованием SQL?

Вспомним запрос из предыдущего поста в блоге. Там мы считали разницу в днях между датой установки и датой активности пользователя. Модифицируем запрос так, чтобы активность считалась в 24-часовых окнах: заменим расчёт datediff на расчёт 24-часовых окон, обновив строки, выделенные жирным


SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
   floor((cast(cs.created_at as int)-cast(installed_at as int))/(24*3600)) as date_diff,
   ndv(user.id) AS ret_base
   FROM USER
   LEFT JOIN client_session cs ON cs.user_id=user.id
   WHERE 1=1
     AND floor((cast(cs.created_at as int)-cast(installed_at as int))/(24*3600)) between 0 and 30
     AND from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1,2

Обновленный запрос:

SELECT 
       cohort.date_diff AS day_difference,
       avg(reg.users) AS cohort_size,
       avg(cohort.ret_base) AS retention_base,
       avg(cohort.ret_base)/avg(reg.users)*100 AS retention_rate
FROM
  (SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          ndv(user.id) AS users
   FROM USER
   WHERE from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1) reg
LEFT JOIN
  (SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
    floor((cast(cs.created_at as int)-cast(installed_at as int))/(24*3600)) as date_diff,
          ndv(user.id) AS ret_base
   FROM USER
   LEFT JOIN client_session cs ON cs.user_id=user.id
    WHERE 1=1
     AND floor((cast(cs.created_at as int)-cast(installed_at as int))/(24*3600)) between 0 and 30
     AND from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1,2
  ) cohort ON reg.reg_date=cohort.reg_date
    GROUP BY 1        
    ORDER BY 1

Результат:

Сравним с результатам, полученным предыдущим скриптом:

Заметно, что в первые дни Retention, посчитанный методом 24-часового окна, несколько ниже.

Гайд по современным BI-системам

Время чтения текста – 4 минуты

В новой серии постов постараемся подробно изучить различные BI-системы на популярной группе датасетов SuperStore Sales. В основе данных — продажи и прибыль сетевого ритейлера в долларах.

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

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

Ниже перечислен перечень BI-систем и инструментов для работы, с данными, которые хотелось бы опробовать и описать опыт построения дашборда. Приглашаю тех, кто желает поучаствовать в решении данной задачи написать мне в Telegram — @valiotti. Разумеется, авторство дашборда будет указано. Проект некоммерческий, но полезный для сравнения современных систем для аналитики независимо от квадрантов Gartner.

Сейчас в планах подготовить материалы о следующих инструментах:

Бесплатные (Open source):

Бесплатные (cloud):

Платные (cloud):

  • Mode
  • Cluvio
  • Holistic
  • Chartio
  • Periscope
  • DeltaDNA
  • Klipfolio
  • Count.co
  • SAP Analytics Cloud: 8,7 баллов из 10

Платные:

  • PowerBI: 8,0 балла из 10
  • Tableau: 8,8 баллов из 10
  • Looker: 7,7 балла из 10
  • Excel: 7,5 балла из 10
  • Alteryx
  • Qlik Sense: 8,4 балла из 10

Итоговая цель — оценить системы по нескольким внутренним критериям:

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

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

Параллельно, результаты работы будут представлены в Telegram-канале @leftjoin, и подписчики также смогут высказать свое мнение относительно полученного результата.
В итоге каждый инструмент будет описан точкой на плоскости, а сама плоскость будет поделена на 4 части.

По мере написания новых материалов в цикле этот пост будет обновляться: будут добавляться ссылки на посты и оценки.

 2 комментария    2543   2020   bi   BI guide   BI-инструменты   excel   looker   powerbi   redash   tableau

Передаём и анализируем собранные данные по рекламным кампаниям в Redash

Время чтения текста – 6 минут

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

from facebook_business.api import FacebookAdsApi
from facebook_business.adobjects.adaccount import AdAccount
from facebook_business.adobjects.adreportrun import AdReportRun
from facebook_business.adobjects.adsinsights import AdsInsights
from facebook_business.adobjects.adaccountuser import AdAccountUser as AdUser
from facebook_business.exceptions import FacebookRequestError
import time

Redash, к примеру, принимает данные в формате json. Ранее мы не разбирали этот источник данных, сегодня изучим и его. Файл формата json выглядит как список словарей — его наш новый скрипт и будет передавать в Redash, предварительно переведя в json. Из прошлого скрипта нам понадобятся переменная с полями, access token, app id, app secret и две функции: wait_for_async_job() и get_insights(). Вторая функция принимает все параметры аккаунта и асинхронно собирает информацию по рекламным кампаниям — из них мы выбираем поля клики, просмотры, затраты и даты.

В материале используется практически весь скрипт из статьи «Собираем данные по рекламным кампаниям Facebook»

Получение данных обернём в функцию return_json() — она будет вызывать get_insights(), заполняя список insights_lists. Так как рекламных кампаний в аккаунте может быть несколько, наш результат окажется не списком словарей, а списком списков словарей. Для этого используем простое лямбда-выражение, «сглаживающее» список списков в список. Затем возвращаем наш insights_lists_flatten.

def return_json():
   insights_lists = []
   date_preset = 'last_year'
   for elem in my_accounts:
       elem_insights = get_insights(elem, date_preset)
       insights_lists.append(elem_insights)
   flatten = lambda lst: [item for sublist in lst for item in sublist]
   insights_lists_flatten = flatten(insights_lists)
   return insights_lists_flatten

Теперь наш скрипт возвращает список словарей с информацией. Но ещё нам нужен сервер на aiohttp, который будет собирать список и возвращать его в формате json. Создадим новый файл, импортируем библиотеку aiohttp и функцию get_json() из нашего прошлого скрипта. Напишем простой обработчик запросов — данные из Facebook скрипт получает асинхронно, так что асинхронная функция handler будет «спать», пока вся информация не будет собрана и передана. Возвращает функция данные через json_response, чтобы информация передавалась в формате json.

from aiohttp import web
from get_json import return_json
 
async def handler(request):
   data = return_json()
   return web.json_response(data)

Далее инициализируем и запускаем наше приложение.

app = web.Application()
app.add_routes([web.get('/json', handler)])
web.run_app(app)

Теперь идём на AWS, создаём папку и через sftp кидаем туда оба скрипта. Проверим, что в ACL на AWS нужный порт открыт. Заходим в console — network & security — security groups — default.

Запускаем файл с сервером. После запуска можно проверить, работает ли скрипт, обратившись к нему по ip сервера с портом 0880 на route, указанный в скрипте с сервером — там мы указали /json.

Теперь обратимся через Redash к URL и получим ту самую таблицу, которую вернул скрипт:

url: ip сервера

Сформировав query results, можем написать запрос следующего вида:

select date_start, sum(clicks) as clicks, sum(impressions) as impressions, sum(spend) as spend from query_45
group by date_start

Получаем такую таблицу, сгруппированную по колонке date_start:

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

Готово! В следующий раз поработаем с ВКонтакте — получим информацию по рекламным кампаниям уже оттуда.

Когортный анализ в Redash

Время чтения текста – 6 минут

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

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

Мы разберемся с тем, как сравнить Retention пользователей недельных когорт в Redash, поскольку у Redash имеется специальный тип визуализации для построения такого отчета.
Определимся для начала c SQL-запросом. У нас как и прежде две таблицы — user (id пользователя и время установки приложения) и client_session — таймстемпы (created_at) активности каждого пользователя (user_id). Будем считать Retention первых семи дней для недельных когорт за последние 60 дней.
Запрос написан в Cloudera Impala, рассмотрим его.

Для начала построим общую численность когорт:

select trunc(from_unixtime(user.installed_at), "WW") AS cohort_week, 
	ndv(distinct user.id) as cohort_size //считаем количество пользователей в когорте
	from user 
	where from_unixtime(user.installed_at) between date_add(now(), -60) and now() //берем зарегистрированных за последние 60 дней
group by trunc(from_unixtime(user.installed_at), "WW")

Вторая часть запроса поможет посчитать количество активных пользователей на каждый день в течение первых тридцати:

select trunc(from_unixtime(user.installed_at), "WW") AS cohort_week, 
        datediff(cast(cs.created_at as timestamp),cast(user.installed_at as timestamp)) as days,
	ndv(distinct user.id) as value  //считаем количество активных пользователей на каждый день
		from user 
		left join client_session cs on user.id=cs.user_id
where from_unixtime(user.installed_at) between date_add(now(), -60) and now()
and from_unixtime(cs.created_at) >= date_add(now(), -60) //берем сессии за последние 60 дней
and datediff(cast(cs.created_at as timestamp),cast(user.installed_at as timestamp)) between 0 and 30 //отрезаем только первые 30 дней активности
group by 1,2

Итого запрос целиком:

select size.cohort_week, size.cohort_size, ret.days, ret.value from
(select trunc(from_unixtime(user.installed_at), "WW") AS cohort_week, 
		ndv(distinct user.id) as cohort_size 
	from user 
	where from_unixtime(user.installed_at) between date_add(now(), -60) and now()
group by trunc(from_unixtime(user.installed_at), "WW")) size
left join (select trunc(from_unixtime(user.installed_at), "WW") AS cohort_week, 
        datediff(cast(cs.created_at as timestamp),cast(user.installed_at as timestamp)) as days,
		ndv(distinct user.id) as value 
		from user 
		left join client_session cs on user.id=cs.user_id
where from_unixtime(user.installed_at) between date_add(now(), -60) and now()
and from_unixtime(cs.created_at) >= date_add(now(), -60)
and datediff(cast(cs.created_at as timestamp),cast(user.installed_at as timestamp)) between 0 and 30
group by 1,2) ret on size.cohort_week=ret.cohort_week

Отлично, теперь нам доступны правильно посчитанные данные.

Данные когорт в табличном виде

Создадим новую визуализацию в Redash и правильно укажем параметры:

Важно правильно указать параметры — им соответствуют колонки результирующего запроса

Обязательно отметим, что у нас недельные когорты:

Вуа-ля, наша визуализация когорт готова:

К ней можно добавить фильтры и параметры и использовать в дашборде

Материалы по теме

Использование параметров в Redash

Время чтения текста – 3 минуты

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

Параметр в отчете может быть следующих типов:

Про каждый тип по отдельности:

  • Text — текстовое поле свободного ввода, может использоваться в конструкциях типа LIKE, параметр такого типа не может использоваться в публичных дашбордах
  • Number — число, которое вводит пользователь
  • Dropdown list — список значений, из которых пользователь сможет выбрать одно или несколько (недавно появилась возможность мульти-ввода параметров в выпадающим списке)
  • Query dropdown list — аналогично предыдущему, однако значения будут браться из имеющегося запроса
  • Date / Date and Time / Date and Time (with seconds) — поля ввода даты
  • Date Range / Date and Time Range / Date and Time Range (with seconds) — поля ввода интервалов дат. Удобно использовать для конструкции вида
between '{{parameter.start}}' and '{{parameter.end}}'

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

Из неочевидных, но крайне полезных решений: как сделать параметр отключаемым?
Предположим, что параметр типа «выпадающий список» называется parameter и мы хотим его настроить для столбца geo таблицы, тогда в коде запроса будет что-то типа:

WHERE
    ('{{parameter}}' = 'Disabled' or geo = '{{parameter}}')

При этом, разумеется, в значения выпадающего списка нужно добавить ’Disabled’.

Настройка алертов в Redash

Время чтения текста – 6 минут

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

Вспомним как собрать данные, используя Google Analytics, и для этих данных настроим оповещения, используя внутреннюю БД Redash (query-results). В качестве основания для оповещения нас будет интересовать падение числа пользователей на сайте за вчерашний день более, чем на 30%.

Построение запроса к Google Analytics

{
    "ids": "ga:128886640",
    "start_date": "30daysAgo",
    "end_date": "yesterday",
    "metrics": "ga:users", 
    "dimensions": "ga:date"
}

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

Включаем хранение query results

Одной из основных фишек redash считается возможность обращения к результатам выполнения запроса, которые хранятся во внутренней СУБД SQLite.
Для того, чтобы включить хранение результатов необходимо перейти в Data Sources и включить query-results (beta).

Теперь простой командой:

select * from query_37

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

Строим запрос для оценки изменений в числе пользователей

Для того, чтобы настроить оповещение необходимо в начале написать запрос, которые выдаст целевой показатель для проверки, в нашем случае — рост или падение числа пользователей на сайте.
Напишем запрос, который обращается ко внутренней СУБД Redash:

SELECT sum(CASE WHEN date(ga_date)=DATE('now', '-1 day') THEN ga_users ELSE NULL END) AS yesterday,
sum(CASE WHEN date(ga_date)=DATE('now', '-2 day') THEN ga_users ELSE NULL END) AS before_yesterday,
(sum(CASE WHEN date(ga_date)=DATE('now', '-1 day') THEN ga_users ELSE NULL END)*1.0/
sum(CASE WHEN date(ga_date)=DATE('now', '-2 day') THEN ga_users ELSE NULL END)*1.0-1)*100 AS difference
FROM query_37

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

Теперь, чтобы мы могли получать алерты, необходимо настроить выполнение запросом по расписанию (регулярное обновление результатов / scheduled query в терминах redash).

Поставим обновление на 10 утра каждого дня:

Настраиваем оповещение

Переходим в меню Create — Alert. Вводим название запроса, в моем случае — это «Alert on users».
Далее, можем поменять отображаемое название нотификации или оставить то, что предлагается системой.

Выбираем целевую метрику, в рассматриваемом примере — difference. Ниже в операторе сравненения (Op) выбираем less then и устанавливаем значение -30.

В блоке справа на странице необходимо выбрать куда именно будет отправляться алерт. Подробно о настройке пути следования алерта можно прочитать на официальном сайте Redash.

Теперь алерт появился на странице со списков алертов и по умолчанию находится в статусе OK.

Как только показатель превысит заданный нами уровень статус изменится на TRIGGERED, а оповещение отправится на почту / в Slack.

Больше по теме

Нововведения в Redash v8

Время чтения текста – 6 минут

Две недели назад произошел финальный релиз Redash версии 8. Полный список усовершенствований представлен на странице релиза beta версии v8.

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

  • Support for multi-select in dropdown (and query dropdown) parameters.
  • Support for dynamic values in date and date-range parameters.
  • Search dropdown parameter values.
  • Pivot Table: support hiding totals.
  • New Visualization: Details View.

Support for multi-select in dropdown (and query dropdown) parameters.

В 8-ой версии Redash появилась долгожданная поддержка выбора нескольких значений в параметре типа «выпадающий список» или «выпадающий список на основе запроса»:

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

Для нас это означает возможность использования в запросах условия типа IN с параметром:

При использовании таких значений параметра, мы получим следующий URL в строке браузера:

Support for dynamic values in date and date-range parameters.

Максимально удобная и полезная фича для выбора дат, которая часто используется в Tableau, но до сих пор не была реализована в Redash: использование динамических значений для дат:

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

Search dropdown parameter values.

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

Pivot Table: support hiding totals.

Достаточно долгожданная фича, позволяющая убрать итоги по строкам / столбцам.

New Visualization: Details View

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

Как посчитать Retention?

Время чтения текста – 8 минут

В этой заметке разберём как правильно построить отчет по Retention с использованием Redash и языка SQL.
Для начала, в двух словах, что это за метрика Retention rate, почему она важна, какой бывает и каким образом считается.

Retention rate

Метрика Retention rate довольно широко распространена и особенно известна в мобильной индустрии, поскольку позволяет понять насколько хорошо продукт вовлекает пользователей в ежедневное использование. Вспомним (или узнаем) как рассчитывается Retention:
Retention дня X — это N% процентов пользователей, которые вернутся к продукту в день X. Иными словами, если в какой-то конкретный день (день 0) пришло 100 новых пользователей, а на 1-ый день вернулось 15, то Retention 1-го дня составит 15 / 100 = 15%.
Чаще всего выделяют Retention дней 1, 3, 7 и 30 как наиболее описательные метрики продукта, однако полезно в целом рассматривать кривую Retention и делать выводы исходя из нее.

Кривая retention

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

Кривая Retention rate c 0-го по 30-ый день

Rolling Retention (RR)

Кроме классического Retention rate выделяют также Rolling Retention (далее RR). При расчете Rolling Retention помимо дня X учитываются также все последующие дни. Таким образом RR 1-го дня — количество пользователей, которые вернулись в 1-ый и последующие дни.

Сравним Retention и Rolling Retention 10-го дня:
Retention10 — количество пользователей, вернувшихся в 10-ый день / количество пользователей, установивших приложение 10 дней назад * 100%.
Rolling Retention10 — количество пользователей, вернувшихся в 10-ый день или позже / количество пользователей, установивших приложение 10 дней назад * 100%.

Гранулярность (retention временных отрезков)

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

Пример когорт по месяцам и соответствующий им месячный Retention

Как построить Retention отчет на языке SQL?

Выше мы разобрали как посчитать Retention в формулах. Теперь приложим это к языку SQL.
Допустим, что у нас есть две таблицы: user — храним данные об идентификаторах пользователей и мета-информацию, client_session — информация о посещениях пользователями мобильного приложения.
В запросе будут фигурировать только две эти таблицы, поэтому вы с легкостью сможете адаптировать запрос под себя.
примечание: в рамках данного кода я использую Impala в качестве СУБД.

Собираем размер когорт

SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          ndv(user.id) AS users
   FROM USER
   WHERE from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1

Разберем этот довольно несложный запрос: по каждому дню мы считаем количество уникальных пользователей для отрезка [60 дней назад; 31 день назад].
Чтобы не лезть в документацию: команда ndv() в Impala аналог команды count(distinct).

Считаем количество вернувшихся пользователей по каждой когорте

SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          datediff(cast(cs.created_at AS TIMESTAMP), cast(installed_at AS TIMESTAMP)) AS date_diff,
          ndv(user.id) AS ret_base
   FROM USER
   LEFT JOIN client_session cs ON cs.user_id=user.id
   WHERE 1=1
     AND datediff(cast(cs.created_at AS TIMESTAMP), cast(installed_at AS TIMESTAMP)) between 0 and 30
     AND from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1, 2

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

Отлично, теперь у нас есть размер когорт и количество вернувшихся пользователей

Собираем все вместе

SELECT reg.reg_date AS date_registration,
       reg.users AS cohort_size,
       cohort.date_diff AS day_difference,
       cohort.ret_base AS retention_base,
       cohort.ret_base/reg.users AS retention_rate
FROM
  (SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          ndv(user.id) AS users
   FROM USER
   WHERE from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1) reg
LEFT JOIN
  (SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          datediff(cast(cs.created_at AS TIMESTAMP), cast(installed_at AS TIMESTAMP)) AS date_diff,
          ndv(user.id) AS ret_base
   FROM USER
   LEFT JOIN client_session cs ON cs.user_id=user.id
   WHERE 1=1
     AND datediff(cast(cs.created_at AS TIMESTAMP), cast(installed_at AS TIMESTAMP)) between 0 and 30
     AND from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1, 2) cohort ON reg.reg_date=cohort.reg_date
    ORDER BY 1,3

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

Retention rate, посчитанный для каждой когорты пользователей

Построение единственной кривой Retention

Несколько модифицируем наш запрос и получим требуемые данные для построения одной кривой Retention:

SELECT 
       cohort.date_diff AS day_difference,
       avg(reg.users) AS cohort_size,
       avg(cohort.ret_base) AS retention_base,
       avg(cohort.ret_base)/avg(reg.users)*100 AS retention_rate
FROM
  (SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          ndv(user.id) AS users
   FROM USER
   WHERE from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1) reg
LEFT JOIN
  (SELECT from_unixtime(user.installed_at, "yyyy-MM-dd") AS reg_date,
          datediff(cast(cs.created_at AS TIMESTAMP), cast(installed_at AS TIMESTAMP)) AS date_diff,
          ndv(user.id) AS ret_base
   FROM USER
   LEFT JOIN client_session cs ON cs.user_id=user.id
   WHERE 1=1
     AND datediff(cast(cs.created_at AS TIMESTAMP), cast(installed_at AS TIMESTAMP)) between 0 and 30
     AND from_unixtime(user.installed_at)>=date_add(now(), -60)
     AND from_unixtime(user.installed_at)<=date_add(now(), -31)
   GROUP BY 1,2) cohort ON reg.reg_date=cohort.reg_date
    GROUP BY 1        
    ORDER BY 1

Теперь у нас для каждого дня посчитан средний по всем когортам Retention rate.

Больше по теме

Строим funnel-репорт в redash

Время чтения текста – 4 минуты

Итак, мы планировали разобрать Funnel-визуализацию отчета в redash.
В первую очередь, построим запрос к подключенному нами источнику данных — google analytics.

Прямо вот такой текст необходимо положить в консоль запроса:

{
    "ids": "ga:128886640",
    "start_date": "30daysAgo",
    "end_date": "yesterday",
    "metrics": "ga:users,ga:goal1Completions,ga:goal2Completions,ga:goal3Completions"
}

В данном запросе мы просим API Google Analytics отдать данные за последние 30 дней по аккаунту GA: 128886640. Мы хотим увидеть число пользователей и число выполнения целей 1, 2 и 3.

В итоге получаем таблицу следующего вида:

ga:users ga:goal1Completions ga:goal2Completions ga:goal3Completions
3,926 105 41 32

Отлично, это именно то, что нам нужно для построения воронки.
Расскажу об одной очень полезной фиче Redash: query-results. Чтобы подключить таблицы с результатами выполнения запросов, идем в Data Sources и ищем query-results (beta). Подключаем новый источник данных.
Теперь у нас появилась возможность обращаться к результатам запросов redash. Так, например, мы можем воспользоваться результатами запроса к Google Analytics.

Как это сделать?
Необходимо выбрать слева источник данных query-results:

Выпадающее меню с выбором источников данных (в консоли — слева)

Теперь научимся делать funnel-визуализацию. Для этого пишем следующий SQL-запрос:

select 'Добавление товара в корзину' as step_name, ga_goal1Completions as goalCompletion from query_8
union all
select 'Просмотр корзины' as step_name, ga_goal2Completions from query_8
union all
select 'Оформление заказа' as step_name, ga_goal3Completions from query_8

В данном случае query_8 — это как раз таблица с результатами запроса к источнику данных Google Analytics.

Настроим визуализацию:

Аккуратно выбираем параметры, чтобы получить желаемый результат

В итоге мы получаем воронку конверсий из одной цели в другую:

Данную воронку можно отобразить в дашборде и добавить к ней фильтры / параметры

Как подключить Google Analytics к Redash?

Время чтения текста – 4 минуты

В этой статье разберем как подключить источник данных Google Analytic к сервису Redash [подробнее Redash и его возможности мы разбирали в предыдущих заметках].

Создаем сервисный аккаунт в Google

Переходим в консоль сервисных аккаунтов.

Создаем новый сервисный аккаунт

В окне создания аккаунта вводим имя, а затем формируем новый ключ. Выбираем, что нам необходим JSON-ключ и затем нажимаем «Создать».

Включаем Analytics API

Для созданного нами сервисного аккаунта необходимо включить Analytics API.

Когда мы все установили, Analytics API должен гореть зеленым

Добавляем сервисного пользователя в Google Analytics

Далее, необходимо добавить созданного нами сервисного пользователя в Google Analytics. Пользователь будет иметь примерно такой вид:
user@PROJECT-ID.iam.gserviceaccount.com.
Необходимо добавлять пользователя с правами на Чтение и Просмотр.

Создаем новый источник данных в Redash

Идем в Настройки (Settings) -> Добавляем новый источник данных

Подключаем новый источник данных.

Нас интересует источник данных Google Analytics, поэтому ищем «google»:

Ищем google analytics в источниках данных.

Вспоминаем, куда мы сохранили JSON файл, он нам сейчас потребуется

Выбираем созданный ранее JSON файл

Пишем запрос к новому источнику данных

Именно в таком виде запрос выполняется в консоли redash:

{
    "ids": "ga:128886640",
    "start_date": "30daysAgo",
    "end_date": "yesterday",
    "metrics": "ga:users,ga:newUsers,ga:goal1Starts,ga:goal2Completions,ga:goal3Starts,ga:transactions,ga:transactionRevenue", 
    "dimensions": "ga:date"
}

Как узнать параметры для выполнения запроса?

У Google есть отличный ресурс Query Explorer, в котором можно найти все необходимые метрики и измерения, которые доступны в Google Analytics.

Надеюсь, данная инструкция оказалась вам полезной, далее мы разберемся как построить воронку целей в Redash на основании данных из Google Analytics.

Визуализация данных в Redash

Время чтения текста – 4 минуты

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

Поскольку я про аналитику, то вместе с графиками мы будем изучать полезные показатели бизнеса. Начнем с довольной традиционной метрики для ритейла/e-commerce AOV (Average Order Value) — средняя сумма заказа (в данном случае за месяц). Показатель позволяет отслеживать изменения, связанные с покупательским поведением (стали ли в среднем больше или меньше покупать).

Пример столбиковой диаграммы в Redash на основе показателя AOV (Average Order Value)

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

Зачастую динамика гораздо отчетливее, если посмотреть либо на традиционной график, либо на так называемую area-диаграмму. В данном случае мы исследуем новых пользователей, а также какую долю MAU (Monthly Active Users) занимают новые пользователи.

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

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

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

Два типа диаграмм на одном графике

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

Redash — полноценная on-demand аналитика

Время чтения текста – 3 минуты

Сегодня мы рассмотрим и постараемся разобраться в весьма популярном сейчас инструменте под названием Redash. Инструмент крайне удобен тем, что он умеет работать с Clickhouse. Все остальные разработчики BI-утилит не поддерживают Clickhouse. Буквально недавно появился ODBC драйвер под Tableau.

Я сделаю краткий обзор полезных фич Redash’a, а в дальнейшей серии постов разберу какие полезные запросы и отчеты с помощью Redash можно построить.

Домашняя страница Redash

Итак, что такое Redash? Это инструмент для on-demand аналитики, его можно использовать на совершенно разнообразных база данных. К примеру, Redash можно подключить к БД под управлением MySQL или HP Vertica.

Основное, что предлагает нам Redash — удобная консоль для написания SQL-запросов к базе данных.

Консоль для написания SQL-запросов

Соответственно, первый главный вывод: для того, чтобы использовать redash вы должны знать SQL или иметь в штате специалиста, который знает SQL.

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

Разберем чуть детальнее базовую консоль. Пользователю доступны полезные фичи: использование фильтров, мультифильтров и параметров запроса:

Использование параметров, фильтров и мульти-фильтров в запросах одновременно

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

В следующей заметке подробнее обсудим визуализацию в Redash, позже — построение дашбордов и системы уведомлений.