顧客データを基にしたHivemallによる成約率予測

1. 顧客データを基にしたHivemallによる成約率予測
2018-04-17
レバレジーズ株式会社 ⼩原陽介

2. ⽬次
1. 会社概要
2. ⾃⼰紹介
3. 背景
4. Hivemallを⽤いた予測モデルの構築
5. まとめ

3. ⽬次
1. 会社概要
2. ⾃⼰紹介
3. 背景
4. Hivemallを⽤いた予測モデルの構築
5. まとめ

4. 1.会社概要
❖ 名称
レバレジーズ株式会社
❖ 設⽴
2005年4⽉6⽇
❖ 事業内容
⾃社メディア事業
⼈材関連事業
システムエンジニアリング事業

5. 1.会社概要 ~事業紹介~

6. 1.会社概要 ~成約までのフロー~
病院
ユーザー
営業
⾯談・提案・⾯接設定 ⾯接
提案・⾯接設定

7. 1.会社概要 ~成約までのフロー~
病院
ユーザー
営業
⾯談・提案・⾯接設定 ⾯接
提案・⾯接設定

8. 1.会社概要 ~成約までのフロー~
病院
ユーザー
営業
⾯談・提案・⾯接設定
提案・⾯接設定
⾯接

9. 1.会社概要 ~成約までのフロー~
病院
ユーザー
営業
⾯談・提案・⾯接設定
提案・⾯接設定
成約
⾯接

10. ⽬次
1. 会社概要
2. ⾃⼰紹介
3. 背景
4. Hivemallを⽤いた予測モデルの構築
5. まとめ

11. ❖ ⼩原陽介
❖ 2015年に⼊社しCRMチームに配属
❖ 配属後はMA(マーケティングオートメーション)の運⽤や
CRMシステムの設計・データ整備を担当
❖ 現在はメディカル事業部におけるデータ活⽤領域全般を担当
➢ 営業がユーザーに求⼈を提案する際のレコメンド設計/登録数予測/
事業部の課題分析/⼈員配置最適化モデル設計etc
2.⾃⼰紹介

12. ⽬次
1. 会社概要
2. ⾃⼰紹介
3. 背景
4. Hivemallを⽤いた予測モデルの構築
5. まとめ

13. 3.背景 ~事業課題~
CRMシステム
❖ 課題1:Web上の⾏動ログを営業が活⽤出来ていない
➢ ユーザーのWeb上の⾏動をリアルタイムで把握できない
❖ 課題2:ユーザーのうちどのユーザーが成約する可能性が⾼いか判断がつかない
➢ 休眠顧客にアプローチする際に適切な優先順位が付けられない

14. 3.背景 ~TreasureData導⼊前の取り組み~
CRMシステム
分析ツール
❖ 導⼊前の状態:各⾏動(Aページ閲覧/Bページ閲覧/メールクリック…etc)が
登録にどの程度寄与するかどうか計算
➢ 問題1:チューニングにコストがかかる(都度データを落として分析する必要がある)
➢ 問題2:ログの量が増えると計算が⾏えなくなる
⇒システム内で⾃動で計算を⾏う事が望ましい

15. ⽬次
1. 会社概要
2. ⾃⼰紹介
3. 背景
4. Hivemallを⽤いた予測モデルの構築
5. まとめ

16. 4.予測モデルの構築 ~今回の取り組み~
❖ ユーザーの属性データ・⾏動ログを基にユーザーが成約する確率を、
ロジスティック回帰を⽤いて予測する。
➢ 属性データ:年代/希望転職時期/希望勤務形態…etc
➢ ⾏動ログ:登録後30⽇間のサイト閲覧ログ・メールクリックログ・広告閲覧ログ
登録 30⽇間の⾏動ログ 成約
年代:20代
希望転職時期:3ヶ⽉以内
…

17. 4.予測モデルの構築 ~今回の取り組み~
登録 30⽇間の⾏動ログ 成約
年代:20代
希望転職時期:3ヶ⽉以内
…
❖ ⾯談が⾏えているユーザーは⾯談情報が取得できているので、
登録ユーザーモデル・⾯談ユーザーモデルに分けて予測する。
特徴量として使⽤するデータは下記のように異なる。
➢ 登録ユーザーモデル:登録時属性データ+⾏動ログ
➢ ⾯談ユーザーモデル:登録時属性データ+⾏動ログ+⾯談時ヒアリングデータ
(希望年収/離職中かどうか…etc)

18. 4.予測モデルの構築 ~①データの前処理~
■⾏ったこと
・属性データと各⾏動ログの紐付け
・各⾏動ログに対して、登録⽇時
から30⽇以内の⾏動回数を集計
・属性情報のうち、
1対多で保持しているデータを整形
・異常値と思われる値を除外
(Ex.転職回数…999回)
コード(⼀部抜粋)
実⾏結果イメージ
id order age_20 click
1 0 1 3
2 1 0 10

19. 4.予測モデルの構築 ~②配列化~
■⾏ったこと
・各特徴量をadd_bias関数、
array関数、concat関数を⽤いて
配列化(ロジスティック回帰を⾏うため
には配列化が必要)
・量的変数に対して、最⼩:0、最⼤:1に
なるようにrescale関数を⽤いて正規化
・テストデータと評価データに分ける際に
偏りを⽣じさせないために、
「CLUSTER BY rand()」 を⽤いて
データをシャッフル
id order age_20 click
1 0 1 3
2 1 0 10
id label features
1 0 [1:1,2#0.03, ]
2 1 [1:0,2#0.10, ]
クリック数の最⼤値:100
最⼩値:0

20. 4.予測モデルの構築 ~③偏回帰係数の算出~
■⾏ったこと
・テストデータとして全データの80%を
抽出
・予測精度を上げるために、
amplify関数を⽤いてテストデータを
反復させた後rand_amplifyで
データをシャッフル
・logress関数を⽤いて
ロジスティック回帰を実⾏し、
各特徴量毎の偏回帰係数を算出
前処理(⼀部抜粋)
コード(⼀部抜粋)
実⾏結果イメージ
features weight
1 -0.1
2 2
… …

21. 4.予測モデルの構築 ~④成約率の算出~
id label features
1 0 [1:1,2#0.03]
2 1 [1:0,2#0.10]
lateral view explode(features)
id label feature value
1 0 1 1
1 0 2 0.03
2 1 1 0
2 1 2 0.10
■⾏ったこと
・評価データとして全データの
20%を抽出
・explode関数により配列を展開
・「偏回帰係数(weight)×
特徴量の重み(value)」を⾜し合わせて
成約スコアを算出
・sigmoid関数を⽤いて成約スコアを
成約率に計算

22. 4.予測モデルの構築 ~④成約率の算出~
features weight
1 -0.1
2 2
id label score
1 0 -0.04
2 1 0.2
sum(weight *value)
id label feature value
1 0 1 1
1 0 2 0.03
2 1 1 0
2 1 2 0.10
(=(-0.1) * 1 + 2 * 0.03)
(=(-0.1) * 0 + 2 * 0.1)
■⾏ったこと
・評価データとして全データの
20%を抽出
・explode関数により配列を展開
・「偏回帰係数(weight)×
特徴量の重み(value)」を⾜し合わせて
成約スコアを算出
・sigmoid関数を⽤いて成約スコアを
成約率に計算

23. 4.予測モデルの構築 ~④成約率の算出~
■⾏ったこと
・評価データとして全データの
20%を抽出
・explode関数により配列を展開
・「偏回帰係数(weight)×
特徴量の重み(value)」を⾜し合わせて
成約スコアを算出
・sigmoid関数を⽤いて成約スコアを
成約率に計算
■参考
・シグモイド関数
⇒今回のモデルでは-∞~+∞の値(スコア)
を0~1(確率)に変換するために
使⽤している
  ))0(
1
1
( 

 
a
e
xf ax
引⽤元:
https://ja.wikipedia.org/wiki/シグモイド関数

24. 4.予測モデルの構築 ~④成約率の算出~
コード(⼀部抜粋)
実⾏結果イメージ
id label score order_probability
1 0 -0.04 40%
2 1 0.2 65%
■⾏ったこと
・評価データとして全データの
20%を抽出
・explode関数により配列を展開
・「偏回帰係数(weight)×
特徴量の重み(value)」を⾜し合わせて
成約スコアを算出
・sigmoid関数を⽤いて成約スコアを
成約率に計算

25. 4.予測モデルの構築 ~⑤モデル評価指標の算出~
■⾏ったこと
・成約スコアが⾼いユーザーから順に
実際に成約したユーザーの数だけ
予測ラベル(=predict)に1を付与
・評価指標はAUC,正解率(Accuracy),
適合率(Precision)を使⽤
・AUCはauc関数を⽤いて算出した。
正解率(Accuracy)適合率(Precision)
は正解ラベルと予測ラベルを基に算出した
id label score
121 1 3.5
35 0 3.3
223 1 3.2
… … …
19 0 -2.5
predict
1
1
1
…
0
AUC Accuracy Precision
○○○ ××% %

26. 4.予測モデルの構築 ~Workflowによる⾃動化~
■⾏ったこと
・配列化~評価指標算出までの
クエリ実⾏をWorkflowを⽤いて
⾃動化した
・モデルの評価指標、偏回帰係数を
確認するために、Workflowを50回
実⾏し各評価指標・偏回帰係数の
平均値を算出した
Workflow(⼀部抜粋)

27. 4.予測モデルの構築 ~評価指標結果~
50回試⾏した際の平均値
種類 AUC 正解率 適合率
登録 0.750 88.2% 3.45倍
面談 0.688 75.6% 4.57倍
❖ 特徴量が多いにも関わらず、⾯談ユーザーモデルの⽅がAUCが低くなった
➢ 原因:データ数が少なく精度が出なかった可能性がある
⇒⾯談ユーザーモデルで使⽤した対象(⾯談出来たユーザーのうち、
使⽤している特徴量が全て⼊⼒されているユーザー数)は
登録ユーザーモデルの 40%以下
※適合率はランダムに
予測を⾏った場合に対する⽐率

28. ⽬次
1. 会社概要
2. ⾃⼰紹介
3. 背景
4. Hivemallを⽤いた予測モデルの構築
5. まとめ

29. 5.まとめ ~収穫・改善点~
❖ 収穫
➢ Hivemallを⽤いて成約率予測を⾃動で⾏う⼀連の流れを実装することが出来た
➢ 登録ユーザーモデルに関してはAUC=0.750とある程度の精度を出すことが出来た
(各特徴量における偏回帰係数も現場の肌感と整合性が取れていた)
❖ 改善点
➢ ⾯談ユーザーモデルに⽤いるデータ数を増やす
■ データ抽出期間を広く取る・⽋損値補完を⾏う(多重代⼊法…etc)
➢ ⾏動ログの特徴量をより細かく設計する
■ スクロール距離/滞在時間/…etc
➢ ユーザー側だけでなく、求⼈側のデータを特徴量に組み込む
■ 紹介可能求⼈数/エリア毎の平均給与…etc
➢ ロジスティック回帰だけでなく、他の⼿法を取り⼊れる
■ ランダムフォレスト/Factorization Machines…etc
➢ 不均衡データ(成約した⼈の割合が少ないデータ)に対する対策を⾏えていない
■ アンダーサンプリング/オーバーサンプリング…etc

30. 5.まとめ ~事業課題(再喝)~
CRMシステム
❖ 課題1:Web上の⾏動ログを営業が活⽤出来ていない
➢ ユーザーのWeb上の⾏動をリアルタイムで把握できない
❖ 課題2:ユーザーのうちどのユーザーが成約する可能性が⾼いか判断がつかない
➢ 休眠顧客にアプローチする際に適切な優先順位が付けられない

31. 5.まとめ ~今後の展望~
CRMシステム
❖ 今後の展望1:Web上の⾏動ログをCRMシステムに返す連携の構築
➢ ユーザーのWeb上の⾏動をリアルタイムで把握出来るようになる
❖ 今後の展望2:Hivemallで算出した成約率をCRMシステムに返す連携の構築
➢ 成約率が⾼いユーザーが分かることで、休眠顧客アプローチの際に
適切な優先順位付けが出来るようになる

32. 5.まとめ ~直⾯している課題~
CRMシステム
❖ 課題:(成約率予測に限らず)データ活⽤の結果を現場に使ってもらう事は
容易ではない(中⾝がよく分からない・今まで成功してきたやり⽅を継続したい)
➢ 現場で影響⼒が強い⼈間を協⼒者にして進めることが⾮常に⼤事
➢ 現場への普及活動を怠ってはならない

33. ご清聴ありがとうございました。

34. 4.予測モデルの構築 ~②配列化~(参考)
■苦労した点
・rescaleの際にエラーが起きる
⇒データ型が間違っている・Nullの
データが⼊っているなどが
原因だったので、それぞれ対処
・rescaleを使⽤する際に最⼤値、
最⼩値が必要になるが、
ベタ書きではなく動的に扱いたい
⇒別のクエリで算出して統計データ
⽤テーブルに⼊れた後必要に
応じて呼び出す
コード(⼀部抜粋)
実⾏結果イメージ
id label features
1 0 [1:1,2#0.03, ]
2 1 [1:0,2#0.10, ]

35. 4.予測モデルの構築~⑤モデル評価指標の算出~(参考)
■使⽤したモデル評価指標
・AUC(Area under the curve)
⇒ROC曲線下の⾯積であり、
分類器の性能の良さを表す指標。
ランダムの分類では0.5となり、
0.7を越えることが⼀つの⽬安となる
・正解率(Accuracy)
⇒予測結果全体と実際の結果が
どの程度⼀致しているかを⽰す指標
・適合率(Precision)
⇒成約すると予測した中で、 実際の
結果も成約であった割合 ROC曲線
引⽤元:
https://oku.edu.mie-u.ac.jp/~okumura/stat/ROC.html