2017-01-06 3 views
4

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

В поисках решения этой проблемы я ищу BigQuery, поскольку Firebase Analytics предоставляет удобный способ экспорта данных в эту службу.

Но у меня много вопросов, и у Google нет ответа или примера, который может указывать мне в правильном направлении.

Общие вопросы:

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

firebase cohorts

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

Вот, что я получаю до сих пор:

enter image description here

Основная проблема - большая разница в расчетах пользователей. Иногда это около 100 пользователей, но иногда близко к 1000.

Это подход я использую:

# 1 

# Count users with `user_dim.first_open_timestamp_micros` 
# in specified period (w0 – week 1) 
# this is the way firebase group users to cohorts 
# (who started app on the same day or during the same week) 
# https://support.google.com/firebase/answer/6317510 

SELECT 
    COUNT(DISTINCT user_dim.app_info.app_instance_id) as count 
FROM 
    (
    TABLE_DATE_RANGE 
    (
    [admob-app-id-xx:xx_IOS.app_events_], 
    TIMESTAMP('2016-11-20'), 
    TIMESTAMP('2016-11-26') 
    ) 
) 
WHERE 
    STRFTIME_UTC_USEC(user_dim.first_open_timestamp_micros, '%Y-%m-%d') 
    BETWEEN '2016-11-20' AND '2016-11-26' 

# 2 

# For each next period count events with 
# same first_open_timestamp 
# Here is example for one of the weeks. 
# week 0 is Nov20-Nov26, week 1 is Nov27-Dec03 

SELECT 
    COUNT(DISTINCT user_dim.app_info.app_instance_id) as count 
FROM 
    (
    TABLE_DATE_RANGE 
    (
    [admob-app-id-xx:xx_IOS.app_events_], 
    TIMESTAMP('2016-11-27'), 
    TIMESTAMP('2016-12-03') 
    ) 
) 
WHERE 
    STRFTIME_UTC_USEC(user_dim.first_open_timestamp_micros, '%Y-%m-%d') 
    BETWEEN '2016-11-20' AND '2016-11-26' 

# 3 

# Now we have users for each week w1, w2, ... w5 
# Calculate retention for each of them 
# retention week 1 = w1/w0 * 100 = 25.72181359 
# rw2 = w2/w1 * 100 
# ... 
# rw5 = w5/w1 * 100 

# 4 

# Shift week 0 by one and repeat from step 1 

BigQuery запросов советы запросить

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

Here is BigQuery Export schema if needed

Боковые вопросы:

  • почему все user_dim.device_info.device_id и user_dim.device_info.resettable_device_id является null?
  • user_dim.app_info.app_id отсутствует в док (если firebase поддержка товарища по команде будет прочитан этот вопрос)
  • как event_dim.timestamp_micros и event_dim.previous_timestamp_micros следует использовать, я не могу получить их назначение.

PS

Это будет хорошо кто-то из Firebase партнера по команде ответить на этот вопрос. Five month ago there are was one mention о расширении когортных функций с фильтрацией или отображением примеров больших запросов, но все не движется. По словам аналитиков Firebase Analytics, Google Analytics устарела. Теперь я провожу второй день, чтобы сфокусировать bigquery и построить собственное решение над существующими инструментами аналитики. Я нет, переполнение стека - это не место для комментариев, но ребята вы думаете? Сплит-тестирование может грамматически повлиять на сохранение моего приложения.Мое приложение ничего не продает, воронки и события во многих случаях не являются ценными метриками.

+0

с учетом из вашего 'BigQuery запросы советов request' - вам нужна только Firebase конкретной версия? или просто генератор bigquery будет работать для вас, чтобы вы могли принять его в конкретной схеме firebase? –

+0

@ Майкл Берлянт да, генерал bigquery будет работать отлично – George

ответ

7

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

да, общий BigQuery будет работать нормально

Ниже не самый универсальный вариант, но может дать вам представление о
В этом примере я использую Stack Overflow Data доступные в Google BigQuery Public Datasets

Первого суб- select - действия - в большинстве случаев единственное, что вам нужно переписать, чтобы отразить специфику ваших данных.
Что он:
a. Определяет период, который вы хотите установить для анализа.
В приведенном ниже примере - это месяц - FORMAT_DATE ('% Y-% м', ...
Но вы можете использовать year, week, day or anything else - соответственно
• По году - FORMAT_DATE ('% Y', DATE (ответы. create_date)) Период AS
• По неделям - FORMAT_DATE ('% Y-% W', DATE (answers.creation_date)) Период AS
• По дням - FORMAT_DATE ('% Y-% m-% d', DATE . (answers.creation_date)) AS период
• ...
б Кроме того, «фильтры» только тип событий/деятельности необходимо проанализировать
, например, `WHERE CONCAT ('|', questions.tags ' | ') LIKE'% | go кокетничать-BigQuery |%»ищет ответы на Google-BigQuery помечено вопрос

Остальные подзапросов более-менее общий характер и в большинстве случаев могут быть использованы как

#standardSQL 
WITH activities AS (
    SELECT answers.owner_user_id AS id, 
    FORMAT_DATE('%Y-%m', DATE(answers.creation_date)) AS period 
    FROM `bigquery-public-data.stackoverflow.posts_answers` AS answers 
    JOIN `bigquery-public-data.stackoverflow.posts_questions` AS questions 
    ON questions.id = answers.parent_id 
    WHERE CONCAT('|', questions.tags, '|') LIKE '%|google-bigquery|%' 
    GROUP BY id, period 
), cohorts AS (
    SELECT id, MIN(period) AS cohort FROM activities GROUP BY id 
), periods AS (
    SELECT period, ROW_NUMBER() OVER(ORDER BY period) AS num 
    FROM (SELECT DISTINCT cohort AS period FROM cohorts) 
), cohorts_size AS (
    SELECT cohort, periods.num AS num, COUNT(DISTINCT activities.id) AS ids 
    FROM cohorts JOIN activities ON activities.period = cohorts.cohort AND cohorts.id = activities.id 
    JOIN periods ON periods.period = cohorts.cohort 
    GROUP BY cohort, num 
), retention AS (
    SELECT cohort, activities.period AS period, periods.num AS num, COUNT(DISTINCT cohorts.id) AS ids 
    FROM periods JOIN activities ON activities.period = periods.period 
    JOIN cohorts ON cohorts.id = activities.id 
    GROUP BY cohort, period, num 
) 
SELECT 
    CONCAT(cohorts_size.cohort, ' - ', FORMAT("%'d", cohorts_size.ids), ' users') AS cohort, 
    retention.num - cohorts_size.num AS period_lag, 
    retention.period as period_label, 
    ROUND(retention.ids/cohorts_size.ids * 100, 2) AS retention , retention.ids AS rids 
FROM retention 
JOIN cohorts_size ON cohorts_size.cohort = retention.cohort 
WHERE cohorts_size.cohort >= FORMAT_DATE('%Y-%m', DATE('2015-01-01')) 
ORDER BY cohort, period_lag, period_label 

Вы можете визуализировать результат выше запрос с инструментом вашего выбора
Примечание: вы можете использовать либо period_lag или period_label
Чувствуете разницу их использования в примерах ниже

с period_lag

enter image description here

с period_label

enter image description here

+0

Привет, Михаил. Очень хороший ответ! Я блуждал, могли ли вы поделиться мыслями о том, как можно было бы рассчитывать более определенные ограничения когорты. Примеры включают: (1) Ежемесячное удержание, (2) Сохранение пользователей, у которых было 2 или более сеансов на протяжении всей их жизни, (3) Сохранение пользователей, которые инициировали «in_app_purchase» -эвентов, по крайней мере, один раз на протяжении всего их жизненного цикла (4) Сохранение пользователей, которые запускали «in_app_purchase» -эвентов, по крайней мере, один раз за последние 30 дней. Заранее спасибо ! – Dirk

+1

Постараюсь что-то собрать. В то же время, подумайте о том, чтобы ответить, если вам понравилось: o) –

+0

Отлично, только что сделал :) Теперь я вижу свой комментарий, и я оставил «Weekly Retention» -metrics. Просто, чтобы дать больше контекста моим пунктам выше.Я использую события Firebase и хотел бы заменить слова «in_app_purchase», например, «tut_level_1», а также, возможно, также посмотреть «Ежедневно/Еженедельно/Сохранение пунктов 3 и 4» (я бы просто заменил 30 дней на 1 или 7 дней). Благодаря! – Dirk