読者です 読者をやめる 読者になる 読者になる

機械学習

いよいよ、二冊目も最終章です。

 

■問題

仲間とみんなで協力して強いボスを倒すイベントを作りたい

重要なのはチーム編成をどうするか

よりチーム戦の楽しさを引き出すようなチーム編成がないか

 

■チーム戦の楽しさの定義

仲間とリアルタイムで一緒に戦っている感覚

→チーム内で同じ時間に利用している人数

データ分析を活用して「同じ時間に利用する人をチームにまとめる」

ことは可能か?

 

■分析のストーリーの整理

過去のサービス利用状況から、ユーザ毎に明日ゲームを利用する

時間帯の予測を行う。

分析結果をもとに、同じ時間帯にアクセスするであろうユーザを

まとめてチームを作る

 

■予測モデルの構築

予測モデルを構築するための、ツールは色々あり

それぞれに強みと弱みがあるが、うまくモデル構築が行える条件として

・データにある程度の規則性があること

・データにある程度のまとまりがあること

が必要で、予測モデルがうまく構築できることが多い。

 

■利用するツールの選定

データ分析の経験を積み重ねると、基礎的なデータの検証を行なった際に

ある程度このデータにはどのツールが最適なツールとなりそうかは

予想がつくが、時間がある場合は多くのツールで検証し

一番精度が高くなったものを利用するという姿勢が必要

 

■利用する学習器の選定

ロジステッィク回帰、k近傍法、単純ベイズ分類器、SVM、ランダムフォレスト

という代表的な5種類の学習器を用いて、

一番効果の高い学習器を考えていく。

あるユーザ群データでそれぞれ予測モデルを作成し、

別データ群のデータを適用し、精度を検証する

 

予測モデルからあるユーザが入るチームを探したときに

そのユーザが来るであろう時間帯となるべく同じ時間帯に多く人がいる

チームを推薦するという機能をつけることになったようす。

 

決定木分析

■テーマ

どんな行動をしたユーザが継続するか

 

ゲーム自体に特に問題はない状態ではあるが

新規ユーザの離脱が多いということでより

離脱を少なくするためにどうすればいいかを考えていく。

 

■離脱する理由よりも、継続する理由を考える

ライトユーザはコアユーザよりもゲームへの関心が低く、

継続率の低さは発生してしまいがち

継続してくれるユーザから継続する理由を見いだすことを考える

 

■楽しさを要素に分解する

楽しさは抽象的なものなので、このまま議論できない。

ゲーム内の行動を楽しさに分解する

例えば、

 ・戦い 他のユーザに戦いを仕掛ける

 ・協力 他のユーザと協力してボスを倒す

 ・メッセージ 他のユーザにメッセージを送る

 

■ソーシャルアクションを定量化する

離脱ユーザは1週間以内にやめることから

1週間以内の行動で継続が決まると予測できる

アクションを何らかの数値で出すことを考える。

アクションを何回行なったか、何日後に行なったかの2つが

考えられる。

 

■定着を数値がする方法を考える

ログイン密度を使う。

密度=ログインした日/集計期間

 

■決定木分析で一番影響の大きな分解軸を見つける

複数の項目間で影響を見るときは通常丹念に1つひとつ

クロス集計をしていくのが王道

・戦いは仕掛けずに10回以上協力したユーザは定着が良い

・三日目以降にメッセージを3回以上送り、かつ協力を7日目に10回以上したユーザは定着が良い

組み合わせの量を考えると人間が網羅できる量ではない。

このような場合に便利な分析手法として決定木分析という手法があります。

一番大きな影響のある分解軸を見つけることができる

 

■まとめ

何が問題なのかわからない場合に、要因を見つけるために

最適な手法。

やはり、問題点はない(わからない)状態でより良くしていくためにどうしていくか

というのは難しい話なんだなと感じた。

 

 

クラスタリング分析

この章は、いきなり主成分分析などの知らない分析が出てきて

話が飛躍しすぎている。初見でわかる人いないと思う。

 

ゲームをプレイしている人たちはどんな人たちかを理解する

方法として、20代男性が多いなどと分けることがありますが

ゲームをプレイしているユーザを理解するには不十分。

 

次の施策に繋げやすい、ゲームの内容にそった分類をしたい。

ゲーム上の行動パターンでセグメント分けできるとわかりやすい。

 

行動データを用いて似ているユーザをグルーピングする方法として

クラスタリングと呼ばれる手法が適切。

クラスタリングの1つであるk-means法を使う。

グルーピングの手順は以下の通り。

 

1. k個のクラスタの中心の初期値を決める

2. 各データと1.でのk個のクラスタ中心との距離を求め、もっとも近いクラスタに分類

3. 形成されたクラスタの中心を求める

4. クラスタの中心が変化しない時点までステップ2. 3. を繰り返す

 

行動ログは様々な行動について、記録されているため

ほとんどが0のログだったり強い相関をもつログがあります。

例えば、バトル回数が多いほどボス討伐回数が多いなどです。

このようなデータがある場合、k-means法がうまく動かない可能性が

ある。なので、これらをデータから排除します。

(読んでる限りこれはよしなにやるらしい

 

弱い相関を持った、データはまだいくつか残っている場合がある。

このままでも動くが、説明変数は直交であることが望ましい。

(ちょっと、何言ってるかわからない

 

これを解決するために、主成分分析を行う。

主成分分析は、相関のない主成分と呼ばれる値に変換すること。

 

ここまでで、データが準備できたのでクラスタリングを実行

したいところだか、クラスタの数をどうするかという問題がある。

クラスタの数は分析者に委ねられている。

どんなユーザがいるのかを知るのが目的なので、

あまり多すぎると理解しにくい。今回だと5個ぐらいが良さそう。

 

クラスタリングした結果をRを使えばレーダーチャートで表示できるらしい。

今回だと、協力したい(友達の応援などをよく行なっている)ユーザが

ARPU, ログイン日数が他クラスタより高く、協力を促す施策を行うことに

なりましたとさ。

 

■まとめ

今回の前提はゲームのユーザが頭打ちになっていて、

既存ユーザを大事にしていきたいというところから

どういうユーザがいるのだろうという話に繋がっていきます。

今まで、色々な分析手法がありましたがそれぞれに使うべき

場所があり課題から手法を決定することが大事であると感じました。

 

また、今回は実際に施策をしたときに振り返りができるように

この分析を自動化し、レポートできるようにしています。

こういうことも考えられるようにならないとなぁと思いました。

 

 

ロジスティック回帰

この章は理解がなかなか難しかった。

 

問題としては、ガラケーからスマホへの移り変わりが

激しい時の話でDAUが携帯電話ユーザの減少に対して

スマホユーザの上昇が少ない。

つまりトータルでDAUが減少しているということ。

 

ガラケーユーザ減少の原因の仮説は、

・自然離脱

スマートフォンで新規アカウントで初めた(少ないことがわかっている)

スマートフォンに引き継ぎをした

スマートフォンへのID移行がうまくいかなかった

以上があげられる。

 

もし、ID移行がうまくいっていないのであれば、

早急にシステムを改修する必要がある。

 

■正解つきデータがない時のデータ収集

ID移行がうまくいっていない仮説を検証するためには、

自然離脱かID移行に失敗したのかを何らかの

データで区別する必要がある。

離脱前のアクセス状況を見る方法がある。

自然に離脱するユーザはだんだんアクセス頻度が低くなってから

離脱するのに対し、ID移行に失敗したユーザはある日

突然アクセスがなくなる。

 

ID移行を完了したユーザのデータは特定できるが、

自然離脱、移行失敗の離脱はログからは判断できない。

データ上は区別できず、正解つきデータがないということ。

 

ビジネスにおいて、毎回正解がある綺麗な データとは

限らない。正解データがない中で、何らかのビジネス上意味のある

成果を出さなければならないことは珍しくないらしい。

 

どう考えればいいか。

ID移行に失敗しているユーザが多い場合を考える。

この場合、離脱ユーザと移行ユーザの離脱前月のアクセス数に

差異がなくなる。

この場合アクセス数を元に判別するモデルを作ることはできない。

逆に言えば、少なければアクセス数に差異が出るので

モデルを作ることができる。

モデルが作れれば、ID移行失敗ユーザは少ないと言えそう。

 

今回はロジスティック回帰分析を用いて判別モデルを構築する。

ロジスティック回帰分析は、目的変数が買う・買わないのような2値

の時に使う回帰モデルでシンプルでざっくりと傾向を掴むのに

最適な手法。

 

横軸をアクセス数、縦軸に0、1を取り、ID移行を1, 離脱を0

としてデータをプロットしていく。

0,1のデータに対しては、アクセス数に対しての1の割合をあつかうのが

良い。

これを行うとアクセスが増えるとID移行の割合が増えることがわかる。

 

このような割合のデータに対して、ロジスティック曲線呼ばれる

曲線を当てはめるのがロジスティック回帰分析。

ID移行の割合が0.5となるアクセス数を閾値として

それより大きいならID移行小さいなら離脱と判断することができる

 

 

 

 

重回帰分析

今までの分析手法は、関係性を明確化していた。

例えば、値引き額と販売量は関係があるといったぐあい。

この分析手法では、実際にどれだけ値引きをするとどれだけ販売量の

増加を見込めるのかというのはわからない。

 

こんなときに、役立つのが回帰分析(重回帰分析)。

横軸と縦軸にデータを散布した図において、

それぞれのデータを図にプロットする。

このプロットに一番当てはまりがよくなるような直線を引いて

縦軸の値から横軸の値を予測していくのが(線形)回帰分析。

 

導き出された直線から以下の数式を得られる

インストール数=広告費x + y

回帰分析は、xとyを推定する分析になる。

 

例えば、広告をテレビにかけるのか、雑誌広告にかけるのか

というものに対して最適な広告量を決めるのにも使える。

テレビの広告によるインストール数を回帰分析したときに

インストール数=1.35 x TV広告費 + 188

、同様に雑誌広告について

インストール数=7.25 x 雑誌広告費 + 188

と導けた。

 

このことから

 

インストール数=1.35 x TV広告費 + 7.25 x 雑誌広告費 + 188

と言えます。なので雑誌広告に広告費を振った方がいいことは

明らかである。

 

■まとめ

重回帰分析も割と手軽そうな感じではあった。

ただ、どれに使えばいいのかなという迷いはある感じ。

様々な分析手法を理解して課題に対して最適な分析手法を取り入れる

ことが重要なのではないかと思った。

 

A/Bテスト

複数の選択肢のうち、どちらがよりより結果をもたらすかを

見極めるための検証方法の一つ

 

例えば、あるアプリ内で、ゲームのアイテムのセールを行なっているとして

その販売ページへの誘引をするためにバナーが作られる。

ユーザはこのバナーを見て、興味を持つのでバナーの内容は

重要になる。

この時、バナーのクリック率や、遷移後のコンバージョン率が

バナーの質を測る要素になるが

今回はクリック率をよりよくするためにどんなばなーいいかを

検証する方法として取りあげている。

 

2つのバナーでどちらが良いかを検証するときに

順番に同じ期間バナーを出す方法(前後比較)

があるが、この方法は時期や特定期間で行われているゲーム内の

イベント等の外部要因を受けやすい。

 

しかし、A/Bテストは、同時期にランダムに表示させる手法を取るため

こういった外部要因を受けにくくこの検証に向いている。

 

A/Bテストの対象の分けかたはランダムでなければならない。

わかりやすいのはユーザIDの下一桁が偶数か奇数かという分けかた。

 

検証したときに、クリック率に差が出たとして

その差が偶然のものでないかを調べる方法に

仮設検定というものがある(最初の本でやったやつ)

 

人数(サンプルサイズ)が多い場合、ほとんどの

結果が有意に差があると言える。

 

ただ、有意に差があるか良いのではなくて、

有意に差があるので、この差がビジネス的に意味があるかを検討する

という使い方のよう。

 

2つのバナーと「クリックした、していない」の仮設検定には

カイ2乗検定を使う。

 

■まとめ

A/Bテストは導入がしやすく、検証もしやすく手軽さで言えば一番良さそう。

仕事でも使えるかもしれない。

クロス集計

今日は第4章を読みました。

先週と違い、土日の2日に分けて書けました。

これが平日にできるようになるとより優秀なんですが。

 

■クロス集計

4章はクロス集計の話で、その使い方を実例をもとに示していました。

クロス集計は手段の一つで先日書いたフレームワーク

基本に考えていくことが重要。

なので、まず何が問題でどうあるべきかを考えて仮説を

立てることが重要。

 

今回の例だと、ユーザ数が今まで順調に伸びていたが、

ある月に大きく減少した。

原因を調べて、改善を行いたい。

ここで、現象はユーザ数の現象で

あるべき姿は、先月同様のユーザ数に戻すことになる。

 

分析には、検証型と検索型の2つあり、

先日書いた売上現象はプロモーションを行わなくなったからという

有力で具体的な仮説が想定できたので、その仮説検証の分析を

行った。これが検証型データ分析。

今回のように、現象はわかっているが原因が明確でない場合に

データ分析によって原因を特定していく方法は検索型データ分析と

言われている。

 

仮説を複数個考えてみて、それに関連する部署に実際はどうなのか

を聞いてみることが重要。

ヒアリングをした上で、まだ可能性のある仮説について調べてみる。

今回だと、性別や年代に分けたときにどこかのセグメントで

ユーザの減少が起きているのではないかと仮説を立てた。

 

縦軸に月(先月、今月)横軸に性別の表を作成する。

このように2つの因果関係をかけ合わせて集計する分析手法を

クロス集計という。

 

今回だと、男女ともにユーザ数の減少があり、性別は関連が

低いことが見て取れる。

同様に年代別に分けた場合も全体的に現象している。

 

次は年代と性別をかけ合わせ見てみる。

これをn重クロス集計という。

年代と性別であれば2重クロス集計になる。

 

この場合も全体的な減少があり、それが原因ではないと見て取れる。

 

ここまでくると別の要素が無いか探してみる。

たとえばOS別にクロス集計する。

すると今回の場合、Androidユーザが大きく減少しており、

それをもとにエンジニアに聞いてみると、減少し始めた日に

アプリアップデートを行っておりそこに不具合があったことがわかる。

といういい感じに出来上がったストーリとなっていた。

 

今回の予め立てた仮説をふりかえると

・ユーザ数が減少している(事実

・どこかのセグメントが現象しているのではないか(仮説

・セグメントにあった施策を行う(解決策

であり

・ユーザ数の現象(事実

Androidユーザの減少(事実

・不具合を解消し、これを改善する施策を行い先月同等に戻す(解決策

となったことがわかる。

 

■感想

クロス集計について、Excelのピボットテーブルを使うと

便利にできるようだが、多重クロス集計は面倒らしい。

そのときにR言語を用いるとこのあたりもできるようになるらしい。

SQLからデータを抽出してもクロス集計に変形するのが

面倒なのでこういうのを使えるようになるといいと感じた。

 

話のストーリ的にしょうがないかもしれないが、

突然にセグメントに問題があるのではと言う仮説が入ったり

OS別に急に見てそれが見事にあたるという若干の無理矢理感を感じた。