東京で働くグロースハッカーのブログ

東京で働く、グロースハッカーによるマーケティングに関する話がメインのブログ。

DDM(データ・ドリブン・マーケティング)とは何か

Binary

グロースハッカーが行う施策は データ・ドリブン であることがキーになります。データ・ドリブン・マーケティングとは何なのか？また、データ・ドリブン・ドリブンマーケティングの施策の例、さらにデータ・ドリブン・マーケティングの施策を進める際のデータの取り方について説明します。

データ・ドリブン・マーケティングって何？

これまでのような派手な発表イベントやプレスリリース、マスコミ報道のような、結果が予測しづらい一か八かのような施策ではなく、施策の進捗具合や成果が随時確認可能なものを用いて、常にデータを見ながら改善プロセスを回していくようなスタイルを指します。

これまでの施策でも、改善プロセスを回すこと自体は可能ですが、その改善プロセスのサイクルが長くなってしまいがちな部分があったかと思います。具体的には、何らかの発表イベントを実施する、となった際に、その発表イベントのための企画から準備、実施、効果測定とやっていくと、1ヶ月や2ヶ月といったサイクルになってしまいます。またここで効果測定を行ったところで、その効果が次の発表イベント（全く別のジャンルであったり別のターゲット・ユーザーに訴求する必要があることもある）でどれだけ活かすことができるかは明確ではありません。

グロースハッカーは、短いスパンで実施可能な施策であったり、繰り返し活用できる可能性の高い施策を中心に行います。具体的には1週間や2週間程度のスパンで、企画から準備、実施、効果測定ができる方法を使い、改善プロセスを回す回数を極端に増やすことに注力します。また、改善プロセスのスパンが少し長くなってしまうとしても、その内容が繰り返し活用できる可能性の高いものであれば、次のアクション・プランにつながるデータを随時取得しながら、軌道修正を行い、進めていきます。

データ・ドリブン・マーケティングの施策の例

  • Webサイトの改善
  • ランディング・ページの最適化(LPO: Landing Page Optimization)
  • エントリー・フォームの最適化(EFO: Entory Form Optimization)
  • Web広告のクリエイティブ
  • Web広告の配信ターゲット(キーワードや配信サイト)
  • ソーシャル・コミュニティ上での行動や発言
  • 見込顧客に対する定期メール
  • 見込顧客に対するダイレクトメール

どれも一度に多数のユーザーに対してアプローチできる手段が多く、さらにWeb技術に寄ったものが多く使われています。ただ、ここに挙げていないものであっても、 データを取り、そのデータを元に次のアクション・プランが立てられるような施策 であれば、それはデータ・ドリブン・マーケティングの施策の一例に含めていいと思います。

データ・ドリブン・マーケティングの施策を進める際のデータの取り方

これが正解！というデータの取り方は存在しません。 ただし、データを取得する際に考えなければいけないことはいくつか挙げることはできます。

次のアクション・プランにつなげるイメージができるデータを取得する

たとえ、どんなに細かく正確なデータを取得したとしても、その習得したデータが、次のアクション・プランにつながらないのであれば意味はありません。なので、 どういった項目をデータとして保持するか を決める段階で、合わせて、次のアクション・プランにどう繋がってくるかの仮設を立てる必要があります。また、この仮説は間違っていたら間違っていたで構わないと思いますし、仕方ないことです。たとえ、仮説が間違っていて、当初のアクション・プランのイメージと全く異なるものになりそうな場合であっても、 あとからデータを拡張できる形になっているか のおかげで、最悪の事態を免れることができます。

フォーマット

フォーマットは特に拘る必要はないかと思いますが、当然ながらデータが収集できたときに、どう分析するかを考慮に入れたフォーマットにする必要があります。なので、テキスト形式とかはやめておいたほうが無難です。まず最初は、ExcelやCSVのような表形式でデータを保持すれば、いろいろ他のアプリケーションから利用したりも可能なので無難かもしれません。 もし、関係するメンバーが全員技術者出身だったりする場合で、SQL系を利用できるようであれば、SQLデータベースに入れてしまってもいいかもしれません。

データ同士の関係性は妥当か

Excelのような表形式でデータを取得するケースを考えたときに、1行の単位を何にするかは注意を払う必要があります。そして指標を計測するdimensionとして使われる項目であった場合、正しく正規化できるかなどについても考えておく必要があります。 最初の準備段階で、最終的なアウトプットとなるデータをイメージしながら、取得するデータのフォーマットを設計するのがいいでしょう。最初のうちは、イメージだけでなく、適当なデータを入れてしまうとさらにいいでしょう。

あとからデータを拡張できる形になっているか

どれだけ精緻にデータのフォーマットを設計したとしても、実施するにつれてあとからデータを拡張したい、ということが発生します。これは、 最初の準備段階が疎かになっていた、とかではなく実際のデータを取得し始めると発生する仕方ないこと です。むしろこれを恐れて準備段階に必要以上の時間をかけてしまってはいけません。大切なことは、 あとからデータを拡張したい、となったときに拡張しやすい状態にしておくこと です。

具体的には自分たちが保持している情報資産にはどういったものがあるかを把握した上で、それらをVLOOKUPなりJOINなりをするためのキーとなる項目については可能な限り取得するデータに含めておくのがいいでしょう。例えば、ECサイトを運営し、登録ユーザ情報という情報資産を持っているとします。ここで、登録ユーザに対してメルマガを送信する、という施策を行うとします。このとき、施策のデータの中には、実施した登録ユーザを紐付けることができるようなキーとなる列を追加してあげることが必要です。その代わり、登録ユーザから一意に定まる情報（例えば、住んでいる都道府県や、年齢、学歴など）に関しては、施策のデータ内に保持する必要はなく、必要に応じて、登録ユーザ情報のマスタデータから引っ張ることができるようになります。

おわりに

ここでは実際の例などは何も出しておりません。次回以降、なんらかの例を出してみようかと思います。