電⼦版アプリの分析関連のお仕事について

第６章では、電⼦版アプリの分析のお仕事について、分析環境・ツールと最近の施策・分析⽅法などを通して紹介します。

全章を一括して購入されたい方はこちらの記事をご購入ください。https://note.mu/nikkei_staff/n/n44623c9b9ab4

⽇経電⼦版のアプリチームで分析を担当しているKei/@kei_n_n_iekです。

6.1 はじめに

こんにちは。本稿では電⼦版アプリの分析のお仕事について、分析環境・ツールと最近の施策・分析⽅法、などを通してざっくりお話ししたいと思います。筆者は⽇経電⼦版のアプリチームで分析を担当しています。これを読んで⼀緒に分析したいと思って下さる⽅がいたらいいな、という淡い期待を抱いて書きました。

6.2 環境について

電⼦版アプリの分析環境・使⽤ツールについてご紹介します。

6.2.1 データプラットフォーム

まずデータトラッキング・プールのツールです。

• サードパーティのアクセス解析ツール
• Atlas*1

の2 つを使っています。

電⼦版創刊当初からWeb もアプリもサードパーティのアクセス解析ツールをメインで使っていましたが、

• データ送信の形式が柔軟性に⽋けること
• 従量課⾦

などが理由で⼗分ではなくなってきました。

そこで内製開発したAtlas というデータ収集・トラッキングツールを昨年から徐々に使い始めました。2018 年はAtlas への移⾏期間で、今は多くのサービスで上記2 つのツールを併⽤して計測しています。

少しだけAtlas の計測⽅法をご紹介します。⼀般に計測対象の項⽬はPV、タップ数、滞在時間などがあると思います。Atlas の計測では全てのリクエストに「action」と「category（action の対象物）」を必ず設定し、その組み合わせでユーザの⾏為を表現しています（表6.1）。

たとえばPV は action: page, category: page と表現します。この action・category というフィールドに加えて、それぞれどのページのPV か、どのボタンのタップか、などを別のフィールドに設定して計測しています。

電⼦版のWeb ページはほぼ全てのページでAtlas での計測が完了しているのですが、アプリはまだAtlas 移⾏中で全画⾯のPV はサードバーティーのツールでしか取っていません。施策の分析では、訪問回数やPV を⾒るときはサードバーティーのツールのデータソース、action など単発の⾏動ログを追うときはAtlas のデータソース、というように使い分けています。

6.2.2 可視化ツール

アクセスログ可視化には、Domo, Kibana, Redash といったBI ツールを使っています。⽤途による使い分けは次の表のとおりです（表6.2）。

Kibana はボタンのタップ数や、とあるページを閲覧したUU（ユニークユーザ数）などの単純な指標の可視化に、Domo はPV・UU・エンゲージメントランク別のユーザ割合など普遍的な指標の可視化に、そしてRedash はアクセスログ以外のテーブルとjoin する必要があるときや、サブクエリを書く必要があるときの可視化に使っています。

図6.1 はイメージです。3 つともダッシュボードを作ることができます。

3 つのうち利⽤頻度が⾼いのはKibana です。Kibana の利点は

• 実⾏結果がすぐに返ってくる*2
• 基本的な図表は楽に作れる
• 社内事情によるが、データ送信から反映までほとんど時間がかからない*3

などが挙げられます。データの反映が早いので、アプリ開発者に計測関連の実装タスクのデバックにも使⽤しています。

基本的な図表は楽に作れると書きましたが、Vega というjson のフォーマットを使うと少し複雑な図などを作れるようになります。ただ、Vega はvisualize やdiscover と⽐べると書くのが⼤変なのでまだあまり使っていません。*4

Kibana はアクセスログの可視化の他にも沢⼭の⽤途で使っています。記事のメタデータ専⽤のElasticsearch（ES）や、API やサーバ側のシステムログ専⽤のES が⽴っていてそれぞれのチームがKibana を使っています。

6.3 施策の計測から分析までのフロー

電⼦版アプリはiOS もAndroid も⼤体2 週間に1 回のペースでリリースしています。計測が必要な新機能実装のフローは次のとおりです（図6.2）。

計測・分析が必要なIssue があるときはまず機能の実装を⾏い、並⾏して計測項⽬・KPIなど分析⽅針の精査を⾏います。機能の実装があらかた終わった頃、PM/開発者/分析担当者（私）で分析⽅法と計測項⽬の⽅針を共有し、修正があればこの時点で修正します。

このとき、「ここのタップ数も測った⽅がよいね」とか「リリースのスケジュールを鑑みて、今回は計測はここまでにして、細かいところは次回のリリースで⼊れよう」、というようなやりとりが⾏われます。

そして、計測実装が終わったタイミングで、分析担当者とパートナー企業のテストエンジニアさんがそれぞれ計測項⽬が意図どおりに計測できているかを確認します*5。計測の確認完了後から、Kibana やRedash でKPI 指標・ネガティブチェックのための指標*6、のダッシュボード作成します。

6.4 分析内容

6.4.1 2018 年の施策分析

細かい施策を書くことはできませんが、主に

• UI 改善
• プッシュ通知の送信時間、内容変更
• GooglePlay 課⾦
• その他さまざまなAB テスト

などの施策の分析を⾏なっています。

6.4.2 分析の深さについて

施策ごとに状況は異なりますが、基本的には次のステップで分析を⾏います。

1. KPI の評価
2. ネガティブチェック
3. セグメント別の分析

KPI の評価は、とあるボタンのタップ数、とあるページのPV、訪問回数、滞在時間などを⾒ています。ネガティブチェックは、プッシュ通知の施策では通知の許諾率が急激に下がっていないか、登録導線まわりの数値が著しく低下していないか、などを確認しています。1・2 まではほぼ全ての施策で確認します。

3 のセグメント別の分析は施策によってどこまで確認するか、PM と相談して決めます。基本は次の項⽬をチェックすることが多いです。

• 世代別
• ユーザの会員ランク別（有料会員, 無料会員, その他）
• ユーザのエンゲージメントランク別（Dormant, Light, Middle, Loyal, Super loyal）*7

直前まで休眠ユーザだった⼈をどれだけActive にすることができたか、エンゲージメントランクが上がったユーザ数・上がり幅がどれだけだったなども施策によっては重要指標として確認しています。

雰囲気をお伝えするため、この節の最後に、ユーザの会員ランク別にページごとのUUを⾒ているクエリをひとつご紹介します（リスト6.1）。iOS の電⼦版アプリでストックコンテンツのタブ、”コラムタブ”をAB テストで表⽰したときの分析に使ったクエリです。

コラムタブの各画⾯を訪問したユーザ数をエンゲージメントランク別に集計しています。

少しコード内容を解説します。ig_ctx_custom_object_abtesting_featured_uids = ’true’と書いた箇所は、実際にはjson_extract_path_text(ig_ctx_custom_object, ’ab_testing’, ’enabled_featured_uids_20180427’) = ’true’ だったのですが、下の該当箇所全てに書くと冗⻑なので少し短く書きました。電⼦版アプリの画⾯設計は階層構造が割としっかりしているので、ページをWeb のURL と同じ形式で表現して計測しています。er_ref_pathnameは直前にいた画⾯、Web でいうリファラに当たります。Where 句では単純に、データソースをiOS のAtlas のトラッキングSDK 経由の情報に絞ったり*8、社員のアクセスを除いたりしています。

6.4.3 施策分析以外の調査

施策分析以外の調査・分析も、必要に応じて⾏います。具体的には、

• とある施策を⾏う前の、ターゲットユーザ数の調査
• サポート対象のOS を決めるため、OS ごとの利⽤ユーザ数を集計
• 障害が起きた時の影響ユーザ数を算出

などがあります。

6.5 AB テストの⽅法

細かな改善を進めるとき、優れているパターンがどちらか検討がつかないとき、AB テストはよく使われる⼿法です。本節ではそのAB テスト設計について学んだ社内勉強会と、アプリのAB テストの⽅法について記します。

6.5.1 データ道場AB テスト編

他章でも記載がありましたが、弊社では昨年頃からデータ道場と題した社員トレーニング講座が開催されています*9。

過去には

• Atlas やSQL に慣れるための講座
• 機械学習で各々の課題を解決する講座

などが⾏われてきました。今年5 ⽉〜8 ⽉に新たに統計的な視点を持ってAB テストを設計・評価する講座が開催されました。

それまでAB テストでは「プッシュ通知の開封率はこちらがX ％⾼かった」「会員登録ボタンのタップ数はこちらがY% ⾼かった」という結果が出た時、統計的に有意だったのかの確認が不⼗分なことがありました。

これを解決するため、統計的な観点から施策の計画段階・実⾏中・以降の分析で何をチェックするべきなのかをきちんと学ぶ場が設けられました。トレーニーはマーケティングプロモーションのメンバーと私でした。マーケティングプロモーションチームはキャンペーン施策や登録導線周りの施策などを企画・運⽤するチームで、登録導線まわりのUI・ポップアップの出し⽅などのAB テストなどを⾏っています。

このデータ道場は3 ヶ⽉くらいに渡って⾏いました。⼤まかなカリキュラムは以下です。1 ⼈1 つ課題とするAB テストの施策を設定し、講義を受けながらその施策の設計と評価を⾏い、最後に全体に報告するという流れです。

1. 財務モデリング（施策にかかるコストをPay できるだけの⽬標値を決めるため）
2. SQL とAltas の扱い⽅のおさらい（SQL やテーブル定義などに慣れていない参加者も多かったので）
3. 1. で決めた⽬標値を使い、R で必要なサンプル数を⾒積もる
4. KPI 指標の優先順位の付け⽅についてディスカッション
5. 成果報告

個⼈的には3 のステップがもっとも勉強になりました。統計的に必要なサンプル数は、⽬標値・第1 種の過誤・第2 種の過誤を決めれば出せること。また、R でのサンプル数の⾒積りや施策実施後のp 値の計算⽅法などを学びました。そしてこれは以降のAB テスト設計に活かせています。

余談ですがこのサンプル数の⾒積もり⽅法はアプリチームの開発者たちに共有しているので、開発者も何をどう計算すればいいか理解してくれています...！

6.5.2 アプリのAB テスト

電⼦版アプリのAB テストのグループ分けはFirebase Remote Config を使って⾏っています。テスト期間中は、対象ユーザのアプリの全てのアクセスログにA/B どちらのグループに振り分けられたユーザかという情報を⼊れてもらっています。

直接施策と関係のあるユーザ全てのアクセスログにグループ分けを含めるのは冗⻑ではないか、ユーザID とグループわけのリストを他のテーブルに持っておいて分析のときにjoin すれば⼗分なのでは？ と思われる⽅もいらっしゃるでしょう。外にリストを持っておくべきか、別のところに紐付けたテーブルを持っておくべきかというのは度々検討しているのですが、

• ユーザのグループ振り分けのデータのデータサイズは⼤きいわけではない
• 振り分けられたタイミングも知りたい*10

ので、全てのログにグループを⼊れてもらった⽅が分析しやすく、このような⽅法を取っています。

6.6 課題感

9 ヶ⽉ほどアプリの分析をさせてもらってきた今持っている課題を簡単に記します。

• ダッシュボード・クエリ作成をフォーマット化・⾃動化できていない*11
• 異常検知のアラートが弱い*12
• 分析後の、より明快な説明（個⼈の論理性・⼒量の問題）
• プッシュ通知の送信時刻・内容などに機械学習活⽤の余地があるが、未着⼿

下期に全部解決したいと思っています。

6.7 おわりに

初めはサードバーティーのツールとAltas のハイブリッド状況に慣れず苦労しましたが、実装が整備され、今はクエリ⽣成などを⾃動化してもっと速く楽に⾏う⽅法を考えています。

ここまでであまり触れてきませんでしたが、電⼦版アプリは毎⽇多くのユーザに使っていただいています。したがって、まとまった量のデータがありますし、社会的にも意義があるお仕事なので分析しがいがあります。

電⼦版アプリの分析に少しでも興味を持っていただけましたら幸いです。

著者：Kei / @kei_n_n_iek
電⼦版アプリ・紙⾯ビューアーアプリのログ分析をやらせてもらっています。昨年は https://r.nikkei.com/ の開発をしていました。

140年の歴史ある会社が、AIやデータを駆使した開発を現場で実践しています。是非疑問や感想を #nikkei_dev_book をつけてツイートしてください！

全章を一括して購入されたい方はこちらの記事をご購入ください。
https://note.mu/nikkei_staff/n/n44623c9b9ab4

この記事を購入すると、この下に第６章だけのダウンロードリンクが表示されます。