「SoftBank Ads Platform」を支える分析基盤　エンジニアが明かす、その運用と苦労

Treasure Dataを活用したデータ収集基盤の利用と苦労

斉藤克哉氏（以下、斉藤）：よろしくお願いします。DACさんのゴツめのプレゼンがある中で、だいぶ僕のプレゼンはナヨナヨしておりますので、今ハードルを下げ気味にして、本当にハードルが低かったことをあとで後悔したいと思います。

まず、自己紹介しますと、ソフトバンクの法人事業戦略本部のデジタルマーケティング事業統括部で開発課に所属しております。

とはいえ、こちらに移ってきてからはまだ2年程度で、それまでは動画サービスの技術サポートと開発との調整とか、あとソフトバンクではないですが、ほかのISPさんでインフラエンジニア、運用とか開発を行っておりました。ですのでTreasure歴は非常に短くて、初心者チックな作業をよくしております。

弊社のデジタルマーケティング部で取り扱っている商材としては、「ウルトラ集客」「GENERATE ディスプレイ」「GENERATE ビデオアド」「シナラ」「ソフトバンクお知らせメール」というようなものがあります。オウンドだったりO2Oのものが多いんですが、そこに2016年の10月から「SoftBank Ads Platform」というものを加えて運用しております。

今日は、Treasure Dataを活用したデータの収集基盤の作成・分析・利用についてと、その苦労についてお話ししたいと思います。どちらかというと愚痴に近い感じもあって、こんな公のところでしてもしょうがないとは思いつつも、お話しさせていただきます。

「SoftBank Ads Platform」サービス開始の裏側

まず1st Phaseとして、2015年の春に、DMPの実証実験ということで、外部のDMPサービスを利用して、O2Oとか普通のデジタルディスプレイの広告とかで、キャンペーンの効果測定を実施しました。

このときは自社の計測環境とかTreasure Dataの利用はなかったんですが、一番の問題が3rd Party CookieはiOSで利用できないということで、こちらを取るためにどうしたらいいかとなったとき、自分たちで計測基盤を作るしかないということになって、着手し始めました。この時点ではまだ僕はいなかったので、ほかの方が取りかかっていたものを1年後に引き継ぐかたちになります。

このように、2016年の10月、プレスリリースで「SoftBank Ads Platform」サービスを、ディスプレイ含め、Web広告のサービスというかたちで、ソフトバンクが「ファーストパーティデータとくっつけてできるだけ最適化された広告を配信する」ということでサービスを開始いたしました。

構成としては、インプットはWebだったりテレビだったりオフラインで、O2Oのクーポン機会やIoTを目標に、弊社DMPで処理をして、再度そちらからターゲティングしたり、ジオターゲティングしたり、マーケティングオートメーションしたり、ビデオアドで、ファーストパーティデータと出すことでセグメントを最適化したものを広告として提供するというふうになっています。これがだいたい2nd Phaseです。

「SoftBank Ads Platform」の構造

僕がジョインしたのがちょうど2016年の4月からで、このあたりで引き継ぎを開始しました。この時点でTreasure Dataというものを初めて聞きました。

そこから実際のリリースまで6ヶ月ほどかかっていますが、SoftBank Ads Platform自体は、マイクロアドさんとジーニーさんのお力も借りつつ構築したところがあるので、こちらでガリガリガリッと作ったというほどのものでもないです。

この時期、ちょうど僕がジョインしたタイミングから、自社計測サーバの実際の構築作業を行っておりました。はじめの見積もりから6ヶ月程度経った9月から予算が確保できましたので、自社の計測サーバ（3PAS）の実際の構築を行いました。

2ヶ月、3ヶ月で、サービスとしては自社計測のサービスを立ち上げることができました。ですが、ここにはいろいろありまして。

（スライドを指して）構造としては、こちらにあるのがファーストパーティデータで、SoftBank Ads Platform自体は右半分だけでも動作はするんですが、さらに、自分たちで所有しているオウンドのメディアとか、あとディスプレイ広告。当然、SBDSPで出したもののリタゲとかも含めて、計測サーバのほうで可能なかぎりデータの所有を行おうというようにしています。

こちらを最終的にはアウトプットとしてDWHのほうに再度戻すようなことも行っており、Treasure Dataは基盤としてだけでなく、最終的なインプット・アウトプットの両方を行うかたちで存在しております。

この図は外販のほうのモデルでして、内販というか社内利用としては、アドプラットフォームとしても利用しております。

もらえるデータはなんでも集める

計測サーバの位置はオウンドメディアとディスプレイ広告の間に入っておりますが、実際は、GoogleさんとかYahoo! DMPとかを直接Treasure Dataさんから経由して広告を出すような動作にもしておりまして、SBDSPだけではなく、自社の契約のDBM、自社の契約のYDM・YDSPといったところにも広告を出せるような仕組みとして社内利用を行っております。

DBMとかDCMですと当然データが返ってこないので、データを戻すためにData Transferという契約もして、実際のDBM・DCMのほうで取れたインプレッション・クリック等のアクションをさらにTreasure Dataに戻すような設定もしております。

現在は、集めるデータと集める方針としては、主にCookieベースですべて収集しておりまして、プロダクトオーナーと調整がついたものからモバイル広告識別子も収集するかたちをとっております。

さらに、いくつかはオウンドメディアのほうでキャンペーンやアンケートを取っています。キャンペーンでアンケートを取得するものもありますので、そちらもTreasure Dataに取り込んで処理をするようなことも行っております。

大前提として、もらえるデータはなんでも集めるようにしています。けっこうな量が集まってきちゃうんですが、まずは「データはどのぐらいあるのか」「どのようなデータが社内に存在しているのか」ということも含めて「もらえるデータはなんでも集める」ということを主眼に集めております。

計測サーバを自社構築するメリットは透明性

しかし、自分たちが始めてからまだ2年も経っていないぐらいですが、データがボンボン増えてしまって、けっこうまとまりがない状態になっております。

すでに弊社側では、計測サーバで付与しているユニークなIDは1年経たずに2億件を突破してしまって、処理にだいぶ困っているところもあります。あとはID Syncを行う事業者などサービス側がいくつか増えてきているのも、データの増加に関係しています。

計測サーバを自社構築してよかったことと、イケていない、悪かったことについてです。よかったことは、みなさんだいたいおっしゃられているとおりで、データの透明性です。自社でどのようなユーザーのアクティビティがあったか、どのようなときにアクセスが来ているかのデータが取れるようになったので、がんばってガリガリガリっとSQLを書けばある程度統計として出せるようになりました。

タッチポイントをうまく、シンクのだったりPVの仕組みをうまく使えばデータを取り込んだりできるようになったのが一番大きいところだと思っています。

イケていないところは、自社で構築してしまったので、大きいキャンペーンがどのぐらいの量で実際に測れるのかわからなくて初日はすごくドキドキします。

昨年のiPhoneの商戦期など、けっこうトラッキングのタグが仕込まれてしまったことがありました。例えば、Yahoo!のトップのディスプレイアドとかに出てしまったために、サービスが4時間ほど止まってしまった。

動かすまでわからないのがドキドキする

そこのフェイルポイントが、想定している量をだいぶ超えていたこともありますが、落ちたタイミングがまったくわからなかった。

わからないというのは、当初、予約が始まって数時間は普通に捌けてたんですが、深夜帯手前ぐらいにいきなりドンと落ちまして、その理由がまったく解析してもわからない状態が発生していたんです。調べるのに3〜4時間かかってしまった。

結局、ロードバランサがrequests per secに耐えきれない状態になってしまって落ちたことが想定外だった。テストのときはそんなに問題はなかったんですが、実際のユーザートラフィックになったときは想定外の動きをしたという出来事がこのドキドキに含まれております。

いまだにキャンペーン初日と聞くとドキドキが止まらないのがイケていないポイントです。できるだけスケーリングできるような環境を作りたいとは思っているんですが、今のところなかなかできていない。

似たような話ですが、想定外の障害というものが、データとして取れていないとか、実際に取得しなければいけない秒数やタグマネージャーに起因するところがある。例えば、4秒であればだいたい取れると思ってたところが、実は10秒以上待たないと取れなかったとか。

そういったちょっと不思議な障害が起きたり、先ほどのとおりで、自分たちがキャンペーン初日以外もドーンと来るときがあって、想定外のトラフィックにまだ耐えきれるほどの設備構成が取れていないのがイケていないところだと思います。

自社構築の難しい点は？

自社で構築する上では、とくにIDとセキュリティ、あと社内処理が一番通常の広告配信業と異なるところで、弊社の場合は総務省管轄の通信事業者としてポリシーのガイドラインをあげているので、個人情報とみなされる部分が若干厳しめに想定されています。

社内レビューも、行うんですが、実際すごく時間がかかります。「こういうデータを取り扱いたい」「こういうふうにデータを集めてほしい」「こういうふうにデータをつなげてほしい。突合してほしい」と言われるんですが、そう簡単には突合処理ができなくて、社内利用ですら難しいときがあります。

社内レビューと監査に時間がかかってしまって、ちょうどいいタイミングでなかなか提供できないことが、社内利用ですら存在する。

あとは、当然そういったレビューの中でフィードバックがあるのが「こちらはちゃんと匿名化してるんですか？」もしくは「匿名化が難しいのであれば、そのデータは容易照合性をちゃんと担保できているのですか？」ということです。

データ処理をする上で、単純に突合処理をすれば実際のデータとしては処理できるんですが、そういったかたちでできなくて、データフローとしては非常に余計な、1回ハッシュ化かけてハッシュ化テーブルを作って、突合させるためにラベリングというようなことをする。

そのようなひと手間ふた手間の実際の処理が必要になってくるのが社内セキュリティです。単純にデータの処理と考えたときは、正しい処理ではありますが、非常にイライラする。

求められているものを理解するのは必要だが難しい

社内連携も、すごく大事だとは思うんですが、現実の僕たちの作業上ではデータを見ているだけだというところが難しいです。

実際の施策のLPだったり、コンバージョンポイントが決まって、タグを作ったりシンクできるIDを探したりして用意をして、タグを設置したり取ってるデータの状態を見たりするんですが、マーケティング部門や施策部門がなにを求めているのかをすぐに理解できないことが多いんです。

実際に求められているものとはまったく違うデータの出し方をしてしまって時間がかかっちゃったりすることが多いので、ここに関しては本当に、マーケティングの方がやりたいと思っている施策内容をちゃんと理解することが非常に大事だと思っております。

とはいえ、先ほどのデータの取得の基本的なスタンスとして「なんでももらう」と言いましたが、なんでももらってしまうと、データの順番が違ったり想定していないラベルがついているデータが来たりして、収集したはいいけれど、まったくまとまらないことがある。

まとまらない上に「このデータがすぐ欲しい」と言われて処理しても、イメージとぜんぜん違うデータ量が発生することがよく起きます。

正直、ここは完全に愚痴ですが、今、サービスシステムの運用を実際しながら、そのデータの収取の方法を見直したり施策の内容を深く理解するのは、先ほどのDACさんの内容でもあったとおりで、非常に難しいです。ちゃんと理解しなければいけないですけど、言葉が違ったり考え方が違ったりすると、なかなかすぐには難しいと思っています。

難しいポイントが絶えない

あと、マーケティング部門からリクエストされたデータの処理とかを考えていると、各施策だったり各リクエストに対して、毎度、調査用のクエリとかを書いている状態なので、なかなかこううまくいけない。

書いて、走って、resultを出すのはいいんですが、TreasureDateがそこらへんの使い勝手が非常にいいというのもあって、クエリを書いて、resultを取って、保存を忘れることもあります。あとは弊社はプロキシ環境なので、クエリをうまく保存できないことがある。

保存するのを忘れると「あの結果ってどのクエリから出てきたやつだっけ？」となって履歴から探すことになる。ヒストリーからなかなかそのクエリが見つからなくて、最終的にはまったく同じだったり似たようなresultが出るクエリを書かざるをえなくなるので、よく二度手間、三度手間がかかります。

あとは、当然クエリでresultをそのままお渡しすればいいんですが、お題目としてはダッシュボードを作るということがよくあがってきます。

一番はじめにDMPとしてデータを集め始めた時、Treasure Dataの中にあるデータをできるだけ結合してダッシュボードを作りました。こういう要求でこういうふうに作ってくださいと言われてユニークユーザーの分布だったり、可能なかぎり細かい粒度で、最終的にはIDが引き出せる程度まで細かく見られるようなものにしました。

1つを解決するとまた1つ問題が生まれてしまう

でも結局、データ粒度がすごく細かいのはユーザー単位のリストを作れたりするので非常にいいんですが、統計データだけ見たいとき、例えば「どういうブラウザのアクセスが多い」「どういう機種からのアクセスが多い」というデータを表示させるのに3〜4分かかるようになってしまった。

改善する方法が見つからなくて、結局、要求をもう1回確認し直して精査し直して、可能なかぎりまとめるられるものはまとめる、粒度とか加工済みデータにすることで統計情報の表示を速くするという方法を考えました。

ただし、統計情報を表示するだけというわけでもなくて「粒度の細かいデータも見たい」という要求が出てきたり「データを掛け合わせてもっと施策に活かせる見せ方をしてください」と言われるので、結果を見ると、見やすく統計情報の表示だけだと速いんですが、要求されているものからするとコレジャナイ感が半端なく出てくる。

そうすると、やっぱりちゃんとデータの加工をはじめから見てどういうふうに持てばいいのかなというようなことを、現在悩んでいる最中でございます。

そんなことをしてる間に、またデータが増える話がでてきた。昨年の6月ぐらいから、弊社のソフトバンクのLINEアカウントとLINE Business Connectで接続をしました。

こちら、今、毎週金曜日に「一生分の〇〇が当たるキャンペーン」というものを展開させていただいているんですが、そちらでキャプチャしたユーザーデータとファーストパーティのデータをぶつけて分析をしたりしております。

新技術に追いつき続ける難しさ

もうテスト的に、one-to-oneマーケティングを何回か行ってはいます。先ほどあげたGoogleですとかYDSPとユーザーの接点だとか、あとMAして、メール・Web・LINEでどの反応がよかったかを見たりしています。

なかなかこちらに結果としてお出しできないのが歯がゆいですが、3回ほどテストをしたところでは、やっぱり比較的ミックスドメディアというか、Web・メール・LINE、すべてのタッチポイントで広告、メッセージを出したほうがユーザーの反応は非常に良いということは出ております。

と調子乗ってたら、昨年iOSの11がリリースされた。ITP、これがけっこうゴツい感じで、正直まだ分析が全部できていません。

ITPの影響は、見てスパッとはよくわからない。いろんなところで「こういうふうになっていれば大丈夫」というようなことは出ていますが。例えばデベロッパーのツールとかでCookieの保存されている状態を見るとCookieは表示されていないけど、通常Cookieが保存されているファイルを見ると、ファーストパーティとしてデータは保存されている。

ただ、それの永続期間が、一応こちらで設定しているexpire timingで入っているけども、本当にそれがexpireされずにそのexpire timeまで生きているのかをなかなか確認しづらい。どのぐらいの影響度が実際に起きているのかを把握するのがなかなか難しい。

このID連携などで、ユニークなユーザーにできるだけタッチできるような環境ができてるんですが、iOSに限っていうと、そのユーザーに対してのCookieがいつまで有効なのかがなかなか難しく思っております。

悩んでいる間に次のフェーズが来る

そして、悩んでいる間に次のフェーズが来る。（スライドを指して）これはTreasure Dateさんのホームページからキャプチャさせていただいたんですが、先日、弊社と、あとTreasure Dataさんで協業するかたちで、リリースを出させていただきました。

最後に、今後の取り組み、こういうことをしたいという話ですが、Treasure Dataをもっとうまく活用したいと思っています。正直、今Treasureさんが持っている機能を100パーセント、120パーセント、1000パーセント、全部しゃぶり尽くしたいと思ってるんですが、今のところできていない。

とくにHivemallによる学習にはすごく興味があるんですが、なかなか学習コスト的に僕たちのスキルがまだ追いついていないので、もうちょっと時間をかけて勉強して活用したいと思っています。

トレジャーデータ様との協業もリリースを出させていただいておりますので、弊社内でのCDPの活用についても、マーケティング部門でうまくデータをハンドリングできるようにするためにCDPの利活用を進めていきたいと思っております。

いろんなものに頭をひねりながらつくっている

もう1個、CDPの契約ユーザーに対してどのようなサービスができるかということは、Treasureさんと今がんばって詰めてますので、サービスとしてリリースができるタイミングができたら、みなさまとはうまく連携していきたいと思っております。

（スライドを指して）あと、こちらはIDのスティッチングとかIDグラフの作成なんですが、いろんなユニークなIDを起点にCookie IDを見てると、ちょっと不思議な動きをしているユーザー、Cookie IDがけっこう見られます。

今そこをうまくまとめる方法について、だいぶ頭をひねっております。もし今日いらっしゃる中ですごくいいアイデアをお持ちの方がいらっしゃったら、教えていただけると非常にありがたいです。

あとは、いろんなメディアさんと連携可能なアプリについても、社内・社外含めできるだけ整理を進めて、法的に当然問題のないかたちでいきたいと思いますので、その上で、ユーザーさんが広告を見てそのブランドがいいなと思っていただけるような広告サービスを提供していきたいと思っております。

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

（会場拍手）