Firebase、BigQuery、Looker を使用した統合アプリ分析プラットフォームの作成

Last reviewed 2021-06-30 UTC

このドキュメントでは、データソースをデータウェアハウスで一元管理し、お客様の行動を深く掘り下げて、情報に基づくビジネス上の意思決定を行う方法について説明します。このタイプのソリューションは、複数のチャネルをまたいで情報を追跡するのに役立ちます。組織は、たとえば、プロダクトの改善が顧客の行動にどのような影響を与えるか、機能とアプリケーションの修正をどのように優先すべきかを決定できます。このドキュメントは、Software-as-a-Service（SaaS）ゲーム、ゲーム業界や e コマース業界などのデジタルネイティブな組織に特に役立ちます。

このドキュメントは、データアナリストとデベロッパーを対象としています。また、構造化クエリ言語（SQL）の使用経験があり、以下の基本的な知識があることを前提としています。

BigQuery
Looker
Firebase
組織の顧客管理（CRM）、問題追跡、カスタマーサポートツール

このドキュメントでは、より幅広いユーザー層に対する現実的なビジネスニーズへの対応方法について説明します。

手順	対象	ビジネスの目標
レポート	経営幹部、アカウントマネージャー	目標の達成状況を可視化し、1 日の平均アクティブユーザーを追跡します。
バグに優先順位を付ける	テクニカルプログラムマネージャー、プロダクトマネージャー、デベロッパー	価値の高いユーザーに対して発生しているクラッシュと、チャットサポートで報告された問題を特定できます。
アカウントを管理する	営業担当者とアカウントマネージャー	アカウントのクラッシュと使用傾向の影響を受けるお客様を特定します。

アーキテクチャ

このアーキテクチャでは、分析のための信頼できる単一情報源として BigQuery を使用し、さまざまなソースから定期的にデータを受信します。Looker では、データアナリストが Looker Block を自社のカスタム LookML モデルと組み合わせて、さまざまなユーザーのデータを分析します。

Looker は、Google Cloud のビジネスインテリジェンスプラットフォームです。これを使用すると、ライブダッシュボードを構築し、データの詳細を掘り下げて、知見を直接操作できます。

このアーキテクチャでは、次のデータソースを使用します。

Google アナリティクス 4: アプリケーションでのお客様の操作を追跡します。
Firebase Crashlytics: Firebase アプリケーションのクラッシュ情報を収集して整理します。
Firestore: Firebase アプリケーションのバックエンドデータベースが提供されます。
Google スプレッドシート: スプレッドシートに手動で入力された自社データを収集します。
顧客管理プラットフォーム（CRM）: 顧客データを管理します。このドキュメントでは、Salesforce を例にしていますが、同じことを他のツールにも適用できます。
問題追跡またはプロジェクト管理ソフトウェア: チームによるバグ修正と機能開発の追跡に役立ちます。このドキュメントでは、JIRA を例にしていますが、同じことを他のツールにも適用できます。
カスタマーサポートソフトウェアまたはヘルプデスク: これらのタイプのツールは、お客様からの連絡を整理し、迅速かつ効果的にお客様に対応するために役立ちます。このドキュメントでは、Zendesk を例にしていますが、同じことを他のツールにも適用できます。

料金

このドキュメントの手順では、次の課金対象の Google Cloud コンポーネントを使用します。

BigQuery
Looker（カスタム料金モデル）

このドキュメントでは、独自の料金モデルを持つサードパーティのデータ統合プラットフォームとデータソースについても説明します。Fivetran の料金情報をご覧ください。

始める前に

Google Cloud コンソールでプロジェクトの選択ページに移動します。

プロジェクトセレクタに移動
Google Cloud プロジェクトを選択または作成します。

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。
すべての転送について、プロジェクトで課金を有効にします。無料の転送では、$0 が請求されます。

課金の有効化が必要になるのは、プロジェクトごとに 1 回のみです。複数のソースからデータを転送する場合も同様です。BigQuery でデータのクエリを行うには、データの転送後に課金を有効にする必要があります。

プロジェクトに対して課金が有効になっていることを確認するで詳細をご覧ください。
新しいプロジェクトでは、BigQuery が自動的に有効になります。既存のプロジェクトで BigQuery を有効にするには、BigQuery API を有効にします。

BigQuery API を有効にする

環境の準備

Firebase アプリケーションで、Google アナリティクスと Crashlytics を有効にします。
独自の Looker モデルとダッシュボードを設定するには、Looker インスタンスに対するデベロッパーアクセス権が必要です。トライアルをリクエストするには、Looker の無料トライアルのデモをご覧ください。

BigQuery でのデータの一元化

このセクションの手順では、次の方法について説明します。

Google アナリティクス 4 から未加工のイベントとクラッシュデータをエクスポートする。
Firestore から BigQuery にエクスポートする。
Google スプレッドシートでデータをクエリする。
サードパーティ製ツールを使用してデータをエクスポートする。

Google アナリティクス 4 からのエクスポート

より複雑な分析を行うために、Google アナリティクス 4 のプロパティからすべての未加工イベントを BigQuery にエクスポートできます。Google アナリティクス 4 のデータをエクスポートする方法については、BigQuery Export をご覧ください。

Crashlytics からのエクスポート

Crashlytics は、アプリケーションのクラッシュをトラッキングしてモニタリングするための優れた方法です。このクラッシュデータを BigQuery にエクスポートすると、このデータを使用して回答できる質問に対する柔軟性がより高まります。BigQuery にデータをエクスポートする方法については、Crashlytics データを BigQuery にエクスポートするをご覧ください。

BigQuery への接続は、Firebase の [統合] タブで構成できます。必要に応じて、ストリーミングをオンに切り替えて、クラッシュデータを BigQuery にリアルタイムで push できます。

Crashlytics をエクスポートする

Firestore から BigQuery へのエクスポート

Firestore は、Firebase と Google Cloud からのモバイル、ウェブ、サーバー開発に対応した、柔軟でスケーラブルなデータベースです。Firestore から BigQuery へのドキュメントのバッチエクスポートを設定して、データをアプリケーションから分析に直接組み込むには、Firestore エクスポートからのデータの読み込みをご覧ください。または、Firebase 拡張機能を使用する場合は、Firestore BigQuery のエクスポートをご覧ください。

Google スプレッドシートでのデータのクエリ

多くの企業は、スプレッドシート（Google スプレッドシートなど）に、手動で入力または変更されたビジネス情報を保存しています。このシナリオの一例は、ビジネス目標や収益目標です。目標達成の進捗状況を追跡できるように、この情報を BigQuery に一元化することが重要です。BigQuery は、Google スプレッドシートに保存された情報に対して直接クエリするおよびデータを結合できるように、外部テーブルの作成をサポートしています。詳細については、ドライブデータをクエリするをご覧ください。

サードパーティ製ツールを使用したデータのエクスポート

コードをほとんどまたは一切行わずにデータをエクスポートするデータ統合ツールがいくつかあります。Fivetran は、CRM、問題追跡、カスタマーサポートソフトウェアなど、さまざまな Software-as-a-Service（SaaS）アプリケーションからのコネクタを提供しています。ソースの宛先として BigQuery を構成する方法については、BigQuery 設定ガイドをご覧ください。

このドキュメントで使用されているソースの設定については、次の Fivetran 設定ガイドをご覧ください。

データソースの統合

データを BigQuery に連結すると、次のようなプロジェクトを作成できます。その場合、各データソースは独自のデータセットに格納されます。

プロジェクト内のファイルの例

さまざまなデータセットのテーブルを結合するクエリを作成するには、プラットフォーム間で標準化された ID を使用します。

ユーザー ID をデータソース間でマッピングする

Firestore などのアプリケーションデータベースのユーザー ID は、信頼できる情報源として使用できます。また、他のアプリケーションのユーザー ID を入力するためにも使用できます。各ユーザーに一意の永続的な ID を割り当てることで、データソースを結合し、ユーザーの行動をクロスプラットフォームビューで表示できます。

ユーザー ID をデータソース間でマッピングする

アーキテクチャで説明した各データソースは、カスタムユーザー ID が設定されるように構成できます。データが BigQuery にエクスポートされると、指定したテーブルの列としてこのユーザー ID が利用可能になり、クエリ内のテーブルの結合に使用されます。

Crashlytics

ユーザー ID を取得するクエリを実行します。
```
SELECT user.id FROM crashlytics.[my_crashlytics_table]
```
他のアプリケーションと一致するようにユーザー ID を設定するには、Crashlytics SDK を使用します。
Google アナリティクス 4

ユーザー ID を取得するクエリを実行します。
```
SELECT user_id FROM google_analytics.events
```
Google アナリティクスに送信するデータにユーザー ID を含める方法については、以下の記事をご覧ください。
- Google アナリティクス 4 タグ: Google アナリティクス 4 のイベントタグを使用してユーザー ID を設定する方法を説明します。
- Google アナリティクスのユーザー ID: ユニバーサルアナリティクスプロパティ用に作成されていますが、情報は Google アナリティクス 4 プロパティに適用され、追加のコンテキストを提供します。
- Cookie とユーザーの識別: 測定コードを使用してユーザー ID を含める方法について説明します。
Zendesk

ユーザー ID を取得するクエリを実行します。
```
SELECT external_id FROM zendesk.users</code>
```
Zendesk は、ユーザーの一括インポート中または API の使用中に設定できる外部ユーザー ID をサポートしています。

データソースを CRM にマッピングする

データソースを CRM ツールにマッピングする方法は、企業間取引（B2B）組織と一般消費者向け取引（B2C）組織で異なる場合があります。B2B 企業は、ユーザーをアカウント ID にマッピングし、場合によってはプラットフォームごとにアカウント ID をマッピングする必要があります。

次の図では、データソースを CRM ツール（Salesforce）にマッピングする例を示します。

CRM にソースをマッピングする

Salesforce（B2C）: Salesforce からユーザー ID にアクセスするには、統合ユーザー ID を Salesforce ユーザー ID にマッピングします。外部ユーザー ID は、Salesforce のカスタムフィールド命名に依存します。統合型ユーザー ID を含む Salesforce Contact オブジェクトでカスタムフィールドを使用できます。カスタムフィールドは、Salesforce のエクスポートでは独自の列として入力されます。
Salesforce（B2B）: Salesforce からアカウント ID にアクセスするには、統合ユーザー ID を Salesforce アカウント ID にマッピングします。独自のデータベース（Firestore）にカスタムテーブルを作成して、ある列では統合ユーザー ID を、別の列では Salesforce アカウント ID を追跡し、そのテーブルは BigQuery に複製できます。

もう 1 つの選択肢は、Salesforce アカウント ID を含めるために Google アナリティクス 4 と Crashlytics でカスタム変数を使用することです。
- Google アナリティクス 4 のカスタムユーザープロパティにアクセスするには、次のコマンドを実行します。
```
SELECT up.value.string_value FROM google_analytics.events, UNNEST(user_properties) as up WHERE up.key = 'sfdc_account_id'
```
- Crashlytics でカスタムキーにアクセスするには、次のコマンドを実行します。
```
SELECT ck.value FROM crashlytics.[my_crashlytics_table], UNNEST(custom_keys) as ck WHERE ck.key = 'sfdc_account_id'
```

Zendesk で外部組織 ID を設定するには、次のように操作します。

SELECT external_id FROM zendesk.organization

データソース間で問題 ID をマッピングする

お客様の行動に関する問題の影響と解決経路を追跡するには、Crashlytics、JIRA、Zendesk 全体でお客様の問題を結合します。この場合、すべてのプラットフォームで Crashlytics の問題 ID を信頼できる情報源の ID として使用できます。

Crashlytics の問題 ID は、次のクエリで取得できます。

SELECT issue_id FROM [my_crashlytics_table]

データソース間で問題 ID をマッピングする

JIRA

Crashlytics の問題 ID を取得するために、クエリを実行します。
```
SELECT external_id FROM jira.issue
```
Firebase は JIRA と Crashlytics を直接統合します。プロジェクトに JIRA 統合を追加するをご覧ください。この統合により、Crashlytics ページから新しい問題を作成できます。または、特定のしきい値に基づいて JIRA の問題を自動的に生成することもできます。Looker アクションによる自動 JIRA 作成のために複数のソースのデータを使用する方法については、バグに優先順位を付けるをご覧ください。
Zendesk

Zendesk チケット ID を取得するクエリを実行します。
```
SELECT ticket_id FROM zendesk.ticket
```
サポートチケットが作成されると、チームはお客様に代わって JIRA にバグや機能のリクエストを作成します。Zendesk は JIRA と直接統合されているため、このプロセスはサポートエージェントにとってもより簡単になります。詳しくは、Jira アプリと Zendesk のサポートの統合をご覧ください。JIRA 内のカスタムフィールド内のこの情報にアクセスできる Jira 統合のための Zendesk サポートの使用もご覧ください。JIRA の列名は、統合の設定方法と使用する特定のコネクタによって異なります。

Looker でのデータの分析

Looker に BigQuery を接続する

BigQuery で使用できるデータによって、プロジェクトを Looker に接続できます。Looker で Google BigQuery への接続を設定する方法をご覧ください。

Looker Blocks を使用する

Looker Marketplace には、特定のソースに特化した、さまざまな事前構築されたデータモデルとダッシュボードが用意されています。Looker Block により、指標の定義や LookML の開発に費やす時間を削減し、データのより深い質問により多くの時間をかけられます。

現在、Salesforce、Zendesk、JIRA、Crashlytics で利用できるブロックがあります。Google アナリティクス 360 のブロックもあります。これらのブロックをマーケットプレイスからインストールするには、Looker インスタンスのストアフロントシンボルに移動します。

検索バーを使用すると、特定のブロックを見つけることができます。

Looker Blocks を検索する

ブロックを見つけたら、モデルをインストールできます。

モデルをインストールする

モデルをインストールしたら、ビジネスニーズに合わせて定義を拡張およびカスタマイズできます。このドキュメントでは、新しいプロジェクトを作成して、現時点でマーケットプレイスで入手可能な Zendesk、Salesforce、Jira、Crashlytics のブロックを使用します。

この新しいプロジェクト用の SaaS（B2B）企業を対象としたサンプル LookML は、統合アプリケーション分析 GitHub リポジトリにあります。LookML を使い始めたばかりの場合は、コードを使用する前に LookML を使ってみるをご覧ください。

このサンプルコードでは、ローカルプロジェクトのインポートを使用して、各ブロックから必要な LookML をインポートします。

モデルファイルには、組み込むファイルを指定できます。次に例を示します。

include: "//marketplace_crashlytics/*.model"

もう 1 つの方法は、将来の開発を簡素化するために、ブロックから利用する LookML を直接コピーして、独自のプロジェクトに貼り付けることです。

データソースの統合で説明されている ID を使用して、複数のデータソースにわたって結合する Explore を作成します。この場合、1 つのワイドテーブルは作成されません。代わりに、Looker は、このセマンティックモデルを使用して、クエリの実行時に必要な結合を行います。次の例では、Crashlytics、JIRA、Salesforce データの間の関係を作成します。

# Crash events, combined with JIRA issues and Salesforce accounts
explore: crashlytics {
  fields: [ALL_FIELDS*, -issue.needs_triage, -issue.is_approaching_sla,]
  join: user_details {
    type: inner
    relationship: many_to_one
    sql_on: ${user_details.data__user_id} = ${crashlytics.user__id} ;;
  }
  join: account {
    type: inner
    relationship: many_to_many
    sql_on: ${account.id} = ${user_details.data__account_id} ;;
  }
  join: issue {
    type: left_outer
    relationship: many_to_one
    sql_on: ${issue.external_id} = ${crashlytics.issue_id} ;;
  }
}

Explore を配置することで、エンドユーザーはクロスプラットフォームの質問をサポートするセルフサービス分析環境にアクセスできるようになります。また、ブロックで提供される LookML ダッシュボードをインポートしてコピーし、各データソースの情報を結合した指標を使用してより効果的なダッシュボードを開発することもできます。

LookML ダッシュボード

運用ワークフローを自動化する

データを運用アクティビティに組み込んで繰り返しタスクを自動化するには、Looker アクションを使って他のアプリケーションにデータを送信します。Looker アクションの詳細と、Looker アクションを有効にする方法については、管理者の設定 - アクションをご覧ください。

このドキュメントでは、Looker のアクションを使用して以下のことを行う方法について説明します。

データを Google スプレッドシートに送信し、Google スライドでデータを可視化する。
さまざまなソースのデータのしきい値に基づいて、JIRA の問題を自動的に作成する。
お客様に特別な対応が必要な場合は、Slack ですぐに通知されます。詳細については、Slack 統合への配信のスケジューリングをご覧ください。

BigQuery にデータソースを一元化すると、さまざまなユースケースで情報を分析できます。BigQuery で計算できる指標と Looker 内で自動化できるワークフローの例については、レポート、バグの優先順位付け、アカウントの管理をご覧ください。

レポート

経営チームは、ビジネスに関する最新の情報を把握する必要があります。経営幹部にとって重要な指標としては、目標に対する収益ターゲット、1 日の平均アクティブユーザー数などがあります。

目標へのトラッキングを可視化する

Google スプレッドシートに保存された収益目標（salesforce.goals テーブルに格納されている）と CRM 内の顧客情報を比較することで、目標に対するトラッキング方法を可視化できます。

# Total Bookings Goal for Current Quarter plus Closed Revenue
SELECT
goals._Total_Bookings_ as goal,
SUM(CASE WHEN opportunity.stage_name = 'Closed Won' THEN opportunity.amount  ELSE NULL END) AS total_closed_won_amount,
FROM salesforce.opportunity  AS opportunity
LEFT JOIN salesforce.goals AS goals
ON CONCAT('Q' , EXTRACT(QUARTER FROM opportunity.close_date)) = goals.Quarter
AND EXTRACT(YEAR FROM opportunity.close_date) = goals.Year
WHERE DATE_TRUNC(opportunity.close_date, QUARTER) = DATE_TRUNC(CURRENT_DATE(), QUARTER)
GROUP BY 1

LookML では、Liquid 変数を使用して、ユーザーが適用したフィルタに基づいて、特定のチーム、リージョン、または期間に対する正しい目標を動的に取得できます。Liquid の使用方法については、Liquid 変数リファレンスをご覧ください。Liquid の使用例については、Google スプレッドシートのサンプルでモデル化されたこちらのデモビューファイルをご覧ください。

目標へのトラッキングを可視化する

1 日のアクティブユーザー数の平均を算出する

1 日のアクティブユーザーの平均指標は、Firestore および Salesforce からのアカウントの詳細からユーザーアカウントマッピングテーブルに結合された Google アナリティクスイベントログに基づき、各アカウントごとに毎日ログインしたユーザーの数を表します。

    # Average number of active users each day for each account
    WITH account_facts AS
    (SELECT
        events.event_date AS event_date,
        account.id  AS account_id,
        COUNT(DISTINCT events.user_id ) AS number_of_users
    FROM google_analytics.events AS events
    LEFT JOIN firestore.user_details AS user_details ON events.user_id=user_details.data.user_id
    FULL OUTER JOIN salesforce.account  AS account ON account.id = user_details.data.account_id
    GROUP BY 1, 2)

    SELECT
        account_facts.event_date AS account_facts_event_date,
        AVG(account_facts.number_of_users) AS account_facts_average_number_users
    FROM account_facts
    GROUP BY 1

ワークフローを運用化する

ダッシュボードで指標を可視化するだけでなく、これらのワークフローを運用化できます。たとえば、チームが目標を達成したときに通知を送信するようにアラートを作成できます。

ワークフローを運用化する

もう 1 つの例として、指標から取得した情報を使用して、全社的な会議用に Google スライドのデッキを作成します。これを行うには、Google スプレッドシートにレポートをスケジュール設定します。

Google スライドに入力する

次に、Google スライドで Google スプレッドシートのデータに基づいてグラフを作成できます。

バグに優先順位を付ける

お客様に対するサービス提供の中断に優先順位を付け、解決および最小化するために、テクニカルプログラムマネージャー、プロダクトマネージャー、およびデベロッパーは、アプリケーションの問題の影響を測定する必要があります。このユースケースに対処するための指標には、価値の高いユーザーに対して発生したクラッシュやチャットサポートで報告された問題などがあります。

価値の高いユーザーが経験したクラッシュをフィルタする

CRM データを使用すると、特定のしきい値を超えた値による Crashlytics の問題をフィルタできます。

# Issues that resulted in a fatal crash for accounts worth more than $5000
SELECT
    DISTINCT crashlytics.issue_id
FROM crashlytics.[my_table] AS crashlytics
INNER JOIN firestore.user_details  AS user_details ON user_details.data.user_id = crashlytics.user.id
INNER JOIN salesforce.account  AS account ON account.id = user_details.data.account_id
WHERE (select sum(amount) from salesforce.opportunity where account_id = account.id) > 5000 and crashlytics.is_fatal

チャットサポートで発生した問題をフィルタする

サポートログデータを Crashlytics と組み合わせることで、チャットサポートでお客様によって報告された問題をフィルタできます。

# Issues that are linked to at least one Zendesk ticket
SELECT crash.issue_id, count(distinct zen.id) as num_tickets
FROM crashlytics.[my_table] as crash
INNER JOIN jira.issue as jira on jira.external_issue_id = crash.issue_id
INNER JOIN zendesk.ticket as zen on zen.id in unnest(jira.c__zendesk_ticket_ids)
GROUP BY 1
HAVING COUNT(distinct zen.id) > 0
ORDER BY 2 DESC

この情報により、エンドユーザーは特定の条件を満たす新しいバグ（新しいリリースで特定されたバグが価値の高いお客様にも影響を与える場合など）の通知を設定できます。

これらの問題に関する通知を受信することに加え、エンドユーザーが JIRA Looker アクションを使用して、クエリに入力されたフィールドで提供される情報を使用してバグを自動的に作成することもできます。

JIRA のバグを作成する

アカウントを管理する

定着率を向上させ、アップセルの機会を活用するには、営業担当者とアカウントマネージャーが顧客の健全性を評価し、注意が必要なアカウントを優先する必要があります。これらのペルソナに関連する可能性がある指標には、アカウントのクラッシュや使用傾向の影響を受けるお客様が含まれます。

クラッシュの影響を受けたお客様を特定する

CRM データと Crashlytics 情報を結合することにより、エンドユーザーはクラッシュ情報をフィルタして、自分のアカウントでのみ表示できます。

#Get account information for customers that experience a fatal or non-fatal crash
SELECT
    account.id  AS account_id,
    account.name  AS account_name
FROM crashlytics.[my_table] AS crashlytics
INNER JOIN firestore.user_details  AS user_details ON user_details.data.user_id = crashlytics.user.id
INNER JOIN salesforce.account  AS account ON account.id = user_details.data.account_id
LEFT JOIN salesforce.user  AS account_owner ON account.owner_id = account_owner.id
WHERE (account_owner.name ) = 'myname'
GROUP BY
    1,
    2

アカウントの使用状況の傾向を特定する

アカウントの使用状況の傾向を特定することで、Google アナリティクスのデータを基にアクティブユーザー数が前週比で減少した顧客に焦点を当てることができます。

# Calculates the average week-over-week change in event counts for each account over the past 4 weeks
WITH week_over_week as (
  SELECT
  account_id,
  (events_count - LAG(events_count,1) OVER (PARTITION BY account_id ORDER BY event_week DESC)
    )/LAG(events_count,1) OVER (PARTITION BY account_id ORDER BY event_week DESC) AS wow_change
  FROM
  (
    SELECT
      account.id  AS account_id,
      DATE_TRUNC(PARSE_DATE('%Y%m%d', events.event_date), WEEK(MONDAY)) AS event_week,
      COUNT(*) AS events_count
  FROM google_analytics.events AS events
  LEFT JOIN firestore.user_details  AS user_details ON events.user_id=user_details.data.user_id
  FULL OUTER JOIN salesforce.account  AS account ON account.id = user_details.data.account_id
  WHERE PARSE_DATE('%Y%m%d', events.event_date) >= (current_date() - 4*7)
  GROUP BY
      1,
      2
  )
)
SELECT account_id, AVG(wow_change) avg_wow
FROM week_over_week
GROUP BY 1
ORDER BY 2 ASC

Slack の統合を使用すると、お客様の週次アップデートを入手し、その情報に基づいて迅速に対応できます。Looker アプリケーションでは、指定したエンドポイントに POST リクエストを送信するカスタムのフィールドレベルのアクションを作成できます。これにより、Salesforce のフィールドを直接更新できます。また、Looker アプリケーションから顧客に連絡することもできます。

Looker でカスタムフィールドレベルのアクションを作成する

次のステップ

BigQuery ドキュメント
Looker のドキュメント
Cloud Architecture Center で、Google Cloud に関するリファレンスアーキテクチャ、図、チュートリアル、ベストプラクティスを確認する。

Firebase、BigQuery、Looker を使用した統合アプリ分析プラットフォームの作成

アーキテクチャ

料金

始める前に

環境の準備

BigQuery でのデータの一元化

Google アナリティクス 4 からのエクスポート

Crashlytics からのエクスポート

Firestore から BigQuery へのエクスポート

Google スプレッドシートでのデータのクエリ

サードパーティ製ツールを使用したデータのエクスポート

データソースの統合

ユーザー ID をデータソース間でマッピングする

データソースを CRM にマッピングする

データソース間で問題 ID をマッピングする

Looker でのデータの分析

Looker に BigQuery を接続する

Looker Blocks を使用する

運用ワークフローを自動化する

レポート

目標へのトラッキングを可視化する

1 日のアクティブ ユーザー数の平均を算出する

ワークフローを運用化する

バグに優先順位を付ける

価値の高いユーザーが経験したクラッシュをフィルタする

チャット サポートで発生した問題をフィルタする

アカウントを管理する

クラッシュの影響を受けたお客様を特定する

アカウントの使用状況の傾向を特定する

次のステップ

1 日のアクティブユーザー数の平均を算出する

チャットサポートで発生した問題をフィルタする