追記 10/15/12
Githubにて公開されました
https://github.com/clutchio
以下は初稿です
Clutch A/B TestingはClutch.ioによるA/Bテスト実行のフレームワーク+ウェブサービス。
属にいうモバイルBaaSの内の更にA/Bテスト実行に特化した作りになっているところが面白いと思いましたのでここで紹介します。
Clutch.ioとは？
iOS/Androidに対応したモバイルアプリケーション開発基盤を提供するサンフランシスコのスタートアップが運営しているサービス。
元々はWeb技術とネイティブAPIのハイブリッドアプリケーションを作る為のClutch Frameworkを提供してたんだけど、最近A/Bテストの方に注力してきた。
ここで言うA/Bテスト
ウェブ業界のランディングページ最適化のようなサイト一部の見た目を切り替えるのが典型的な例。
iOSアプリの事情でいうとウェブアプリのように柔軟に内部処理の切り替えや平行的実験をすることが難しいので、従来は単純にウェブサイトを埋込むことで行われてきた。
Clutch A/B Testingのアプローチは,まずA/Bテスト=実験に使うデータだけをキー・バリュー構造に定義してサーバーからクライアントへ配信できるようにしておき、実験が「達成」した時に今度はクライアントがサーバにその通知をする。
そうするとその統計情報をClutch.ioのダッシュボードで閲覧・分析ができるようになる。
利用までの流れ
- Clutch.ioにユーザー登録
- Clutch.frameworkをダウンロード
- ダッシュボードからApp作成
- AppにExperimentを追加する
- iOSアプリのObjective-Cソースコードにアプリケーションキー・A/Bテスト用の記述をする
Clutch.io - A/B Testing - Documentation
テストコード
Blocksベースのメソッドを使用する。
Normal Testsは単純な分岐のみ
Data-driven Tests はダッシュボードで定義した文字列をそのままアプリに渡す
Normal Tests
// Test which color of tint performs better
[ClutchAB testWithName:@"loginButtonColor" A:^{
// Red?
loginButton.tintColor = [UIColor redColor];
} B:^{
// Or green?
loginButton.tintColor = [UIColor greenColor];
}];
Data-driven Tests
[ClutchAB testWithName:@"loginButtonTitle" data:^(NSDictionary *testData) {
// Extract the title from the testData dictionary, and assign it to the button.
loginButton.title = [testData objectForKey:@"title"];
}];
Goal
//ログイン後に呼び出す
[ClutchAB goalReached:@"loginButtonColor"];
詳細はドキュメント参照。
Clutch.io - A/B Testing on iOS - Documentation
不満だった点
Goalの段階設定が足りない。
例：ゴール=ユーザー登録完了→ボタンをタップしたけど完了まで操作してもらえなかった/ボタンをタップしてもらえなかった
プランについて
freeプランでは1つのアプリ、月に5000ユーザーのアプリ起動までに制限されてる。
これダッシュボード上は無制限に検証用にアプリを作成できて、本番に有効化できるのが1個だけとかだと使いやすいのに、と思いました。
月額プランも割高に感じるが、ちなみに以前はA/B Testingはfreeプランでは利用でなかったので改善される余地はあるかもしれない。
組込むことのオーバーヘッドについて
Clutch.ioのサーバーにA/Bテストに使う値を取得しに言って結果を送信していることによる通信処理の負担はないのか気になっている。一応ネットワークが利用不可の時は以前にダウンロードしたデータを使いまわして、結果はネットワークが復帰した時に再度サーバーに送信されるようになる。
個体識別方法について
サービスの性質上、各端末を区別しないといけないので個体識別の値を取得しているものと思われる。Clutch.ioのサイト上では
・MACアドレス+Bundle Identifierのハッシュ値
・MACアドレスのハッシュ値
が利用されると書いてある。
今のところ一方向的は送信のみなのでこのハッシュ値を元にサーバー上の個人のデータが取得できる、というようなことはなさそう。
アプリ間で端末を同定する必要もなさそうなのでUUIDでよさそうだが、このへんClutch.ioの「月あたり何ユーザーまではこの月額プラン」というビジネスモデルが関係しているのかもしれない。
留意点
自分が使ってみた限りでは特にアルファ版とか実験的とか謳っているわけではないんだけど、実用的な段階には程遠いと感じました。たとえばアプリを作成できるけど削除、変更できなかったりと。
ただ前述のとうりコンセプト自体は面白いと思うし発展の余地もありそうなので取り上げました。
むしろアプリをバンバンリリースしている会社なんかは既に同じような社内向けシステムを構成しているのかもしれません。
またサーバーアクセス解析などとは違ってデスクトップアプリの統計情報送信に近いのでユーザー同意やオプトアウト設定などまだ課題があると感じました。