活動報告

マイナビTechNight#3『ライフメディアにおけるプライベートDMPの取り組み』小澤 紀和さん

こんにちは、マイナビエンジニアブログ編集部です。

マイナビでは定期的にエンジニア向けミートアップイベント【マイナビ Tech Night】を実施しています。
第三回となる今回は、マイナビでエンジニアとして働いている岡部さん、柴垣さん、小澤さんにお話を聞きました。

登壇者

小澤 紀和(おざわ のりかず)さん
IT戦略事業部 BPR推進課/2017年入社

マイナビ新卒入社後、マイナビ賃貸に配属。
賃貸サービスの物件情報処理システムを担当した後、
現在のIT戦略事業部にて

  • SFA開発支援、運用改善
  • BIツールの導入・実装
  • クラウド型BPRツールの導入・実装
  • プライベートDMPの運用

サーバーを触っている日もあれば、DMPでどうマネタイズするかといった企画を考えることろまで
幅広く担当しています。

発表内容

今回は以下の3点について発表していただきました。

  • DMPって?
  • 今までやってきたこと
  • 今やっていること、これからやっていきたいこと

※本記事は、発表内容を書き起こしたものです。

DSC_0129.jpg

BPR推進課とは

IT戦略事業部は統括部が2つに分かれてまして、

  • 戦略統括部 ⇒住まい、ウーマン、学生の窓口チーム、SEO、BPR推進課
  • 開発統括部 ⇒ウエディング、トラベル、ニュースの開発チーム

となっています。
住まい、ウーマン、トラベルなど、それぞれ媒体別に開発チームがいるのですが、SEOとBPR推進課はサービスに紐づかずにサービスを横断して担当をしております。

そのなかで私たちは、SFA、BI、DMP、RPAなどのソリューションを、サービスを跨いで横断的に提供しています。

DMPって?

DMPは「Data Management Platform」、
つまりデータを蓄積し、活用目的に特化した機能が付随するサービス・基盤のことです。
例えばGoogleAnalytics、これは来訪したユーザーの行動を分析することに特化したDMPといった解釈ができます。

他にどういったDMPがあるのかというと、

  • 広告配信(DSP、SNS等)
  • CRM
  • MAツール

などがあげられます。

今までやってきたこと

2017年にパブリッシャー向けDNPを導入しました。
この時、IT戦略事業部はまだなくて私も担当はしていなかったんですが、生活情報メディアであるニュースや、ほかの媒体で同じプラットフォームを導入しました。

主な利用目的は、ニュースとかウーマンなどのメディアでのタイアップ広告配信で、その他記事コンテンツの分析など、あくまで記事媒体での利用でした。

そして2018年にIT戦略事業部が発足しまして、そのなかにBPR推進課ができて、私たちが担当することになりました。
そこから、広告商材の拡販等施策を検討し、実施するなかで問題が浮き彫りになってきたという感じとなっています。

過去の基盤にはどういう問題があったのか

  • パブリッシャー向けDMPは広告配信中心
  • 賃貸とかウエディングのようにユーザーを獲得する媒体においてはMAツールなどでデータを連携させたいけどできない
  • BIもDMPにパッケージされているものでは、フォーマット化されていて欲しい情報が見れない
  • ローデータに簡単にアクセスできないのでETLで加工して可視化も難しい
  • JSタグの仕様が公開されていないので、自分たちで修正ができず時間がかかる

じゃ、どうするかってなったときに、
自分たちで内製化して、要件に合うものを作ることも考えましたが、リソース的に難しい部分があったので、
要件に合う新しいプラットフォームへと乗り換えることにしました。

リプレイス先はArm Tresure Data eCDPという、いわゆるDMP(目的に縛られたデータをためる箱)というよりも、フルマネージドのDWHにような印象を持っています。

これは、ローデータを実際に自分でQueryを書いて加工して活用していくので、非常に自由度が高いです。
ある程度成型したデータをGUIでデータ抽出できるので、Queryが書けないマーケターやビジネスサイドの方でもデータに触れやすくなるという点がメリットだと思っています。

先ほどフルマネージドのDWHといいましたが、広告とかBIなどのさまざまなツールにコネクタを持っているので、いろいろなサービスの目的に対応できるものになっています。

私的にはこれが一番いいと所だと思ってるんですが、JSタグはSDKとして公開されていて自由に取得データの設計ができます。
これがデメリットになる場合もありますが、自分たちが今何をやっているか把握がしやすいという点では私的にはこれが一番やりやすいと思っています。

DSC_0172.jpg

今やっていること、これからやっていきたいこと

マーケティングの基盤を確立しようと日々動いております。
ウーマンやニュースなど複数媒体があるなかで、JSやSDK、Embulkですとか、3rd party DMPからAPIを使ってTresure Dataにデータを取り込んでいます。

直近で特に取り組んでいるところとしては、BI・BAの部分です。
ニュースにおいて、記事単位でどのユーザーがどの記事をどのくらい読んでいるかをTresure Data上で集計して、BigQueryにバルクでエクスポートしてtableauで可視化するということをやっています。そういうもので、例えばニュースなどでタイアップのようなものや、どういうユーザーが読んでいるかといったマーケティングの活用に生かしていこうとしています。

またMAや、Web接客、KARTEを導入しているので、そういう部分でユーザーへのコンテンツの出しわけを制御したり、もっと深いアナリティクスの部分でRとか、その他の分析ツール、あとは広告でGoogleとかそういったところ積極的に連携していきたいなと思っています。

ところが、実は私の課、今2人しかいないんですよね。
そろそろきつくなるよな、というのが本音でして。
私たちも採用を始めたいなと思い、準備を始めているところです。
また新しい情報が公開されましたらご確認いただきたいなと思っています。

質疑応答タイム

最近話題の人材データは別部署ですか?

A:そうですね。今回は生活情報系だけをDMP構築していますので、人材データは一切入っていないです。

DMPについて最近ニュースがありましたが、マイナビさんは大丈夫でしょうか?

A:はい、大丈夫です。

安易に大丈夫と言っているわけではなくて、インフォモティブデータの取り扱いに関しては現在各部署とも議論が進んでおりますし、ちゃんとユーザーにパーミッションを取って活動をしていくというところも検討をしています。

ETLとしては基本的にTreasureDataのコネクタを利用するような形でしょうか、要件的に適さない場合などは独自のDigdagワークフローなどを利用されているのでしょうか?差支えなければお聞きしたいです。

A:そうですね、Digdagワークフローを使っています。

DigdagでQueryとかでどんどんワークフローを組んで、最終的にBigQueryのコネクタを使ってバルクで吐き出しています。
しっかり日時でサフィックスが切れるようにテーブル名を日付にしてBigQueryのコストを抑えるような工夫も行っています。

共通基盤を導入するにあたり、苦労したところはありますか?

A:いろいろなサービスがあって、各方面に「こういうことがしたいです」というような説明をするところが一番苦労したかもしれないですね。

やはり、全部のサービスが同じ目標をもっているわけではないので、そういうところはうちならではというか、いい経験になったと思います。
ビジネス側の方と関わりながらこういうものを導入していくところは非常にいい経験になりました。

事業会社のマーケ部門でCDP保守・運用に関わっていますが、マーケターとの認識のズレなどありませんか?私は一人です。

A:一人で頑張ってらっしゃる方もいるんだなということで、私はすごい恵まれているんだなと認識できました。

そうですね、ありますね。特にBI関係は意識がズレやすいので、最近意識してることは最初から100%を目指さないことが実は大事なじゃないかなと思っています。

コミュニケーション取りながらやってるので、ある程度ズレは仕方ないと思っています。なので、ある程度の5割くらいのものを渡して、コミュニケーションをとりながら改善していくみたいな、そういう部分をうまくfixしていく工夫というのは私も常々悩んでおります。

KARTEは具体的にどのように使っていますか?

A:サービス名は控えさせていただきますが、キャンペーンの告知とか、キャンペーンに反応がよさそうなユーザーに対して、バナーを出すとか、そういう使い方をしています。

可視化ツールとして、tableauとredashはどう使い分けていますか?

A:これはですね、どちらかというとサービスがどちらを使っているか次第ですね。

redashが使われているところであればredashを使うし、tableauを使うところであればtableauを使うしといったところです。

資料に書かれていたTreasureDataとBigQueryの連携は具体的にどのような使い方をしているのでしょうか。

A:具体的に一つ挙げますと、tableauのサーバーが全社導入してるものが一つありまして、そこからデータを参照しに行くときに、TDだと重たいQueryになって帰ってくるのが遅くなってしまうので、BigQueryのほうが速いというところで、TD上である程度成型しておいたデータをBI用に入れておいてtableauから参照させる連携をしています。

生ログがいらなくなったらどんどん成型して、BigQueryに入れてTDのデータを削除してコストを削減するという側面もあります。

活動報告の記事一覧
タグ一覧
TOPへ戻る

関連記事