なぜマーケターにSQLが必要なのか？

こんにちは。プリンシプルの木田です。

この2、3年、マーケターにとってSQLの重要性は増していると感じています。そして直近の1年くらい、マーケターにSQLを広める活動をしています。

マーケターにとってのSQLの必要性

以前、どこかでも書きましたが、マーケターにとってのSQLの必要性は、以下の通りにまとめられると考えています。

データが大型化しているので、エクセルやスプレッドシート、BIツール等で取り込むより先に「前処理」が必要になるシーンが増えている。いわゆる、データラングリングや、データハンドリングと言われる作業領域です。広い意味では、データウェアハウスから目的の分析に適した部分的なテーブルをデータマートとして切り出す作業も含まれてきます。
Google アナリティクスやGoogleサーチコンソール、Salesforce、Pardotなどのツールが提供してくれている「分析機能」では他の人より深いインサイトを得ることはできず、ツールが吐き出す生データを自分で分析する必要がある。私は最近、Google アナリティクスを直接操作する機会はずいぶん減っています。
Tableauやデータポータルを学ぶことでSQLが果たしている特定の機能をツールに肩代わりしてもらうことができるがSQLこそが最も汎用的なスキルである。（Tableauが入っていない会社はあるけれど、リレーショナルデータベースを使っていない会社はない）最近、私が行う分析も、まずはBigQueryにデータを上げてしまい、SQLで加工したテーブルを作り、その後、TableauやExploratoryからそのテーブルに接続することが標準的になっています。

一方、完全に私見ではありますが、

マーケターはSQLの利便性、その強力さを理解していないのではないか？

という懸念や、

SQLを知り、学び、使いこなすマーケターと、SQLを知らず、だから使えず、エクセルなど従来のデータ分析基盤でしか自分の業務を執行できないマーケターに二分されているのでは？

という懸念があります。

もし、そうだとすると、それには多少、無理からぬところがあります。

例えば、企業向けWeb解析ソリューションとして、Google アナリティクスとよく対比されるのが、Adobe Analyticsです。私はその存在は知っていますが、業務上では利用したことがなく、しっかり学んだことがなく、したがって使いこなせません。

Adobe Analytics偏差値のようなものがあれば、きっと50以下でしょう。

私の場合には、GA、AA二つのWeb解析ツールを学ぶのはコストとリターンの点で合わないと判断したからなのですが、こうした状態を「食わず嫌い」と言います。

つまり、SQLを使いこなしていないマーケターは「食わず嫌い」をしてるのではないでしょうか？

もし、そうであれば、食わず嫌いを解消していただくのに、実例を出すのが一番良いでしょう。

ミクロ分析（Google アナリティクスのユーザーエクスプローラのように、一人のユーザーをヒットベースデータで追いかける分析です）を、ページ閲覧動向だけでなく、イベント発生動向と合わせて行うことをやりたいと思います。

ウェブページでユーザーがどこまでスクロールしたかを、イベントとして取得していると、一人のユーザーのヒットベースデータは「ページビュー、イベント、イベント、ページビュー」のようにページビューとイベントが混在した状態になるはずで、それを統一的に可視化しようという試みです。

この分析を、以下の方針で行います。

Google アナリティクスのカスタムディメンションや、データポータルから、①ページビューのヒットベースデータと、②イベントのヒットベースデータをCSVファイルで取得します。
それらをBigQueryに2つの異なったテーブルとしてアップロードします。それらをBigQueryでSQLを使ってUNION（ゆにおん|テーブルを縦に伸ばす方向につなぎます）します。
結果をテーブルとして保存したものに、Tableauから接続します。

１のデータ：このような形になります。

BigQueryにアップロードし、テーブルを作成すると、スキーマは以下の通りになります。pageviewsテーブルという名前にしました。

２のデータ：このような形になります。

BigQueryにアップロードし、テーブルを作成すると、スキーマは以下の通りになります。eventsという名前にしました。

SQLで二つのテーブルをUNIONします。SQLは以下の通りとなります。

大したことではありませんが、工夫したところは以下です。

ウインドウ関数で、次の行のタイムスタンプを取得し、自分の行との差分を秒で表すことで、次のアクションまでの秒数を取得しています（2行目）
レコードがページビューだったのか、イベントだったのかを明示するために、固定のテキスト”PV”、もしくは”EV”を６列目に記録しています。（10行目と19行目）
UNIONはカラム数が同じでないと成立しません。pageviewカラムは1列で構成されていますので、3カラムにわたって記録されているイベントの属性を、イベントカテゴリ、アクション、ラベルを”-“で連結することで、1カラム化しています。（20行目）

結果テーブルは、以下のように、すぐに分析できそうな、なかなか美しいテーブルとなりました。