架空の例を考えます。先週は、条件を満たす訪問者1,000人のうち80人が、料金ページを見てから24時間以内にアカウントを作成しました。今週は1,000人のうち50人です。登録率は8%から5%に下がりました。
分析レポートを見れば、どの層で登録率が下がり、どの段階で次に進む人が減ったかが分かります。別のページだったらどうなったかは分かりません。それを確かめるには、変更を加え、結果を比較できるようにしておきます。
どこから減り始めたかを調べる
まず、計測した登録完了数をサーバー側のアカウント記録と照合します。アカウントは作成され続けているのに計測イベントが届かなくなったのであれば、問題は計測にあります。料金ページの文言を変えても解決しません。
アカウント記録でも減少が確認できたとします。モバイルでは登録フォームに到達する人が減っていますが、到達した人の完了率は以前とほぼ同じです。流入元ごとにも比較します。登録するつもりの薄い人を多く集めるキャンペーンがあれば、似た条件の訪問者に対するページの働きが変わっていなくても、全体の登録率は下がり得ます。
次に、影響を受けた端末でページを確認します。最近のレイアウト変更で、幅の狭い画面では登録ボタンが長い機能一覧表の下に来るようになったとします。そこで、既存のボタンを表の上に移せば、フォームに到達するモバイル訪問者が増えるという仮説を立てられます。ファネルは調べる場所を示し、実機での確認は試す価値のある変更を示しました。
変更を一つに絞ってレビューし、公開する
ボタンを移します。文言、料金、フォームはそのままにします。別の人に差分を確認してもらい、対象の画面サイズで両方のレイアウトを試し、どちらも同じアカウント作成イベントを記録することを確かめます。公開した日時と、変更版を無効にする方法も残します。
AIは、端末や流入元ごとにファネルの各段階を比較するクエリの下書きを作れます。実行する前に、条件を満たす訪問者を一人一回だけ数え、両方の週で同じ24時間の範囲に入るアカウント作成を対応づけているかを確認します。もっともらしいクエリでも、登録完了数をページビュー数で割っていれば、見当違いの問題を調べかねません。AIに小さなコード修正を提案させることもできますが、実機で問題を確認して修正が効くかを判断するのはレビュー担当者です。
Mixpanelのクローズドループ分析の例では、マーケティングチームが営業に渡した見込み客のその後を知り、その情報をランディングページの変更に生かします。この考え方を変更自体にも当てはめます。訪問者がどちらの版を見て、その後にアカウントを作成したかを記録するのです。そうしなければ、調査結果と公開の記録がまた別々の文書に残ります。
ZenovayのGrowth Engineには、進行中の測定と記録済みの結果を閲覧できる、読み取り専用の社内Ops画面があります。測定の記録を置く場所の一例です。この例の料金ページの変更を公開する機能として紹介しているわけではありません。
ボタンを移した効果を確かめる
十分なトラフィックがあれば、対象となるモバイル訪問者を旧版か新版に無作為に割り当て、再訪時も同じ版を表示します。ボタンを一度も押さなかった人を含め、割り当てた全員を数えます。そうしないと、変更によって助けたい人を分母から外してしまいます。
開始前に、試験の期間、変更を残すのに必要な改善幅、悪影響が出たときの早期終了の条件を決めます。最後に割り当てた訪問者の24時間の登録期間が終わってから集計します。
公開後にサイト全体の登録率が上がったとします。モバイルの試験では、旧版で500人中25人、新版で500人中35人がアカウントを作成しました。5%対7%で、差の推定値は2パーセントポイントです。二つの独立した二項比率に対する簡単な近似では、差の95%区間はおよそ−0.9から+4.9パーセントポイントになります。このデータは、小さな悪化とも、実用的な改善とも矛盾しません。サイト全体で登録率が戻っても、この区間が狭くなるわけではありません。
同時に比較できない場合は、期間中に起きた他の変更を記録し、結果を変更前後の観察として説明します。フォームに到達する人が増えても、登録完了がはっきり増えなかったなら、その両方を残します。次にレポートを開く人が、なぜボタンを動かしたのか、その後どうなったのか、なぜ変更を残したのか、あるいは元に戻したのかを追えるようにしてください。
