AWS Startup ブログ

【開催報告】ML@Loft #7 ユーザー分析

こんにちは、AWS スタートアップソリューションアーキテクトの針原 (Twitter: @_hariby) です。10月23日の ML@Loft 第7回はユーザー分析をテーマに開催しました。

ML@Loft は機械学習のお悩み相談イベントで、目黒の AWS Loft Tokyo で2019年4月より毎月開催されています。AWS をお使いのお客さまがサービスの中に機械学習を取り入れて開発・運用していく際のお悩みを気軽に相談できる場が欲しい、ということで始まったコミュニティイベントです。登壇者 (相談役) が自己紹介を兼ねた10分ほどの Lightning Talk (LT) を順番に行った後、テーブルに分かれて具体的な相談・ディスカッションを行う、という二部構成で開催されています。過去の様子は登壇者のスライド付きでブログにまとまっています [#1 (MLOps), #2 (MLOps), #3 (Recommendation), #4 (Edge), #5 (NLP), #6 (MLPP とコラボ)]。

毎回参加者の希望をもとにテーマを決めていて、第7回目となる今回のテーマは「ユーザー分析」です。ユーザーの行動データや採寸データなど、ユーザーを理解しそれを自社サービスに生かすための手法や知見について経験者の意見を聞きながらディスカッションを行いました。今回登壇・相談役をお願いしたのは 伊ヶ崎 一起 氏 (dely株式会社)、平山 知宏 氏 (ルームクリップ株式会社)、神山 恭平 氏 (Bodygram Japan株式会社)、石塚 淳 氏 (株式会社Gunosy) です。当日の流れに沿って内容を振り返りたいと思います。

LT セッション

前半の LT セッションでは登壇者の方々からユーザー分析における課題を問題提起して頂きました。これが後半のディスカッションのベースラインとなります。

「クラシルにおけるファネルに対するトラフィックバランス異常検知の取り組みについて」伊ヶ崎 一起 氏 (dely株式会社 データサイエンティスト; @_ikki02)

dely さんにおける機械学習の取り組み、特に Amazon SageMaker を使っている話は AWS Startup ブログでも「【寄稿】dely株式会社における機械学習の取り組み」という記事として公開されています。データ・ドリブンな企業として、レシピ動画アプリ「クラシル」を (最近の数字ではアプリダウンロード数2000万へと) 成長させるなかで、新機能・サービス評価における2つの悩みが出てきました: どのデータが分析に必要なのか分からないことと、既存機能への影響評価が属人的になっていることです。このそれぞれに対し、データの定義を明確にし後から変更が起こらないようにする取り組み、日々の数値をトラッキングし変化に素早く気づく仕組みについて紹介して頂きました。

[クローズドファネル]
クラシルのアプリではユーザーの行動ログを分析し、様々な新しい施策を試しています。仮説提案・デザイン・実装・評価のサイクルを回す中で、新施策の導入によって全体のトラフィックバランスが不安定になる可能性があります。ここで分析を容易にするため、クローズドファネルを導入しています。クローズドファネルというのはユーザーの行動遷移における各ステップへの流入が一つ前の既知のステップのみから成るファネル構造です。クローズドファネルに制限することで予期せぬ途中流入を防ぎ、ファネルの入り口から入ってくるユーザーのみを分析対象とすることができます。

[ランダムカットフォレスト]
さらに、ファネル内の急激なトラフィック変化を発見するために異常検知を行います。Amazon SageMaker のビルトインアルゴリズムである Random Cut Forest (RCF) を用いています。RCF は時系列のデータ点を分類する際、決定木の深さ (異常データはそれ以外のデータより簡単に記述できる = 決定木が浅くなる) により異常データを見分けるアルゴリズムです。RCF でログの変化を検知すると Slack に通知を飛ばして確認できるようにされています。

最後に、良い指標設計のための STEDI というキーワードも紹介して頂きました。詳しくはスライドをご覧下さい。

Event Design and Anomaly Detection | ML@Loft_20191023

「C向けサービスの1セッションのモデル化と適用の方法」平山 知宏 氏 (ルームクリップ株式会社 取締役 CTO)

RoomClip はお部屋のインテリア写真を投稿・共有できるサービスです。今回は Consumer (C) 向けアプリの肝となるターゲティングセグメントと、それに応じたコンテンツレコメンドについて話して頂きました。プラットフォームとしての C 向けサービスが提供できる価値として、メーカー・小売に対するマーケティング支援があります。様々なマーケティングモデルが提案され、タッチポイントごとのアクションが議論されますが、現実はマーケティングモデルよりも計測可能なファネルや情報カスケードが重視されます。ただ、カスケードを支援することはすなわち認知 (= トラフィック)・獲得 (= CVR, CPA) を追うことになり、サービスに対するエンゲージメントの話が疎かになりがちです。結果、広告での収益を求める形に落ち着き、膨大な Conversion (CV) や膨大なトラフィックを持つサービスに勝てなくなります。
それでもマーケティング支援の活路を見出すため、平山さんはユーザーの意思決定にかわり「意図を持ったアクティビティの連鎖」としてユーザー行動をモデル化しました。それぞれのステップでのユーザーの意図を満たすことで、期待する方向へユーザーを導くよう設計ができ、CV につなげるという発想ができます。この一つ一つの「明確な意図を持ったアクティビティ」に注目し、1セッションをモデル化できればボトムアップでより上位の目的・意思決定が理解可能という考えです。個人情報を保護した形で意図のあるアクションを選定し、1セッションの情報をベクトル化した上でクラスタリングを行います。すると、意図が曖昧なセッションと明確なセッションが分類できそうだという結果が得られました。セッションの意図に対する満足度を評価するものとしてユーザーのアクションを紐付けることで、ユーザージャーニーとの定性的な対応づけを行なっていきたい、というようなことを今後深めていくそうです。

「AI B2B2CサービスにおけるCのConfidence Check」神山 恭平 氏 (Bodygram Japan株式会社 Director)

Bodygram は AI 身体採寸技術とそれを提供するプラットフォームを展開しています。正面・側面の2枚の画像をサーバーに送信することで、写真からボディラインを抽出、ML モデルが全身のサイズ推定を行います。導入事例として、Uniqlo, Shoplist, Airweave などの実績があります。この B2B2C サービスは AWS 上で構築されており、Amazon API Gateway / AWS AppSync, Amazon DynamoDB, Amazon S3 で構成される BodyBank サービスがモバイルから SDK で呼び出され、裏では Amazon SQS を挟んで BodyGram AI が GPU インスタンスで稼働しています。Bodygram AI は、深層学習による特徴抽出と機械学習による測定の2つのステップで構成されています。
Bodygram AI をパートナー企業側のサービスに組み込んだ際、AI の推論失敗や推定精度が低いという問題が起こりました。入力画像を調査した結果、真っ暗な部屋、謎の観光写真、壁、決めポーズ、複数人、遠すぎる、近すぎると言った様々な予期せぬ画像が投げられていることが分かりました。これらの画像を全て入力として受け入れてしまうと AI の精度が悪いと評価されてしまうので、手前でこれを弾く処理が必要です。そこで confidence check のために別の AI を使うことで、具体的にはジャイロセンサーで撮影アングルを、加速度センサーでぶれを、ヒストグラムから明るさを、顔検出で人数を、ポーズ検出でポーズを、服装やコートなどの厚着をチェックすることで、意図しない画像を弾くような設計となりました。この事前処理をエッジ (スマホ) 側で行うことで、余分なデータをアップロードするのにかかる待ち時間を削減することも可能になりました。

「GunosyにおけるABテストの全容」石塚 淳 氏 (株式会社Gunosy GunosyTechLab BIチーム エンジニア)

まずはじめになぜ A/B テストが必要かについてまとめて頂きました。答えはユーザーが知っている、すなわち我々サービス開発・提供者は何が優れたアイディアかを予め判断できないところに A/B テストの必要性があります。仮説 → 検証 → 計測のループを回すことにより、再現性のあるノウハウを蓄積することが可能になります。また、グノシー・ニュースパスのようなニュースアプリでは特に時期性や季節の影響を受けますが、これらの変動によらず効果計測を行い、インフラ変更・アプリリリースなどでの意図しない数値の低下を防ぐことができます。
仮説立案には価値仮説シートというものを用いることで、考慮すべき観点を明確にし、メンバー全員が仮説を提案できる仕組みにしています。この価値仮説シートには、ユーザー・欲求・課題・製品の特徴が端的にまとめられています。
新しい施策を行うためのヒントは、事前の分析から得ることができますが、その際に現状把握だけではなく仮説・検証・意思決定を含んだ分析を行うことが重要となります。また、前回の A/B テストの知見を活かせるよう失敗から学ぶこと。重要な数値をモニタリングしてそれが下がった原因を探ったり、大切の大きな数値と相関の大きな数値を見つけることで仮説立案のためのヒントが見つかることもあります。
A/B テストを始める際は、まず1%のユーザーから始めて徐々にロールアウトしていきます。小さく始める理由は、急激な変更により数値が毀損する可能性を緩和するためです。導入のフェーズによってそれぞれ見るべき数値・期間が異なり、

  • 1% (1-3日): 大幅な数値低下やバグがないか
  • 5-10% (7日): クリック率などの KPI
  • 20-50% (14-21日): 継続率
  • 99% (長期間): 長期的な継続率やその他 KPI

といったところを確認しています。これを計画するためには、A/B テストの割合に応じて計測・監視する KPI を設計し、必要・新規実装の必要なログを精査、撤退・拡大の条件を定めます。テストの成否は既存アルゴリズムとの統計的な有意差で判断するため、十分なサンプルサイズを確保する必要があります。詳細については Gunosy データ分析ブログ「より正しい意思決定のための統計的仮説検定とサンプルサイズ計算」をご覧下さい。
テスト対象の割り当ては、テスト ID とユーザー ID のハッシュ値から計算しており、異なる A/B テスト同士の影響が重ならないようにグループを選んでいます。
効果測定は Slack 通知と BI ツールでのダッシュボードで確認しています。

GunosyにおけるABテストの全容

RT ディスカッション

イベント後半はラウンドテーブルでのディスカッションです。4つのテーブルに分かれて、4人の登壇者が相談役としてそれぞれテーブルにつき、お悩み相談会という形でディスカッションを行いました。

  • 例えば具体的にどういう施策を試したことがあるか？
    • クラシルでは Picture in Picture (縮小表示したものを画面の端に出す UI) を試したことがある。しかし、新しすぎて使いづらい、という既存ユーザーにとってネガティブな影響が大きかった。
  • Interleaving (ランキングを混ぜてユーザーに提示し性能評価する手法) はやっている？
  • どうやってデータに強い組織を作るか？
    • Gunosy では会社ができた時から A/B テストありきでやってきた
      • SQL クエリは書けなくても、クエリを読めば意図が分かるように
      • アルゴリズムの意思決定はデータサイエンスチームでやってる
      • プロダクトの意思決定はデータ分析で行なっている
  • SageMaker ビルトイン RCF アルゴリズムの入力はユーザーのログ？
    • カテゴリで分けたユーザー数を使っているが、shingling (sliding window) はやっていない
    • 「お気に入り」するまでをクローズドファネルと呼んでいる
    • Deep Learning だとトレーニングにコストがかかるので RCF でやっている
  • 画像・テキストを含んだマルチモーダルな違反コンテンツ検知が難しい
    • テキストの場合はパターンを洗い出して、キーワードリストで対処できるものと表記揺れを分けた方が上手くいくのでは
  • キュレーションサービスのレコメンドを上手くやりたい
    • レコメンドって各社内部の話は外に出ていない。ドメインに強く依存し、部屋のレコメンド・料理のレコメンド・服のレコメンドなどで全然違う。推薦の文脈が異なるので、なぜこれをレコメンドされたのか理由を提示すること (reasoning) が大事。
      • 新奇性の高いユーザーによくある肉じゃがを薦めても刺さらない。ユーザーをクラスタリングすると、綺麗に分かれる
    • 協調フィルタリングはコールドスタートに弱いので、どうやっていくか。ポアンカレ曲面状のレコメンドの方が収束が速い、とかある。アイテムベースレコメンドの EM アルゴリズムが良いか、とか。
  • クラシルで最初に出てくる動画はレコメンドしてる？
    • よく使ってくれている人にはパーソナライズしている
  • 指標は?
    • CTR を見ている。(相対評価ではなく) 絶対評価
  • RoomClip でのカスタマージャーニーから何が見えてきた？
    • ユーザーが興味のあることとキュレーションで提供できるメディアは直結せず、ギャップがある
    • CV を上げるために、ではなく、課題解決をするためのサービスを実装するのが大事
  • 画像解析ってどうやってます？
    • 基本は fine tuning
    • この画像に対する萌えポイントは何か？みたいのをやりたい
  • 身体採寸ってどうやっているの？
    • アパレルは採寸定義がブランドごとに違う。そこは比較的軽い ML モデルを個別に用意して吸収。コアの身体測定は Deep Learning で共通化してる (けど重い)
  • エッジで推論をするために工夫したことはある？
    • 3D モデルをグリッドに分割して粗々のモデルを使っている
    • OS に組み込みのアルゴリズムを利用すれば速いので、それを利用している
    • Pose estimation だとモデルサイズが100MBくらいになるがメーカ側はアプリをそんなに重たくしたくないというジレンマがある
  • どうやって精度向上させている？
    • 入力データの質を揃えるのが大事。エッジ側で傾いた画像やブレた画像を弾くことで DL モデルへの入力データを選別し精度向上に繋げている
  • A/Bテストって新機能について毎回やる？
    • 毎回やる、大きな機能の改修も
  • 一人のプロダクトオーナーがいくつくらいのA/Bテストを見ている？
    • 10個くらい。エンジニアが分析して、プロダクトオーナーが最終的な判断をする。
  • ユーザー分析・レコメンドに悩んでいる。A/Bテストの評価指標、ロジック自体結構悩ましいが、どうやってる？
    • 一番大事な指標がリテンションレート。それを最大化するために一人当たりのクリック率に注目
    • UI の変更はクリック数には反映されづらい
    • 記事ロジックはクリック数に効く
  • KPI 設計難しくない？
    • リテンションレートが第一。DAU とかも見る。金額も見る
    • 昔はDAUだけだったけど、売上も見るようになってきた
  • 施策の優先順位ってどうやって決めてる？
    • みんなやりたい施策はいろいろあるので、やった施策は backlog にあげて、sprint みたいな感じでやる。
    • テストをいつ走らせるかは、できた順でやる。
    • 今は、重複を許して、ランダムに実施する。

ご登壇・ご参加頂いた皆様、改めてありがとうございました。11月は量子コンピュータ x 機械学習の会が開催され、次は12月19日に Deep Learning フレームワークとプロダクションでの推論についての会を開催予定です。参加登録はこちらから →  https://mlloft9.splashthat.com/

このブログの著者

針原 佳貴 (Yoshitaka Haribara)

AWS のソリューションアーキテクト (スタートアップ・機械学習担当) です。