D2Cスマイル

SHARE

スマイルを共有する

Facebook
Twitter
google+
はてなブックマーク
このエントリーをはてなブックマークに追加
デジタルマーケティングの総合オピニオンサイト
HOME > アプリストアページ最適化!
Google PlayのA/Bテスト、使ってますか?
2016/01/12
2016/01/12

アプリストアページ最適化!
Google PlayのA/Bテスト、使ってますか?

あけましておめでとうございます。 D2C Rの貴志です。
今年も宜しくお願い致します。

 

さて、前回はアプリストアの検索流入増加施策、「ASO」について書きました。しかし、せっかく流入数が増加しても、実際のインストールに結び付かなければ意味がありません。

 

今回はストアページを訪問したユーザーのインストール率、即ちCVRを向上させるための施策について書いていきたいと思います。

 

「自然流入を増やしたい…」「プロモーションのCVRを向上させたい…」
アプリマーケティングにおいて常につきまとうこの課題へのアプローチは色々と考えられますが、その中でも今回はGoogle PlayのA/Bテストをご紹介いたします。

 
 

効果改善の救世主!Google PlayのA/Bテスト!

●CVR改善要素はバナーだけじゃない!
アプリストアのランキングや検索、広告等でアプリを知ったユーザーが、アプリインストール前に必ず訪れる場所、それがストアページです。ここで、実際にそのアプリをインストールするか否かの最終決定が行われます。

 

アイコン、スクリーンショット、説明文…
ストアページ上のそれら一つ一つが、ユーザーのDL判断の基準となります。

 

web広告を実施されている場合、配信するバナー1つで効果が大きく改善/悪化することは実感されていることと思います。

 

ストアページの最適化を行うということは、このバナーという要素に加え、広告改善ポイントをもう一つ作れるということに他なりません。もしかすると、アイコンやスクリーンショットという複合的な要素を持つ分、改善ポテンシャルはより大きい可能性もあります。

 

このように重要な役割を果たすストアページを、容易かつ低リスクで検証するための有効な手段こそ、Google PlayのA/Bテストです。

 
 

Google PlayのA/Bテスト。具体的に何ができる?

Google PlayのA/Bテストは、Developer Console上から行います。
(下図赤枠)

 

160112_01

「現行のストアページ」と、要素を変更した「テストページ」を、ランダムにユーザーに表示してそれぞれのコンバージョン数の多さを比較する、というものです。

 

検証において具体的にどのようなことができるのか、以下にまとめました。

 

●変更可能要素

160112_02

テストページでは、上の6つの要素(属性)を変更することが可能です。

 

ただ、一度に多くの要素を変更しすぎると、検証結果の分析が困難になるため、変更する要素は2つ以内に抑えることが推奨されています。

 

一度目にテストを実施する際には、

 

(1) アイコン
(2) 画像関連(宣伝用画像&スクリーンショット)
(3) 説明文(簡単な説明&詳細な説明)

 

といったように要素のカテゴリをまとめた形で検証すると、分析を行いやすいためお勧めです。

 

●同時検証数
一度のテストで、同時に最大3パターンのテストページを検証可能です。

 

また、現行ページとあわせて、それぞれの露出比率は任意で設定することができます。
このとき、現行ページの露出比率は全体の50%以上である必要があります

 

160112_03

日別のインストール数が少ないアプリの場合は、テストページは1パターンにし、その露出比率を50%程度にされることをお勧めします。テストページのパターン数を増やしたり、露出比率を低く設定すると、サンプル数が足りずに有意な検証結果を得られなくなってしまいます。

 

逆に、日別のインストール数が多いアプリの場合は、テストページのパターン数を増やして同時に検証を行ったり、テストページの露出比率を低く設定して、万が一テストページのCVRが悪い場合でも全体効果への影響を軽微に抑えることが可能です。

 

上記の目安としては、「1~2週間で各テストページに300件程度のインストールが発生する」ことを判断基準とされると良いかと思います。

 

●検証結果確認&終了
上記までの設定を終えたら、実際にテストを開始します。
テスト中は、Developer Console上で随時効果の確認を行うことができます。

 

160112_04

有意なサンプル数(=インストール数)が集まると、最も効果の良いバージョンが太字で表示されます。※上図テスト(2)

 

バージョンの最右部の「適用」を押せば、テストは終了し、マーケットの本番環境への設定完了です。

 

結果を分析して、次なる要素のA/Bテストにうつりましょう!

 
 

最後に:テストを行う際に注意したい2つのこと

以上のように、広告効果改善において非常に大きなポテンシャルを持つA/Bテストですが、この効果を最大限活かすため、テスト実施に際しては以下の点に注意することが必要です。

 

「マイナーチェンジ」ではなく「フルモデルチェンジ」を
アイコンに枠を付ける、スクリーンショットの色味を変える、テキストの説明項目の順番を入れ替える…
A/Bテストを行う際、その容易さ故にマイナーチェンジから始めてしまいそうになりますが、こうなると往々にして有意な差は得られず、折角のA/Bテストも立ち消えてしまいがちです。

 

ターゲットと訴求軸のバリエーションを考慮した上で、現在のストアページとは大きくベクトルを変えたものをテストバージョンとして検証することで、各要素の寄与度を浮かび上がらせ、結果として検証のPDCAサイクルを回していきやすくなります。

 

特に、リリースから時間が経っているタイトルであるほど、ストアページに抜本的な変化を加えることで、既存のストアページではリーチしても反応してもらえなかったユーザーを取り込むことも可能となります。

 

ASO対策KWを考慮したテスト説明文作成を
前項の「抜本的な変更」を意識した際に引っかかってしまいがちなのが、テストバージョンのテキストにおけるASO視点の欠落です。

 

現行のストアページでは、ASOを意識した説明文のテキスト作りをされているかと思いますが、テストバージョンにおいて大きくベクトルを変えることに集中し、ASO対策KWが抜け漏れてしまうことがあります。

 

テスト期間中は、現行のストアページのテキストがアプリ内検索に作用するため、テストを後に本番ページを変更して初めて、検索順位の下落が発覚することとなります。

 

これを避けるため、テストバージョンで説明文を変更する場合は、ASO対策KWそのものの変更も視野にいれつつ、テキスト設計を行っていかなければなりません。

 
 

後半は文字ばかりで少々ややこしくなってしまいましたが、Developer Console上でいつでも即時で始められるのがこのA/Bテストの良いところですので、まだ利用されたことがない場合は、まずはぜひ利用してみてください。

 

D2C Rでは、このA/Bテストの仮説構築~検証内容提案~テスト実施~結果分析に至るまで、トータルでサポートさせて頂くことが可能です。

 

ご興味がございましたら、ぜひD2C R(http://www.d2cr.co.jp/)までお問い合わせください!

 

最後までお付き合い頂きましてありがとうございました。

関連記事 RELATED ARTICLES
このライターが書いた記事