※2016年4月追記 StoreApp / UWP App用のApplication Insights 新規受け付けは2016年4月15日で終了しています。既存ユーザーはHockeyAppへ移行するようにというアナウンスが出ています。
Transitioning Mobile Apps from Application Insights to HockeyApp
https://azure.microsoft.com/ja-jp/blog/transitioning-mobile-apps-from-application-insights-to-hockeyapp/
※2015年2月追記 Application Insights は現在Azure ベースのサービスに移行しており、本記事でお話しているVisual Studio Online 版は提供が終了するようです。このため本記事は現在のApplication Insights にはあまり当てはまるところがありません。
Azure版については以下の記事も御参照下さい。
うまく行かない人用の Application Insights ガイド(2015/02)
http://ddlgjp.blogspot.jp/2015/02/application-insights.html
------
データの取得と評価
ここでは、具体例として
ストアアプリ WiFiSD8 でどのようなデータ収集を行っているかを紹介し、又取得したデータがDashboard 上でどう見えるのか、その評価について簡単に説明します。
前記事
Microsoft Application Insights を ストアアプリで使う(その1)
本項でのデータ取得の目的
「App を起動したユーザーの内、どれくらいがWiFiSD8 の初期設定を終えて次のPage までたどり着いたかを知りたい」
今回サンプルとしているWiFiSD8 は
- 起動
- ユーザーが自分でWiFi 接続をFlashAir のSSID に切り替え
- 写真のブラウズ
というパスで動作します。FlashAir を使いなれている方ならば2 は判る…はずですが、全く初めて使う方には???な所でもあります。
現状、WiFiSD8 上では特に接続に当たってのチュートリアル等を表示していないため、写真のブラウズが本当に出来ているだろうか?という心配がありました。
これを、AIを使って確認してみます。
ページ遷移のデータ取得と評価
WiFiSD8 のページ遷移を示したのが下図です。
ユーザーが接続に成功した場合、TopPageのその先への遷移が発生するはずです。
また、失敗した場合、TopPageから動く事ができません。
この遷移が実際にはどう行われているのかのデータを取得します。
|
WiFiSD8 のページ遷移図 |
Code上の作業はとても簡単で、Page 毎のCode Behind のLoadState に以下の様に一行追加するだけです。
protected override void LoadState(Object navigationParameter, pageState)
{
ClientAnalyticsChannel.Default.LogPageView("TopPage");
wds = App.WSDDataView.wsdDataSource;
wdc = App.WSDDataView.wsdCardSource;
wdl = App.WSDDataView.wsdDownload;
...
※Parameterに文字列のDictionaryが入るとSyntaxHighlighterの動作が妙になるので削っています。
※WiFiSD8 は元々Win8 用に作成したSolutionを使っているので「LoadState」になっています。Win8.1 のTemplateで作ると又違ったはずです。
首尾良くデータ取得に成功すると、アプリを操作して
15分程度で直ぐにAI Dashboardに反映されます。この異常なレスポンスの良さはAIの長所でしょう。
さて、上のようなCodeを入れたアプリをストアに公開し、ある程度データが溜まってきたとします。
AIでは、取得したデータを大きく分けて三種類、で表示します。順に見てみましょう。
- Features アプリ内のPage View, Event から見た統計
- Users ユーザーの増減に主眼を置いた統計
- Devices デバイス種別毎の統計
1. Features
Dashboard上では、Features→Usage→Feature. と辿ると「Features」事に整理されたデータが表示されます。
(※ この項以降も同様ですが、なるべく「ざっくり」なデータを選んで紹介しています。実際のDashboardではもう少し細かいデータが出てきます。)
この円グラフで出ているのは、ある期間中の各Page表示回数を全部足したものを分母とし、それぞれの回数を割合として出したもの、になります。
ただ、このPage Viewでは総和になっているため…今回の目的、
Top Page を表示したユーザーの何パーセントがWiFiSD8 の初期設定を終えて次のPage までたどり着いたか?までは見えてきません。
2. Users
ユーザー毎の動向は、Usage/Users から見る事ができます。
…
一日あたりのUnique Userが10人、という数字に心が折れそうなのですが、そこは今回の主眼ではありません。
この「Users」Viewでは、他にも
- 1日のユニークユーザー数の内、新規ユーザーと継続ユーザーの割合
- 継続ユーザーが何日開けて又アプリを使ったか
等が取得可能です。
ポイントは、一番右、
Activities per Session です。Page View 発生回数、が「Activities」になります。これをSession、アプリ起動回数で割ると平均値は約4であると。
WiFiSD8 での動作例から考えてみると、
- 起動後、FlashAir カードの検索から先に進めなかったユーザーの場合 1セッションでTop Page を1度表示しただけで終わるため、Activities per sessionは「1」以上にはならない(検索を終えない限りWiFiSD8は他ページに遷移できない)
- 起動後、FlashAir カードへの接続に成功すると他ページへの遷移が可能となるため、Activities per session の数字は1以上。一般的なUsageを考えると…接続→グループ表示→全画面表示→グループに戻る、あたりか?この場合Activities per session は4,5程度と予想される
であると。つまり、
- 平均値が1だと100%だれも使えていない
- 1を越えると、そこそこ・・・・使えて頂いている・・かな?
辺りでしょうか。ぼんやりした話で恐縮ですが、それでも明らかに使えてもらえていると判るのは開発側としては小躍りするくらい嬉しいです。
3. Devices
ここでは、デバイス種別毎の統計が表示されます。
黒で隠している所はデバイス名…「Surface 2」「Surface with Windows8」「VivoTabRT」等が表示されています。
今回隠したのは、下の方のSession 1回のデバイスの場合…使っている人には「あ、これ俺のだ」とすぐ分かるので…そこの回数等のデータが出るのはダメだろう、という判断です。
このデータで注意すべきなのは、
あくまでも「デバイス種別毎の」統計で、「ユーザー毎」では無い、ところでしょう。
例を挙げると、一行目のデバイスAではSession 73, Activities/Session 2.92, と、かなり頻繁に使っている様子が判ります。
が、
これは「デバイスA」を使っている人が73人居る、事を示しているのかもしれません。
又は、一人でデバイスAを激しく使っているのかも、しれません。
このデータからどちらかは判りません。
※Active Userの統計から考えると73人は無いはずですが…種別毎の人数割り振りはできませんね。
さて、本項でのデータ取得と評価の目的に立ち返ると…
この表の下半分のデバイスでは、アプリを起動したものの結局何をすれば良いかわからず諦めてしまった、ケースが多いことが判ります。その総セッション数に対する割合は
14%程度。
うーん。低いとみるか高いとみるか。個人的には、何か対策を打たないとまずいなという気がしています。
…
ここまで読んで頂いて、どう思われたでしょうか。使いやすそうで実は結構使いづらいデータが多いなと個人的には思っているのですが。
AIの「個人を特定しない形でのデータ収集」という看板は伊達では無いのだなという感想です。
※ デバイス種別名、見ていると、おそらくSMBIOSのType1、ModelNameあたりを取得しているようです。
以上、簡単ですがPageViewのデータ取得と評価の実例をお見せしました。
長くなってしまったので、Numeric Eventの取得等については又章を分けたいと思います。