Compartilhar via

モバイル アプリの分析

  • Artigo

このポストは、4 月 23 日に投稿された Analytics for Mobile Apps の翻訳です。

現在、Web 上では 300 万種類 (英語) を超えるモバイル アプリが公開されています。その中で自分のアプリに注目してもらうには、どうすればよいでしょうか?

アプリの基盤となるアイデアが優れていることはもちろん重要ですが、それだけでは十分ではありません。

開発者はユーザーが体験していることをリアルタイムに把握して、ユーザーの好みにすばやく対応し、問題点を即座に修正する必要があります。

アプリを公開するのは簡単です。今では製品を段ボール箱に詰めて出荷する必要はなく、寝室でくつろぎながら、大企業と同じようにゲームや洗練されたツールを数百万本単位で販売することができます。また、ツイート ストームには大企業のマーケティング部門で行われる宣伝活動と同等の効果 (英語) が期待されます。しかし、たとえアプリのランキングで上位に入れたとしても、その順位を保つのは至難の業です。ユーザーに長い間愛用してもらえるアプリの作成は困難ですし、ユーザーもすぐに他のアプリに目移りしがちです。低価格、または無料でアプリを提供している場合、そのアプリを利用しているユーザーは、他のアプリを試すことにもあまり抵抗がありません。そのため、アプリのエクスペリエンスにユーザーが不満を抱いた場合、そのアプリの順位はあっという間に上位から下位へと転落 (英語) してしまいます。

成功の秘訣は、ユーザーが今まさに経験しているかもしれない不満な点に迅速に対応することです。かつてはソフトウェアを出荷してから、不満な点やご提案をユーザーの皆様に投書していただいていました。しかしそれは過去の話で、今では非常に迅速な対応が求められています。

ユーザーが不満に思う点は、主に次の 2 つです。

  • アプリがクラッシュする: アプリが強制終了したり、期待どおりに動作しない。
  • ユーザー エクスペリエンスの質が低い: 操作方法がわかりづらい、簡単な設定をするにも手順が複雑すぎる、操作ミスをしやすい。または、単純に機能が魅力的ではない。

ここで大切なのは、アプリの使い心地がどんなものなのか、ユーザーが不満を持つ前に把握することです。そして、分析を行う際に必ず注意しなければならないのが、周囲の友人からの聞き取りだけでこの作業を終わらせないようにすることです。

作成

アプリに小規模な SDK を含めると、クラッシュやユーザーの操作を監視することができます。ユーザー デバイスの監視データはすべて分析プラットフォームに送信され、そこでメトリックを表示したり、不具合を分析したりできます。また、アラートを設定して、無視できないレベルの問題が発生した場合に即座に把握することができます。

計測

使用状況はさまざまな方法で計測できます。まず、機能が使用された回数や、日単位または月単位でユーザーがアプリケーションを実行した回数といった単純な計測が可能です。さらに実用的なメトリックとしては、ゲームの勝利回数、作曲数、製品の購買数など、ユーザーが機能を使用して特定の成果を得た回数を測ることもできます。また、もっと細かく使用状況を把握したい場合には、大きな目標を達成するための個々の段階についてもデータを得ることができます。さらにキー操作の回数とタイミングを計測することで、ユーザーが 1 つのタスクを完了するのに時間がかかったり、何度もタップを必要とする厄介な操作がないかを確認することもできます。

標準的なメトリックのほとんどは、分析ツールで標準のアプリケーション フレームワークと連携すると、最小限のコードを追加するか、まったくコードを追加せずに収集できます。自社製アプリ独自のメトリックを取得するには、分析用 SDK を呼び出す数行のコードをアプリに挿入し、その SDK から操作回数やログ、メトリックなどを分析ポータルに送信します。

使用状況の追跡は、診断トレース機能と異なり設計時に各機能に追加するため、後から追加することはできません。このため、どのようにすればユーザーが短時間でゲームをクリアすることができるか、始めたゲームをクリアする割合を上げることができるかなど、新しいユーザー ストーリーを計画する際に、計測する項目を決定し、新しいコードがどのように計測結果に影響するかについて考慮する必要があります。

考察

将来導入を検討している機能の計画を作成する際には、下記の基本原則を守る必要があります。

計画作成にあたっては、ユーザーにとって何が大切であるかを推察するだけで済ませないこと、数週間から数か月の間変更することができない計画を作成しないことが重要です。まずは新機能を作成し、実際に実行されているアプリでどのようなことが起こるかを計測し、その結果から情報を取得します。対策をたてるためには、アプリは使用されたか、ユーザーは目標を達成できたか、アプリ ストアでのランキングは上昇したか、収益を上げることができたかなどのデータが非常に重要となります。それらの計測結果に応じて、その機能を廃止したり、ユーザー エクスペリエンスを微調整したりすることもあれば、成功とみなして次のアイデアの実現へと進むこともあります。

後はこの繰り返しです。ソフトウェアのライフサイクルとは、いくつもの細かいステップの積み重ねと、その各段階でのアプリのユーザーに対する動作の評価です。アプリの動作はパフォーマンス (一定時間内に期待どおり動作したか) と使用状況 (ユーザーが使用したか、またどのように使用したか) の両方の観点から評価されます。このアプローチでは計画段階で非常に高い柔軟性を確保することが必要で、修正を繰り返すうちに初期のアイデアが大幅に変更されることもあります。

このプロセスには、興味深いオプションがあります。たとえば、A/B テストで、あるエクスペリエンスを一部のユーザーに示し、それとは異なるエクスペリエンスを残りのユーザーに示して、どちらの人気が高いか、または使いやすいかを検証するとします。モバイル アプリの場合、更新をリリースしてもユーザーがすぐに取得するとは限らないうえに、頻繁な更新は歓迎されないため、Web アプリほど簡単にソフトウェアを更新することはできません。しかし、一連の機能テストを計画的に実施することはできます。A/B テストの 2 つの候補を同一リリースに含め、そのどちらを使用するかの指示をホーム画面で呼び出すようにソフトウェアを設定します。そして、分析を一定期間実施した後、A が B よりも優れているという結果が得られた場合、A のエクスペリエンスの使用を指示するようにすべてのインスタンスに伝達します。ベータ テストの対象ユーザー (友人や同僚、既存のユーザーからの有志など) と連絡が取れる場合は、新バージョンのアプリを頻繁にインストールすることを比較的気軽に依頼できるでしょう。これにより、一般提供を開始する前に、協力的なユーザーによる各機能のテストを実施することができます。また、ベータ版の管理と分析や結果の評価を統合するユーティリティも提供されています。

Application Insights

マイクロソフトでは、モバイル アプリと開発者が作成するアプリケーションの基盤となるサービスの情報をあらゆる角度から収集できる分析プラットフォームの構築に取り組んでいます。また、マイクロソフトのサービスが開発サイクルの重要な部分となること、SDK を新規または既存のアプリケーションに (ほとんど) 手間を掛けずきわめて容易に追加できるようにすることを目指し、日々尽力しています。

Application Insights は、この記事で取り扱った 2 つの分野で大きな役割を果たします。

先日の HockeyApp (英語) の買収以降、同社のテクノロジを Application Insights に統合する作業が進められています。モバイル開発者向けの今後の機能のリリースにご期待ください。

更新情報 (2015 年 4 月 30 日): Application Insights の iOS (英語) 版および Android (英語) 版アプリケーションのサポートとリリースが発表されました。この SDK では、セッションのテレメトリ データの自動収集、カスタム イベント、カスタム メトリック、クラッシュ分析の各機能が使用できます。クラッシュ分析機能では iOS スタックの象徴化と Android のバック トレースの難読化解除が可能です。

もちろん、どのようなツールを使用したとしても、モバイル アプリケーションの作成で成果を上げるには斬新で優れたアイデアと強運を持ち合わせていなければなりません。アプリの内容がだれの目にも留まらないものだったり、だれも楽しませることができなければ、アプリ ストアで上位のランクに入ることはできません。もちろん、その場合はベータ テストのフィードバックで改善すべき点を知ることができます。

次回の記事にもご期待ください。

Frank Weigel