マーケターが使えるCDP「トレジャーデータ」。データを使って顧客を理解する方法 | 連載企画・前編
【連載企画】CDPツールベンダーロングインタビュー②〜Treasure Data前編〜
デジタルマーケティングジャーナル（DMJ）にて連載企画が始動。
今回のテーマは、「各CDPツールベンダーを訪問し『CDP』についてのロングインタビューを行う」というもの。 今回はTreasure Data前編（全3回）をお送りします。
CDPの参考記事：カスタマーデータプラットフォーム（Customer Data Platform、CDP）とは？
トレジャーデータは、企業内に散らばったカスタマーデータを統合するCDP（Customer Data Platform）を提供している。顧客企業のCRMやeコマース、IoTなどのデータを収集することはもちろん、サードパーティベンダーと連携してデータを企業経営に活かすことを可能にする。数あるCDPの中でトレジャーデータの特徴は、様々な種類の大容量のログデータを蓄積できること。2018年にはソフトバンク傘下の英Arm社に買収されたことでも話題に登った。
今回は、CDPとしてのトレジャーデータについて、トレジャーデータ株式会社 マーケティングディレクター 堀内健后氏にインタビューを敢行。トレジャーデータ自身の話はもちろん、トレジャーデータ運営の知見から得たデジタルマーケティング人材や組織の話など、幅広く話を伺った。インタビュアーはアンダーワークス株式会社 マネージャー 高橋 諭が務めている。
CDPは顧客理解にデータを活かすためにある
高橋：
本日はよろしくお願いします。
早速ですが、CDPという言葉が市民権を得てきたと感じているのですが、トレジャーデータにおけるCDPの考え方を教えていただけますか。
堀内：
そもそもCDPという単語はCDP InstituteのDavid Raabが提唱し、トレジャーデータのアメリカ本社も「CDP」と言い始めたので、日本側も使い始めたという経緯があります。それまではプライベートDMPという言葉を使っていました。
高橋：
アメリカで言葉を変えた理由はあるのですか？
堀内：
正直に言うと、結果的にCDPと言われるようになったんです。
アメリカに限らず日本もですが、そもそもトレジャーデータは当初からログデータを大量に溜めて分析するプラットフォームを提供しています。その使われ方が広告ログだけでなく、いつからか例えばMAのログやPOSデータのような、マーケティング・CRM目的のためのデータを溜めるようになってきたんです。要するにデータは広告のためではなく、顧客理解のために使おう、ということですね。
トレジャーデータがそういうふうに誘導したわけではなく、あるクライアントから「うちは顧客理解のためにデータを使っていますよ」という話を聞いて、「あ、うちはCDPだったのか」と認識したんです。
高橋：
顧客企業が気づかせてくれたんですね。
堀内：
ちょうどその時期にDavid RaabがCDPの定義を言い始めていて、「あ、この話って結局うちのことだよね」みたいな感じになったんです。そこからCDPという概念でサービスを考えるようになって、例えば顧客理解のためのユーザーインターフェースやレポーティングといった機能を作りはじめました。
高橋：
CDPに必要な要件はなんでしょう。
堀内：
トレジャーデータに関して言うと、顧客データを扱うのでセキュアであることは当然として、データがマーケターでも簡単に蓄積・分析・連携できること。
データプラットフォームなのでデータはあるわけですが、それを顧客企業のマーケターが見ても「で、どうすればいいの？」「これは儲かるの？」という話になったら、「わかりません」と答えるしかない。データを商品開発や需要予測といったアクションにつなげるためには、メールやLINEで顧客に連絡をとったり、広告配信したりといったことが必要です。つまりCDPとマーケティングツールを連携させなければなりません。
トレジャーデータにはアクションする機能は一切ないので、データとアクティビティを連携するということが絶対的に必要です。実際に約200社以上と連携して、データ活かせるような体制を築いています。
非エンジニアである、マーケターのためのユーザーインターフェイス
高橋：
CDPをマーケターが使うケースについて伺わせて下さい。マーケターがトレジャーデータを使うケースで、トレジャーデータが意識していることはありますか？
堀内：
ユーザーインターフェイスですね。
実はマーケターにどうのように使っていただけるかという点では、苦労しているんです。どういうことかというと、データを扱うためにはSQLなどのプログラム言語を扱う必要があるわけですが、エンジニアと違ってマーケターの方は、必ずしもSQLを叩けるわけではありません。かといって、いちいちエンジニアがSQLを書いていては時間もかかるし、エンジニアにも負荷がかかってしまいます。そうするとSQLを誰が扱うのかという問題は、システム側のユーザーインターフェイスで解決できたほうがいい。
ただトレジャーデータは成り立ちがデータベースの会社ですし、現実にもエンジニアがユーザーとして多いので、マーケターが困っていることが肌感でわからない。そのためマーケター向けのユーザーインターフェイスはどうしたらいいか、というのは課題に感じていて、ヒアリングしたりしながら、少しずつ良くしているといった状況です。
高橋：
理想的にはマーケターがSQLを扱えるべきでしょうか。
堀内：
扱えるべきとまでは言わなくても、扱えた方が満足する分析結果を得やすいのは事実です。エンジニアに「こういう分析をしたい」と頼むと、エンジニアにビジネスを全部説明してクエリを書いてもらわなくてはなりません。これだとマーケターにとってもエンジニアにとっても負荷が高い。だったらマーケター自身がクエリを理解して自分で書いた方が早いし、欲しい結果を得られますよね。
とはいえ全マーケターにSQLを自助努力で完璧に使いこなしてもらうのは現実的でないので、トレジャーデータでも手を打っています。SQLのレクチャーを開催したり、テンプレートを渡したり、顧客企業のためにSQLを扱える人を探してくることもあります。拒否反応が出ている方に「SQLは必ず扱えるべきだ！」って言っても仕方ないですからね。
高橋：
ツールベンダーとしてCDPを使ってもらうために、またビジネスがより進むような施策は協力すると。
堀内：
折角CDPやトレジャーデータを検討・購入していただいたのですから、長く使っていただいてデータでビジネスを成功させてもらいたいですし、ビジネス的にも顧客企業の課題をサービス内外で解決するのは非常に重要です。
トレジャーデータはSaaSベンダーですが、SaaSベンダーは、お客様にサービスを使い続けていただかなければなりません。ある意味で顧客企業が勝手に使って勝手に成果が出るのであればそのままでよいのですが、そんなケースはほぼありません。成果が出ないと解約されてしまうので、こちらとしてもそれは避けたい。
高橋：
ユーザーインターフェイスの話でいくと、数か月前にインターフェースが大きく変わりましたが、これもマーケターが使うことを意図して変えたのでしょうか。
堀内：
そうですね。日米のカスタマーサクセスやテクニカルサポートチームがお客様とコミュニケーションをとる過程で課題を吸い上げました。そこからプロダクトチームを中心にユーザーインタフェースを作り込んでいます。
高橋：
開発はアメリカがメインということですか？
堀内：
ユーザーインターフェースという観点でいうと、アメリカ主体ですね。アメリカって色々な人たちが、ある種混然一体となった国じゃないですか。だから様々な方に使っていただくというモノづくりは得意だと思うんです。
デザインとバックエンドはアメリカ主体で、それ以外のAPIなど他の部分は、日本や他の拠点のエンジニアが中心になって開発しています。お客様に使っていただくという意味で、日本においてはセールスにエンジニアが同行してお客様のところに伺って、どうやってトレジャーデータを使ったらいいかサポートするということもやっていますね。
この記事を書いた人
