ブログ 継続率を正しく計測していますか

継続率を正しく計測していますか

継続率、特に「1日目」の継続率は、キャンペーンパフォーマンスを示す重要な指標として多くのマーケターに採用されています。しかし、その定義や計算方法について議論がほとんどされていないのが現状です。

このKPIは単純で分かりやすいように思えますが、実際はかなり細かな考慮が必要とされます。定義方法もさまざまあるため、場合によっては計測結果が大きく異なる可能性があります。

例えば、アプリ計測ツールをAdjustに切り替えたお客様の中で、1日目の平均継続率が著しく低下したケースがありました。このお客様は、Adjustによる継続率の計算方法に問題があるのではないかと判断しました。

実際にはどちらの計算方法も「適切」だったものの、「日」の定義が異なっていました。

「日」の定義の難しさ

インストールした翌日もアプリを「継続」して使用するユーザーは、例えば、仕事帰りにアプリをインストールし、翌朝もアプリを起動させていると解釈することができます。もしかしたら、このユーザーは通勤途中に同じゲームを2回プレイしたり、2晩続けて同じフードデリバリーアプリを使っているのかもしれません。このように、ユーザーが2日連続でアプリを開いたと考えるのが直感的な感覚です。ここで「日」とは、このユーザーにとっての1日として定義されるもので、当該ユーザーの所在地とタイムゾーンによって特定されます。

ここで問題が発生します。

すべてのユーザーが単一のタイムゾーン内でのみ生活し、仕事や移動をしているのであれば、上記の定義を採用するのは問題ありません。しかし、現実の世界ではそうはいきません。ユーザーは世界中に存在するため、タイムゾーンはプログラマーが対処すべきケースの中でも非常に難しい課題のひとつです

つまり、ユーザー個人の1日が「翌日」になったタイミングを知ることはほぼ不可能なため、1日目に継続していると見なされます。

これは、上記の定義を現在のMMPやモバイル分析ツールで使用していない理由にもなっています。単に複雑すぎて使用できないのです。

しかし、「日」の意味が想定しているようなものではないとしたら、アトリビューションプロバイダーはどのように定義しているのでしょうか?

1日の違い

この問題を解決する最も簡単な方法は、標準時を使用して、普遍的な「標準日」を作成することです。

これは分析ツールで最も一般的に使用されるアプローチで、多くの場合、日時のグローバル定義であるタイムゾーンとしてUTC(協定世界時)を使用します。実装は簡単であり、必要なのはユーザーがアプリを開いた日をサーバーがUTCタイムゾーン時間として把握することだけです。

しかし、この定義は、先ほど述べた想定シナリオとどう違うのでしょうか?

ヨーロッパのユーザーの話に限るなら、UTC時間の日と実際のカレンダーベースの日との差は数時間しかありません。サマータイムと国によって異なりますが、±2時間以上の差が出ることはほとんどありません。

しかし他の地域ではどうでしょうか?

ニューヨークの場合、実際のカレンダーベースの日は、グローバルなUTC時間よりも4〜5時間遅れており、それほど問題にはなりません。ありがたいことに、その時間帯は夜間のため、ユーザーの移動が少ない時間です。

しかし、サンフランシスコだとUTC時間より7時間か8時間遅れています。つまり、現地時間の午後5時前にアプリを開き、その後(同じ時間内であっても)再び開いた場合、そのユーザーは1日目に継続したものとしてカウントされます。想定するような継続率の結果が算出されない場合があるということです。

一方、日本の場合はUTC時間より9時間進んでいるため、UTC時間の「真夜中」が午前9時になります。そのため、朝にアプリを開いてから昼休みにアプリを開いた場合、そのユーザーは継続したものとしてカウントされます。

したがって、この定義にはいくつかの重大な問題があり、この例だと「1日目の継続率」が現実を反映したものではないことが明らかです。タイムゾーン内の継続率に従ってキャンペーンのパフォーマンスを比較することもできますが、この定義で国際的に比較するには大きな欠陥があります。

他にも問題があります。

多くのアプリ計測企業は、クライアントにカスタマイズ機能を提供する目的で、クライアントがUTCとは異なるタイムゾーンを選択して、コホートの「グローバル日」を定義できるようにしています。すなわち、クライアントが1日を設定することで、可能な限り現実的な方法でユーザーベースの「実際の日」を処理することができます。

しかし、Adjustに移行したお客様の例に戻ると、これによって深刻な欠陥のあるKPIを作成してしまうことになります。

例えば、拠点を日本に置き、ユーザーのほとんどが北米に集中している場合を考えてください。ユーザーがグローバル日を「日本標準時」と定義したらどうなりますか?ニューヨークの午前10時、そしてサンフランシスコの午前7時が、日本標準時である「午前0時」と定義されます。

アプリ利用が最も活発な期間を人為的に2日に分けてしまう結果となり、継続率が非常に高くなります。ニューヨークのユーザーが昼休み中(例えば午前11時50分と午後12時30分)にゲームを2ラウンドしたら、「継続している」と見なされます。

このような継続率のカウント方法は間違っているだけでなく、危険であることは明らかです。こうしたアプローチをとると、広告費を投入した対象が非常に価値があるように見えても実際はそうではないユーザーである可能性があります。

時間で定義

Adjustでは、ここ数年、この問題を解決するための代替アプローチを研究してきました。カレンダーの日付を変えて「日」を定義するのではなく、「日」を「24時間」と定義しました。

この方法では、ユーザーがアプリを開いた時点の2つのタイムスタンプを比較して、その差が24時間以上かどうかを判断できます。つまり、タイムゾーンやユーザーの現地時間に関係なく、1日目の継続と見なすには、24時間経過している必要があります。

全てのユーザーが同じ定義に従うことで曖昧なケースがなくなり、比較可能で意味のあるKPIが作成されます。このように仕組みは簡単です。

必要となる調整

他のアプリ計測企業からAdjustに移行するお客様にとって、急にこの方法に合わせて調整するのは難しいかもしれません。前述のお客様の中には、1日目の継続率が50%から約25%に低下したケースもありました。

しかしこれは想定内です。1日目で継続しているユーザーの約半数はカレンダーロジックによるものでしたが、インストール24時間後にユーザーは戻ってきていませんでした。それでも数字が下がるのを好む人はいません。当然のことながら、お客様は懸念していました。

こうした理由から、大きな数字を追うのではなく、アプリのエコシステムの全体的な成功と健全性という共通の目標の下、分析とマーケティングに対するアプローチを一致させることが大切です。Adjustのアドフラウド防止機能を導入することで不正なインストールが検出され、代わりに正当なインストール数が減少します。同様に、Adjustのコホート手法に切り替えると、1日目の継続率が低下する場合があります。統計上では数値は下がりますが、Adjustのコホート計測によって客観的で実用的なデータが得られるのです。しかし、仮に継続率の成果がユーザー獲得マネージャーのボーナスにひびくようであれば、気まずい会話が待っているかもしれません。

最終的には、情報に通じたマーケターこそが最良の決断を下すことができます。タイムゾーンや地域などの要素を考慮に入れた場合と同様、すべてのKPIの背後にあるロジックを理解することが利益につながります。高い数値は喜ばしいことですが、正確な数値はもっと重要です。だからこそ、Adjustは継続率の計算に対してこのようなアプローチをとっています。

Adjust の最新情報をお届けします