データドリブンマーケティングの最短ルート
すかいらーくにおけるマーケティングとＩＴの融合
すかいらーく 神谷さん
・すかいらーくについて
・本日の内容
分析から創出された価値
分析を加速させるためのＩＴ
テクノロジーによる外食のさらなる進化
・分析から創出された価値
ＰＯＳデータを分析するために構築したシステム
→クラスメソッド
ＲｅｄＳｈｉｆｔ→たぶろー
ＰＯＳデータから分かること
単純な販売数だけではない
新メニュー開発の方向性立案、及び効果検証に活用
平日・郊外・ロードサイド→どういうメニュー
ＡＢテストみたいに・・
方向性を出して、当たったのかどうか
仮説：人間 検証
そのほかＰＯＳデータで分かること
オペレーションの質
販促の質
将来売り上げ
販促例：サンクスくじのカイゼン事例
ブランドごとに顧客属性が違う
デザート、サイドメニュー中心
→付加価値の高いグリル商品中心
これまでの４倍
つぎ：ガストでフォアグラ
消費者テスト→ネガティブ
食べるとおいしい：説明した上でだから
実験計画法
どの店と比べるか？
統計的に同じ動きの店舗で比較
うまくいった→来月よりフェア
つぎ：継続率
セグメントに差：立地
習慣化：タイムライン
１０％の客数成長
・分析を加速させるためのＩＴ
新しい分析基盤導入の背景
できていたこと
できていなかったこと：時間
→回せる仮説検証の数
仮説検証を数多くまわすことの意義
そのためには ＩＴ大事
人間の時間効率をＩＴで最大限に高める
分析自体の自動化
レポート作業の省力化
・テクノロジーによる外食のさらなる進化
すかいらーくにおけるデジタルマーケティング
ネットのノウハウを外食産業へ：アプリ
スマホアプリのポテンシャル
アプリの機能：特に目新しいものはない
→運用が大事
更なるテクノロジー活用の可能性
------------
トレジャーデータ流データ分析
井上さん
・自己紹介
トレジャーデータブログ
・いきなりですがＱ＆Ａ
→なにもない・・・
・サービス概要
データ解析の世界をシンプルにしたい
分析レイヤーの下位からの積み上げが必須
あつめる、管理する
やりたいデータ分析に専念
データ収集
センサーデータ：テレマティックスデータ
Ａｎｄｒｏｉｄログ
Ｗｅｂログ
過去に蓄積
並列分散、バッチ処理、集計
→アドホック型
クラスメソッド：監視
分析
たぶろーＢＩ
・分析プロセス
データ分析の期待値が高すぎる
仮説→検証をまわす
前段：敷居が高い
目的明確化
目標設定
データ収集
いままで：仮説を立てないとはじめられない
→トレジャーデータ：スモールスタートができる
データを見る
データ収集
データＷａｔｃｈ
目標設定
データ：過去と未来
ログインログ
データＷａｔｃｈ
データの「項目」を見る
バッチ処理・アドホックの使いえけけ
データの「内訳」を見る
でぃめんじょん、メジャー
あるからむをセグメント
メジャー：ＰＶ，ＵＵなど数値型
テンプレートがある
ディメンジョン
データの「分布」を見る
数値でグルーピング
タブロー
項目、内訳、分布、全部やる
さくさく分析＝ＧＲＯＵＰ ＢＹで
ＰＯＣ
続きは公式ブログ
質問：Ｈａｄｏｏｐの違い
Ｈａｄｏｏｐ：ＨＤＦＳ トレジャーデータ：もちかたちがう
ＨＩＶＥを使える
まはうとはまだ。機械学習：ＰＩＧのスクリプトでかくか？
はいぶもーる
すぱーくは？（ストリーミング処理）
いまはない。ふるーえんとべーす。
------------
顧客理解のためのビッグデータ分析基盤
クラスメソッドの偉い人
・カスタマージャーニー
タブローであるデータ
やばそうなのはなんなのか？
配送方法の違いで
・カスタマーストーリー
今日の内容
・会社事例
・すかいらーく
・カスタマーストーリー
Developers.IO
・ノウハウひたすら垂れ流し
・事例：紅白歌合戦
ＡＷＳ秒間２０万トラフィック→落ちたら困る
クラウドフォーメーション ９００台
集英社、ガリバー：クルマのセンサー
ＡＮＡシステム、スシロー、すかいらーく等
３０００店舗のＰＯＳデータを整形して、クラウドへＵＰ
分析しやすい形で加工、ＲｅｄＳｈｉｆｔへ
１．５ヶ月で構築３０秒で分析
ログ→トレジャーデータ
→スキーマレスでとりあえず突っ込める！
後から考えて整形
１秒ごとのユニークユーザー
→中の人にＦａｃｅＢｏｏｋ
ＲｅｄＳｈｉｆｔは最初に設計するのが大事。
この設計にミスると、パフォーマンスがでない。
・カスタマーストーリー
顧客理解のためのビッグデータ解析
構成図：talendで引っ張ってきて、
個人情報を削り、Ｓ３へ
モバイルログ、センサーをトレジャーへ（→例、スシロー）
最後はＲｅｄＳｈｉｆｔ
→９月のあまぞんの講演で
たぶろー：生データを手繰りながら
・企業に眠る大量データあるある
歴史的背景が複雑
個人情報や機密情報法が多い
複数のシステム、ＤＢにまたがっている
多数のテーブルがある
正規化されたデータをインポートする？
→１まいのでっかいＣＳＶください！
・データ分析のためのインフラあるある
とても高価なハード、ソフト 初動が遅い
導入しただけで使っていない
分析する専門家がいない
処理が遅い
運用保守する人がいない
・分析ビューワーあるある
何も決まっていない
分析軸の変更をしずらい
特定の人しか使うことが許されない
異なるリソースにアクセスできない
地図と天気を重ねて表示したい
市場データを重ね合わせたい
結局Ｅｘｃｅｌでガンバってしまう
・データ収集あるある
最初にフォーマットを決められない
大量すぎで処理しきいれない
縦もちを横もちに
意味のある情報にしてから活用したい
そのうち分析をするかもしれない
・カスタマーストーリーによる解決
・ＴＤとＲｅｄＳｈｉｆｔとタブローとたれんど
→そんなもんだよね
・導入手順
インプット
アウトプット
代表的なビュー
→パフォーマンスチューニング
ＲｅｄＳｈｉｆｔ
ノード分散：これをチェックする構文がある
最適プロダクト
ロールモデル
・Ｒとかクラスタリングは次。まず、足元を固める
１ヶ月、２ヶ月
・設計
スキーマ／スキーマレス
バッチ
データ定義
１ヶ月でプレ
３ヶ月すれば
わかんなかったら、ブログ見て
・地図、ジオコーディング、市場データ
階段を１段半
すかいらーくにおけるマーケティングとＩＴの融合
すかいらーく 神谷さん
・すかいらーくについて
・本日の内容
分析から創出された価値
分析を加速させるためのＩＴ
テクノロジーによる外食のさらなる進化
・分析から創出された価値
ＰＯＳデータを分析するために構築したシステム
→クラスメソッド
ＲｅｄＳｈｉｆｔ→たぶろー
ＰＯＳデータから分かること
単純な販売数だけではない
新メニュー開発の方向性立案、及び効果検証に活用
平日・郊外・ロードサイド→どういうメニュー
ＡＢテストみたいに・・
方向性を出して、当たったのかどうか
仮説：人間 検証
そのほかＰＯＳデータで分かること
オペレーションの質
販促の質
将来売り上げ
販促例：サンクスくじのカイゼン事例
ブランドごとに顧客属性が違う
デザート、サイドメニュー中心
→付加価値の高いグリル商品中心
これまでの４倍
つぎ：ガストでフォアグラ
消費者テスト→ネガティブ
食べるとおいしい：説明した上でだから
実験計画法
どの店と比べるか？
統計的に同じ動きの店舗で比較
うまくいった→来月よりフェア
つぎ：継続率
セグメントに差：立地
習慣化：タイムライン
１０％の客数成長
・分析を加速させるためのＩＴ
新しい分析基盤導入の背景
できていたこと
できていなかったこと：時間
→回せる仮説検証の数
仮説検証を数多くまわすことの意義
そのためには ＩＴ大事
人間の時間効率をＩＴで最大限に高める
分析自体の自動化
レポート作業の省力化
・テクノロジーによる外食のさらなる進化
すかいらーくにおけるデジタルマーケティング
ネットのノウハウを外食産業へ：アプリ
スマホアプリのポテンシャル
アプリの機能：特に目新しいものはない
→運用が大事
更なるテクノロジー活用の可能性
------------
トレジャーデータ流データ分析
井上さん
・自己紹介
トレジャーデータブログ
・いきなりですがＱ＆Ａ
→なにもない・・・
・サービス概要
データ解析の世界をシンプルにしたい
分析レイヤーの下位からの積み上げが必須
あつめる、管理する
やりたいデータ分析に専念
データ収集
センサーデータ：テレマティックスデータ
Ａｎｄｒｏｉｄログ
Ｗｅｂログ
過去に蓄積
並列分散、バッチ処理、集計
→アドホック型
クラスメソッド：監視
分析
たぶろーＢＩ
・分析プロセス
データ分析の期待値が高すぎる
仮説→検証をまわす
前段：敷居が高い
目的明確化
目標設定
データ収集
いままで：仮説を立てないとはじめられない
→トレジャーデータ：スモールスタートができる
データを見る
データ収集
データＷａｔｃｈ
目標設定
データ：過去と未来
ログインログ
データＷａｔｃｈ
データの「項目」を見る
バッチ処理・アドホックの使いえけけ
データの「内訳」を見る
でぃめんじょん、メジャー
あるからむをセグメント
メジャー：ＰＶ，ＵＵなど数値型
テンプレートがある
ディメンジョン
データの「分布」を見る
数値でグルーピング
タブロー
項目、内訳、分布、全部やる
さくさく分析＝ＧＲＯＵＰ ＢＹで
ＰＯＣ
続きは公式ブログ
質問：Ｈａｄｏｏｐの違い
Ｈａｄｏｏｐ：ＨＤＦＳ トレジャーデータ：もちかたちがう
ＨＩＶＥを使える
まはうとはまだ。機械学習：ＰＩＧのスクリプトでかくか？
はいぶもーる
すぱーくは？（ストリーミング処理）
いまはない。ふるーえんとべーす。
------------
顧客理解のためのビッグデータ分析基盤
クラスメソッドの偉い人
・カスタマージャーニー
タブローであるデータ
やばそうなのはなんなのか？
配送方法の違いで
・カスタマーストーリー
今日の内容
・会社事例
・すかいらーく
・カスタマーストーリー
Developers.IO
・ノウハウひたすら垂れ流し
・事例：紅白歌合戦
ＡＷＳ秒間２０万トラフィック→落ちたら困る
クラウドフォーメーション ９００台
集英社、ガリバー：クルマのセンサー
ＡＮＡシステム、スシロー、すかいらーく等
３０００店舗のＰＯＳデータを整形して、クラウドへＵＰ
分析しやすい形で加工、ＲｅｄＳｈｉｆｔへ
１．５ヶ月で構築３０秒で分析
ログ→トレジャーデータ
→スキーマレスでとりあえず突っ込める！
後から考えて整形
１秒ごとのユニークユーザー
→中の人にＦａｃｅＢｏｏｋ
ＲｅｄＳｈｉｆｔは最初に設計するのが大事。
この設計にミスると、パフォーマンスがでない。
・カスタマーストーリー
顧客理解のためのビッグデータ解析
構成図：talendで引っ張ってきて、
個人情報を削り、Ｓ３へ
モバイルログ、センサーをトレジャーへ（→例、スシロー）
最後はＲｅｄＳｈｉｆｔ
→９月のあまぞんの講演で
たぶろー：生データを手繰りながら
・企業に眠る大量データあるある
歴史的背景が複雑
個人情報や機密情報法が多い
複数のシステム、ＤＢにまたがっている
多数のテーブルがある
正規化されたデータをインポートする？
→１まいのでっかいＣＳＶください！
・データ分析のためのインフラあるある
とても高価なハード、ソフト 初動が遅い
導入しただけで使っていない
分析する専門家がいない
処理が遅い
運用保守する人がいない
・分析ビューワーあるある
何も決まっていない
分析軸の変更をしずらい
特定の人しか使うことが許されない
異なるリソースにアクセスできない
地図と天気を重ねて表示したい
市場データを重ね合わせたい
結局Ｅｘｃｅｌでガンバってしまう
・データ収集あるある
最初にフォーマットを決められない
大量すぎで処理しきいれない
縦もちを横もちに
意味のある情報にしてから活用したい
そのうち分析をするかもしれない
・カスタマーストーリーによる解決
・ＴＤとＲｅｄＳｈｉｆｔとタブローとたれんど
→そんなもんだよね
・導入手順
インプット
アウトプット
代表的なビュー
→パフォーマンスチューニング
ＲｅｄＳｈｉｆｔ
ノード分散：これをチェックする構文がある
最適プロダクト
ロールモデル
・Ｒとかクラスタリングは次。まず、足元を固める
１ヶ月、２ヶ月
・設計
スキーマ／スキーマレス
バッチ
データ定義
１ヶ月でプレ
３ヶ月すれば
わかんなかったら、ブログ見て
・地図、ジオコーディング、市場データ
階段を１段半