• [アーティクル]

2015 年 7 月

Volume 30 Number 7

Google Analytics - Google Analytics による Windows/Windows Phone アプリでのユーザーの行動分析

Nicola Delfino

アプリの開発は、本質的には反復プロセスです。そのため、アプリの使用方法、新バージョンや新機能のリリースによるユーザーの行動への影響などを、できる限り短時間で知りたいと考えます。ある機能が実際にはどの程度使用されているか。特定のページでユーザーはどのように行動するか。ユーザーは特定のタスクの完了にどの程度時間をかけているか。最もよく使われているハードウェア構成はどのようなものか。クラッシュが起きたらどうなるか。試用版とアプリ内購入はどの程度成功しているか。ユーザーはアプリをオフラインで実行するか。以上は、利用統計情報システムを利用すれば答えが得られる疑問の一例にすぎません。

Windows 開発を公式にサポートする利用統計情報プロバイダーは数多く存在します (bit.ly/1KGgAdQ、英語)。また、Visual Studio Application Insights が Microsoft Azure に組み込まれ、さらに Visual Studio 2015 にも統合されます (https://azure.microsoft.com/ja-jp/documentation/articles/app-insights-get-started/)。

Google Analytics もその 1 つです。Google Analytics SDK for Windows (Codeplex、bit.ly/1zXfvxJ、英語、から入手可) により、Windows アプリや Windows Phone アプリ (Sliverlight とユニバーサルの両方) に簡単に統合できます。

今回は Google Analytics に注目します。Google Analytics は、Web などの Windows 以外のプラットフォームで最も広く使用されている利用統計情報プロバイダーの 1 つです。既に Web サイトを Google Analytics でインストルメント化しており、アプリでも同じアカウントを使用する場合は Google Analytics が最適な選択肢です。ここでは、Google Analytics での利用統計情報の収集方法や、インストールしたアプリのバージョン、地理的分布、ユーザーの行動など、収集したデータの分析方法、および A/B テストの実行方法を取り上げます。

利用統計情報の概念を理解しておくことは、使用する利用統計情報プロバイダーを問わず有益です。今回のトピックに関しては、Build 2014 で使用された Kraig Brockschmidt のデッキから始めることをお勧めします (bit.ly/1QGIsSO、英語)。

Google Analytics とは

Google Analytics は当初 Web サイトでのユーザーの行動を追跡して分析することを目的に開発されました。時間の経過と共に、Google はそのサポートとツールの対象をアプリに拡大し、現在 Google Analytics SDK が Android や iOS でも利用できるようになっています。Google は測定プロトコルも用意しています。この測定プロトコルを利用すると、ユーザー操作のデータを加工しないで Google Analytics サーバーに直接送信するために、HTTP 呼び出しを行えるようになります (bit.ly/1kHgDYz、英語)。これにより、ユーザーがどのようにそれぞれのタスクに関わっているかをほぼすべての環境で特定できます。Google Analytics SDK for Windows を Windows 8 と Windows Phone で用いる場合にはこのプロトコルを使用します。この SDK は独立したオープン ソースのツール セットで、公式の Google Analytics SDK for Android と同じ機能と同様の API を備えることを目指しています。

Google Analytics とアプリの統合

アプリを統合するには、まず有効な Google アカウントを使用して Google Analytics ダッシュボードにアクセスする必要があります。次に管理領域 (bit.ly/1kPLnqG) にアクセスできるアプリケーション アカウントを少なくとも 1 つ作成します。開発、ベータ テスト、運用のそれぞれに別のアプリケーション アカウントを作成するようにします。こうすることでそれぞれのデータ セットを分離し、他の開発者やベータ テスターの不完全なデータで重要な運用データが変更されるのを防ぐことができます。

アプリケーション アカウントはアプリケーション (今回は Contoso) を一意に識別します。この場合の「アプリケーション」とは、実際にはさまざまなプラットフォームや Web サイトで利用可能なアプリのコレクション (Windows 用 Contoso、Android 用 Contoso、Contoso Web ダッシュボードなど) を指します。これらのアプリは利用統計情報をすべて同じアカウントに送信します。各アプリケーションを、複数のバージョン (Windows 1.0 用 Contoso、Windows 1.1 用 Contoso、Android 2.0.1 用 Contoso など) で利用することもできます。

Google Analytics でアカウントを作成したらプロパティを 1 つ以上定義することも必要です。この場合のプロパティとは自身のアカウント用のアプリまたは Web サイトのことです。アプリ プロパティは複数のバージョンを定義できます。サポートするプラットフォーム (ContosoW8、ContosoWP8、ContosoDroid など) ごとにプロパティを定義するのが合理的です。アプリの名前を決め、アプリの対象業種を分類する質問にいくつか答えると、Google Analytics は数値形式のアカウント ID と、UA-xxxxxxxx-x という形式のトラッキング ID を生成します。トラッキング ID は Google Analytics におけるプラットフォーム固有のアプリを表し、そのアプリから送信されるすべての利用統計情報通信に使用されます。

今回のサンプル シナリオでは (Windows 8.1 と Windows Phone 8.1 用の) ユニバーサル アプリを用意します。そのため、1 つの Google Analytics アカウントで 2 つのプロパティ ID を作成しました。アプリを Google Analytics と通信可能にするには、NuGet パッケージを使用します。そのためには、Windows アプリと Windows Phone アプリの両方について、[参照設定] を右クリックし、[NuGet パッケージの管理] をクリックします。次に "GoogleAnalyticsSDK" パッケージを追加します。このパッケージによって、いくつかの参照設定と、analytics.xml ファイル (図 1 参照) が Visual Studio ソリューションに追加されます。このファイルを編集し、先ほど作成したトラッキング ID をアプリから正常に使用できるようにします。

図 1 Windows と Windows Phone アプリ用の Analytics.xml

<?xml version="1.0" encoding="utf-8" ?>
<analytics xmlns="http://googleanalyticssdk.codeplex.com/ns/easytracker">
<trackingId>UA-60759067-2</trackingId>
  <appName>ContosoWindows</appName>
  <appVersion>1.0.0.0</appVersion>
</analytics>
<?xml version="1.0" encoding="utf-8" ?>
<analytics xmlns="http://googleanalyticssdk.codeplex.com/ns/easytracker">
  <trackingId>UA-60759067-1</trackingId>
  <appName>ContosoWinPhone</appName>
  <appVersion>1.0.0.0</appVersion>
</analytics>

最後に、ネットワークの使用許可がアプリに与えられていることを確認する必要があります。Windows Phone アプリの場合は、WMAppManifest.xml ファイルの [機能] タブで [ID_CAP_NETWORKING] チェック ボックスをオンにします。Windows 8 の場合は、Package.appxmanifest ファイルの [機能] タブで [インターネット (クライアント)] チェック ボックスをオンにします。

アプリのインストルメント化

開発者の多くが追跡するカテゴリの筆頭はユーザー ナビゲーションです。Google Analytics SDK を使用して、ユーザーがページにアクセスするたびに適切なイベントを送信する必要があります。これを実現するために Google Analytics SDK では SendView コマンドを公開しています。このメソッドを呼び出すのに適切な場所は各ページの Loaded イベントです。

void MainPage_Loaded(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendView("Main");
}
void Page1_Loaded(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendView("Page1");
}
void Page2_Loaded(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendView("Page2");
}

ユーザーが "View" (見る) のはアプリ ページだけではありません。(設定パネルやダイアログ ボックスなど) ユーザーが注目し、なおかつ監視や分析が必要となる UI の他の側面についても考慮する必要があります。

SendView は、追跡するページや UI の側面を一意に識別する文字列パラメーターを必要とします。この名前は、アプリ ページに対する参照として Google Analytics ダッシュボードやレポートに表示されます。名前は汎用的なものにし、意味があり、ソース ページを連想しやすいものにします。たとえアプリが複数の言語をサポートするとしても、名前を翻訳してはいけません。翻訳すると、 Google Analytics システムは別のページとして解釈します。つまり、ローカライズ版アプリの利用統計情報データを区別しない場合は、Google Analytics に送る ID 自体はローカライズしないようにする必要があります。

これで、アプリは最初のページでのユーザー ナビゲーションについての利用統計情報を送信できるようになりました。これを確認するため、アプリを開いてしばらくページ間を移動してみましょう。

ユーザー ナビゲーションとアプリ バージョン

数秒以内にナビゲーション データが準備され、分析に使用できるようになります。google.com/analytics に移動し、サインインして Google Analytics のホーム画面にアクセスします。次に、分析するプロパティ (今回の例ではプロパティは ContosoW8 または Contoso WP8) の下に表示されている [すべてのモバイル アプリのデータ] をクリックします。

ダッシュボードの開始画面には当日を除く過去 30 日間の履歴データが表示されます。新規アカウントの場合はおそらく全チャートが空白の状態になります。また、ダッシュボードには直近のデータを表示する領域もあります。このデータにアクセスするにはダッシュボード左側の [リアルタイム] ボタンをクリックします。

サマリー ページにはアクティブ ユーザー数が表示されます。また、詳細グラフを使用して直近のユーザー数を分単位と秒単位で示すスクリーン ビューも表示されます (図 2 参照)。グラフの縦棒はページにアクセスしたユーザー数を示します。

リアルタイム データ ダッシュボード
図 2 リアルタイム データ ダッシュボード

現在から 1 時間以内に最も多く表示されたアクティブ スクリーンの一覧も確認できます。この一覧にはアクティブ ユーザー数も示されています。ダッシュボード上に表示される名前はアプリケーション コードで SendView パラメーターに使用した名前です。図 2 は "Caledos Runner" のリアルタイム データの例を示しています。Caledos Runner は今回開発したアプリで、利用統計情報データの収集に Google Analytics を使用しています。Google Analytics を利用することでどれだけの情報を得ることができるかを知り、その可能性を理解していただけるように、Caledos Runner のリアルタイム データを掲載しています。

各アクティブ スクリーン名はクリックできます。そこからデータをスライスし、ページの具体的な利用方法を分析できます。ここでは、各ページの (さらに詳しくはアクセスごとの) 滞在時間が最も重要な情報の 1 つです。スクリーン名をクリックすると、スクリーンに関する平均時間を示す指標をグラフに追加できます。そのためには、[エクスプローラ] タブの [指標を選択] をクリックします。

Google が提供する優れたツールの 1 つに行動フロー レポートがあります (図 3 参照)。SendView API を利用することで、ダッシュボードで [レポート] タブの [行動] をクリックし、次に [行動フロー] をクリックすることでこのツールを使用できるようになります。行動フローでは、アプリの各ページ間をユーザーがどのように移動するかをユーザー セッションの最初から分析できます。グラフは一連のスクリーン (第 1 スクリーン、第 2 スクリーンなど) で構成されます。また接続および終了したユーザー セッション数も表示されます。セッションの終了については、(セッション数で順序付けられている) 次にアクセスされたページおよびそのページからアプリを終了したユーザー数 (赤) によって確認できます。

行動フロー レポートのサンプル
図 3 行動フロー レポートのサンプル

このツールを利用すると、ユーザーがアプリの使用中にどこで時間を費やしているかを把握できます。その結果、お気に入りのページに簡単にアクセスできるように、大きく目立つボタンを配置するといった判断につなげます。図 3 を見ると、Caledos Runner では main ページの次の移動先になるスクリーンの上位 3 つは askcloud、running、activity detail であることがわかります。この結果から、これら上位 3 スクリーンに移動するためのボタンを main スクリーンの中心の目立つ場所に配置するのがおそらく適切であることが示されます。あるいは、上位 3 つのスクリーン上で利用できる機能の一部を main スクリーンに移動し、ユーザーが目的の行動を遂げるまでに必要な時間やタップ数を減らすことも考えられます。

また、ユーザーが使用しているアプリのバージョンを知りたいと考えることもあります。その場合、この情報はアプリを実行しているデバイスから入手します。Google Analytics SDK for Windows は、毎回の呼び出しで analytics.xml から提供されるアプリ バージョンを送信するため、データをスライスすることでユーザーが使用しているアプリのバージョンを特定できます。アプリ バージョンの履歴データは、ダッシュボード左側のウィンドウから [ユーザー] をクリックし、[アプリのバージョン] をクリックすることで利用できます。図 4 は、Caledos Runner の新バージョンをストアにリリースすると通常どのようなことが起こるのかを示しています。Windows 8.1 の既定の動作では、Caledos Runner の新バージョンが利用可能になるとアプリを自動的にダウンロードしてインストールするため、数日以内にユーザー ベースの 90% 超が最新バージョンに移行します (ただしなんらかの理由で更新できない、または更新しないユーザーが 10% 未満残ってグラフにロングテールを形成しています)。

アプリ バージョンのデータ
図 4 アプリ バージョンのデータ

ユーザー ナビゲーションの追跡を通じて "勝手に" 入ってくる要素には、場所、言語、デバイス名 (Windows Phone に関しては正確性は 100% ではありません)、ネットワーク サービス プロバイダーがあります。数に関してはセッション数、ユニーク ユーザー数、新規ユニーク ユーザー数があります。

こうした情報から次の疑問に対する答えが見つかるでしょう。アクティブ ユーザー数が最も多い国や街はどこか。前月に新規ユーザーを最も獲得したのはどこか。新バージョンのリリースによってユーザーのアプリの使用頻度はどう変わったか。ユーザーの追跡では、カスタム イベント、カウンター、ディメンション、および指標を設定できるため、限界を作るのは想像力のみです。

ユーザーがアプリを使用する方法を理解するには、ユーザーがどのようにスクリーン間をナビゲーションするかを把握することから始めるのが最適ですが、入手できる情報はこれだけではありません。アプリの特定領域に関連性が高い情報を利用できます。この種の情報はカスタム イベントととして追跡可能です。カスタム イベントは一部の包括的なユーザーのやり取りや情報などであることが多く、開発チームにとって意味のある情報が満載されています。イベントは次の 4 つのフィールドから構成され、このフィールドを使用してユーザーとアプリ コンテンツとのやり取りの特徴を記述できます。

  • String 型のカテゴリ
  • String 型のアクション
  • String 型のラベル
  • Long 型の値

カスタム イベントはすべて単独の共通リストに追加されるため、カテゴリ、アクション、ラベルの各フィールドを使用することで、分析が必要な固有の情報を明確にできます。

カスタム イベントを使用して集めた情報は非常に包括的です。ここから先の統計情報の利用にはテクニックが必要です。この情報に意味を付加するために、解決策を求める課題を考えるところから始めます。この課題が利用統計情報の設計につながり、さらには必要なインストルメンテーションにつながります。それではアプローチの例を見ていきましょう。

課題: 今回のサンプル アプリには数多くの関数があり、アプリ内のさまざまなページのボタンからトリガーできます。開発の取り組みが正しい方向に向かうように、使用頻度が高い関数を把握します。

利用統計情報設計: アプリの中心となる関数はボタンによってトリガーされます。そのため、こうしたボタンのクリックを追跡すれば、おそらくユーザーの好みをより正確に把握できます。今回の利用統計情報の成功指標は、各ボタンから取得できるクリック数です。

インストルメンテーション: 選択したボタンのクリック イベントを利用して、イベントを追跡できます。

以下のコードは、ユーザーによる "play" (再生) ボタンと "stop" (停止) ボタンのクリックを記録する方法を示しています。

private void buttonPlay_Click(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "ui_action", "press", "play", 0);
// Your code here
}
private void buttonStop_Click(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "ui_action", "press", "stop", 0);
// Your code here
}

前述のユーザー ナビゲーションの分析と同様、ダッシュボード左側のリアルタイムと行動の両グループの下にイベント テーブルを表示できます。実行する分析の種類に応じて履歴またはリアル タイムのいずれかから適切な表示方法を選択できます。

イベントは特定の時間範囲 (既定は 1 か月) について表示されます。その範囲内で上位カテゴリ、上位アクション、上位ラベル別にグループ分けされたイベント数を確認できます。特定のカテゴリや特定のイベント アクションにドリル ダウンすることも、分析の日付間隔を変更することも可能です。

特定のイベント カテゴリ、アクション、またはラベルについては、合計イベント数、ユニーク イベント数、すべての値の合計、それに応じた平均値を知ることもできます。

図 5 はイベントの一覧の例です。また図 6 はグループ Grp1 の合計イベント数、ユニーク イベント数、合計値、平均値を示しています。

図 5 イベント例

グループ 操作 ラベル 値
Grp1 押す Button1 1
Grp1 押す Button1 2
Grp1 押す Button1 2
Grp1 押す Button2 3
Grp1 タップする Label1 4

 

図 6 Grp1 のサマリー値

合計イベント数 5
ユニーク イベント数 4
イベントの値 12
イベントの平均値 2.4

使用方法の実例を見ることでツールの可能性についての理解を深めることができます。"Caledos Runner" に関して言えば、追跡したアクティビティについて実際にどの程度アプリが使用されているかを把握することを考えました。また、Caledos Runner を使用するユーザーにアカウント登録を強制したくはなかったため、イベントを使用してこの情報を追跡しました。

アプリの起動時にアカウントに登録済みの各ユーザーのイベントを追跡します。また未登録の各ユーザーについては別のイベントを追跡します。下記のようなコードを使用しています。

if (!string.IsNullOrEmpty(currentUser.AccessToken))
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "user", "Cloud", "Registered", 1);
}
else
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "user", "Cloud", "Unregistered", 1);
}

ユーザーの 55% がクラウドにデータを送信していないことがわかりました。そのため、ユーザーの正確な統計データを入手するために、各 GPS アクティビティの最後に、移動距離の情報を使用する 1 つのイベントと、その GPS アクティビティの合計経過時間の情報を使用する 1 つのイベントを、次のようなコードを使ってアプリから送信します。

GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "activity", "outdoor", "time", (long)CurrentFitnessActivity.Duration);
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "activity", outdoor", "distance", (long)model.CurrentFitnessActivity.TotalDistance);

結果として、2015 年 2 月の第 1 週について、図 7 に示すデータを入手しました。

カスタム イベント例
図 7 カスタム イベント例

この分析結果から次のようなことがわかります。2 月の第 1 週に Caledos Runner は 15,000 時間 (54,000,000 秒) 以上および 51,000 km (32,000 マイル) 以上の追跡に成功しました。平均ユーザーは、1 回のアクティビティについておよそ 5 km (3.1 マイル) このアプリを利用しており、この距離を進むのにかかる時間は 1 時間と 30 分 (5,400 秒) です。

適切な情報ではありますがまだ不十分です。これは平均的使用法についての見方にすぎません。アプリの使用法が実際にはどのように分散しているかに関してさらに把握することを考えます。Caledos Runner は複数のスポーツに対応しているアプリです。そのため、最も人気のあるスポーツと、その人気は少数のユーザーがアプリを頻繁に利用していることが原因なのかどうか、それとも多数のユーザーが短い時間のみ利用していることが原因なのかどうかを把握したいと思います。

ここで、Google Analytics のカスタム ディメンションとカスタム指標が役立ちます。カスタム ディメンションとカスタム指標を利用することで、Google Analytics にデータをさらに追加することができます。こうしたデータを利用することで、ユーザーがアプリのコンテンツと情報をどのような形でやり取りしているのかという新たな疑問に対する答えを円滑に得ることができます。指標は、Google Analytics でヒットしたデータをまとめ、そのまとめたデータの種類を数えたものです。指標はレポートでは列に該当します。ディメンションによって、たとえばスクリーン名別のスクリーン表示数など、特定の値で指標を細分化できます。ディメンションはレポートでは行に該当します (bit.ly/1lOry2r)。

カスタム ディメンションまたはカスタム指標を実行する主な手順は次の 2 つです。

  • Google Analytics Web インターフェイスを使用してカスタム ディメンションまたはカスタム指標を定義する (bit.ly/1Je9RJQ)。
  • カスタム ディメンションおよび指標の値を設定および収集するコードを実装する。

各 Google Analytics プロパティでは、カスタム ディメンションのインデックスを 20 個利用でき、それとは別にカスタム指標のインデックスを 20 個利用できます。ディメンションまたは指標を作成すると、対応するインデックスを使用した指標またはディメンションをコードから参照することができます。

ここで今回の課題に戻ります。スポーツの内訳を把握するためにスコープを "ヒット" にして Activity Type (アクティビティの種類) というディメンションを作成します。次のコードを使用して、フィットネス セッション中にアプリに表示されるアクティビティの種類の情報を追跡します。

GoogleAnalytics.EasyTracker.GetTracker().SetCustomDimension(1, activityType);
GoogleAnalytics.EasyTracker.GetTracker().SendView("Running");

A/B テスト

A/B テストとはマーケティング担当者が使用する用語で、顧客の行動に対して洞察を得るテストを指します。このテストの目的はコンバージョン レートの向上にあります (Wikipedia によると、コンバージョン レートとは「Web サイトの訪問者の内、マーケティング担当者、広告およびコンテンツ製作者からの潜在的または直接的なリクエストの結果、不定期のコンテンツの閲覧や Web サイトへのアクセスという範囲を超えた行動を取る訪問者の割合」のことです)。

アプリ開発における A/B テストでは、一方が他方を上回ることを明確にできる指標を使用して、1 つの要素 (ページやボタンなど) の 2 つの異なるバージョンをテストします。

あるページの設計が A と B の 2 種類あるとします。通常、A が既存の設計 (コントロール) で、B が新しい設計です。ユーザー ベースをこの 2 つのバージョン間に分割し、アプリにとって理にかなった指標 (特定ボタンのクリックなど) を用いてそれぞれのパフォーマンスを評価して、成功の指標やコンバージョン レートを求めます。テストの最後に最もパフォーマンスが高かった要素を選択します。

具体的に説明しましょう。A、B の各設計が XAML ファイルの異なるアプリ ページ (page3v1.xaml と page3v2.xaml) だとします。各ページ上にはターゲット、つまりユーザーがクリックするボタンを配置しており、このボタンのクリック イベントを使用して、ボタンが正常にクリックされたことを認識するカスタム イベントを追跡できます。MVVM (Model-View-ViewModel) パターンを利用することで、モデルとビュー モデルを分離できるため、同一のロジックとデータを含む 2 つの XAML ファイルを簡単に用意できます。

次に下記のようなコードを使用して、バージョン A と B の間でユーザー ナビゲーションを均等に分割し、ユーザーをテスト用のページに導きます。

if (DateTime.Now.Second % 2 == 0)
  this.Frame.Navigate(typeof(Page3V1));
else
  this.Frame.Navigate(typeof(Page3V2));

次のコードでボタンのクリックを記録することで、レイアウトの結果を追跡します。

GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "ABTest", "Scenario1", "pageV1", 0);

これが、バージョン A ページでのボタン クリックです。

GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
  "ABTest", "Scenario1", "pageV2", 0);

さらに、バージョン B ページでの同じボタンのクリックです。

各ラベル (PaveV1、PageV2) の合計イベント数によって最も成功しているページが決まります。テストの最後には、成功しているページのみをアプリケーションに残してもう一方は取り除くことができます。

まとめ

最新アプリの開発では、利用統計情報ツールと分析ツールによって、アプリケーションの問題とその解決法はもちろん、ユーザーの行動をどれほどすばやく特定できるかで大きな差が生まれる可能性があります。今回説明したのは分析可能なシナリオの簡単な例にすぎません。このようなシナリオの種類と数に限界を作り出すのは、想像力と好奇心だけです。

Nicola Delfino は、イタリア語サービス部門のアプリケーション開発マネージャーで、非常に高い評価を獲得している Windows Phone フィットネス トラッキングアプリの 1 つである "Caledos Runner" の開発者です。このアプリによって、利用統計情報を使用してユーザーがアプリをどのように使用しているのかを見つけ出し、分析する機会を得ました。連絡先は nicold@microsoft.com (英語) または nicola@caledos.com (英語) です。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Kraig Brockschmidt に心より感謝いたします。