機械学習を用いた日経電子版Proのユーザ分析　データドリブンチームの知られざる取り組み

機械学習を用いた日経電子版Proのユーザ分析

石原祥太郎氏（以下、石原）：「機械学習を用いた日経電子版Proのユーザ分析」という題目で発表します、日本経済新聞社から来ました石原と申します。よろしくお願いします。

弊社のエンジニアとデザイナーの有志で、昨年の10月にありました『技術書典5』に技術書を出しました。

そこで私が第1章で同じタイトルのものを担当しまして、現在無償公開しております。本日は、それをスライドのかたちでまとめ直して発表させていただきます。なので興味があれば、ぜひ後ほどこちらをご覧いただければと思います。

こちらが本日の話題です。最初に自己紹介を簡単にさせていただいて、そのあとタイトルにも入っている「日経電子版Pro」というものがどんなものなのかご紹介したあとに、具体的なデータの取得や予測であったり、最後はビジネス活用の部分まで、ちょっとお話しできない部分もあるんですけど、流れに沿ってお話しできればなと思います。

自己紹介です。

日本経済新聞社に2017年10月に新卒で入りました。なので、世間的には新卒1年目とか2年目とかいう代になるかなと思います。肩書きとしては、データアナリストとエンジニアと名乗っています。学問としては、大学は工学部で、大学院にも行きました。

課外活動としては、ずっと大学新聞というものをやっていて、編集長もやっていました。これは単なるサークル活動ではなくて、公益財団法人として独立している大学新聞があって、そこできちんとお金稼ぎとかも含めて新聞のことを考えていました。データアナリストやエンジニアとして日経新聞に入ったのはごく自然な流れかなと思っています。

趣味は、Kaggleとか、競技プログラミングとか、あとはブログとかも書いています。このあとお話しになるエムスリーさんが、僕の中では技術ブログをめちゃめちゃ書いているイメージがあって。おそらく、12月に毎日くらいすごく更新をされていたと思うんですけど、僕も負けじとがんばって12月は22本のブログを書きました。

会社ではデータドリブンチームに所属しています。まさにこのイベントと同じく「Data Driven」という名前がついていて、サービスの企画・開発とか営業・マーケティングに、「データを身近に」していろいろやっていこうという中で、中心になってデータ活用を進めていくような組織になっています。

なので、単なるデータ分析をするだけじゃなくて。私はそんなにインフラ側はやっていないですけど、基盤の整備をやっているメンバーもいますし。あとは測定項目の設計みたいなところ……「サービスから、どういうデータをきちんと採ればいいんだっけ？」みたいなところの設計とか。

あと、採ったデータを使って、例えばプログラマじゃない人たちにもデータを身近に思ってもらうにはどうすればいいか、といったことを踏まえた環境整備とかをやっています。具体的には、Slackというコミュニケーションツールを弊社で導入しているんですけど、そこに多くの人に見てほしいデータを流したりといった実装もやっています。

僕は利用言語としてはSQLが多くて、PythonやRも使うんですけど、単なるデータアナリストではなく、Node.jsで実装する業務もあったりしますね。ここはあえて「日本語」って書いたんですけど、「どうやったらデータをもっと身近に思ってもらえるかな？」というところをかなり意識して、社内向けにドキュメントを具体的に書くといったお仕事も積極的にやっています。

データ道場と「日経電子版Pro」

日本経済新聞社は、世間一般にはなかなか古臭い会社というイメージが強いと思っていて、それはそれで事実ではあるんですが、一応弊社でもデータを積極的に活用しようという取り組みが昔から進んでいます。2017年から、データドリブンを加速する教育制度ということで、「データ道場」というものを始めています。

これは私みたいなデータ分析担当者だけじゃなくて、営業とか広告担当者とか。あとは弊社でかなり特徴的なのは、編集の人たちとか。そういう人たちもSQL……とくに弊社ではBIツールのRedashでSQLを書けるようになっているんですけど、そこでSQLを書いてデータを使えるようにしようと。

ただ、SQLの文法を学ぶだけじゃ意味がなくて、「それは具体的に、ビジネス的にどういう価値があるんだっけ？」と考えていこうということで、その流れも踏まえながらSQLの書き方を勉強しています。

とはいえ、普通の業務もあるので、3ヶ月にわたって週に1回、業務時間の中で「このときはデータ道場です」というので確保して、枠を取って集中的にやっています。私の場合は木曜日でしたね。木曜日の14〜17時までがこのデータ道場の枠で、3ヶ月間で1週間に1回、ずっとこれに集中して、10人ぐらいが集まってやっていました。

この取り組みについては、弊社の鈴木が半年くらい前に発表した内容があるので、もし興味があればご覧ください。

そのデータ道場は編集の方も含んでいろいろやっていたのですが、とくにデータを扱う人に注力して、発展版の「機械学習トレーニング」を昨年やりました。これに参加していろいろ分析をしてまとめたのが、今回の内容になっています。

こちらも外部講師を招きまして、機械学習の理論から始め、あとはビジネスにどう応用・活用するかという内容になっています。具体的に言うと、決定木とかランダムフォレストのかじりみたいなところまでをパッケージを使わずに……、まぁ、NumPyは使うんですけどsklearnは使わずに実装したり。

あとは最終的に、sklearnとかそういうパッケージを使いながら機械学習モデルを構築して、自社サービスのデータを分析して、「こういうふうにビジネスに活用できそうですよ」みたいなところをそのプロダクトの担当者に向けてプレゼンするとか、そういった取り組みを同じ枠でやっていました。

「日経電子版Pro」を分析する

それで、今回タイトルにも入れました「日経電子版Pro」というものを我々は分析しました。おそらく「日経電子版」はご存知の方も多いかと思いますが、実は法人向けの日経電子版を「日経電子版Pro」というかたちで売り出しております。

こちらは何かというと、普通の電子版と違って、複数人で記事のコメントとか共有とかをサイト内ですることができます。なので、具体的には企業の新人研修で、人事部長が「弊社のこういう記事があるので、みなさん見ておいてください」というふうにシェアできたり、それに対して新入社員それぞれがコメントをしてみたりとか、そういった機能を備えた日経電子版になっています。

法人向けというのが肝で、法人なので無料トライアル期間みたいなものがあります。その無料トライアルから本契約してくれるかしてくれないかというのは、お金というか、ビジネスに直結する話なので、「ここはきちんと分析すべきだよね」という背景がありまして、その向上を目指して過去のトライアルユーザーさんを分析しました。

もちろん本契約してくださったユーザーさんもいらっしゃいますし、してくれなかったユーザーさんもいらっしゃいます。それぞれの分析ログからどのような特徴があるか見ていけるといいな、ということをやってみました。

具体的には、ユーザーの属性情報、あとは利用傾向を使います。「定性的」ではなく「定量的」と書いてあるのは、もちろんうちの社内の営業さんがヒアリングというかたちで企業の意見を聞いてはいるんですけど、もっと具体的に数字で見られるところは見てみようというのが今回の取り組みです。

より具体的に言うと、機械学習モデルの中で、予測に用いた重要度を測れるような仕組みがあるモデルがあります。それを用いて、説明変数xにユーザーの属性や利用傾向を入れてあげて、目的変数yとして、本契約に至ったか至っていないかという部分を予測します。

「予測のモデルを構築するにあたってどれが効いたんですか」というのを見ることで、本契約に影響しそうな特徴は何かを分析していく取り組みです。ここから、具体的にデータをどう採ってどう処理していったかをお話しします。

内製リアルタイムデータ処理基盤「Atlas」

これは私が弊社に入る前から進めていたプロジェクトで、内製のリアルタイム処理基盤「Atlas」と呼ばれているものが実はあります。これはGoogle AnalyticsとかAdobeのAdobe Analyticsみたいなものなんですけど、それだと設定上うまく採れないものとかもあったりするので、自前で作っちゃいましたよ、というものです。

AWS上にそのようなことをできるような基盤が整ってまして。一番下に書いてあるんですけど、Atlasのソースコードを公開しますということで、弊社初のオープンソース公開みたいなことをGitHubでやったりしています。

こういった基盤があるので、僕らみたいなデータ分析をしたい人にはけっこういい環境になっていて。下にも書いてあるとおり、RStudioだったりとかJupyterとかRedashとか、自分が得意な言語でデータをつっつけるような環境が整っています。

今回は「SQLで取ってきて、Pythonでゴリゴリしましょう」というやり方でやりました。ちょっと複雑な分析をするので、データだけはSQLで取ってきて、PythonのJupyter Notebookでごねごねやったほうが都合がいいかなと思ったのが理由です。

実際、弊社の中でRが得意な人もいるので、RStudio Serverとか使っている人もいますし。あとは、経営陣とかですとSQL自体をあんまり書かない人もいますので、そういう人に向けてはDomoというもっと簡単にGUI操作でいろいろデータを見れるものを使ってみたり。あとは、障害対応とかはKibanaとかのほうがデータ見やすかったりするので、そういうことを使い分けながらいろいろやっています。今回は、こういうふうにSQLでCSVへ落としてきて、Pythonで処理します。

探索的データ分析と前処理

探索的データ分析と前処理の話をします。「探索的データ分析」というワードは、去年・一昨年ぐらいから流行りだしてきている言葉だと個人的には思っていて。データ分析コンペティションのKaggleには「Kernel」という各々が実装を公開できる場所があるんですけど、以前そこのタイトルを分析したときに、2017年ぐらいから如実にこういうワードが出てきているというのがわかったことがあります。

これは何かというと、「取得したデータをきちんと眺めましょうよ」という、ものすごく当たり前のことを言っているんですけど。EDAと呼ばれたりしていて、個人的にはビジネスの世界でデータを扱っていく上では、データ分析コンペティションとかと比べて、すごく大事な過程だなと思っています。

Kaggleとかだと、「この問題を解いてください」と言って与えられた枠組みの中でその精度を競うんですけど、ビジネスではそもそも「これを機械学習とかのデータ活用で解決できるというのを見つけられれば、もうそれで勝ち」みたいなところが正直あって、それを見つけるためにどうがんばるかがすごく大事です。

そのために探索的データ分析にすごく時間をかけるのがいいというか、それをしなきゃいけないのかなというのは、個人的にずっと思っていることで。このプロジェクトの中で3週か4週間ぐらい、ずっとこれをやったりもしていたぐらいです。

データの概要をつかむ

データはあまりお見せできないんですけど、属性情報。ご登録いただいている方もいるかもしれないんですけど、日経電子版などの弊社サービスは日経IDというものでログインするようになっていまして。そこで属性情報として、性別だったりとか生年月日であったりとか、あとは任意回答とかでいろんな項目とかを取得したりしているので、その情報が10個ぐらい。

アクセス情報というのは、日経電子版の中のいろんなページですね。スポーツのPVがいくつぐらいとか、あとは政治のPVがいくつぐらいとか、そういうのをうまくパースして、いろいろアクセス情報という形で落とし込んであげました。

一番右のコンバージョンフラグ（cvn_flg）というのが、成約したかどうかです。「1」が本契約に至ってくれたユーザーさん。「0」がやめてしまったユーザーさんです。

これは実際こういう基礎統計量を眺めたりとか、あとは「不均衡データだな」ということがわかったりとか、「欠損がこういうところにあるよな」みたいなところがわかったりとか、そういうようなことをいろいろ眺めて、2次元に落とし込んで可視化をしてみたりしました。

どう捉えるかは個人によるかなという気はするのですが、黄色が本契約してくれた人なんですけど、ある程度固まっているんじゃないかなと個人的には読みまして、きちんとモデルを作ればいろいろできそうだなと思って取り組み始めたというところです。

ビジネスにおけるデータ分析でありがちなこと

具体的に、ビジネスで「データ分析あるある」だと個人的に思っているやつをいくつか挙げました。

欠損値やカテゴリ変数の処理ですね。欠損値がちょっと多すぎるやつ。「自由記述の項目で、大多数のユーザーさんが回答してくれてはいない」みたいな変数は使わないようにしようという対策を取ったりとか。

あと保存記事数0のユーザーさんが欠損になっていたのは、1件以上の保存記事があるユーザーさんしか集計の際にSQLで上手にJOINできていなかったからなので、これはきちんと0で埋めたというだけです。あとはカテゴリ変数を扱えるようにダミー変数にしてあげたというのもあります。

なかなか機械学習とかをやっている人とかじゃないとちょっとピンと来ないしれないんですけど、Leakageという、データ漏れみたいなものになるんですけど。予測モデルを作るときに、予測の対象に関連しすぎる値を説明変数側に入れてしまったせいで、もうほぼ100パーセントそのモデルが当たっちゃうみたいな。

Kaggleとかの機械学習コンペティションだったら、ぜんぜんそれはそれでいいんですけど、今回やりたいことはそうじゃないので、それは絶対ダメだと思っていって。

今回の場合、最初に試してみたら「98パーセントぐらい当たるモデルができました。やった！」と思ったんですが、先ほどの「アクセス情報」ってところに、いろんな「政治のPV」「スポーツのPV」みたいなのを入れているところに、「本契約手続き」というカテゴリのPVみたいのが入っていて。まぁ、「本契約のPV」が10くらいあったら、本契約しているよな」みたいなものが。

実際、これは思考停止してやっていると気づけないんですけど、気づいた時は「ああ、これはやらかしてしまったな」「こういうところを、ちゃんとデータを眺めていってやらなきゃいけないんだな」と思った次第です。

こういうのは今回削除して、きちんとある程度ほかの、「こういう直結しない値の中でどれがよさそうなんだろう？」みたいなのを分析していったという流れになっています。

予測モデルの構築

予測モデルの構築です。sklearnでいろんな機械学習パッケージがあるので、その中で試しました。

正解率だったりとか、今回は不均衡……あまり不均衡データというほどでもないんですけど、ある程度不均衡データだったので、AUCという指標だったりで評価をしてあげて、いろいろ試しました。これは我々の設定でやったやつなので、必ずしもこれが正しいとか、機械学習モデルの優劣だというわけではないとは思います。

その上で、先ほどのfreeeさんの発表でも取り上げられたGradientBoostingClassifierとか、SVCというSupport Vector Machineを使った分類器だったりとか、KNeighborsClassifierというK近傍法を用いたモデルとかが、比較的精度がよさげだったかなと。

実際にはGradientBoostingClassifierを使いました。

理由としては、Gini係数を用いた特徴量と重要度を出すような手法があって、今回の目的に合致してますよというところと、SVCと比べて二値分類以外に応用しやすい。

今回は、トライアルから本契約するかしないかだけを予測すればよかったんですけど、SVCは二値分類に使いやすいんですけど、それ以上の多値分類になるとあまり応用しづらいかなと思っていて。勾配ブースティングだったら、分類以外にも回帰みたいなところに使いやすいかなと思って、こっちを採用しました。

交差検証のAUCで0.80程度という値が出まして、これをどう捉えるかは人それぞれかなとは思いますが、ある程度ビジネス的にはよさげな数字が出たんじゃないかなと、個人的には思っています。

これは本当に申しわけないことで、その予測モデルの中で何が重要な特徴量だったのかというのを具体的に出せないのが残念なんですけれど……公式には出せないだけなので、懇親会とかでお話しいただければ、ちょこっと話すことができると思います。

結果の解釈とビジネス活用

今回こういうふうに出した重要度をもとに、サービスの企画・開発とか営業・マーケティングといった現場の人たちといろいろお話をしながら、「こういうところはこのモデルではよかったので、こういうところにアプローチをするといいんじゃない？」みたいな、ディスカッションの種というかたちでいろいろ使っています。

基本的にはこの特徴量の重要度というのは、特徴量間に相関があったときとか、けっこう疑わしいものもあったりするとは思っていて、こういうディスカッションの種程度に使っていくのが一番いいんじゃないかなと思っています。今回の場合も、こういうふうにサービスや営業の方々といろいろお話ししながら、議論の材料としてやっていました。

長々とお話しさせていただきましたが、まとめとなります。

今回、機械学習を用いて「日経電子版Pro」というサービスのユーザー分析を実施して、無料トライアルから本契約に至る要因にどんなものがあるかというのを定量的に特定して、データドリブンで話を進めていく上での材料としました。

今回お伝えしたかったのは、日本経済新聞社という会社名を聞くと、もうすごくドメドメで、古臭くて日系大企業で……みたいなことを思うかもしれないんですけど、こういうところで「データ道場」という取り組みだったり、内製のデータ基盤や機械学習を使ったりして、積極的にデータ活用を展開しているんだよってところが伝わったら、すごくうれしいかなと思っております。

以上です。ありがとうございました。

（会場拍手）

ビジネス側でやったこと

司会者：ありがとうございます。5分ほど時間があるので、ご質問等がある方はお願いします。

質問者1：freeeの者です。2つ質問があります。1つ目ですが、この結果を出されて、ビジネス側の方は結局どういうことをされたんでしょうか？

石原：まずはこの特徴量を（見て）「どういうものが出ました」とか、予測が「ある程度こういうふうなものができそうです」というので、使い方としては2つあったと思っていて。予測自体を活かす方法と、特徴量の重要度を活かす方法です。

前者に関して言うと、ある程度予測ができると、トライアルの途中の段階で「このユーザーさんはもう放っておいても大丈夫そうだな」とか「このユーザーさん、このままだと予測モデルが落ちると言ってるから、ちょっとサポートしたほうがいいんじゃない？」とか、そういう使い方が1個できますよねって話はしました。

もう1個の重要度のほうで言うと、例えば「とあるコンテンツを見ている人が、すごく本契約しやすい」みたいな例があれば、そのコンテンツをトライアル時の最初にメールで教えてあげるとか、UI／UX上見やすい位置にそれを配置してあげるとか。そういったサービス開発のアイデア出しとかに活用できるという、この2つが主にやろうとしているところです。

質問者1：ありがとうございます。2つ目が、1日で本契約まで至った人と、1年かかって本契約に至った人とは違うかなと思うんですけど、時間という観点はどういうふうに埋め込みましたか？

石原：ちょっとスライドに書けていないのですけど、PVの横の行みたいなところ、「アクセス情報」のところに「ログイン日数」みたいな情報が入っています。

なので、トライアル期間は具体的にお伝えできないんですけど、たとえばトライアル期間が1日の人はそこに「1」が入っているし、数字が多い人は「30」ぐらいが入ったりとか、もっと大きい数字が入っている人もいるみたいなもので、一応情報量としては含めています。

質問者1：ありがとうございます。

トレンドや季節性をどうするか？

司会者：ほかに質問のある方はお願いします。

質問者2：興味深い話をありがとうございます。先ほどの方と重複するかもしれないんですけれども、今回の問題設定は「トライアルの方が、そのまま続けるかやめるか」という問題だったんですけど。定常状態を仮定しているわけじゃないので、トレンドによって……その季節とか時間で、いろいろ変わると思うんです。

そのときにはそれを考慮しないといけないと思うんですけれども、そこらへんをどうしたかということで。例えば問題設定として、もう「こういう期間のときにこうするべき」みたいな感じで決めたところもあるかもしれないし、もしくは、何か分析の時に「じゃあ、こういう特徴量を出そう」ってことでやられたかもしれないんですけれども。

そこらへんの、例えば問題設定として、どういう時間分解能で、そのYes／Noを出したいかとか、そういうところをどう定義・アプローチとして決めたかというところをもっと具体的に教えていただきたいです。

石原：ありがとうございます。まず1つ、今回「電子版Pro」は法人向けであるという点があって、先ほどのfreeeさんの例とも近いと思うんですけど、3月年度末だったら「そのお金を最後にどう使うか？」みたいなところでトライアルが増えたりといったトレンド要因は存在します。あと、うちがキャンペーンをやっている時期は増えます。こういうところを除外してモデルを作る、という作戦を立てました。

先ほどお話しいただいた中で言うと、前者のほうですかね。完全にそういった他の要因……トレンド要因が入らないような、ある程度短めの期間を取って、トレンド的なものを無視できる仮定を置いて分析をしたというのがお答えになります。

質問者2：よくわかりました。ありがとうございました。

リモデリングについて

質問者3：ありがとうございました。2つありまして。1つ目が、この作ったモデルをどれぐらいの頻度でリモデリングするのか？　まず、そもそもリモデリングするのかというところと、その間隔として何ヶ月に1回かというところをお聞きしたいです。

石原：今回の例で言うと、正直やったきりで（リモデリングは）やっていません。機械学習モデルは、弊社はいろいろなところで使っているんですけど、これに関してはこれでいっぺんやってみて、それをもとにアイデアをディスカッションしています。「おそらくトライアルの傾向はそこまで大きく変わらないし、精度自体をそこまで追い求めているわけではない」みたいなところが理由としてはあって、1回やったきりになっているというのが答えです。

質問者3：ありがとうございます。あともう1つあるんですけど、Leakageをどういうふうにして見つけたかというのをちょっと。

石原：まず、このLeakageを見つける前にモデルを試してみたら、すごく高い率で当てることができたと。その時も、特徴量の重要度をまず見てみました。見てみると、明らかに3本ぐらい長い線があると。それを実際に特徴量……それが何かというのを見て出してみて、よくよく見てみると「あっ、なるほど」という見つけ方ですね。

質問者3：特徴量の重要度から？

石原：そうです。今回の場合は、「本契約手続き」を閲覧しているというのがあればほぼ絶対y=1になっているというモデルになっていて、モデルとして「かなりこいつが重要だ」とされていたので、見つけやすかったというのがありますね。

質問者3：わかりました。ありがとうございます。

司会者：ありがとうございます。もう少し時間があるので。

変数の選び方

質問者4：ありがとうございます。僕からは1点質問させてもらいたいんですけど、先ほど見せていただいた変数の数が、やや多いような印象を受けまして。このモデルだと精度が出ること自体が大事だと思ったのですが、変数を選ぶみたいなことっていうのは、何かされたんでしょうか？

石原：変数選択みたいな？

質問者4：そうです。はい。

石原：そこは、もう意図的に「やらないようにしよう」というのを、チームのみんなで話しました。具体的に言えば、例えば重要度をもとに切ってもう1回トレーニングし直すとか、そういうやり方が、例えばデータ分析コンペティションとかだとよくあったりとか、相関を見て片方を捨てるとか、そういうのはやるんですけど。

今回の場合はバクってやって、「人間がちょっと思いつきもしないようなものが、何かアイデアとして出てくればいいな」みたいなところもあったので、あえて丸々ぶち込んでやろうというのでやっています。

もう1個補足すると、このアクセス情報とか属性情報って、自分でSQL書いて特徴量エンジニアリングみたいなことをして作っている部分があって、そこを作るところでどうしても選択みたいなところが入ってはいるかなと思っている……というのが答えですかね。

質問者4：ありがとうございます。

司会者：はい、すいません。あとお一方だけ。

特徴量の重要度について

質問者5：「feature importance」のところで質問がありまして。理論的なところでは、GiniであったりShapであったり、いろいろあると思うんですけど。どれを選択して見ていくのかなという疑問があって。そこを、実際のビジネス上ではどう扱ったのか聞きたいです。

石原：「機械学習モデルだと、その特徴量の重要度を出すときにいろいろ設定ができるけど？」みたいな話ですか？

質問者5：そうです。

石原：それに関して言えば、今回はもうsklearnの決定木系のモデルでデフォルトのGini係数のやつでいいかなと思ったのが正直なところで。ソースコードとかsklearnのやつは、中を見ていただくと、「Gini係数を使って重要度を出している」と書いてあるんですけど。

いろいろ難しい部分はあって、ひと口に特徴量の重要度と言っても、SVMとかでいろいろやっているやつとかロジスティック回帰でやっているやつとかだと、ぜんぜん出し方が違うので難しいんですけど。そんなに、そこに手間をかけることはしませんでした。

決定木系のモデルでも、Gini係数のGainを使うパターンとか、Splitを数えたりとか、特徴量をランダムにしてどれぐらい性能劣化が出るかみたいなやり方もあると思うんですけど、今回はデフォルト値でいいかなと思ったのが正直なところです。

ビジネス活用という点で言うと、そんなに意識するところではないかなと個人的には思いました、というのがお答えです。

質問者5：ありがとうございます。

司会者：ありがとうございました。ほかにも質問がある方はいらっしゃると思うのですが、また懇親会のときに聞いていただければと思います。石原さん、ありがとうございました。

石原：ありがとうございます。

（会場拍手）