この記事は Kristen Richards による The Firebase Blog の記事 " What’s new at Firebase Summit 2021 "を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

私たち Firebase チームは、人々が学び、生活を向上させ、行くべき場所に行き、ビジネスを成長させるうえで、デベロッパーの皆さんが重要な役割を果たしていると考えています。私たちが、使いやすく拡張可能な統合ツールを提供しようと懸命になっているのは、そのためです。そうすることによって、たくさんの人々が必要不可欠と感じ、かつ気に入ってもらえるエクスペリエンスを、継続的に皆さんが作成できるようにしたいと考えています。

 

スタートアップ企業からグローバル企業まで、あらゆる規模の企業が作った数百万個のアプリが、毎月 Firebase を積極的に活用しています。皆さんの信頼こそが、私たちが Firebase をさらによいものにしたいと考える動機です。 先日、Firebase Summit がバーチャル イベントとして復活しました。このプラットフォームのアップデートをお披露目できて光栄です。いずれのアップデートも、アプリ開発を加速させ、自信をもってアプリを運営し、簡単にスケールアップを実現するうえで役立ちます。ここでは、それぞれの新機能を詳しく紹介しますので、ぜひお読みください。イベントのウェブサイト (英語) には、Summit で紹介したたくさんのすばらしいコンテンツ（テクニカル セッション、デモ、Pathway など）がありますので、そちらも忘れずにチェックしておきましょう！

 

お時間がない方は、特定のセクションにジャンプできます。お時間のある方は、ぜひ記事全体をお読みください。

 

新しいビルディング ブロックでアプリ開発を加速

• 重要な e コマース機能を短時間で追加する新しい拡張機能
  
  
• Apple プラットフォーム、ゲームエンジン、Flutter のサポート強化
  
  
• App Check によるアプリのセキュリティ強化
  
  
• 導入予定の Google Play のセーフティ ポリシーについての詳細ドキュメント

自信をもってアプリを運営するために実用的な知見を獲得

• Performance Monitoring の新しいリアルタイム アラート
  
  
• Crashlytics に ANR（応答しないアプリ）レポートとシグナルを追加

強力なエンゲージメント ツールによる容易なスケーリング

• Cloud Messaging と In-App Messaging のキャンペーン管理機能の統合
  
  
• Remote Config コアの改善とパーソナライゼーション機能のベータ版リリース

新しいビルディング ブロックでアプリ開発を加速

Firebase は効率的に操作できるフルマネージドなインフラストラクチャを提供するので、皆さんは一番重要なことに集中してアプリを開発、運営できます。

 

重要な e コマース機能を短時間で追加する新しい拡張機能

Firebase Extensions は、あらかじめパッケージ化されたコードバンドルにより一般的な開発タスクを自動化する仕組みです。これを使うと、わずかな手順でアプリに機能を追加できます。私たちは、皆さんが信頼するおなじみの企業と連携し、新しい API を学ぶことなくさまざまなサービスを組み込めるようにしています。先日、Stripe の仲間たちが、Run Payments with Stripe (英語) 拡張機能にワンタイム支払い機能と SDK (英語) を追加してくれました。ウォレット、銀行へのリダイレクト、後払い決済など、アプリで 15 種類以上の支払い方法に対応できる新機能もリリースしたばかりです。

 

さらに、アプリに短時間で重要な e コマース機能を追加できる新しい拡張機能も複数発表しました。これらの拡張機能を使うと、ShipEngine で商品の出荷や追跡を行ったり、SendGrid のメールや Twilio の SMS メッセージを使ってショッピング カートを放置しているユーザーに働きかけたり、Elastic による Cloud Firestore 検索を実装したりできます。Google Pay を通じて、1 つのインターフェースで複数のプロバイダからの支払いを受け付けることもできます。複数の国でアプリをリリースする場合、この仕組みは特に便利です。詳しくは、Firebase Extensions のページにアクセスし、早速インストールしてみてください。始めるにあたってアイデアがほしいという方は、17 種類以上の拡張機能を使っている GitHub のサンプルアプリのコードをご覧ください。デプロイされたバージョンは、https://karas-coffee.web.app/ (英語) でご覧いただけます。

私たちのパートナーが Firebase とコラボレーションして作り上げた、これらの新しい拡張機能を活用すると、短時間でアプリに e コマース機能を追加できます

 

Apple プラットフォーム、ゲームエンジン、Flutter のサポート強化

うれしいお知らせです。Firebase が tvOS と macOS に対してベータ版レベルのサポートを提供するようになりました！つまり、お気に入りの Firebase プロダクトを使って Apple TV や Macbook 互換のアプリを開発し、運営することができます。コードベースは 1 つなので、手間を減らしつつ、優れたクロスデバイス エクスペリエンスをユーザーに提供できます。たとえば Crashlytics SDK を追加すれば、致命的なクラッシュを特定したり、Firebase Crashlytics コンソールで Apple デバイスの種類やオペレーティング システムでクラッシュを絞り込んだりできます。

Apple プラットフォームのサポート強化により、スムーズなクロスデバイス エクスペリエンスの提供が可能になります

 

ゲーム デベロッパーの皆さんは、Google の C++ SDK の多くが Apple TV をサポートしたと聞けば喜ぶことでしょう。あの Apple Arcade ゲームを、Firebase を使って開発できるからです。また、その機能をベースに、Cloud Firestore を Unity と C++ に対応させることで、ゲーム フレームワークとゲームエンジンのサポートを強化します。これによって強力な Cloud Firestore をすぐにゲームで利用できるようになり、ゲームのデータをほぼリアルタイムに格納したり同期したりできます。さらに、オフラインをサポートすることも、数千人以上のプレーヤーをサポートするようにゲームをスケールアップすることもできます。

Cloud Firestore が Unity と C++ に対応し、リアルタイム データ同期機能やオフライン サポートを提供します

 

また、Crashlytics の Unity SDK と NDK SDK に多数の大幅な改善を加え、ゲームのコードベースを簡単にデバッグできるようにしました。現在、Crashlytics により、ネイティブ コードでのクラッシュをより広範囲に追跡できるようになっています。Unity ゲームの IL2CPP もサポートされ、C# コードにマッピングできるシンボル化した C++ フレームが増えています。

 

最後に、Flutter のオンライン エディタである Dartpad の最新リリースにより、Flutter (英語) と Firebase を併用することで、お使いのブラウザだけでプラットフォームを超えてユーザーを獲得するアプリを開発できるようになっています。Flutter は Google のオープンソース フレームワークであり、1 つのコードベースから、ネイティブ コンパイルが可能な美しいマルチプラットフォーム アプリを構築できます。これは、Firebase のクロスプラットフォーム バックエンド サービスを自然に補完するものです。また Dartpad が Cloud Firestore と Firebase Authentication をサポートしました。これ以外の Firebase プロダクトも、近日中にサポートする予定です。dartpad.dev を開き、Firebase パッケージをインポートすると、実際に試してみることができます。サンプルアプリもご覧ください。

Flutter のオンライン エディタである Dartpad が、細かい設定なしに Firebase をサポートするようになりました

 

App Check によるアプリのセキュリティ強化

App Check を皆さんに紹介したのは数か月前のことでした。App Check は、バックエンド インフラストラクチャに強力なセキュリティ レイヤーを提供します。これは、着信するトラフィックが正規のデバイスにインストールされたアプリから来ていることを証明し、有効な認証情報を持たないトラフィックをブロックすることで実現しています。今回の 3 つの大きなアップデートによって、App Check で行えることがさらに増えました。

 

1 つ目は、App Check を使って、以前お知らせした Cloud Storage for Firebase、Realtime Database、Cloud Functions for Firebase に加えて、Cloud Firestore へのアクセスを保護できるようになったことです（Firestore Web SDK も近日中にサポートします）。2 つ目は、App Check を任意のカスタム バックエンド リソースで使えるようにするために、カスタム サーバー保護を追加したことです。この機能には、Apigee などの API 管理プラットフォームや、CloudFlare などの CDN とも統合されています。3 つ目は、App Check がサポートする証明書プロバイダの数を追加し、Apple のアプリ証明書プロバイダである App Attest や reCAPTCHA Enterprise をサポートしたことです。早速 App Check にアプリを登録し、Firebase コンソールから保護を適用してみましょう。App Check の詳細については、ドキュメントをご覧ください。

App Check がアプリとユーザーデータを保護します

 

導入予定の Google Play のセーフティ ポリシーについての詳細ドキュメント

各 Firebase プロダクトが収集および共有するデータを明示した詳細ドキュメントを公開しました。これは、Google Play に導入予定のセーフティ ポリシー (英語) に準拠するうえで役立ちます。私たちの目標は、プライバシーと透過性に対する Google の取り組みを土台として、Google Play の新しいデータ セーフティ セクションの準備をいち早く行ってもらえるようにすることです。このセクションは、来年にはアプリのユーザーに公開される予定です。

これらの画像は方向性を示すものであり、変更される場合があります。

 

自信をもってアプリを運営するために実用的な知見を獲得

Firebase を使うと、アプリのパフォーマンスや安定性を監視したり、変更点をテストしたり、問題を解決する方法についての知見を得たりできるので、可能な限り最高のエクスペリエンスを提供できます。

 

Performance Monitoring の新しいリアルタイム アラート

Firebase Performance Monitoring はアプリのパフォーマンスについてのデータを収集して提示してくれるので、アプリで厳密に何が起きているのかや、アプリが遅いとユーザーが感じたタイミングをユーザー視点で把握することができます。しかし、ローカルマシンでどれほど徹底的にアプリをテストしたとしても、ユーザーは異なるデバイス、異なる国、異なるネットワーク スピードでアクセスしているため、アプリに遅延の問題が発生する可能性が残ります。そこで、皆さんに情報を提供し続けることができるように、パフォーマンス アラートという新機能をベータ版としてリリースします。この新しいパフォーマンス アラートは、遅延の問題が発生したときに即座に調査や修正ができるように、アプリの起動時間が一定のしきい値を超えるとメールを送信してくれます。パフォーマンス アラートはコンソールから設定できます。その他のパフォーマンス指標のアラートも、近日中に追加する予定です。

Performance Monitoring の新しいリアルタイム アラートを使うと、アプリの起動時間が遅くなったときに通知を受け取ることができます

 

Crashlytics に ANR（応答しないアプリ）レポートとシグナルを追加

Firebase Crashlytics を使うと、アプリの安定性を完全に把握することができるので、バグによりたくさんのユーザーに影響がでる前に、バグの追跡や優先順位付け、解消を行うことができます。また、Crashlytics で Apple のプラットフォームやゲームのレポートのサポートが強化された結果、Crashlytics が ANR（応答しないアプリ）エラーを報告できるようになりました。私たちの調査によると、ANR は Android のすべての意図しないアプリ終了のほぼ 50% を占めています。つまり、アプリの品質にとって、クラッシュよりも ANR の方が有害である可能性があります。そこで、アプリの安定性の問題を完全に把握できるように、Crashlytics は ANR と影響を受けたスレッドのコンテキスト情報を報告するようになります。そのため、ANR が起きる理由をピンポイントで特定できます。

Crashlytics が応答しないアプリによるエラーを報告するようになったため、アプリの安定性を包括的に把握できます

 

また、Crashlytics の新しいコンセプトであるシグナルも導入しました。このシグナルは、クラッシュを分析してトラブルシューティングに役立ちそうな共通点や特徴を見つけます。今回、早期クラッシュ、新しい問題、繰り返しの問題を表す 3 つのシグナルをリリースしました。早期クラッシュは、ユーザーがアプリを起動してすぐに発生したクラッシュを指します。新しい問題は直近 7 日以内の新しい問題を、繰り返しの問題はユーザーが何度も繰り返し遭遇している問題を指します。シグナルは、Apple と Android の両方のアプリ デベロッパーが利用できます。次にアプリをリリースするときに、ぜひ確認してみてください！

Crashlytics のシグナルは、トラブルシューティングに役立つ可能性があるクラッシュの共通点や特徴を明らかにします

 

強力なエンゲージメント ツールによる容易なスケーリング

Firebase は、エンゲージメントや収益の増加など、皆さんが望むビジネスの成果を実現するために必要な制御や自動化、柔軟性を、アプリの拡大に合わせて提供します。

 

Cloud Messaging と In-App Messaging のキャンペーン管理機能の統合

Firebase Cloud Messaging を使うと、異なるプラットフォームのユーザーを対象に、ターゲットを絞ってカスタマイズしたプッシュ通知を自動で簡単に送信できます。そのため、 積極的にアプリを使っていないユーザーにアプローチできます。Firebase In-App Messaging を使うと、コンテキストに合わせたメッセージを 積極的にアプリを使っているユーザーに送れます。そのため、重要なアプリ内アクションを行ってもらうように促すことができます。この 2 つのプロダクトは、連動してユーザーのエンゲージメントを維持します。今回、コンソールによる操作を再設計し、この 2 つの機能を統合しました。この統合ダッシュボードを使うと、メッセージング キャンペーン全体を包括的に確認できるので、異なるユーザーを対象に洗練されたマルチタッチ キャンペーンを行い、その反応を 1 か所で確認できます。たとえば、Cloud Messaging と In-App Messaging の両方が Google アナリティクスの新しい予測オーディエンスとシームレスに連携するので、離脱しそうなユーザーにクーポンコードを送信してつなぎ止めることができます。新しい統合ダッシュボードを使ってみるには、コンソールを開いて [Preview now] ボタンをクリックしてください。

Cloud Messaging と In-App Messaging の統合ダッシュボードでは、1 か所でキャンペーンの確認と管理が行えます

 

Remote Config コアの改善とパーソナライゼーション機能のベータ版リリース

ユーザーを維持して喜ばせるためのもう 1 つの方法は、ユーザーのニーズや嗜好に合わせてアプリをパーソナライズすることです。Firebase Remote Config を使うと、新しいバージョンをリリースすることなく、アプリの外観や動作を動的に制御して変更できます。今回、パーソナライゼーションと呼ばれる新しい Remote Config の機能がベータ版としてリリースされたことをお知らせします。パーソナライゼーション機能は、皆さんが重視する目標を最大化できるように、機械学習の力を利用して個々のユーザー エクスペリエンスを 自動的に 最適化してくれます。最初にシンプルな設定さえしておけば、それぞれのユーザーの成果が最高になるようなアプリの設定を継続的に見つけて適用してくれるので、皆さんの負担を軽減できます。

 

ジェットパック･ジョイライド、ダン・ザ・マン、そして人気作 Fruit Ninja などのタイトルを手がけているゲームスタジオ Halfbrick は、既にパーソナライゼーションを使って収益を 16% (英語)、アプリストアでの肯定的な評価を 15% アップさせています。別の早期ユーザーである Ahoy Games は、たくさんのゲームでパーソナライゼーションを試し、チームの作業をほとんど、あるいはまったく行うことなく、アプリ内購入を 12～13% 増加 (英語) させています。

Remote Config のパーソナライゼーションは、目標を達成するために機械学習を使ってユーザー エクスペリエンスを最適化します

 

Remote Config のコア機能にも、いくつかの改善を加えました。たとえば、パラメータの編集フローをアップデートしてターゲッティング条件やデフォルト値の変更を簡単にしたことや、データタイプのサポートの追加によってデータの検証を強化し、不適切な値をユーザーに配信してしまうリスクを軽減したことなどです。さらに、変更履歴を刷新し、最後のパラメータの変更がいつどのように行われたのかがはっきりわかるようにしました。これにより、主な指標の変化と相関性があるのはどの設定の変更なのかが理解しやすくなります。Remote Config のコンソールを開くと、これらのアップデートを確認できます。早速パーソナライゼーションをお試しください。

Remote Config のターゲッティングとデータ検証の改善

 

皆さんのアプリ体験をサポートするパートナー

私たちは、アプリの開発から最適化まで、すべての行程をサポートするパートナーです。私たちが目指すのは、アプリ開発を簡単かつ高速にし、皆さんが効率的に成功を収められるようにすることです。ユーザーやビジネスにとって最適なアプリにするため、ぜひ Firebase をご活用ください。今回お知らせした内容についてさらに詳しく知りたい方は、Firebase Summit のテクニカル セッションや Codelab、デモをご覧ください (英語)。2022 年にリリースされる予定の機能を一足先に見てみたい方は、アルファ版プログラムにご参加ください (英語)。

Reviewed by Tamao Imura - Developer Marketing Manager, Google Play

この記事は Todd Kerpelman による The Firebase Blog の記事 "New Changes Coming to Sessions and User Engagement in Analytics" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Firebase デベロッパーの皆様に、今後予定されている Firebase 向け Google アナリティクスの重要な変更についてお知らせします。今回の変更により、ユーザー エンゲージメントとセッションの測定方法が変わります。既存の BigQuery のクエリに修正が必要になる場合もありますので、ぜひご一読ください。

セッションに関わる変更

これまでセッションは、以下の基準に基づいて測定されていました。

• 現在のセッションがなくても、アプリがフォアグラウンドに移って 10 秒経過すると、Firebase 向け Google アナリティクスが

  session_start

  イベントをトリガーします。
• アプリがフォアグラウンドに移って 30 分経過すると、セッションが終了したものと見なされます。
• つまり、ユーザーがしばらくアプリを使用していて、少しの間だけ別のアプリに切り替えてから元のアプリに戻った場合でも、1 回のセッションとしてカウントされていました。
• これらの時間値は両方とも、クライアントにローカルで設定できました。
• BigQuery でイベントをセッション別にグループ化する場合は、手動で行うしかありませんでした。つまり、

  session_started

  イベントの 10 秒前に発生した

  pseudo_user_id

  に対して

  session_started

  と同一のイベントをすべて選択し、それをセッションが終了するまで（つまり30分経過後まで）継続する必要があったのです。BigQuery でイベントをグループ化するのは非常に面倒な作業でした。

最新の Firebase SDK では、セッションの測定方法を以下のように変更する予定です。

• アプリがフォアグラウンドに移るとすぐに、Firebase 向け Google アナリティクスが

  session_start

  フォアグランドに移ってから

  session_start

  をトリガーするのに10秒待つ必要はなくなりました。
• これまでと同様、アプリがフォアグラウンドに移って 30 分経過するとセッションは終了したものと見なされます。
• 上記以外の変更点として、イベントに

  extend_session

  パラメータを追加できるようになります。このパラメータを追加したイベントは、バックグラウンドでトリガーされた場合でもアクティブなセッションの一部と見なされます。バックグラウンドで使用することが多いアプリ（音楽アプリ、ナビゲーション アプリなど）に便利です。
• ほぼすべてのイベントに新しいプロパティを追加し、どのセッションのイベントかを識別できるようにします。具体的には、セッション固有の識別子となる

  ga_session_id

  イベントが追加され、単調増加する

  ga_session_number

  パラメータを使ってユーザーのセッション数をカウントできるようになります。

これらの変更の影響

Firebase コンソールでみなさまが気づかれるであろう最も大きな変化は、アプリのセッション数が増えることでしょう。これは、ユーザーによるアプリの利用が 10 秒未満でもカウントされるようになるためです。セッション数が増えるということは、結果として統計情報の「セッションあたりの平均 xxx」は減ることになります。
BigQuery に関しては、新しいイベント パラメータのおかげで集計の手間が大幅に軽減されます。データをセッション別に分析する場合は、 ga_session_id でグループ化するだけです。独自の「セッションあたりの平均 xxx」を計算したい場合も簡単です。

たとえば、平均的なユーザーが 1 セッションあたりに生成する

level_complete_quickplay

イベントの数を計算するクエリは次のようになります。

SELECT AVG(total_quickplays) as average_quickplays_per_session FROM (

  SELECT COUNT(event_name) as total_quickplays,

    (SELECT value.string_value FROM UNNEST (event_params) WHERE key =

      "ga_session_id") as session_id

    FROM `firebase-public-project.analytics_153293282.events_xxxxxxxx`

  WHERE event_name = "level_complete_quickplay"

  GROUP BY session_id

  HAVING session_id IS NOT NULL

)

また、たとえばユーザーが購入に至るまでにかかった平均セッション数を知りたい場合も、

ga_session_number

パラメータを分析することで簡単に計算できます。
ユーザー エンゲージメントに関わる変更
これまで Firebase では、ユーザー エンゲージメントの総数を測定するために、ユーザーがフォアグラウンドでアプリを利用した時間を記録し、その値（増分測定値）を

user_engagement

イベントとして送信していました。このイベントで送信された

engagement_time_msec

パラメータの値を集計することで、ユーザーがアプリを利用した時間の合計を計算していました。
この

user_engagement

イベントが送信されるタイミングとして一般的なのは、a）アプリがバックグラウンドに移行したとき、b）画面を切り替えたとき、c）クラッシュしたとき、d）アプリを 1 時間利用したときなどです。つまり、

user_engagement

イベントは、

app_exception

や

screen_view

などのイベントと一緒に送信される可能性が非常に高いということです。そこで、イベントを余分に送信する代わりに、もともと送信していたイベントのパラメータとしてエンゲージメント時間を送信することにしました。
この変更は、2019 年の早い段階で実施します。今後も

user_engagement

イベントが単独で送信されることはありますが、基本的には

engagement_time_msec

パラメータが追加されたイベントが Firebase 向け Google アナリティクスで自動的に生成されるようになります。まずは

screen_view

first_open

app_exception

の 3 つのイベントから開始し、将来的にはその他のイベントにも追加していく予定です。
これらの変更の影響
Firebase コンソールに変更はありません。これまで大量に送信されていた

user_engagement

イベントが少なくなるため、アプリのデータが若干減少する可能性があります。それ以外に、目に見える変更は特にありません。
BigQuery に関してですが、重要な指標の計算で

user_engagement

イベントをフィルタしている場合は、

engagement_time_msec

パラメータが追加されたイベントが照会されるようにクエリを修正する必要があります。
たとえば、次に示すクエリでは、

user_engagement

イベントの

engagement_time_msec

パラメータを集計し、ユーザーごとに

user_engagement

の合計時間を計算しています。このクエリは、今回の変更前は正常に動作しますが、変更後は不正確な値が算出されるようになります。

SELECT SUM(engagement_time) AS total_user_engagement

FROM (

  SELECT user_pseudo_id,

    (SELECT value.int_value FROM UNNEST(event_params) WHERE key =

      "engagement_time_msec") AS engagement_time

  FROM `firebase-public-project.analytics_153293282.events_20181003`

  WHERE event_name = "user_engagement"

)

GROUP BY user_pseudo_id

このクエリを、

engagement_time_msec

パラメータが含まれているすべてのイベントを照会するように修正すると次のようになります。

SELECT SUM(engagement_time) AS total_user_engagement

FROM (

  SELECT user_pseudo_id,

    (SELECT value.int_value FROM UNNEST(event_params) WHERE key =

      "engagement_time_msec") AS engagement_time

  FROM `firebase-public-project.analytics_153293282.events_20181003`

)

WHERE engagement_time > 0

GROUP BY user_pseudo_id

修正後のクエリの利点は、ユーザー エンゲージメントの変更前と変更後の両方の測定方法に対応できることです。つまり、BigQuery クエリを今すぐ修正しても問題なく機能し、変更が実施された後もそのまま使用できるということです。
これらの変更が、短期的には最小限の手間で対応でき、長期的には負荷の軽減につながることを願っております。ご不明な点がございましたら、StackOverflow または公式サポート フォーラムまでお気軽にお問い合わせください。

今後も Google アナリティクスをご活用ください。

Reviewed by Yusuke Fujita - モバイルアプリスペシャリスト

この記事は Google Analytics チームによる Accelerated Mobile Pages Project の記事 "Google Analytics is Enhancing Support for AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


この記事は、Google アナリティクス チームによってGoogle アナリティクス ブログに投稿された記事の クロスポストです。

この 1 年間で、Accelerated Mobile Pages（AMP）テクノロジーはニュースサイトからレシピ、e コマースに至るあらゆる種類のサイトで採用され、ページの高速化を実現してきました。公開されている AMP ページは既に数十億を数えており、Google アナリティクスでは AMP を導入されたサイト運営者様のためのサポート強化を続けています。

しかし、Google アナリティクスのユーザー様からは、サイト訪問者の ID が AMP ページと非 AMP ページで一致しないため、完全にナビゲーションを理解するのが難しいというフィードバックが寄せられています。そこで、ユーザーがウェブサイトの AMP ページと非 AMP ページをまたいで遷移する際のナビゲーションをさらに正確に捉えられる拡張機能をリリースしたことをお知らせいたします。これにより、AMP および非 AMP を含むサイト全体におけるユーザーのエンゲージメントをより正確に理解することができます。


新たな仕組み
今回の変更によって、サイト運営者様のドメインから提供される AMP ページのサイト訪問者と非 AMP ページのサイト訪問者が一致するようになります。2 つのページ形式によらずサイト訪問者が統一されるので、ユーザー解析の精度が上がります。Google AMP Cache などの AMP キャッシュから提供される AMP ページへの影響はありません。

導入時期
今後数週間ですべての Google アナリティクス アカウントに反映される予定です。

この変更による他の影響
AMP ユーザーと非 AMP ユーザーの統一により、今後ユーザーがサイトを訪問した際に、ユーザー数やセッション数などの指標に影響が出る可能性があります。以前は同じユーザーが別々の ID として認識されていたため、ユーザー数やセッション数は時間が経つにつれて減少します。ただし、この変更が反映された時点で ID がリセットされるため、新規ユーザー数の指標が一時的に上がる可能性があります。

また、AMP のページビューと非 AMP のページビューが別のセッションとして扱われることがなくなるので、サイトの滞在時間、セッション当たりのページビュー、直帰率などの指標は上がります。これは、過去に AMP ページを閲覧したすべてのユーザーの ID が統合されるまで続きます（この期間は、ユーザーがサイトやアプリを使用する頻度によって異なります）。

今回の変更に際して必要な対応
これらの変更は自動的に反映されるため、特にアクションは必要ありません。

自社ドメインと他社ドメインの両方で自社ページを閲覧したユーザーの識別子統合
AMP ページの中には、元々コンテンツがホストされているドメインではなく、AMP キャッシュ経由やプラットフォーム内にあるコンテンツにアクセスするものもあります。しかし、今回の変更では、クライアントに提供する価値をできるだけ速やかに高めるため、まずサイトオーナーのドメインに関する問題を修正することに重点を置いています。

私たちは、AMP ページでも非 AMP ページでも同じようにユーザーのナビゲーションを分析できるよう、最高の品質のデータを提供することに努めています。今回の変更によって、サイト運営者様のドメインで AMP ページを提供しやすくなります。この改善が皆様のお役に立つことを願っております。ぜひご利用ください。

どうぞよろしくお願いいたします。

Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

この記事は [author] による The Firebase Blog の記事 "How do I add Firebase Analytics to an app that's already using Google Analytics?" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Todd Kerpelman

Developer Advocate

私たちがよく遭遇するシナリオがあります。Firebase Analytics を使ってアプリ内のイベントデータのトラッキングや把握を行いたいものの、今まで何年もかけて Google アナリティクスの実装の微調整やチューニングを行ってきたため、新しいレポーティング ツールを白紙から使い始めるのは気が進まないという状況です。

それでも、Firebase Analytics やそれが提供する横断的機能の活用には興味があります。たとえば、自分で定義できるユーザー層（Audience）を作成して通知の対象を絞り込む機能や、Remote Config の対象指定に利用できるユーザー プロパティを作成する機能などです。

では、どうすれば両方を同時に使うことができるでしょうか。ここでは、Firebase Analytics を Google アナリティクス対応アプリに追加したい方向けに、いくつかの戦略を紹介しましょう。

まずはイベントについての話から
もう少し具体的な例をあげましょう。モバイルゲームがあり、ラウンドが終わるたびにいくつかのイベントを Google アナリティクスに送信する場合を考えます。具体的には、合計スコア、倒した敵の数、生き延びたラウンド数の 3 つです。これらの値を Google アナリティクスに記録する方法は次のようになります。

func recordGameOver() {
    let tracker = GAI.sharedInstance().defaultTracker
    let gameOverEvent = GAIDictionaryBuilder.createEvent(withCategory: "gameOver",
       action: "totalScore", 
       label: "", 
       value: myGameStats.totalScore as NSNumber)
    let enemiesBeatenEvent = GAIDictionaryBuilder.createEvent(withCategory: "gameOver",
       action: "enemiesBeaten", 
       label: "", 
       value: myGameStats.enemiesBeaten as NSNumber)
    let roundsSurvivedEvent = GAIDictionaryBuilder.createEvent(withCategory: "gameOver", 
       action: "roundsSurvived", 
       label: "", 
       value: myGameStats.roundsSurvived as NSNumber)
    tracker?.send(gameOverEvent.build() as [NSObject: AnyObject])
    tracker?.send(enemiesBeatenEvent.build() as [NSObject: AnyObject])
    tracker?.send(roundsSurvivedEvent.build() as [NSObject: AnyObject])
}

お気づきの方もいらっしゃるかもしれませんが、カスタム ディメンションを持つ 1 つのイベントを使っても同じことを行えます。大まかな考え方は同じで、これだけを行いたいのであれば、ひょっとすると 1 つのイベントを使う方が簡単かもしれません。

この仕組みによって、Google アナリティクスでちょっとしたすばらしいレポートができ、やがてはプレイヤーの最終スコア、倒した敵の数、生き残ったラウンド数を確認できるようになります。

では、どうすればこれを Firebase Analytics イベントに変換できるかを考えてみましょう。Google アナリティクスは 1 つのイベントに 1 つの値が関連付けられる階層構造になっています。一方、Firebase Analytics では 1 つのイベントに複数のキーと値のペアをイベント パラメータとして渡すことができます。

そのため、Google アナリティクス イベントから Firebase Analytics イベントへの変換は、非常に単純な 1 対 1 の変換として実行できます。次の例をご覧ください。

  FIRAnalytics.logEvent(withName: "gameOverTotalScore", 
      parameters: [kFIRParameterValue: myGameStats.totalScore as NSObject])
  FIRAnalytics.logEvent(withName: "gameOverEnemiesBeaten", 
      parameters: [kFIRParameterValue: myGameStats.totalScore as NSObject])
  FIRAnalytics.logEvent(withName: "gameOverTotalScore", 
      parameters: [kFIRParameterValue: myGameStats.totalScore as NSObject])

しかし、Firebase Analytics の世界では、次のようにして複数のカスタム パラメータを持つ 1 つのイベントとして記録する方が自然です。

  let finalStats = ["totalScore": myGameStats.totalScore as NSObject,
                    "enemiesBeaten": myGameStats.enemiesBeaten as NSObject,
                    "roundsSurvived": myGameStats.roundsSurvived as NSObject]
  FIRAnalytics.logEvent(withName: "gameOver", parameters: finalStats)

（カスタム ディメンションによるアプローチを取ろうとした方は、これに近いものになっているはずです）

この 2 番目のアプローチを取るというと、BigQuery を使ってイベントとともに送信されたカスタム パラメータを分析する必要があります。しかし、実のところ、アナリティクス データを本気で気にしている方が探しているのはこのようなものでしょう。幸運なことに、このことを説明した動画もすでにあります。

正しい方法で Firebase を追加する
Firebase Analytics を動作させようとする際に最初にぶつかる壁の 1 つは、似たようなセットアップ プロセスが Google アナリティクスと Firebase Analytics の両方で使われていることです。

たとえば iOS では、多くのデベロッパーが Google アナリティクスを動作させるために GoogleService-info.plist ファイルを生成して Xcode プロジェクトに追加しています。しかし、Firebase Analytics を正しく設定するには、もう 1 つの GoogleService-info.plist ファイルを生成してそれを Xcode プロジェクトに追加しなければなりません。どうすればこの両方を行えるでしょうか。

ここでの答えは、Firebase をインストールする際に、コンソールで新しい Firebase プロジェクトを作るのではなく、Google アナリティクス対応の既存プロジェクトを Firebase にインポートすることです。

これを行うには、Firebase プロジェクトを作成する際に、[Import Google Project] ボタンをクリックします。そして、Google アナリティクス対応プロジェクトを選択してから、プロジェクト設定の GoogleService-info ファイルをダウンロードし直します。

これによって得られるのは、Firebase Analytics と Google アナリティクスのそれぞれから入手できる plist ファイルの両方を含んだものになります。ファイルの中身を調べれば、Google アナリティクスのトラッキング ID と一致する TRACKING_ID のエントリとともに、Firebase に関するさまざまな情報が追加されていることがわかるでしょう。古い GoogleService-info ファイルをこの新しいファイルで置き換えて、残りの Firebase インストール プロセスを終えれば、準備完了です。

Android での手順も基本的には同じです。ただし、.plist ファイルではなく、.json ファイルを使います。おそらく、Xcode ではなく Android Studio を使うことになるでしょう。

では、プロジェクトの設定が正しくできたとして、どうすれば Google アナリティクスと Firebase Analytics の両方にデータを含めることができるようになるでしょうか。それには、3 つの方法が考えられます。

オプション 1: 単純に 2 つの Analytics SDK を利用する
もっとも単純なシナリオは、そのまま Google アナリティクス サービスを利用しつつ、アプリをトラッキングする Firebase Analytics を追加することです。その場合、クライアントのコードは次のようになります。

func recordGameOver() {
    // All the old code you had previously to record Google Analytics
    // … 
    // … So much code … 
    // … 
    // Now add the Firebase stuff
    let finalStats = ["totalScore": myGameStats.totalScore as NSObject,
                      "enemiesBeaten": myGameStats.enemiesBeaten as NSObject,
                      "roundsSurvived": myGameStats.roundsSurvived as NSObject]
    FIRAnalytics.logEvent(withName: "gameOver", parameters: finalStats)
}

デベロッパーの観点から見れば、なぜこのソリューションが魅力的かわかるでしょう。とても簡単に実装でき、リスクもほとんどありません。現在の Google アナリティクス レポートに問題が起きることを心配する必要もありません。すべてのクライアント コードはそのままであり、今までとまったく同じように Google アナリティクスを呼び出しているからです。新しいコードでは、Firebase Analytics も呼び出してそちらにもデータを渡しているだけです。

しかし、このソリューションにはいくつかの欠点があります。まず、データを 2 種類のアナリティクス パッケージに送っている点です。一般的に、これはクライアントが今までよりも多くのネットワーク呼び出しを行っていることを意味します。したがって、アプリは今まで以上にユーザーのモバイルデータを使うことになり、電池も悪影響を受けます。ただし、Firebase Analytics はネットワークの呼び出しがかなり控えめであるため、Google アナリティクスのトラフィックにわずかに上乗せされる程度かもしれません。

おそらく、それよりも大きな欠点は、あらゆる場所でアナリティクスのコードが 2 重に書かかれることです。すでにアナリティクスの呼び出しを別のメソッドに抽象化しているなら、実装の詳細を隠すことができるので、これはさほど大きな問題ではないかもしれません。そのメソッド 1 つに Firebase を追加すれば済むでしょう。しかし、そうでない場合、アプリ全体にこのコードを追加するというのはさほど魅力的だとは思わないでしょう。そんな方のために、別のオプションも用意されています。

オプション 2: Google タグマネージャを使用して両方にイベントを報告する

Google タグマネージャはスイスアーミーナイフのような万能ツールで、いつも私の「いつかじっくり学びたいもの」リストに載っています。これには、正当な理由があります。Google タグマネージャの非常によくできた機能の 1 つは、送信される Firebase Analytics イベントを検知すると、同じイベントを Google アナリティクスやサードパーティ アナリティクス プロバイダにも送信してくれることです。

このソリューションが優れているのは、クライアントに必要なアナリティクス用のレポーティング コードは 1 セットのみであるという点です。この例では、Google アナリティクスの呼び出しを完全に削除でき、はるかに単純な実装が可能です。

func recordGameOver() {
    let finalStats = ["totalScore": myGameStats.totalScore as NSObject,
                      "enemiesBeaten": myGameStats.enemiesBeaten as NSObject,
                      "roundsSurvived": myGameStats.roundsSurvived as NSObject]
    FIRAnalytics.logEvent(withName: "gameOver", parameters: finalStats)
    // That's it!
}

Google タグマネージャを使ってこれらのイベントを Google アナリティクスに報告するには、CocoaPods または Gradle からライブラリをインストールし、プロジェクトに .json ファイルを追加する必要があります。クライアント側での作業はこれで完了です。ほとんどの作業は、タグマネージャのコンソールで行います。

タグマネージャのコンソールで、Google アナリティクスに送信したいすべての値について、Firebase イベント パラメータ変数を作成します。この例では、totalScore、enemiesBeaten、roundsSurvived の値が必要です。

次に、それぞれの Firebase Analytics イベントに対応するトリガーを作成します。今回の場合は、「gameOver」という名前のイベントが発生したときに作動するトリガーを作成します。

最後に、このトリガーに反応して Google アナリティクスにイベントを送信するタグを作成します（これは、Google タグマネージャ内ではユニバーサル アナリティクスと呼ばれています）。AppsFlyer、Kochava、Tune などのサービスにイベントを送信することもできます。

正直なところ、私がこのアプローチを気に入っている理由は、通常、コードを書く量が少なくて済むことはよいことだからです。また、このアプローチには、アプリをリリースした後であっても特定のイベントを Google アナリティクスだけに（または Firebase Analytics だけに）レポートしたり、Firebase Analytics イベントを Google アナリティクスにレポートする方法を変更できるといった柔軟性があります。

ここで 1 つ重要になることは、現在のところ、Firebase Analytics と Google タグマネージャを一緒に使って e コマースのデータを Google アナリティクスに送ることはできない点です。現在、この件についての対応が進められていますが、Google アナリティクスで e コマースのデータが必要な場合、しばらくの間は、他のオプションの利用を検討するか、e コマース イベントを直接 Google アナリティクスに送信するコードをそのまま残しておく必要があります。

しかし、先ほどと同じように、このオプションでもクライアントからのアナリティクスの呼び出しは 2 重に行われています。これはよいこととは言えません。また、多くの時間をかけて、Google タグマネージャ パネルからトリガー、イベント、タグをすべて事前に追加しておく必要もあります。とはいえ、その程度で済むならよい方でしょう。
しかし、クライアントで 2 つのアナリティクス SDK を実行したくない場合はどうでしょう。他に考えられるオプションはあるでしょうか。もちろんです。

オプション 3: BigQuery を使ってすべてを結合する

もう 1 つの考えられるオプションは、クライアントの Google アナリティクスを完全に Firebase Analytics で置き換え、バックエンドで BigQuery を使って古い Google アナリティクス データと新しい Firebase Analytics データを結合することです。

実際にこのソリューションが意味を持つのは、すでに Google アナリティクス 360 ユーザーであり、現在大半のカスタム レポートに BigQuery を使っている場合のみでしょう。そのような場合は、両方のデータソースからデータを取得するように BigQuery クエリをアップデートするのが妥当なオプションかもしれません。

今回の例に戻り、BigQuery で次のようなクエリを実行して「最終スコアの日別の平均」レポートの生成がすでに行われているとします。

SELECT
  AVG(hit.eventInfo.eventValue)
FROM
  `my_awesome_app.ga_sessions_20170123`,
  UNNEST(hits) AS hit
WHERE
  hit.eventInfo.eventCategory = "gameOver"
  AND hit.eventInfo.eventAction = "totalScore"

これを Firebase Analytics に切り替えます。クライアント側では、Firebase Analytics のみを呼び出す先ほどの例の単純な実装を使用します。

func recordGameOver() {
    let finalStats = ["totalScore": myGameStats.totalScore as NSObject,
                      "enemiesBeaten": myGameStats.enemiesBeaten as NSObject,
                      "roundsSurvived": myGameStats.roundsSurvived as NSObject]
    FIRAnalytics.logEvent(withName: "gameOver", parameters: finalStats)
    // That's it!
}

時間ごとに倒した敵の数の平均を確認したい場合、2 つのデータセットを結合する必要があります。この SQL は、次のようなものになります。

SELECT
  COUNT(*),
  AVG(total_score) AS average
FROM (
  SELECT
    event_param.value.int_value AS total_score
  FROM
    `firebase-project.com_example_awesome_app.app_events_20170123`,
    UNNEST(event_dim) AS event,
    UNNEST(event.params) AS event_param
  WHERE
    event.name = "gameOver"
    AND event_param.key = "totalScore"
  UNION ALL
  SELECT
    hit.eventInfo.eventValue AS total_score
  FROM
    `my_awesome_app.ga_sessions_20170123`,
    UNNEST(hits) AS hit
  WHERE
    hit.eventInfo.eventCategory = "gameOver"
    AND hit.eventInfo.eventAction = "totalScore" )

明らかに、これはとても単純な例です。やりたいことやデータの構造によっては、急激に複雑になることも考えられます。しかし、もう少し洗練されたクエリを紹介してくれるGoogle クラウド ビッグデータ ブログに投稿している（もっと優秀な）同僚もいます。こちらにもぜひご注目ください。

いかがでしたでしょうか。今回は、すでに Google アナリティクス用に設定されているアプリに Firebase Analytics を追加する方法について、いくつかのヒントを紹介いたしました（この方法はその他のアナリティクス プラットフォームでも応用できます）。設定を終えたら、特定のプロパティを持つユーザーに新しい Remote Config 設定を提供する機能や、作成した Firebase Analytics オーディエンスに通知を送る機能など、Firebase Analytics データを利用するいくつかの Firebase 機能を試してみることをお勧めします。そして、Firebase Analytics でトラッキングするイベントを増やしてみてください。Firebase Analytics は無料で制限なく利用できます。アプリにどれほどのユーザーがいても大丈夫です。今後 1 年間で、Firebase Analytics にはさらに多くのおもしろいツールや機能が追加される予定です。モバイルアプリに Firebase Analytics を追加するのに早すぎるということはありません。ぜひお試しください。

Posted by Khanh LeViet - Developer Relations Team