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

このドキュメントでは、データソースをデータ ウェアハウスで一元管理し、お客様の行動を深く掘り下げて、情報に基づくビジネス上の意思決定を行う方法について説明します。このタイプのソリューションは、複数のチャネルをまたいで情報を追跡するのに役立ちます。組織は、たとえば、プロダクトの改善が顧客の行動にどのような影響を与えるか、機能とアプリケーションの修正をどのように優先すべきかを決定できます。このドキュメントは、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 コンポーネントを使用します。

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

始める前に

  1. Google Cloud Console で [プロジェクトの選択] ページに移動します。

    プロジェクト セレクタに移動

  2. Google Cloud プロジェクトを選択または作成します。

  3. すべての転送について、プロジェクトで課金を有効にします。無料の転送では、$0 が請求されます。

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

    プロジェクトに対して課金が有効になっていることを確認するで詳細をご覧ください。

  4. 新しいプロジェクトでは、BigQuery が自動的に有効になります。既存のプロジェクトで BigQuery を有効にするには、BigQuery API を有効にします。

    BigQuery API を有効にする

環境の準備

BigQuery でのデータの一元化

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

  • Google アナリティクス 4 から未加工のイベントとクラッシュ データをエクスポートする。

  • Firestore から BigQuery にエクスポートする。

  • Google スプレッドシートでデータをクエリする。

  • サードパーティ製ツールを使用してデータをエクスポートする。

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

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

Crashlytics からのエクスポート

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

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 を含める方法については、次の記事をご覧ください。

  • 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 から User ID にアクセスするには、統合ユーザー ID を Salesforce ユーザー ID にマッピングします。外部ユーザー ID は、Salesforce のカスタム フィールド命名に依存します。統合型ユーザー ID を含む Salesforce Contact オブジェクトでカスタム フィールドを使用できます。カスタム フィールドは、Salesforce エクスポートでは独自の列として入力されます。

  • Salesforce(B2B): Salesforce からアカウント ID にアクセスするには、統合ユーザー ID を Salesforce アカウント ID にマッピングします。その場合、独自のデータベース(Firestore)でカスタム テーブルを作成し、1 つの列で統合ユーザー ID を追跡し、別の列で Salesforce アカウント ID を追跡して、そのテーブルを BigQuery に複製できます。

    もう 1 つの選択肢は、Salesforce アカウント ID を含めるために Google アナリティクス 4Crashlytics でカスタム変数を使用することです。

    • 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 マーケットプレイスには、特定のソースに特化した事前構築済みのデータモデルとダッシュボードがあります。Looker Block により、指標の定義と LookML の開発にかける時間を削減し、データをより深く質問できます。

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

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

Looker Blocks を検索する

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

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

モデルをインストールしたら、ビジネスニーズに合わせて定義を拡張およびカスタマイズできます。このドキュメントでは、新しいプロジェクトの作成ZendeskSalesforceJira、現時点でマーケットプレイスで入手可能な 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 アクションを使用して次のことを行う方法について説明します。

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 でカスタム フィールド レベルのアクションを作成する

次のステップ