マーケター・販促担当者向けのトレジャーデータの使い方

More than 1 year has passed since last update.

マーケティング担当の田村です。トレジャーデータというと

  1. FluentdとかEmbulk使って巨大なアプリやログデータを投げ込む
  2. SQLでとにかく集計しまくる。
  3. ~TD_TIME_RANGEの設定を忘れてJobが終わらない~
  4. Data Tanksとか、Redshiftとか、Google Spreadsheetに整ったデータを書き出して、レポート作成したり、アドホック分析の結果を見てPDCAを回す

みたいな使い方が多いかと思います。ユーザー層としても、データサイエンティストやデータアナリスト、あるいは彼らをサポートするデータエンジニアやインフラエンジニアの方がメインかと思います…

が、断言しましょう。2016年、一番トレジャーデータのユーザーとなるべきは、プランナー・販促担当者の方々です。以下、ちょっとした製品紹介も含め、どうデータを組み合わせると、より効率のよいマーケティングや販促キャンペーンが出来るか説明したいと思います。

あまり技術的な話は出てこないので、「SQLとかちょっと…」「トレジャーデータとかってエンジニアのツールでしょ」みたいに普段感じられている方にもお勧めです。

根本的な問題、それはデータサイロ

マーケティングをやってる元データ分析屋として常々思うのですが、データと幸せは似ています。双方とも、

  1. どこかにあることはわかっている
  2. しかしどうやったら手に入るのかわからない
  3. 誰に聞いてもテキトウな返事ばかり

です。例えばこんな経験はありませんか?

  1. Google Analyticsを眺めていたら、よりディープな考察をしたくなったが、何のデータを見たらいいかわからない。エンジニアに聞きたいが、忙しそうだ。というかそもそもどのエンジニアに聞いたらいいのかわからない。
  2. クラウドサービスの会社なので、お客さんのサービス利用状況が全て把握できているはずだが、自分はサービスを作っていないので、どこにそのデータがあるのかわからない。
  3. 費用対効果とかを計算する際に、顧客管理システム、広告ネットワークの月次レポートなどからCSVをダウンロードしてきてExcelでゴニョゴニョするのダルい。どうにか自動化したいが、プログラミングとかマジ勘弁。

ぼくはこれらの現象を、データサイロ問題と呼んでいます。つまり、各部門、データ用途ごとに、意図せずしてデータの収集・保管システムを作ってしまい、データの共有を妨げてしまっている現象です。

data_silos.jpg

データサイロはプランナー・販促を苦しめる

データサイロ問題で一番苦労するのはマーケティングと販促です(T_T)問い合わせ前に60%以上の購入プロセスを終えているといわれる今、マーケティングは、潜在ユーザーの行動を、事細かく、それも複数のシナリオに渡って把握する必要があります。例えば、オンライン出版社の経営者が、どのキーワードでオンライン広告を打てば、定期購読者数が増えるか知りたいと思います。その場合、以下のデータを一箇所に引っ張ってくる必要があります。

  1. オンラインメディア内での行動履歴:おそらく在り処を知っているのは、ウェブサイトを作ったエンジニアでしょう。ひょっとしたら、ロギングを怠っていて、データそのものがないかもしれません。データがあっても、場合によっては大きすぎて、そう簡単にはアクセスできなかったという話もよく聞きます。
  2. フェイスブック・ツイッターなどの広告出稿データ:要はCSVをダウンロードしてくるわけですが、タグの埋め込みを怠っていたり、間違ったページに見込み客を飛ばしていたりして、データ品質に難があったりというのは、公然の秘密です。
  3. セールスフォースなどの顧客管理システムのデータ:定期購読のデータなどはおそらく顧客管理システムに入っていることでしょう。このデータも必要です。アプリとしては触ったことがあるでしょうが、自動的にデータを取ってくるなんて、何をググっていいかわからない。ということでウィザードからのCSVエクスポートです。

たった3つと思うかもしれませんが、これでも一箇所に集めてきて、顧客ごとにデータを整形するのは非常にかったるい作業です。また、データ分析ツールの老頭Excelさんが、大小問わず全ての企業で、未だにご活躍されている、大きな理由でもあります。Excelさんは、データサイロからちょっとずつデータを取ってきて加工できる小さなバケツのようなもんです。便利ではありますが、本質的な解決ではありません。

では、どうやったらデータサイロ問題を解決できるのか?そこにトレジャーデータの新しい使い方があると思っています。

トレジャーデータはデータサイロのコネクタ

あらかじめ断っておきますと、データサイロはそう簡単にはなくなりません。なぜなら、データサイロは、便利なサービスの意図しない副産物だからです。たとえば、ウェブサイトのデータしかないGoogle Analyticsですが、顧客の動向を俯瞰するには最高のツールです。また、セールスフォースのように、ものによっては無くなってしまったら業務に支障が出てくるデータサイロもあります。

正しい解決方法は、「CSVによるダウンロードからのExcelさん」の代わりに

  1. 自動化された
  2. 大きなデータも扱える
  3. プログラミングしなくていい

データのパイプラインを作ることです。Excelさんを捨てろ、という話ではありません。ただ、Excelさんが得意ではない、顧客ログなどの大きなデータですとか、VLOOKUP的な作業の自動化、データのクレンジングができることが、マーケティングや販促がデータを活用できていくためには必要不可欠だと思っています。

そこでトレジャーデータの登場です。起業当初、クラウド上でデータウェアハウスを作っていた当社ですが、お客様のユースケースを見ていくうちに、うちはデータサイロを繋ぐ会社なんじゃないかと感じるようになりました。

データサイロをつなぎ、マーケターや販促のための顧客データウェアハウスを作ることは、エンジニアにとっても決して楽しい作業ではありません。彼らからしたら訳のわからん第三者システムのAPIを学ぶことは、大して意味ある知識ではないですし、何より作業そのものが非常にめんどくさいです。当たり前ですが、データサイロとなっていく第三者サービスたちは、貯蓄したデータを外に出されるのは嫌がるので、APIそのものが非常に使いにくかったりします。そんな作業を、社内のエンジニアさんに頼むのは気が引けますし、あんまりその手のお願いをしていると、嫌われることでしょう。

幸い、トレジャーデータには、各種コネクタがすでに揃っており、毎月2−3個新しいコネクタができています。技術的な詳細は省きますが、以下いくつかのユースケースを箇条書きで伝えます。

トレジャーデータ for マーケター・販促:使い方

1. セールスフォース+ウェブ閲覧ログ=購読停止を予防

定期購読系のメディアとかですと、どれだけ頻繁にサイトを訪れているか、何分滞在しているかみたいな数字を見ることで、その顧客が購読停止の危機にあるかわかるものです。営業さんからすれば常にチェックしておきたいデータですが、この手のデータはエンジニアたちが持っていて、なかなかセールスフォースには反映されていなかったりします。

そこで、トレジャーデータに行動ログを投げ込み、顧客IDごとにメトリックを集計、SFDC書き出し機能を使うことで、ほとんどエンジニアの手を借りずに、営業さんのための「顧客の見える化」を促進することができます。

2. ウェブ閲覧ログから価格分析→ダイレクトメールのカスタマイズ

商売をしている以上、商品の値段とかって非常に大事なはずなんですが、意外とマーケティング・販促部門の方で、細かい分析ができているという話を聞きません。個人的には、「一番役立つはずの、購入履歴ログが、エンジニアの手元にしかない」というのが原因だと思っています。1-2時間、エンジニアの手を煩わせることにはなりますが、いったんデータがトレジャーデータに流れるように設定してしまえば、

  1. どういう顧客が
  2. いつ
  3. いくらで何を何個買うか

みたいなデータが全部分析できるようになります。こういった分析をもとに、お中元やお歳暮、クリスマスセールといったキャンペーンのパラメータを選定できれば、販促効果は大幅にアップすることと思います。

各種メール配信ツールや、広告配信ツールとのつなぎ込みは、トレジャーデータ上では始まったばかりですが、2016年はコネクタ・事例共々に充実させていただきたいと思います。

さいごに

トレジャーデータはこれからも、エンジニアが楽ができつつ、かつエンジニアではない方も使えるようなサービスになっていくように精進していきます。

が、元データ分析屋のマーケターとして一つだけお願いが。プランナーや販促の方々もSQLを覚えてください。最初はとっつきにくい印象のあるSQLですが、覚えてしまうといろいろな分析が自分でできるようになり、PDCAのPとCが一人でできるようになり、大幅に仕事の効率がアップします。何もSQLマスターになる必要はありません。もし自分でできなければ、エンジニアたちにやり方を聞くのもありです。エンジニアにSQLの手助けを頼むにしても

✕「この数字とこの数字とこの数字を明日までに出して!」
○「この数字を出したくて、こういう風にSQL書いたんですが、これどこがオカしいか教えてもらえますか」

の2つでは大きな差があります。強力な分析ツールだけではなく、営業マーケティングとエンジニアリングの間の潤滑油となり得るSQL。覚えて損はありません^^