![見出し画像](https://assets.st-note.com/production/uploads/images/32021303/rectangle_large_type_2_ea3ad0f55efb3379d8090a4d19d7fd8f.jpg?width=1200)
【アプリ開発・運営】初期離脱の数字改善、どこまで分解しているか?
ゲームプロデューサーうきょうです。
前回に引き続き、数字改善のお話です。
今回は、「初期離脱」の改善のお話です。
初期離脱ですが、記事内では、
ゲームのインストール〜開始3日ぐらいまでの
離脱部分についてを初期離脱と定義して、
話を展開していきたいと思います。
ゲーム開始までの全体概要
ざっくりと書いていることと、どのゲームにもこの体裁が当てはまるとは思わないですが、だいたいこんな感じの構成になっています。
Phase1のDLとインストールのところから初期離脱の範囲は入るという点にご注目いただきまして、3日以内の継続、離脱改善としては大まかにこのような要素を調整していくことがセオリーとなります。
今回はこの流れに沿って、ちゃんと数字取れるようにしよう!ということや、具体例としてどんな対応をしているのかについて描いてみたいと思います。
Phase1
DL&インストール
離脱ポイントはDLデータがデカすぎるかどうか。
まずは各Storeにおけるデータが一定数以上(ストアにアップデートしたファイルが90MB近辺以上)だとWifiダウンロードが必須になります。
これによってユーザー側がダウンロードする時点での離脱ポイントになることがあります。
■アプリサイズがDL数に与える影響
アプリサイズとDL数の関係性を示すデータとして、Segmentが行った調査を公表していますので参照します。
アプリの機能などには変化を加えず、アプリサイズを3MB、99MB、123MB、150MBと徐々に上げていき、DL数に影響があるのかを調べるテストを実施。すると、アプリサイズを増加させたことで最大66%もCVRが低下するという結果が出たのです。グラフを見ると、サイズとCVRは明確に反比例の関係にあることが分かります。
Phase2:
初期起動
次にアプリデータをダウンロードして起動するも、データのダウンロードが始まってなかなかゲームがプレイできない場合。これも離脱の大きなポイントになります。
今はAppleの場合は、ダウンロードしてすぐにゲームがプレイできる状態にしないとリジェクト対象になりますので、分割ダウンロードはバックグラウンドダウンロードが必須になっていますが、すぐにプレイできない状態のものも離脱が極めて高いことは過去にもいくつか証明されていました。
開発者はどうしても序盤にシナリオやら序章やらを見せてしまいがちになりますが、今のゲームユーザーもストア側も、DLしてすぐにそのサービスの楽しさを体験できることを求めています。
■ゲームのスペックが足りないということも物理的にある
ここ最近はスマートフォンのOSアップデートによって、下位の機種が切り捨てられる、またはOSのアップデートが対象外、というようなことが割と当たり前になってきました。
理由としては、過去のスマホでも十分機能としては満たせるので、家族からのお下がりだったり、格安携帯は過去の端末を標準で提供していたりするものがあるからですね。
実質スマホ自体は長持ちしているのに、上位機種や新機種を販売するためにソフトウェアでアップデートして足切りをかけているという事例ではないかと思いますが、これを理由に、過去の端末が急にプレイできなくなるということも良くある話です。(もしくはアプリ自体もどんどんバージョンアップして、最新OSに対応せざるを得なくなるケースもある)
ただこの後者の場合はある程度どうしようもないです。
Phase3:
チュートリアル
個人的にはここが一番難易度が高い要素だと思っています。
それは、一番クリエイティビティと演出が必要な要素であり、かつサービスのエッセンスを凝縮して体験してもらう必要があるらです。
そしてその体験をしてもらう方法、見せ方なども非常に繊細かつ緻密に組み上げていく必要があります。
実はここのPhaseからは継続プレイまでの導線までノンストップのチェーンで繋がっています。
その後の流れ
ここから先は、大きく下記の流れを体験していただくことになりますが、比較的1日目、初回プレイの平均時間はせいぜい10分〜15分です。
できればphase2のチュートリアルからフリー行動に当たるまでの10〜15分の間に、小休止(一度フリーに行動できるようになるシーン。一旦休憩しようと言える場面)状態を意図的に作り出すことも大事です。
仮にシンプルなぽちぽちだったとしても人は強制されることを5分以上やらされるとストレスが溜まって離脱したくなるからですね。
ちなみに私が過去実施したテストでは、180秒以上を超える操作や演出を強制させると、「長い」という意見と共に満足度が急に下がりました。
説明しすぎない
あわせてありがちなのが、とにかく全部のシステムを紹介しようとチュートリアルやらダイアログやらがたくさん出てくるケース。正直これも中を見ていないしユーザーは把握ができないのでほぼ無意味です。
それよりも都度必要になる際に都度学習が自然にできる体験を設けて上げる方が自然ですし、スムーズです。
チュートリアルは定期的に作り替える
これは私の事例でしたが、チュートリアルはゲーム制作においても一番最後に作ります。それはテストを繰り返している内にどこでドロップしているのか、どこが一番面白いと感じているのかをデータで取って、切り捨てたり演出を変えたり、開放する順番を後回しにしたりしていたからです。
しかしそれはゲームが比較的複雑な要素が多い場合ですので、全てが当てはまるとは思いませんが、phase2~phase3の部分はクリア率、その後の仕掛かり率などをデータ聴取して、ドロップしているポイントを改善、改修を常に繰り返していく必要があります。
まずはデータが取れるようにして、1つ1つ改善していきましょう。
PS
当たり前ですが改修と検証は1つ1つやることです。いっぺんにいろんなところを改修して、良くなりました、悪くなりましたは検証のやり方を間違えています。
いただいたサポート費は還元できるように使わせていただきます! 引き続き読んでいただけるような記事を書いていきたいと思います。