マーケティングでA/Bテストはよく行われます。複数のパターンを用意して実施し、その結果を見てより良い方を採用していくという手法です。Webページ、アプリ、メールなど様々な場面でA/Bテストは行われています。
A/Bテストを実施されたい場合には以下のような方法によって実現が可能です。
Installationのデータにフラグを持たせる
Installationに保存されている各データについて、フラグを追加する方法です。
| objectId | ABTest |
|---|---|
| AAA | 1 |
| BBB | 2 |
| CCC | 1 |
| DDD | 2 |
このように交互にしても良いですし、ランダムで振り分けるようにしても良いでしょう。交互にする場合は配信前に全体のデータに対してフラグを割り当てる方法になるかと思います。ランダムの場合はInstallationを新規追加したタイミングで更新できるでしょう。ランダムの場合、Installationを削除（プッシュ通知の解除、アプリのアンインストール）することでフラグのバランスが悪くなる可能性がありますので注意してください。
後はプッシュ通知を配信する際の検索条件として、ABTestカラムの値が1の場合、2の場合と言った具合に配信内容を変えるようにすればOKです。
検索条件で指定する
配信条件を使って2パターンに分ける方法があります。プッシュ通知を作成する画面で、配信予定数が表示されるかと思います。この数値が概ね半分（2パターンの場合）になるようにcreateDateやupdateDateを調整します。一般的にプッシュ通知のデバイストークンは更新しませんのでどちらでも大きくは変わらないかと思います。
この方法の場合、データにフラグを持たせる方法とは異なりAPIを過剰に消費しないのが利点です。欠点としてはランダムなA/Bテストではなく、デバイストークンを登録した順によって区分けされてしまうという問題があります。mBaaSのInstallationのデータではランダムにピックアップする方法がないので、このようになってしまうでしょう。
個別プッシュ通知にする
プッシュ通知を全体に対して設定するのではなく、個別配信にすることでプログラミング側で配信内容を変更できます。その際にランダムに配信内容を変更することでA/Bテストの配信ができるようになります。
欠点としては、現状開封通知のAPIを提供していないために開封したか否かを集計するのが手作業になってしまうという問題があります。解決策としてはpayloadに別途URLを持たせておき（http://example.com/?open=a / http://example.com/?open=b など）、そのURLにアプリからアクセスさせることで開封の確認を行うという方法があります。またはそのpayloadに持たせたデータをデータストアに保存するという方法もあります。いずれにしてもmBaaS側で用意している開封レポート機能は利用できません。
APIの消費数を押さえるならば検索条件で指定するのが簡単です。よりランダム性を求めるならば個別配信やフラグを持たせるのが良いでしょう。集計も自分たちで行うならば個別配信を使う方法もあります。
A/Bテストを行うことで、自分たちの仮定が崩され、よりユーザ目線でのサービス提供ができるようになることもあります。プッシュ通知の開封率は大事なパラメータになりますので、ぜひA/Bテストを繰り返し実践してください。
