「マーケティングオートメーションとは」その３〜リード管理としての役割〜
はじめに
トレジャーデータはクラウドでデータマネージメントサービスを提供しています。
前回ではマーケッターが１つのプログラム（イベントやキャンペーンのことをMarketoではプログラムと呼びます。）を回す方法について具体的にご紹介しました。
ここまでの話だと，マーケティングオートメーションはマーケティングの効率化ツールとして捉える方も多いと思います。また「オートメーション」の意味を，たくさんのプログラムを楽に運用管理できるという所にあると捉える方も少なくないでしょう。
しかし，「マーケティングオートメーション」をそのように軽んじておられる人が多いとすれば，それは残念なことです。マーケティングオートメーションの神髄はリードの管理をスコアリングによって行う「リードスコアリング」にあります。今回は Marketo のリード管理に関するお話です（スコアリングの詳細は次回）。
マーケティングの役割と営業との関係
さて，リード管理の話をするならばその前にまずマーケティングの役割，および営業との関係を明確にする必要があります。
マーケティングの役割は，まず様々な手段によって自社の製品やサービスを認知させるところから始まります。その取り組みの中で得られた見込み顧客（ここでの見込みとは，自社が認知され，匿名ではなく名前およびメールや電話の通信手段が得られている全ての個人を指します）を，育成プログラム（リードナーチャリング）を通じてモチベーションを高め，適切なタイミングで見込みの高いをリードを営業に渡すところにあります。
上図のファンネルは，マーケティング側のリードナーチャリングを経て，営業が引き継いで顧客獲得を果たすまでを表しています。ここでSDR（ Sales DevelopmentRepresentative ）とは，
マーケティング･営業プロセス業務上の責任範囲こそ限定されてはいるものの、その2つを繋ぎ、会社の売上を最大化するために必要なミッションを担うのがマルケトのインサイドセールス(SDR)です。
と定義されています。（以下の図もこの引用先のブログよりお借りしました。）
マーケティングは様々なプログラムを施策することで，見込み客を次のステージへ進める様々な活動を実行，管理しています。前回までの話は，マーケティングオートメーションがこの活動を最大限効率化するものとして紹介していました。その中での「資料ダウンロードプログラム」の例も，「Awareness」や「Friend」から「Name」や「Engaged」へとステージを進める一つの例に過ぎないのです。
さて，このようなマーケティング主導で管理されるリード情報（見込み客についての「何（デモグラ）を知っているか」「どのステージ（スコア）にいるのか」といった情報）はどこで管理するのが適切でしょうか？もしマーケティングオートメーション自身がリード管理ツールとなっていてくれれば、これほど最適なことはありませんね。
マーケティングオートメーションのリード管理とは，CRMとの違いとは
「リード管理」と言えば，Salesforce.com のようなCRMツールがすぐに思いつきますが，マーケティングオートメーションの定義する「リード管理」とは，CRMのそれとは多少異なってきます。異なるというよりも，CRMを補完するツールと呼んだ方が正しい言い方の様に思われます。その違いですが，
- 誰がメインで更新するか
- リードステータスの更新頻度
- 顧客のステータスを表す尺度
といったものが挙げられます。
1. 誰がメインで更新するか
- CRMツールにおいては各営業が現在の商談状況を管理し，全体に共有します。故にCRMのリード管理は完全に営業側に依っています。
- マーケティングオートメーションでは，マーケティングにおけるリード＝見込み客は常にマーケット側（とマーケティングオートメーションツール自身）によって管理される事になります。
2. リードステータスの更新頻度
- CRMにおいては，現在のリードのステータス（進捗）更新頻度は，営業が電話やMTGなど，実際に顧客とのコミュニケーションが生じる度に更新されます。1日に何件もリードを前に進めることはできませんので，更新頻度は日次や週次などにとどまります。また，CRMでは顧客のステータスがやみくもに変化することを好みません。更新が多ければ上司や他の営業がその状況を把握しにくくなるためです。
- マーケティングオートメーションでは，無数にし込められた様々なプログラムに見込み客が接触することで見込み客のステータスが更新されます。例えば資料の閲覧やブログの購読など，営業側で見えない見込み客の，主にネット上でのアクティビティをマーケティングオートメーションは補足します。それ故にリードステータスの更新頻度はCRMに比べて遙かに多くなります。
3. 顧客のステータスを表す尺度
- CRMではリードの進捗状況を「10%（1st MTG），30%（技術バリデーション），...，80%（後は予算の摺り合わせのみ）」といった，%などで管理するのが通例です。また，13%，77%といった区切りの悪い数値は使用しません。これは人間がその数値を見てすぐに状況を理解することに効率化されているからです。
- 頻繁にステータスが更新されるマーケティングオートメーションでは，見込み客のステータスを「スコア」で管理します。また，スコアにも「Behavier Score」や「Demographic Score」の他，自由に追加可能で，かつ取り得る値も17や256といった区切りの悪い数値もとりうります。マーケティングオートメーションでは，複数のスコアからなるモデル式を利用して，しかる値まで達した際には，自動的に「営業へ出動要請が必要リード」としてマーケティングと営業に通知します。そのスコア自身を人間がそのまま参照するような機会はそれほど多くありません。
Salesforce と Marketo 間によるリード情報のSync
また，CRMとマーケティングオートメーションがリード管理において互いに補完関係にあるという事は「Salesforce」と「Marketo」がパートナーシップを組み，互いに情報を同期することができるという事実からも明らかです。
「 リードスコアリング 」がマーケティングオートメーションの「肝」
さて，ここまでの話でマーケティングオートメーションの最も重要な部分は「リードスコアリング」にあることに気づいたと思います。この「リードスコアリング」には明確な答えもガイドラインもありません。
それぞれの会社のマーケティングと営業とデータ分析者による無数の試行錯誤によってスコアリングロジックが成熟され，やがてはそれが顧客の成約率というダイレクトな数字に表れてきます。
次回はMarketo の「リードスコアリング」について説明していきます。そろそろトレジャーデータも登場するかもしれません。
（新機能）「Data Connector for Amazon S3」によるデータロード革命
はじめに
トレジャーデータでは，あらゆるデータソースにリーチするデータ収集ツールを用意していますが，新しい収集機能として「Data Connector」を順次リリースする予定です。
↑ 従来の収集ツールに関しては過去記事をご覧下さい。
何が新しいのか？
さて，今回紹介する「Data Connector for Amazon S3」はその名の通り，Amazon S3上のデータをトレジャーデータに設定のみで「バルクデータロード」する機能です。この機能は先日オープンソースとしてリリースされた Embulk をベースにしたものです。
Embulk については以下の過去記事をご参照ください。
従来の Bulk Import 機能は「Client to Server」型
従来のトレジャーデータの「バルクインポート」機能は，クライアント上の巨大なデータに対して，トレジャーデータへ安全かつ効率良く実行するものでした。
しかし，もしインポート対象のデータがS3やHDFSといったサードパーティツール上にある場合は，まずはそこからクライアントサーバーへダウンロードしてからバルクインポートする必要がありました。また，ダウンロードからインポート完了までの「人」と「サーバー」のリソースが必要でした。
Data Connector は「Server to Server」型
Data Connector はこのクライアント側の悩ましい処理をトレジャーデータが「ホスティング」することで代替します。クライアントサイドからはコマンドだけ実行したら後は放置してマイグレーションが完了するのを待つだけになります。
トレジャーデータではこの Server to Server 型の処理を「Data Connector」と名付け，まずは Amazon S3 から，順次データソースをプラグインとして拡張して行く予定です。
Embulk の思想を受け継ぐ Data Connector は，あらゆるインプットをプラグインによって増やすことができます。
チュートリアル
それではチュートリアルを行っていきましょう。現時点では管理コンソールではなく，コマンドラインからの実行となることをご理解ください。参照源はこちらです。
Data Connector for Amazon S3 | Treasure Data
Step0：データの準備
今回は以下の内容の購買履歴ログが，
以下のバケット名で Amazon S3 に置かれていると仮定します。
Step1：Seed Config File (seed.yml) の作成
Data Connector 実行の第一歩は Seed Config File に「ソース源」と「ソースファイル」を指定するところから始めます。
Step2：Guess Formart in the File (load.yml)
次にこの seed.yml をS3に問い合わせを行い，取得したヘッダー情報を load.yml に保存します。guess コマンドによって以下の情報が書き込まれました。
guess コマンドの後は必ず load.yml を開き，内容に間違いが無いかをチェックして下さい。guess コマンドは非常に優秀ですが，人間の方でも今どのようなファイルをバルクロードしようとしているのかをチェックする意味でもチェックは重要です。
Step3：Preview
次に preview コマンドで，トレジャーデータに格納されることになるレコードの先頭を確認します。
Step4：Execute Load Job
あとは以下のコマンドを実行して放置するだけです。
コマンド実行後は，他のクエリと同じように Job ID が発行され，管理コンソール上からjobの進捗確認ができます。
おわりに
さて，いかがでしょうか？思ったよりも簡単だと思いませんか？そして，この機能がFTPやSFDC，HDFS，RDBMS，オンプレに対しても行えるようになると素晴らしいとは思いませんか？
パブリックリリースまでしばしお待ち下さい。
