ロコガイド テックブログ

「地域のくらしを、かしこく、たのしく」する、株式会社ロコガイドの技術部ブログです。主にトクバイ・ロコナビのサービス開発について発信しています。

「地域のくらしを、かしこく、たのしく」する、株式会社ロコガイドの技術部ブログです。
主にトクバイ・ロコナビのサービス開発について発信しています。

ユーザ行動を深く知るためのログ設計

f:id:hatuyuki4:20190905182403p:plain

こんにちは、ロコガイドでiOSエンジニアをしている @hatuyuki4です。最近はもっぱらデュエリストとして活動しています(対戦者募集中)。

さて最近のことですが、トクバイアプリはトップ画面を一新しました!! このアップデートにより「安いが每日届くトクバイ」をキーワードに、各店舗のおトクな情報を様々な切り口で閲覧できるようにしました。

しかしアプリの開発はアプリをリリースして終わりではありません。今後さらに使いやすいアプリに改善をしていくために、ユーザがどのようなコンテンツに関心があるのか、どのようなコンテンツを求めているのか詳しく把握する必要があります。

今回はそのために行ったロギングの試みについて話したいと思います。

旧トップ ファーストビュー 新トップ ファーストビュー
f:id:hatuyuki4:20190905173237p:plain f:id:hatuyuki4:20190905173222p:plain

ユーザの関心を知るためのログ

CTRだけで十分か?

今までのトクバイでは画面の共通ログとして、主にコンテンツのimpログとクリックログを集計し、そこからCTRを計算して、ユーザの行動を把握していました。しかし、ユーザの行動を深く知るためには、それだけで十分なのでしょうか?

クリックへの動機が違う

例えばトクバイのトップ画面では、ユーザがフォローしている店舗に関するおトクな情報を、様々な切り口で紹介しています。その中には、クリックしてより詳細な情報を知ることに価値のあるコンテンツもあれば、トップで表示しているコンテンツだけで十分情報を伝えられるコンテンツもあります。

その場合クリックへの動機が強いコンテンツのほうがCTRが高くなることが予測されますが、それだけでCTRが高いコンテンツのほうが価値があるとは言い切れません。クリックはされなかったとしても、ユーザが関心を示したコンテンツがあるかもしれないからです。

最適化に有効であるとはいえない

極端な例ですが、どの位置に表示されていたとしてもユーザが必ずクリックするコンテンツがあったとしてます。それは画面のどの位置に配置したとしてもCTRとしての数値は変わらないはずですが、それほど重要なコンテンツはファーストビューに表示されていたほうがユーザフレンドリーであるはずです。

しかしこれらの並び順最適化を図るためにはCTRだけでは数値の変動を把握しづらく、ユーザが本当に求めている最適化が施せるかはわかりません。

in Viewログという試み

そのような経緯があったので、トクバイでは新しくトップ画面のin viewログを計測するようにしました。impログはコンテンツが画面に現れた際にログを計測しますが、in viewログは コンテンツが画面に現れてから消えるまでの時間 を計測してログとして送ります。

in ViewViewable Impressionなどはアドネットワーク広告などで使われる用語ですが、それをすこし応用しています。ユーザがコンテンツを表示していた時間≒注目して関心を示したコンテンツとして、クリック以外からユーザの興味のあるコンテンツを探っていきます。

コンテンツが消えた意味を考える

in viewログを計測するといっても、ただ計測するだけでは数値を誤解してしまうかもしれません。例えばin viewログは長い時間コンテンツを表示したほうがコンテンツに興味を示したといえますが、それがクリックしたコンテンツの場合は意味合いが異なります。ユーザがクリックするまでにコンテンツを長く表示していたということは、ユーザがクリックすべきコンテンツかどうか判断に迷っていたり、クリックしたいコンテンツを画面上から探すのに手間取っていて時間がかかっている可能性もあります。

ユーザの行動を正しく把握するにはユーザがどのようにコンテンツを表示したかどうか以上に、どのようにコンテンツを消したのかが重要になります。

そこでトクバイアプリでは、以下のようなコンテンツ非表示パターンを定義して、そのパターンごとにログを計測しました。

- スクロールアウト
- コンテンツクリック
- その他のコンテンツクリック
- 他ページへ遷移(コンテンツクリック以外)
- バックグラウンドモード移行

これにより、ユーザの行動がよりクリアに見えてきて改善ポイントを探しだす手助けをしてくれます。

対象ユーザを限定する

in viewログを計測しようとすると、ざっと画面をスクロールしただけでもログが複数回連続で送られるようになります。アプリ側では連続でログが送られる場合も、バッファリングして連続でログ送信リクエストを送らないようにしていますが、それでもアプリやバックエンドのパフォーマンスに多少なり影響を与えてしまいます。

そこでRemote Configを使用して、対象ユーザを絞ることを行いました。今回のロギングの目的はユーザ行動の把握なので、それを把握するだけのサンプル数があれば問題はありません。ログを取る目的とパフォーマンスを考慮して、適切な範囲でログを取るのがよいかと思います。

トクバイの場合

最後にトクバイで集計した例を軽く紹介します。まずはトップ画面のコンテンツごとのCTRです。

f:id:hatuyuki4:20190905173255j:plain

トクバイのトップ画面のCTRは、よりおトクな商品を掲載している店舗をピックアップするピックアップ店舗が高く、その次にフォローしている店舗のチラシ一覧が見られる チラシが高くなりました。詳しい数値はあげられないのですが、毎日の買い物プランを決定するのに有用なコンテンツがユーザによくクリックされているというのがわかります。

次にin viewログを見てみます。

f:id:hatuyuki4:20190905173258j:plain

in viewログで一番注目されていたコンテンツは スペシャルクーポンという、通常のクーポンよりも値引率の高いクーポンでした。スペシャルクーポンはまだ一部地域でのみスタートしたサービスですが、近隣店舗にスペシャルクーポンが投稿されていた場合、トップのファーストビューに表示されます。

スペシャルクーポンはCTRでいうとピックアップ店舗やチラシよりも低いのですが、in view時間でみると、強い関心を示されているのがわかります。

f:id:hatuyuki4:20190905173215p:plain

クーポンをクリックする動機はおもに店頭でクーポンを使用するときなど、場面が限られれてしまうのでCTRという面ではあまり高い数値にはならなかったと考えられます。しかしin Viewログと組み合わせると、スペシャルクーポン自体はユーザにとって強い関心のあるコンテンツだったといえそうです。

Next Step

今回はトップのコンテンツによってin view時間がどのように変わるのかというのを見ていきましたが、これで終わりではありません。今後はin viewログを応用して、個別商品へ適用していくことを検討しています。例えばユーザが画面に表示した商品をもとにユーザの興味のある商品を推定することができれば、よりそのユーザに最適化されたレコメンドなどができるかもしれません。

単に安い商品を紹介するのではなく、安くてユーザが好きな商品が紹介できるようになったら、より喜んでアプリを使ってもらえそうですね。

まとめ

in viewログを計測することで、CTRだけでは測れなかった、ユーザの関心をより深く知ることができるようになりました。また、それ以外のログを組み合わせることで、より改善すべきポイントが明らかになっていきます。

これからもユーザの興味関心を把握して、ユーザに喜ばれるアプリを作っていきたいですね。