Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
fez_cloud_next_tokyo2024_ブレイクアウトセッションD1-DA-07.pdf
Search
Fez開発
August 08, 2024
Programming
3
560
fez_cloud_next_tokyo2024_ブレイクアウトセッションD1-DA-07.pdf
https://cloudonair.withgoogle.com/events/next-tokyo-24?talk=d1-da-07
Fez開発
August 08, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
ECS Service Connectのこれまでのアップデートと今後のRoadmapを見てみる
tkikuc
2
240
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
17
4.3k
Quine, Polyglot, 良いコード
qnighy
4
630
Nurturing OpenJDK distribution: Eclipse Temurin Success History and plan
ivargrimstad
0
520
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
10
1.2k
macOS でできる リアルタイム動画像処理
biacco42
9
2.3k
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
katty0324
5
4.2k
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
2
340
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.9k
ActiveSupport::Notifications supporting instrumentation of Rails apps with OpenTelemetry
ymtdzzz
1
200
A Journey of Contribution and Collaboration in Open Source
ivargrimstad
0
530
僕がつくった48個のWebサービス達
yusukebe
20
17k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Typedesign – Prime Four
hannesfritz
40
2.4k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Ruby is Unlike a Banana
tanoku
96
11k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
15
2.1k
A Philosophy of Restraint
colly
203
16k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
4 Signs Your Business is Dying
shpigford
180
21k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Transcript
Proprietary データ分析を支える Looker を用いた 生成 AI + BI プロダクト
02 Google Cloud Next Tokyo ’24 Proprietary 小池 悠太 データテクノロジーグループ
GM ビジネス開発 海沼 玲史 プロダクト開発グループ GM PM/プロダクトエンジニア 株式会社フェズ
03 Google Cloud Next Tokyo ’24 Proprietary LLM によるノーコードでの データ加工・抽出と、
独自の分析ロジックを組み合わせた 意思決定のための示唆を提供
04 Proprietary 01 事業内容 02 ユーザー課題 03 開発課題 04 ソリューション紹介
アジェンダ
05 Google Cloud Next Tokyo ’24 Proprietary 01 事業内容
06 Google Cloud Next Tokyo ’24 Proprietary 事業領域 = リテール
メディア Voyageur Group Newsletter「Retail Media - The 3rd (and fastest growing?) Wave of Digital Marketing」より引用 Amazon Meta
07 Google Cloud Next Tokyo ’24 Proprietary リテール メディアの定義 小売企業様の購買データと連携されており、
小売データを活用した 配信設計や 顧客アプローチ・効果の検証・改善が可能な メディアや機能 小売様を横断化していくことで価値が高まる と考えられる TV デジタル プラット フォーム 小売 EC 小売 アプリ LINE メルマガ サイネー ジ 棚 狭義のリテール メディア 広義のリテールメディア 消費者 パネル 小売様が保有するメディア枠 小売様単独になることが多く、 商品配架や販促の延長になりがち
08 Google Cloud Next Tokyo ’24 Proprietary リテール メディアの価値 マーケティング
KGI である「実店舗購買データ」 の計測 / 活用 1. マーケティング効果を認知から購買までフルファネルで計測 - 特に日本国内は EC 化率が 9.3% と実店舗購買が主流 2. ID 単位で様々なデータソースと突合可能 - 広告 ID や個人情報をキーに他のマーケティング データとの突合ができ、 購買を起点に顧客の解像度を上げることが可能に
09 Google Cloud Next Tokyo ’24 Proprietary フェズの事業概要 複数流通の購買データの収集 /横断化
マーケティング活用 A 小売 購買データ B 小売 購買データ C 小売 購買データ 流通横断 購買データ 広告 = Urumo Ads ・デジタル広告の実店舗での購買計測 ・購買データを基にしたターゲティング 分析 = Urumo BI ・消費者購買パネルデータの BI ツール ・生成 AI + Semantic Layer を活用
010 Google Cloud Next Tokyo ’24 Proprietary 本日ご紹介する対象 複数流通の購買データの収集 /横断化
マーケティング活用 A 小売 購買データ B 小売 購買データ C 小売 購買データ 流通横断 購買データ 広告 = Urumo Ads ・デジタル広告の実店舗での購買計測 ・購買データを基にしたターゲティング 分析 = Urumo BI ・消費者購買パネルデータの BI ツール ・生成 AI + Semantic Layer を活用
011 Google Cloud Next Tokyo ’24 Proprietary 02 ユーザー課題
012 Google Cloud Next Tokyo ’24 Proprietary 購買データ活用の課題 購買データを 使いたい人
「分析設計」 ができる人 「分析実行」 ができる人 「結果解釈」 ができる人 ↓ 購買データを使う 購買データを使いたい人が多くいる一方で、 データ活用には「分析設計」から「結果解釈」まで多く の離脱ポイントがあり、結果として購買データを使える人がほとんどいない
013 Google Cloud Next Tokyo ’24 Proprietary 「分析設計」 自身のミッション /業務
購買データの分析手法 ・時系列比較 ・性年代別構成比 ・併売分析 ・新規/リピート分析 ・ターゲットの選定 ・訴求の選定 ・施策の効果検証 ・商談 ❓ 自身の業務と必要な分析手法をマッチングさせることを「分析設計」と定義する 分析のマニュアルがあったとしても、目的や業務に適合する分析を選ぶのは簡単ではない
014 Google Cloud Next Tokyo ’24 Proprietary 「分析実行」 新規・リピート 分析手法
SQL 分析実行方法 生成 AI BI / ダッシュボード ・SQL 書けない 直面する課題 ・SQL は出てくるが使える品質じゃない (定義が異なる / チェックできない) ・BI ごとに定義が異なる (新規の期間など ) ・フィルタやディメンションが分からない 行いたい分析を出力する「分析実行」フェーズでは、技術的 /環境的な問題に直面する 仮に BI ツールがあったとしても、各人が共通の正しい定義で分析を実行するのは難しい
015 Google Cloud Next Tokyo ’24 Proprietary 「結果解釈」 データ分析結果 分析結果の解釈基準
Action ・新規人数が 105% 伸長 ・リピートが 100 伸長 ・新規率が 30% 新規 / リピートの伸長を見る = 目的と手段の混同 新規の伸長が市場平均以下の 場合、認知度に課題がある へぇ〜そうなんだ = Action に移らない スポットの CP を実施 × 多くの場合、分析はそれ自体が目的となり分析結果を解釈する基準が設定されていない 分析が Action に繋がらず結果として多くの分析が使われなくなる
016 Google Cloud Next Tokyo ’24 Proprietary 課題の整理 購買データを 使いたい人
「分析設計」 ができる人 「分析実行」 ができる人 「結果解釈」 ができる人 ↓ 購買データを使う 自分に合った 分析手法のマッチング 正しく共通な定義 でのデータ出力 分析結果と Action の 紐付け
017 Google Cloud Next Tokyo ’24 Proprietary 03 開発課題
018 Google Cloud Next Tokyo ’24 Proprietary 以前の開発体制 ユーザー A
DB/DWH 指標の決定 集計 グラフ化のロジック 指標の決定 集計 グラフ化のロジック 指標の決定 集計 グラフ化のロジック ユーザー B ユーザー C • 複数存在するプロダクトチームや分 析チームそれぞれが独立して分析 ロジックを実装していた • BI プロダクトや分析レポートを作成 する統一的なフローがないので流用 ができない • 実装した分析機能が実際使ってもら えていないケースが存在
019 Google Cloud Next Tokyo ’24 Proprietary 必要な開発体制 • データ定義や分析ロジックを共通化
し、社内で統一的な分析フローを構 築したい • データ分析の PDCA を高速に回し、 本当に必要なもののみに注力して 作り込みたい ◦ => データ分析、プロダクトでそれ ぞれの注力ポイントを明確にする 必要がある ユーザー A DB/DWH ユーザー B ユーザー C 共通 ロジック
020 Google Cloud Next Tokyo ’24 Proprietary データ分析の型 1. 現状把握型
過去から現在にかけての状況を把握し 全体像を理解する 2. 課題特定型 課題・問題点の発見と原因の特定 3. 特徴抽出型 重要な特徴やパターンを抽出し新たな インサイトを得る 4. 施策評価型 実施した施策・取り組みの効果を評価 し改善点を見つける
021 Google Cloud Next Tokyo ’24 Proprietary 1. 現状把握型 全体像を俯瞰し現状の状況を把握するための記述的プロセス
• 定義した KGI や KPI の構造分解、達成・乖離の確認 • 全体像を効率よく把握できればよいため比較的型化しやすい • ダッシュボード化して定常的に参照できる環境があることが望ましい • 売上サマリ、カテゴリ別・ブランド別集計売上実績など
022 Google Cloud Next Tokyo ’24 Proprietary 2. 課題特定型 データから問題点と原因を明らかにするための診断的プロセス
• ディメンション / メジャーの組み合わせによる異常値の発見 • ビジネス ミッションによって特定するべき課題が異なり型化が難しい • 時系列比較、デモ グラフィック集計、セグメンテーション集計など
023 Google Cloud Next Tokyo ’24 Proprietary 3. 特徴抽出型 データの潜在的構造や関係性からパターンや新たなインサイトを
発見するための探索的プロセス • クラスタリングや主成分分析など比較的専門的なスキルが求められるた め仕組み化が難しい • クラスタリング分析、共起ネットワーク分析など
024 Google Cloud Next Tokyo ’24 Proprietary 4. 施策評価型 施策が結果にどのように影響を与えたかを特定するために、因果
関係を明確化し効果測定する実験・統計的プロセス • 因果関係の特定や分析結果の解釈に高いデータリテラシが求められる • プロモーション効果検証、ロイヤリティ プログラムの効果検証など
025 Google Cloud Next Tokyo ’24 Proprietary データ分析は難しい BI が浸透しないのは難易度が高く効果を実感し辛いため
• データの専門家ではない多くのユーザーにデータドリブンで精度の高い意思 決定サイクルを回せる体験を届けたい • 小回りが効く分析で意思決定につながる示唆をすぐ獲得 できれば BI は使 われるはず • →BI に生成 AI を組み合わせるモチベーション
026 Google Cloud Next Tokyo ’24 Proprietary データ分析 + AI?
AI に「POS 分析を行い示唆を出して」で実現可能? • 2024/06 現在、生成 AI 単体で自社のデータに合わせてすぐ使えるレベル の SQL を出力するのは難しい ◦ どんなデータ群を持っていてどのように使うかを AI は知らない • AI が精度高く分析を行うためにはメタ情報のインプットが不可欠
027 Google Cloud Next Tokyo ’24 Proprietary Semantic Layer データとビジネス
ユーザーの中間に位置する、複雑なデータを理 解可能なビジネスの概念に変換・翻訳するレイヤー • データの意味、型などのメタ情報や計算方法を提供 • 「アクティブ ユーザー」などの解釈に揺れがある用語のデータ定義を統一 できる
028 Google Cloud Next Tokyo ’24 Proprietary BI + Semantic
Layer + AI AI に精度高く SQL を出力させるためのメタ情報としての Semantic Layer • AI に事前に Semantic Layer の情報を渡しておけば AI が正しいデータ構造 やカラム定義を認識できる • Semantic Layer の知識を使ってデータ分析できればよい
029 Google Cloud Next Tokyo ’24 Proprietary Looker Semantic Layer(=LookML)を使ったモデリング手段と豊富な
API を提供 • API 経由で LookML の取得やクエリ実行が可能 ◦ 柔軟なパラメータ設定 • 生成 AI は「Looker のパラメータを生成すること」のみを責務にできる • => 自然言語から Looker API 用パラメータを生成し精度の高いクエリ実行が 可能
030 Google Cloud Next Tokyo ’24 Proprietary なぜアプリケーション開発するか 一般的な BI
サービスは必要十分にカスタマイズしにくい • 仕組み上や UI 上の制約がある ◦ 我々が持つデータや分析ロジックに最適な UI で表現したい • 必要な情報だけに絞り、より直感的な体験のみを提供したい
031 Google Cloud Next Tokyo ’24 Proprietary 04 ソリューション紹介
032 Google Cloud Next Tokyo ’24 Proprietary Urumo BI(Action BI)
「教育 / 伴走」と「なめらか UX」をコアコンセプトに、 データ スペシャリストの手助けを得つつ小回りが効く分析によって アクションが決まっていくような体験を目指した、 AI を組み込んだ BI プロダクト
033 Google Cloud Next Tokyo ’24 Proprietary おすすめダッシュボード 自己または他の類似利用ユーザーの 利用傾向から推奨される分析機能を
提案 • 定常的に何を見れば良いのかを パーソナライズ、動的にダッシュ ボードを生成 • 現状把握、課題特定に寄与
034 Google Cloud Next Tokyo ’24 Proprietary AI チャット 自然言語(日本語)で精緻なデータ分析
を実行 • インターフェースに依存しない小回 りの効くデータ分析を実現 • 現状把握や課題特定、施策評価 に寄与 ※画像の置換方法 グレーボックスを選択し、 右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。本テキストは削除してください。
035 Google Cloud Next Tokyo ’24 Proprietary AI 分析 出力したデータのサマリと特徴、考え
られる仮説や解釈の提示、 次に行う分析・アクションを提案 • データ スペシャリストに相談しな がら分析を進める体験 • 課題特定や特徴抽出に寄与
036 Google Cloud Next Tokyo ’24 Proprietary アーキテクチャ Backend Cloud
Run Looker LangChain DataStore BigQuery PineCone Frontend Cloud Storage fez-action-bi project Cloud SQL Next.js TypeScript Claude LangSmith ChatGPT ChatGPT
037 Google Cloud Next Tokyo ’24 Proprietary LangChain LLMモデルを扱うための透過的インターフェースを提供する フレームワーク
• 複数モデル(ChatGPT / Claude / Gemini)をほぼ同一の実装で透過的に 扱うことができ、効率的な開発が可能 • Toolという単位でAIに関連する処理をまとめることができる
038 Google Cloud Next Tokyo ’24 Proprietary LangSmith LangChainを基盤としたユーティリティSaaS •
モデルの評価 / トレーシング / プロンプト管理などAIを含むアプリケーショ ンの運用に必要な一通りの機能を持つ • 一連のAIに関連した処理の精度向上やデバッグ、コスト管理に利用
039 Google Cloud Next Tokyo ’24 Proprietary RAG Retrieval-Augmented Generation
AI が必要な情報を外部データベースから取得し検索を 組み合わせることで AI の精度を向上させる仕組み • AI チャット上で日本語で精度の高い分析を行うため利用 • 商品マスタ等独自のデータを AI が自ら参照して適切な解釈を行う ◦ Vector StoreとしてPineconeを採用
040 Google Cloud Next Tokyo ’24 Proprietary
041 Google Cloud Next Tokyo ’24 Proprietary 開発の成果 • Lookerをバックエンドに配置したことで、LookML実装者と
アプリケーション実装者で責務を分離でき非同期進行が可能に • 会社内で統一的な分析ロジックの開発フローが整備され、ロジックの使 いまわしが可能に • LookMLをAIに解釈させることで精緻なデータ分析が可能に
042 Proprietary & Confidential Google Cloud Next Tokyo ’24 まとめ
• データ分析の各プロセス(分析設計 / 分析実行 / 結果解 釈)に異なる難しさがある • それぞれの難しさにアプローチするためにAIを使ったソ リューションを開発した • AI活用のためにLooker(=Semantic Layer)を採用するこ とで開発効率・精度が大きく向上した
043 Proprietary & Confidential Google Cloud Next Tokyo ’24 目指すのは
「データ分析の民主化」 まとめ
044 Google Cloud Next Tokyo ’24 Proprietary Ask the Speaker
にぜひお越しください セッションに関する質問にスピーカーが直接お答えします! Ask the Speaker G213 G214 G216 G217 2F
Thank you 045 Proprietary