クラウドワークスマーケティングチームの安藤です。
クラウドワークス Advent Calendar 2018の11日目として、「マーケターがSQLを使ってデータ分析ができることの3つの効能」をお届けします。
#なぜこの話をすることにしたのか
今回、クラウドワークスアドベントカレンダー初参加のマーケティングチームですが、チームメンバー全員がSQLを使える、というのがちょっとした自慢ポイントです。
他社の方の話を聞くと全員がSQLを使える、というのは意外と珍しいようですので、今回はチームとしてSQLが使えるからこそのメリットをお伝えしようと思います。
#SQLのいいところ
SQLを使えることのメリットの話をする前に、
- そもそもSQLってなんですか？
- SQLの何がいいの？Google Analyticsでよくないですか？
という点についてお話したいと思います。
##SQLとは
Wikipediaによると、
SQL（エスキューエル[1][ˈɛs kjuː ˈɛl] ( 音声ファイル)、シークェル[1][ˈsiːkwəl] ( 音声ファイル)、シーケル[2]）は、関係データベース管理システム (RDBMS) において、データの操作や定義を行うためのデータベース言語（問い合わせ言語）、ドメイン固有言語である。
引用：「SQL」『フリー百科事典 ウィキペディア日本語版』。2018年11月6日 (火) 12:12 UTC、URL: http://ja.wikipedia.org
とのことです。
つまり、データベースを扱うための言語なわけですが、多くのマーケターが扱う場合には、データベースから必要なデータを取り出し、分析するための言語、として利用される場合が多いかと思います。
##Google Analyticsじゃだめなの？
Google Analytics（以下、GA）は便利ですよね。
手軽にアクセスができ、ユーザーのアクセス状況、経路などの分析が直観的に行え、弊社でももちろん利用しています。
ですが、GAにも限界はあると考えています。
GAでセッション以外の情報を取得するには、イベントトラッキング（やカスタムディメンション）を設定して計測を行っている必要があります。
裏を返すと、設定を行う以前の情報や、設定をしていない行動の計測はできないわけです。
また、セグメントなどである程度のカバーはできるものの、特定の行動をとったユーザーがその後どうしているのか？といった分析を詳細に行うのは難しい部分があります。
その点、SQLでは、蓄積されたデータベースの情報に直接アクセスできるため、例えば「会員登録からN日後のユーザーの継続ログイン状況」「仕事応募までに必要な仕事の閲覧数はどれくらいか」といったような、詳細な行動分析を行うことが（データさえとっていれば）比較的容易です。
ですので、弊社ではSEOで必要な分析や、大まかなアクセス状況の把握にはGAを利用しており、ユーザー行動の変化や、詳細な行動分析にはSQLを活用しています。
#SQLを使ってデータ分析ができる効能
##効能①：データ「分析」ドリブンになれる
データドリブンではまだ甘い。
これからはデータ分析ドリブンの時代です。（言いたかった）
データドリブンとは、
得られたデータをもとに施策決定や意思決定を行う
という、皆さまご存知のやつですね。
私が勝手に命名したデータ「分析」ドリブンとは、
得られたデータをもとに施策決定や意思決定を、その結果をどう分析し、次の意思決定に活かすか考えたうえで行う
というものです。
分析という行為は、「何を」知りたいのかを正確に定義することから始まります。
なので、データ「分析」ドリブンになるとは、
- 施策が「何を」狙っているのかを正確に言語化し、
- その目的をどのような指標で計測するかを決定し、
- その指標を計測して、次のアクションにどう活かすのか
を決めて施策を動かすということを意味しています。
これを行うことで、直接的なメリットとして次のような事態がなくなります。
- 施策をリリースしてから、「あの数字を見たかったけど、今からは見れないなぁ」となって正確な分析ができなくなる
- リリースした施策が、後から考えると様々な数値に影響を与える内容になっており、結局何が起きたのかわからなくなる
- 施策をどんどんリリースした結果、影響が混ざり合って結局何が起きたのかよくわからなくなる
これだけでも大きなメリットですが、副次的大きなメリットとして、
- 施策の影響範囲を正確に考えてからリリースするので、事前の考慮漏れが減る
- 施策が何を狙っているのかを言語化してからリリースするので、風呂敷の広げすぎが減り、施策を尖ったものにしやすくなる
という点があります。
例えば、最近マーケティングチームでは、利用者のプロフィール文章の入力例の改善をリリースしました。
小規模な改善ではありますが、この施策一つとっても、
- 入力例の利用率はどの程度なのか？
- 利用したユーザーのプロフィールは改善しているのか？
- 逆に似たようなプロフィールばかりになる、などの事態は発生していないのか？
など、様々な影響が考えられます。
その中で、何が本質で計測すべきものなのか？
そして、その指標をどのように計測可能な状態にしてリリースするか、を考えることで、施策の狙う本質まで考える癖がつきます。
この学びは、何を分析するかを自分で決め、自分でデータを抽出するからこその学びだと思います。
##効能②：アイデアが増える
異論はあるかもしれませんが、新しいアイデアとは既存の知識の組み合わせによって生まれると私は信じています。
要は、使える状態の情報をどれだけ保持しているか、がアイデアの幅を決めると思います。（それを引き出せるかは別の問題ですが）
さて、突然ですが皆さまは、自社のサービスに関わる「新しい切り口」のデータは1カ月にどれくらい見ているでしょうか？
1つでしょうか？
5つでしょうか？
私が、10月に新たに作成したクエリ（データ抽出用のSQL文）は18個でした。
他の月にも同様のペースで作成しており、平均すると月に20個のクエリを作成しています。
つまり、自分が作ったものだけでも新しい切り口でのデータを、月に20種類、 1年だと240種類、作成してインプットしているわけです。
もちろん、そのすべてを詳細に覚えているわけではありませんが、調べたという事実や印象的な傾向は覚えているものです。
常に新しい切り口でサービスを見て、そこから気付きを得られる、というのは自身でデータ抽出ができればこそのメリットだと思います。
##効能③：なんか楽しい
単純に楽しいです。
普段やらないコードを書く、という作業も楽しいですし、自分が見たいデータが即座に見られる、という結果にもワクワクします。
一つのデータを見ると、
「他の角度から見るとどうなのだろう」
「どうしてここの数字だけ大きく動くなんてことが起きるのだろう」
と非常に好奇心が刺激されます。
唯一の難点としては、ついついいろいろなデータを見てしまい、今すぐ必要がないものまで調べてしまうことがある、という点でしょうか。
#まとめ
いかがでしたでしょうか？
SQLはやってみると思った以上にカンタンにデータを扱えるようになります。
マーケターの役割は、広告やSEOなどの領域だけでなく、いかにデータを扱うか、という領域を中心に現在も、そして今後ますます多様性をもっていくことと思います。
データを扱うには、まずデータを知ることから。
ということで、社内の分析環境に触れられる方は、ぜひSQLでの分析を始めてみてください。