Firebase A/Bテストを試す - Firebase A/B Testing

Firebase A/Bテスト

Firebaseが提供しているA/Bテストを利用した記事となります。

この記事では、A/Bテストとは？から、 実際にTIME HACKERアプリで、インタースティシャルの表示頻度を確認する際に、A/Bテストを導入しているので、実際に実装した際の手順・コードをご紹介します。

最初に、A/Bテストの説明や、TIME HACKERでのA/Bテスト設計について論じています。
実装方法だけを確認したいのであれば、こちらから御覧ください。

A/Bテストとは？

A/Bテストとは、アプリやWebページ等で数パターンの機能・表示を用意して、ユーザー毎に出し分けを行う事で、
用意した数パターンの機能・表示の内、どのパターンが優れているのかを見極めるのに利用します。

A/Bテストは単純に機能だけの評価だけではなく、マーケティング上だとより高いCTR, CVRを得られるのか検証したり、比較的メジャーなテストです。

特にアプリではこのテストは非常に有用で、iOSアプリ等は、機能検証しようとしたら、毎回申請を挟まないと行けないなど、多大な時間を要するのですが、
A/Bテストの概念を採用する事で、一度の申請で複数の検証を行うことが出来ます。

A/Bテストはどうやるのか？

いろんなサービスがありますが、どこもやることは簡単です、
Webサーバにパターン毎のjsonファイルを設置し、アプリ側でそのjsonファイルを取得し、イベントログ等を送信する事で検証を行います。

(イメージ図)

今回のお題としているのは、FirebaseでもA/Bテストをサポートしている為(まだβですが 2018/7/16段階)、それを採用した実例の紹介となります。

Firebase A/Bテストは、jsonの設置もそうですが、イベントトラッキングも全てサポートしてくれているので、一つのコンソール上でA/Bテストで必要な一連の操作ができるので非常に便利です。

何のA/Bテストを実施するか？

当たり前ですが、何のA/Bテストを行うのか？はちゃんと設計しないといけません。
TIME HACKERでは、冒頭でも記載しましたが、インタースティシャルの表示頻度の最適解を求める上で、A/Bテストを実施しています。

ここでは、TIME HACKERでのインタースティシャルA/B設計について記載します。

インタースティシャルの頻度を何故測るのか？

インタースティシャルは全画面に表示される広告なので、ユーザの行動を大きく阻害します。
頻度を間違えた場合は、最悪ユーザがアプリから離脱していってしまうでしょう。
TIME HACKERではアクションの計測を開始したタイミングでインタースティシャル広告を表示するように設計しています。
ですが、アクションを計測するのは、1番ユーザーが利用する機能です。
なのに、毎回アクションを計測する際に表示するのでは、あまりにもフラストレーションが溜まるでしょう。

この解決策として、インタースティシャルの表示頻度を調整します。
まず1度表示したら10分間は表示させません。(これはいたずらに広告をタップする事による、アドセンス狩り対策の意味でも行っています。)

しかし、10分だけで本当に良いのか？
答えはNOです。TIME HACKERでは、ユーザがアクションを起こす時に起動するアプリです。
言うなれば、アクションとアクションのつなぎ目に起動してもらうアプリです。
そのアクションが、例えば

• スマホをいじるのであれば、次起動するのは1時間後
• 映画を見るのであれば、次起動するのは2時間後

等、10分だけの制限では、ほぼ毎回記録測定のタイミングで広告が表示されてしまします。

ですので、10分制限は、あくまでアドセンス狩りとして捉え、ユーザーの行動を阻害しない策として、何回計測実行したのか？で表示するようにします。

TIME HACKERでのA/Bテストで見る数値

以下の数値を追います。

アプリの定着率

定着は4-7日で計測します。
TIME HACKERは毎日複数回利用していただく事を想定したアプリです。
生活に密着している指標として、1日で見るのではなくて、4-7日の定着数を見ます。
ここが、インタースティシャルの頻度によって変わるのであれば、見直す必要が出てきます。

広告のクリック数

ユーザーの事を考えないのであれば、そもそもインタースティシャル広告を出さない事が1番であることは明白です。
ですが、アプリの収益で生活するなどを考えるのであれば、収益を得るのはマストでしょう。

なので、広告のクリック数を見る事は、絶対必要です。

AdMobの推定収益

こちらは、広告のクリック数でも似たような指標を取ることができますが、

TIME HACKERでのインタースティシャル表示制限のA/Bテスト設計

TIME HACKERでは、以下の条件でテストを行います。

Firebase A/Bテストを用いたA/Bテストを実施する

A/Bテストの準備をコンソール上で行う。

Firebaseコンソールから、A/B Testingを選択します。

テストの名前や、概要、どの割合のユーザをA/Bテストの範囲に含めるのか？を設定します。

今回は100%のユーザとしていますが、規模の大きなアプリ等では、全てをテスト対象にするのではなく、ごく1部のユーザをA/Bテストのターゲットとしても良いかと思います。

次に、バリアントを設定します。
要はA/Bテストターゲットユーザのうちに、どの割合でどんな値を設定するのか？を指定します。

TIME HACKERでは、インタースティシャル広告の割合を決めたいので、
25%区切りで、値を設定しています。

最後に目標を入力します。
ウォッチしたい数値をここで指定しておくことで、Firebaseが該当する数値を集計してツール上で確認できるようになります。

ここまで設定したら、次へ進みます。

次に進むと、今設定したA/Bテストが下書きの状態で表示されます。

アプリの設定を行う。

次にアプリの設定を行います。

plistを用意する。

アプリを実行して、tokenを確認しておく。
↓の箇所。

debugPrint("a/b test token :\(InstanceID.instanceID().token()!)")

Firebase コンソールの準備を続け、テスト開始する

テスト確認してみましょう。

今確認したTokenを入力して、テスト確認したいバリアントを設定します。

では、テストを開始しましょう。

開始して間もないのでデータは無いですが、以下の画面のようにテスト実施の画面になっているはずです。

アプリ側でA/Bテスト用のコードを埋め込む

以下、実際にTIME HACKERアプリで実際に作ったコードの一部です。

import Firebase

#if DEBUG
fileprivate let Interval = 0
#else
fileprivate let Interval = 60 * 60 * 24
#endif

fileprivate let RemoteConfigKeys  = "interstitialTimesOnTapNum"
fileprivate let RemoteConfigPlist = "RemoteConfig-default"

class InterstitialTestManager: NSObject {
    
    private let remoteConfig = RemoteConfig.remoteConfig()
    
    private static let instance = InterstitialTestManager()
    
    public class var shared: InterstitialTestManager {
        
        return instance
    }
    
    
    /// ABテストのセットアップ
    /// 初回AppDelegateなどで1度呼ぶだけで十分
    func setup() {
        
        remoteConfig.setDefaults(fromPlist: RemoteConfigPlist)

        if let settings = RemoteConfigSettings.init(developerModeEnabled: false) {
            remoteConfig.configSettings = settings
        }
        
        remoteConfig.fetch(withExpirationDuration: TimeInterval(Interval), completionHandler: { (status, error) -> Void in
            if status == RemoteConfigFetchStatus.success {
                self.remoteConfig.activateFetched()
            } else {
                print("fetch error.")
            }
        })
    }

    
    /// インタースティシャルの頻度を取得します
    ///
    /// - Returns:
    func interstitialFrequency() -> Int {
        var frequency = 10
        
        if let number = remoteConfig[RemoteConfigKeys].numberValue {
            frequency = number.intValue
        }
        
        return frequency
    }
    
    
    /// インタースティシャルを表示するかを判定します。
    ///
    /// - Returns:
    func isDisplayInterstitial() -> Bool {
        
        if actionRunningNumForCount() > interstitialFrequency() {
            return true
        }
        
        return false
    }
    
}

使い方は、まずAppDelegateでセットアップを呼び出します。

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    InterstitialTestManager.shared.setup()
}

後はインタースティシャルの発動条件の条件分に以下のコードで判定を埋め込むだけです。

func displayInterstitial() {
    guard InterstitialTestManager.shared.isDisplayInterstitial() else {
        return
    }
    // インタースティシャル表示
}

これで、A/Bテストを埋め込む事が出来ました。

注意点

載せているSampleコードの以下の部分

if let settings = RemoteConfigSettings.init(developerModeEnabled: false) {

ここの、developerModeEnabledを開発時はtrueにすることで、RemoteConfigのキャッシュタイムを好きにいじることができるようになります。
が、リリース時は、falseにして、Debugモードを解除しておいたほうが無難でしょう。

締めくくり

全て自分でつくろうと思うと、かなり難しいというより、面倒な作業が必要となるため、
Firebase A/Bテストを採用する事で、簡単にA/Bテストを実行する事ができ、
またイベントトラッキングはGoogle Analyticsを利用しているので、より詳細な分析も行うことができそうです。

まだリリースして間もないので、Firebase コンソール上でテスト結果を集計出来ていないので、結果については、このタイミングではお話することができません。

ある程度集計できて、新たな気付きがあれば加筆修正を行おうと思います。

最後に

今回の記事で紹介していますが、TIME HACKERで、Firebase A/Bテストを採用しています。
是非お使いください！

written by ゆう＠あんのうん