こんにちは。ponpoko1968です。

モバイル分析ツール「 Countly」の紹介、最後の3回目は実際のアプリを登録してSDKを組み込むまでを説明します。

アプリの登録

前回、サーバを起動して、アプリの登録画面がブラウザに表示されるまでを説明しました。
countly_initial_screen


実際に分析対象とするアプリを登録するには、上の画面で、
  • アプリの名称
  • カテゴリ選択
  • タイムゾーン
  • アイコン画像
を入力して、[アプリケーションを追加]ボタンを押します。もし、ボタンを押して何も起きない場合、前回説明した、countly-server/frontend/express/public/javascripts/countly/countly.config.jsのcountlyCommon.READ_API_URLという変数の値が正しくない(たとえば、ポート番号など)ことが考えられるので、修正してapp.jsを再起動し、ブラウザをリロードして最初からやりなおしててください。


設定が正しければ、下記のような画面が表示されるはずです。下の画面の「アプリケーションキー」の項目に表示されている文字列でサーバはアプリを識別します。SDKをアプリに組み込む際に使用するので控えておいてください。
countly_new_app

SDKの組み込み

次に、アプリにSDKを組み込みます。今回はiOSアプリの設定例を説明します。まずgithubからiOS用SDKのソースコードを取得します。
$ git clone https://github.com/Countly/countly-sdk-ios.git
Xcodeであらかじめ作ってあるアプリのプロジェクトを開いて、
  • Countly_OpenUDID.m
  • Countly.m
  • Countly.xcdatamodeld
  • CountlyDB.m
をドラッグ&ドロップで追加します。
countly_dnd_source

次に、プロジェクト設定の[Build Phase]タブの、"Link Binary with Libraries"を展開して、「+」ボタンを押すと、リンク可能な標準ライブラリのリストが表示されるので、その中から、
  • CoreTelephony.framework
  • CoreData.framework
を追加します。
countly_link_library


なお、ARCに対応したプロジェクトでCountly SDKを使用する場合、先ほど追加した、Countly SDKのソースコードはARC未対応であるため、コンパイルオプションに-fno-objc-arcをつける必要があります。リンク設定同様、プロジェクト設定の[Build Phase]タブの、"Compile Sources"を展開して、
  • Countly_OpenUDID.m
  • Countly.m
  • CountlyDB.m
をそれぞれダブルクリックするとソースファイル個別に適用するコンパイラオプションを指定する画面が表示されるので、"-fno-objc-arc"と入力します。
countly_objc-no-arc

次に、ソースコードを修正して、Countlyによるトラッキングを有効化します。
#import "Countly.h"
#import "CSAppDelegate.h"

@implementation CSAppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [[Countly sharedInstance] start:@"YOUR_APP_KEY" withHost:@"https://YOUR_API_HOST.com"];
.... 
「YOUR_APP_KEY」の部分は、アプリ登録後の画面に表示された「アプリケーションキー」、「https://YOUR_API_HOST.com」の部分は通信先APIサーバのURLで置き換えます。


カスタムイベントを登録するには
アプリ固有のイベントを記録・計測するには、カスタムイベントを使います。
記録したいイベントが起きたコードの前か後に、
[[Countly sharedInstance] recordEvent:@"event-name" count:1];    
と書くと、カスタムイベントが送信されます。1ユーザにつき、複数回起こりうるイベント、たとえばアプリ内課金などは、count:引数にアプリ側がカウントしていた回数を指定すれば良いでしょう。

イベントを送信する際、ユーザの属性など、付帯する情報を送ることも可能です。

NSDictionary* userAttribute = @{ @"userID" : user.id, @"level", user.level };

 [[Countly sharedInstance] recordEvent:@"event-name"

   segmentation:userAttribute 

   count:userBehavior.aCounter++];

付帯的な属性はNSDictionaryクラスにキー文字列、値のペアを設定して、Countly APIに渡すことが出来ます。

なお、CountlyはSDKの使用例サンプルも公開されており、githubから取得可能です。参考にしてみてください。

https://github.com/Countly/countly-sdk-samples.git

SDKを読んで気がついたこと

この記事の第1回でも書きましたが、Countlyを用いるユニークなメリットとして、クライアントSDKのソースが読めることが挙げられます。筆者がiOS版SDKのコードを読んで感じたことなどを簡単に共有しておきます。
  • 登録したイベントはすぐには送信されずCoreDataベースのキューに永続化され、バックグラウンドで順次送信される
  • つまり、アプリの異常終了があっても、データが失われることなく再起動時に送信が再開される
  • Countlyクラスのsuspend,resumeメソッドでイベントの送信処理を中断・再開できる。音ゲーやシューティングゲームなど、操作タイミングにシビアなゲームなどで、メインの処理を妨げないようにできそう
  • アプリがサスペンドしたら、送信処理は中断され、レジュームしたら再開される

まとめ
  • 導入自体は比較的簡単
  • 商用サービスよりは機能が少ないが、工夫とカスタマイズで補う余地はある
  • クライアントSDKのソースが読めるのは安心
  • ベース技術がnode.jsとmongoDBということで、導入する組織が、これらの運用ノウハウ(負荷・障害対策など)をもともと持ってるかどうかはポイントか

Countlyの紹介は以上となります。このシステムを実運用するとなると、それはそれで、いろいろと考慮・検討すべきことが多いとは思うのですが、手元のローカル環境では、思いのほか簡単に試せたので、アプリの行動解析に興味のある方は試してみられて、こういったサービスがどのようなものか見てみられてはいかがでしょうか。

ではまた。