クラスターごとに特徴量を集計。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いた会員のクラスタリングを試みていますが、前回「BigQuery ML 試し打ち #03」でモデルの作成まで完了したので、今回はモデルの可視化と予測結果の出力を行います。

可視化するには、クラスターと特徴量のクロス集計表にする必要があります。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。このクエリ結果をデータセット「DE」に「sum_clusters_bqml」という名前で保存します。

モデルを可視化する。

「sum_clusters_bqml」テーブルをTableauで可視化します。クラスターIDを［行］、各説明変数を［列］シェルフにそれぞれ設定すると、以下のようなビューが表示されます。

クラスターごとの特徴を見ると、クラスターID:6は女性のみ、平均年齢は30歳程度、主に「エレクトロニクス・コンピューター」を購入しているセグメント、クラスターID:9は男性80%、平均年齢は40歳程度、主に「本・聞く本」「映画・音楽・ゲーム」「エレクトロニクス・コンピューター」を購入しているセグメント、などがわかります。また、年齢についてもクラスターごとにばらつきがあり、クラスターID:2は年齢層がやや高め、クラスターID:10は年齢層がやや低めなどの特徴があります。これらは「クラスター分析入門」で見られた特徴とは異なることがわかります。

どのクラスターかを予測する。

続いて、作成したモデルを使って、特定の特徴をもつ会員がどのクラスターに分類されるかの予測を行い、結果を出力します。それにはBigQuery MLで用意されているML.PREDICTという関数を使用し、以下の構文で記述します。

SELECT 出力したい変数
FROM ML.PREDICT(
  MODEL モデル名
  , (
    SELECT *
    FROM 機械学習用データテーブル
    WHERE 予測対象の会員の条件
  )
)

ではまず、男性で「本・聞く本」「映画・音楽・ゲーム」「エレクトロニクス・コンピューター」の購買経験がある会員がどのクラスターに分類されるかを予測します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

この結果から、すべての会員がクラスターID:9として予測されることがわかります。これはさきほど可視化したモデルと完全に一致します。

続けて、女性で「エレクトロニクス・コンピューター」の購買経験がある会員がどのクラスターに分類されるかを予測します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

この結果から、約90%の会員がクラスターID:6として予測されることがわかります。これはさきほど可視化したモデルとほぼ一致しますが、残りの約10%の会員がクラスターID:2として予測されています。それらの会員の特徴を見ると、比較的年齢の高い会員が多いように見受けられます。これはモデルの可視化結果で見た、クラスターID:2の年齢層がやや高めという評価と一致します。

そこで、年齢を20代から40代に限定した場合に、会員がどのクラスターに分類されるかを予測します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

この結果から、すべての会員がクラスターID:6として予測されることがわかります。これはさきほど可視化したモデルと完全に一致します。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いた会員のクラスタリングを試みをしましたが、BigQuery上で完結して簡単に実現できることがわかりました。現時点で扱えるモデルは線形回帰・ロジスティック回帰・k 平均法クラスタリングのみですが、今後は協調フィルタリングやTensorFlowを用いたディープニューラルネットワークなど扱えるモデルも増えていくことが予定されているので、期待して待ちたいと思います。

SQLによるクラスタリング。

BigQuery MLは、Googleが提供するデータウェアハウス（Data Warehouse：DWH）であるGoogle BigQuery上にて機械学習（Machine Learning：ML）を可能とするクラウドサービスです。最大の特徴は、モデルの作成から評価や予測までをBigQueryと同様の標準SQLによるクエリ形式で行う点です。これにより、データの準備を含めた機械学習のすべてのプロセスをBigQuery上でSQLのみで完結することが可能となり、作業効率やセキュリティの面で大きなメリットが得られます。

前回の「BigQuery ML 試し打ち」ではロジスティック回帰モデルを用いて、総合ECサイトの会員の継続予測を行いました。今回は先日ベータ版がリリースされたk平均法クラスタリングのモデルの試し打ちがてら、例によって「データエスノグラフィ入門」と連動し、総合ECサイトの会員のクラスタリングを行なってみようと思います。

なお、同じテーマを「クラスター分析入門」で扱っており、クラスター分析（Cluster Analysis）あるいはクラスタリング（Clustering）とは何か、階層型と非階層型の違いは何かなどの詳細はそちらに詳しいので、ここでは省略します。また分析ツールについては、そこではGoogle Cloud Datalabを用いましたが、ここではBigQuely MLを用いるため、どちらも試しながら両方の違いを検証するのもよいでしょう。

機械学習用のデータと環境を準備。

それではBigQuery MLを用いたクラスタリングを始めましょう。分析を進める前に、まずは分析の背景と目的を整理します。

あなたは、とある総合ECサイトの責任者です。ECサイトでは、F2転換率が重要であると言われています。この”F”は購買頻度（Frequency）のことで、F2転換率とは初回購買から二回目購買への転換率（Conversion Rate）を意味します。一般的に、新規会員の獲得よりも、既存会員のリピート購買促進のほうがコスト効率が高いため、F2転換率は重要な指標となります。とはいえF2転換した会員が、その後も継続的に購買してくれる、いわゆる優良会員になるとは限りません。

そこで今回の分析目的を「優良化する会員の行動特性を、購買履歴データから把握する」とします。なおそこには、まだ優良化していな会員を意図的に優良化するためのヒントがあることは言うまでもありません。

分析対象データは、とある総合ECサイトの会員の購買履歴データとし、概要は以下のとおりです。

• 種類：総合ECサイトの会員の購買履歴
• 期間：2005年1月〜2013年12月（9年間）
• 会員数：639,777人
• 購買数：7,599,650件（平均11.9件/人）

データソースは以下の３つを使用します。なお、こちらはすでにBigQueryに投入済みとします。

行動特性の分析を進める中で、購買商品カテゴリ数と優良化との間に相関があることがわかりました。（※「データエスノグラフィ入門 #04」を参照）これは、新たな商品カテゴリを提案することが優良化につながる可能性を示唆しています。ただし、闇雲に提案するよりも、類似する会員セグメントの併売傾向と照らし合わせ、未購買商品カテゴリを提案するほうが効果が高いと考えられます。そこでクラスター分析によりそれを明らかにします。

まずはクラスタリングに用いる説明変数を定義します。説明変数を定義することを変数選択や特徴選択といいますが、非常に難しい問題なので、ここでは深く触れず、ひとまず「性別・年齢・購買商品カテゴリ」とします。

なお、クラスタリングにおいて強い相関をもつ変数の存在は冗長で無意味であり、予めどちらかを除外する必要がありますが、これらの各変数間に相関性が見られないことは確認済みとします。（※「クラスター分析入門 #02」を参照）

次にクラスタリング用のデータを用意するわけですが、ここでひとつ前処理が必要になります。クラスタリングでは要素間の距離を類似度とみなすことで類似性を分析するのですが、距離を測定するためには変数が数値化されている必要があります。しかしながら、性別や購買商品カテゴリは質的変数であるため、そのままでは数値として扱うことができません。そこでダミー変数（Dummy Variable）に置き換えます。また、年齢は量的変数であるため、説明変数として扱うことが可能ですが、クラスタリングに使うには他の説明変数と値の範囲を揃える必要があります。そこで正規化（Normalization）を行います。ダミー変数と正規化については「クラスター分析入門 #02」に詳しいので省略します。

以上を踏まえ、クラスタリング用のデータを以下のスキーマ定義で作成します。

この定義に従ってBigQueryで分析用のテーブルを作成します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。このクエリ結果をデータセット「DE」に「sum_members_cls_ non」という名前で保存します。これで分析用のデータと環境は整いました。

モデルを作成する。

データの準備が整ったので、クラスタリングを進めて行きます。まずはモデルの作成を行います。モデルの作成には、BigQuery MLで用意されているCREATE MODELという関数を使用し、以下の構文で記述します。なおクラスタリングは教師なし学習のため、正解を示す目的変数は存在せず、また訓練データと評価用データに分割する必要はありません。

CREATE OR REPLACE MODEL データセット名.モデル名 
OPTIONS( 
  model_type = 使用するモデリングタイプ
  ,num_clusters = クラスター数
  ,standardize_features = 真偽値
) AS (
  SELECT 説明変数, ...
  FROM 機械学習用データテーブル
)

［model_type］にはk平均法クラスタリングを示す［kmeans］を指定します。クラスター数を指定するオプションの［num_clusters］には妥当性が確認されているである10を指定します。（※「クラスター分析入門 #03」を参照）また、［standardize_features］は正規化を行うかどうかのオプションで、すでに処理済みですがTRUEを指定しておきます。なお、初期設定はTRUE であるため省略可能です。

BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。なおこのクエリ結果はデータセット「DE」に「mdl_members_cls」という名前で自動的に保存されます。

これでモデルの作成は完了です。次回は作成したモデルの可視化や予測結果の出力を行います。

モデルを評価する。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いて、一年間の購買傾向から、翌年も継続して購買する会員を予測するという試みをしていますが、前回「BigQuery ML 試し打ち #01」で予測モデルの作成まで完了したので、今回はモデルの評価と予測結果の出力、さらに重みの分析を行います。

まずは予測モデルの評価を行いますが、それにはBigQuery MLで用意されているML.EVALUATEという関数を使用し、以下の構文で記述します。

SELECT * 
FROM ML.EVALUATE(
  MODEL モデル名
  , (
    SELECT 目的変数, 説明変数, ...   
    FROM 機械学習用データテーブル
    WHERE 評価データを指定
  )
)

モデル作成時と同様、目的変数は列名を「label」で指定するルールのため「retention」をそれに置き換えます。説明変数には「性別・年齢・購買商品カテゴリ・購買頻度・購買金額」を指定するため、それ以外は除外します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、クエリ結果に以下のような表が出力されるかと思います。

これらの項目と値の意味を簡単に解説しますが、その前に二項分類の予測と結果のマトリクスについて理解をしておく必要があります。それは以下の表で整理できます。

• 真陽性：TRUEの結果を正しくTRUEと予測
• 真陰性：FALSEの結果を正しくFALSEと予測
• 偽陽性：FALSEの結果を誤ってTRUEと予測
• 偽陰性：TRUEの結果を誤ってFALSEと予測

このマトリクスを基に、評価結果の［precision］［recall］［accuracy］［f1_score］の各項目の意味を以下のように説明することができます。またそれぞれの値は0から1の実数となり、1に近くほど精度が高いことを意味します。

すなわち今回の予測モデルの評価結果としては、正解率は77%であり、TRUEと予測したものが結果としてTRUEであった確率を示す適合率は89%と非常に高いものの、結果が TRUEであるものを正しくTRUEと予測した確率を示す再現率は50%に止まった、ということになります。

継続か否かを予測する。

続いて、作成した予測モデルを使って、評価データに対する「継続か否か」の予測を行い、結果を出力します。それにはBigQuery MLで用意されているML.PREDICTという関数を使用し、以下の構文で記述します。

SELECT 出力したい変数
FROM ML.PREDICT(
  MODEL モデル名
  , (
    SELECT *
    FROM 機械学習用データテーブル
    WHERE 評価データを指定
  )
)

構文としては評価の場合とおおむね同じですが、機械学習用データテーブルから抽出する項目には、最終的に出力したい変数を含めておく必要があります。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、以下のスキーマのテーブルが出力されます。レコードは会員ID単位で、predicted_labelが予測結果となります。predicted_label_probs.probは真偽それぞれの予測の確からしさの値であり、高いほうが予測結果として選択されます。

重みを分析する。

最後に重みの分析を行います。重み（Weight）とは結果の決定に対する影響力のことであり、それが大きい説明変数がわかれば、意図する結果を再現しやすくなります。機械学習の目的は、予測結果を導出することでもありますが、重みの大きい説明変数を発見することでもあります。それにはBigQuery MLで用意されているML.WEIGHTという関数を使用し、以下の構文で記述します。

SELECT * 
FROM ML.WEIGHT(
  MODEL モデル名
  ORDER BY ABS( weight ) DESC
)

BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、クエリ結果に以下のような表が出力されるかと思います。

重みは、正の場合は値が大きいほど、その変数が目的変数の真値への影響力が強く、逆に負の場合は値が小さいほど、目的変数の偽値への影響力が強いことを意味します。この結果から、やはり購買金額（Monetary）と購買頻度（Frequency）が目的変数の真値への影響力が強い、すなわち購買金額や頻度が高い会員ほど継続する可能性が高いことがわかります。逆に年齢（Age）が目的変数の偽値への影響力が強い、すなわち年齢が高い会員ほど離反する可能性が高いことがわかります。

BigQuery MLと総合ECサイトの会員の購買履歴データを用いて、一年間の購買傾向から、翌年も継続して購買する会員を予測するという試みをしましたが、BigQuery上で完結して簡単に実現できることがわかりました。現時点で扱えるモデルは線形回帰・ロジスティック回帰・k 平均法クラスタリングのみですが、今後は協調フィルタリングやTensorFlowを用いたディープニューラルネットワークなど扱えるモデルも増えていくことが予定されているので、期待して待ちたいと思います。

SQLで機械学習。

BigQuery MLは、Googleが提供するデータウェアハウス（Data Warehouse：DWH）であるGoogle BigQuery上にて機械学習（Machine Learning：ML）を可能とするクラウドサービスです。最大の特徴は、モデルの作成から評価や予測までをBigQueryと同様の標準SQLによるクエリ形式で行う点です。これにより、データの準備を含めた機械学習のすべてのプロセスをBigQuery上でSQLのみで完結することが可能となり、作業効率やセキュリティの面で大きなメリットが得られます。

現時点で扱えるモデルは線形回帰・ロジスティック回帰・k 平均法クラスタリングのみですが、扱えるモデルは今後増えていくことが予定されています。

ベータ版リリースから一年近くが経過しており、いまさら試し打ちというのも変ですが、一般提供されたのを受けて、復習もかねてその触り心地をまとめておきます。それではBigQuery MLを用いた機械学習を始めましょう。

今回は「データエスノグラフィ入門」と連動し、総合ECサイトの会員の継続購買の予測を行うという設定で進めます。分析対象データは、とある総合ECサイトの会員の購買履歴データとし、概要は以下のとおりです。

• 種類：総合ECサイトの会員の購買履歴
• 期間：2005年1月〜2013年12月（9年間）
• 会員数：639,777人
• 購買数：7,599,650件（平均11.9件/人）

データソースは以下の３つを使用します。なお、こちらはすでにBigQueryに投入済みとします。

これらのデータを使用し、2012年の一年間の購買傾向から、2013年も継続して購買する会員を予測してみます。

機械学習用のデータと環境を準備。

分析を進める前に、まずは分析手法を決めます。売上や継続率などの数値予測の場合は線形回帰（Linear Regression）を用いますが、「継続か否か」のような二項分類の場合はロジスティック回帰（Logistic Regression）を用います。

また、予測対象の変数を目的変数（Objective Variable）といい、今回は「継続か否か」がそれになります。その結果を決定づける原因となる変数を説明変数（Explanatory Variable）といい、機械学習では特徴量（Feature Value）とも言います。説明変数は無数に存在しますが、結果の決定に対する影響力を重み（Weight）といい、重みの大きい説明変数がわかれば、意図する結果を再現しやすくなります。機械学習の目的は、予測結果を導出することでもありますが、重みの大きい説明変数を発見することでもあります。

説明変数を定義することを変数選択や特徴選択といいますが、非常に難しい問題なので、ここでは深く触れず、ひとまず「性別・年齢・購買商品カテゴリ・購買頻度・購買金額」とします。なお、集計期間は2012年の一年間とします。

次に、BigQueryで機械学習用のテーブルを用意します。必要なのは会員IDごとの集計データで、そこに目的変数と説明変数を含めます。さらに、訓練データ（Training Data）でモデルを作成し、評価データ（Evaluation Data）でモデルを評価するというプロセスを踏まえるため、データをその二つに分割します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。また、このクエリ結果をデータセット「DE」に「sum_members_ret」という名前で保存します。

なお、処理の効率化のために10%のサンプリングをしていますが［※1］、これは会員IDを10で割った剰余が0の場合に限定するという意味です。また、欠損を除外するために性別がNULLでない会員に限定し［※2］、年齢の異常値を除外するために10歳以上90歳未満の会員に限定しています［※3］。さらに、集計期間中の購買がない会員を除外しています［※4］。

SQL内の「retention」が、目的変数である「継続か否か」を指す変数で、最終購買日が2013年以降の会員の場合のみ継続を意味する「TRUE」を、それ以外は離反を意味する「FALSE」を設定します。また「evaluation」が、訓練データと評価データを切り分ける変数で、90%が訓練データ、10%が評価データになるようランダムに振り分けます。もともと10%のサンプリングを行なっているため、会員IDを100で割った剰余が0の場合を評価データとして「TRUE」を、それ以外は訓練データとして「FALSE」を設定します。

ちなみに、説明変数に購買頻度（Frequency）や購買金額（Monetary）は含めますが、最終購買日（Recency）は含めません。これは、目的変数である「継続か否か」自体が最終購買日を基準に定義されるためです。これを含めてしまうと、当然ながら予測精度は自動的に100%になります。

モデルを作成する。

データの準備が整ったので、機械学習を進めて行きます。まずは「継続か否か」の予測モデルの作成を行います。モデルの作成には、BigQuery MLで用意されているCREATE MODELという関数を使用し、以下の構文で記述します。

CREATE OR REPLACE MODEL データセット名.モデル名 
OPTIONS( 
  model_type = 使用するモデリングタイプ
) AS (
  SELECT 目的変数, 説明変数, ...
  FROM 機械学習用データテーブル
  WHERE 訓練データを指定
)

［model_type］にはロジスティック回帰を示す［logistic_reg］を指定します。目的変数は列名を「label」で指定するルールのため「retention」をそれに置き換えます。説明変数には「性別・年齢・購買商品カテゴリ・購買頻度・購買金額」を指定するため、それ以外は除外します。

BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。なおこのクエリ結果はデータセット「DE」に「mdl_members_ret」という名前で自動的に保存されます。

これでモデルの作成は完了です。次回は作成したモデルの評価や予測結果の出力、さらに重みの分析を行います。

データエスノグラフィ環境を構築。

それでは、BigQueryとTableauによるデータエスノグラフィの環境を構築し、会員ランクごとに行動データを観察していきます。なお、BigQueryとTableauの使い方については「BigQueryではじめるSQL」「TableauではじめるBI」を参照してください。

まずは分析用テーブルを作成します。観察したいのは一人ひとりの購買履歴なので、前回とは違い、会員IDではなく購買履歴ごとの行を持つテーブルを作ります。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

すると、以下のスキーマのテーブルが出力結果で表示されるので、それをデータセット「DE」に「sum_orders」という名前で保存します。なお、フィールド名の頭に「Axx」などのアルファベットと数字を付与していますが、これはTableauのビューでデータの内容を確認する際に用いる［データの表示］画面のフィールドの並び順が、フィールド名のアルファベットと数字の順序になるため、スキーマ定義のとおり意図的に並べたい場合はこのように命名しておく必要があるからです。

続いて、テーブル「sum_orders」をTableauに取り込んで分析します。Tableau Desktopであれば、スタート画面の［接続］にあるメニュー［Google BigQuery］から選択するだけでシームレスに連携できます。Tableau Publicであれば、GCS（Google Cloud Storage）経由でCSVファイルとしてエクスポートしてから取り込みます。

ワークシート編集画面で「A00_member_id」を［行］、「C01_frequency」「C02_monetary」を［列］、「C00_rank」を［フィルター］と［色］に、それぞれドラッグ＆ドロップすると、データエスノグラフィ環境の構築は完了です。

一人ひとりの行動データを観察。

では会員ランクごとに一人ひとりの購買履歴を観察していきましょう。まずはF1会員から見て行きます。右上の「C00_rank」フィルタで「4: F1」を選択し、ビュー内に表示される会員IDをF1会員のみに絞り込みます。その中から無作為に抽出してそれぞれの購買履歴を観察するわけですが、それには各会員の行をクリックした際に表示されるポップアップの右上にある［データを表示］ボタンをクリックします。すると［データを表示」という画面がモーダル表示されるので、画面下の［すべてのデータ］をクリックすると、選択した会員の購買履歴を見ることができます。

選択した会員の購買履歴がこのように表示されます。当たり前ですが、F1会員は初回購買の購買履歴しかありません。

では続けてF2会員を観察します。「C00_rank」フィルタで「3: F2」を選択し、F2会員に絞り込んで無作為に何人かを見て行きます。するとどうでしょうか。初回購買から二回目購買までの期間が何ヶ月も空いている会員が意外と多い印象を受けるのではないでしょうか。

続けてF3会員・優良会員についても観察します。するとやはり、初回購買から二回目購買までの期間が長い会員が多いように思います。さらに、3回目購買から定着化し、比較的コンスタントに購入していることがわかります。

さらに、優良会員は比較的多くの商品カテゴリを購買していることに気づきます。長期間にわたり何度も購買しているため必然的にカテゴリ数が増えているだけかもしれませんし、何でもECサイトで買うタイプが総合ECサイトを継続的に利用しているだけかもしれません。ただ、いずれにせよ相関はありそうです。

ここまでの行動データ観察による発見を通して、二つの仮説が浮かび上がります。

1. 初回購買後に休眠化した会員についても優良化するポテンシャルがあるのではないか
2. 新たな商品カテゴリを提案することが優良化につながる可能性があるのではないか

これらの仮説をもとに、データの深掘分析やA/Bテストによる実証実験を行うことで、まだ優良化していな会員を意図的に優良化するためのヒントが得られる可能性があります。一方で、観察した一部の会員だけに見られる特徴である可能性も否定できず、もしそうなら、この仮説の検証に意味はありません。そこで代表性の検証を行います。代表性（Representativeness）とは、調査対象者全体の中から抽出された一部の対象者の調査結果が、調査対象者全体の結果を、偏りなく正確に反映出来ているかどうかのことです。

その発見に代表性はあるか。

代表性検証のための分析テーブルを作成します。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしましょう。

このクエリ結果をデータセット「DE」に「sum_members_rep」という名前で保存します。このテーブルから以下の結果が得られます。

• 休眠会員（初回購買から91日以上購買がない会員）：78.6%
• そのまま離反する会員：64.7%（休眠会員の82.3%）
• 復帰してF2転換する会員：13.9%（休眠会員の17.7%）
• 復帰してF3転換する会員：7.7%（休眠会員の9.8%）

初回購買から91日以上購買がない会員を休眠会員とすると、80%近くが休眠会員となるものの、そのうちの20%近くが復帰し、10%近くがF3転換していることになります。逆に休眠会員の80%近くがそのまま離反しており、大きなポテンシャルがあることがわかります。とはいえ下図のとおり休眠期間が長くなるほど優良化率が下がるため、早いタイミングでの復帰促進が望ましいようです。

さらに下図のとおり、購買商品カテゴリ数と優良化には明らかな相関があることがわかります。

これらの分析結果は、さきほどの二つの仮説が正しいことを証明するものではありません。ただ、その発見には代表性があり、データの深掘分析や実証実験を行うことに意味があることを示唆しています。

また、購買商品カテゴリ数には優良化との明らかな相関があるため、結果との相関が強いサブセグメントに指定し、8以上に絞って改めて行動データ観察をするのもよいでしょう。

このようにデータエスノグラフィは、一人ひとりの行動データをミクロ視点で観察することで、行動の実態を把握し、意図した結果に導くためのヒントが得られる手法であることを理解してもらえたのではないかと思います。

観察すべきセグメント。

データエスノグラフィは、一人ひとりの行動データをミクロ視点で観察し、時系列に追うことで、ユーザーの意思決定プロセスの理解や発見を行う手法です。とはいえすべてのユーザーの行動を観察するわけには行きません。そこで、似たユーザーをセグメント（Segment）に分類し、観察すべきセグメントを選定する必要があります。

では、観察すべきセグメントとはいったい誰でしょうか。ここで再び分析目的に立ち戻ります。今回の分析目的は「優良化する会員の行動特性を、購買履歴データから把握する」でした。

優良化の要因となる行動特性を把握するには、優良化している会員と優良化していない会員との間に存在する違いを比較観察すればよいことになります。すなわち因果推論（Causal Inference）¹⁾いまさら聞けない因果推論でいう疑似実験（Quasi Experiment）を行うわけです。

とはいえ、優良かどうかのみでは範囲が広すぎるため、もう少し絞り込みたいところですが、それには結果との相関が強いサブセグメントが有効です。例えば、優良化と高齢者の相関が強ければ、高齢者同士で比較すれば違いを発見しやすくなるはずです。これは疑似実験におけるマッチング法と同じ考え方です。

まとめると、以下の二つの軸で分類していけばよいことになります。

• 優良会員と非優良会員のセグメント
• 優良化との相関が強いサブセグメント

まず優良会員と非優良会員の分類が必要ですが、詳細はさておき、以下のように分類します。

結果との相関が強いサブセグメント。

続いて、優良化との相関が強いサブセグメントを探ります。これには大きく、検証的アプローチと発見的アプローチの二つがあります。

検証的アプローチ（Verifying Approach）は、二つの事象間の相関が仮説として想定されるものについて事実を検証していくアプローチで、質的変数であればクロス集計（Cross Tabulation）、量的変数であれば散布図（Scatter Plot）などの手法を用いて分析します。今回の場合でいうと、特定の性別や年代、あるいは購買商品カテゴリなどの変数と優良化との間に相関があるのではないかという仮説をたてて検証していきます。

一方で、人の行動を決定づける要因は無数にあるため、優良化につながる思わぬ要因が潜んでいる可能性がありますが、検証的アプローチでそれを見つけることはできません。そこで多くの変数をもつデータから、二つの事象間の相関を機械的に取り出すアプローチが有効となります。それを、発見的アプローチ（Discovering Approach）といい、主にアソシエーション分析（Association Analysis）²⁾アソシエーション分析入門やクラスタリング（Clustering）などの手法があります。

とはいえ今回のように、分析対象データの変数が少ない場合は検証的アプローチで十分です。ではBigQueryとTableauで実際に検証していきます。なお、それぞれの使い方については「BigQueryではじめるSQL」「TableauではじめるBI」を参照してください。

検証的アプローチで相関分析。

まずは分析用のテーブルを作成します。検証したいのは、特定の性別・年代・購買商品カテゴリと会員ランクの間に相関があるかどうかですが、それには会員IDごとに性別・年代・購買商品カテゴリ・会員ランクの変数をもつテーブルを作成する必要があります。BigQueryのクエリエディタに以下のSQL文を入力し、青い［実行］ボタンをクリックしてみましょう。

なお、処理の効率化のために10%のサンプリングをしていますが［※1］、これは会員IDを10で割った剰余が0の場合に限定するという意味です。また、欠損を除外するために性別がNULLでない会員に限定し［※2］、年齢の異常値を除外するために10歳以上90歳未満の会員に限定しています［※3］。さらに、時系列データの開始と終了の問題を解決するために、初回購買日が2006年1月以後かつ最終購買日が2012年12月以前の会員に限定しています［※4］。

すると、以下のスキーマのテーブルが出力結果で表示されるので、それをデータセット「DE」に「sum_members」という名前で保存します。

続いて、テーブル「sum_members」をTableauに取り込んで分析します。Tableau Desktopであれば、スタート画面の［接続］にあるメニュー［Google BigQuery］から選択するだけでシームレスに連携できます。Tableau Publicであれば、GCS（Google Cloud Storage）経由でCSVファイルとしてエクスポートしてから取り込みます。

あとは、性別・年齢・購買商品カテゴリと会員ランクの関係を可視化して分析するだけです。

これらは、性別・年代別・購買商品カテゴリ別での会員ランクの構成比率ですが、どの切り口でもほぼ同じで、性別・年齢・購買商品カテゴリは、会員の優良化に対して何の影響も及ぼしていないことがわかります。どうやら今回の分析対象データからは、優良化との相関が強いサブセグメントを特定することは難しそうです。

ということで「データエスノグラフィ入門」最終回である次回は、サブセグメントでの絞り込みは諦めて、会員ランクごとに行動データを観察していくことにします。

必要なデータは揃っているか。

分析対象である、ECサイトの購買履歴データのBigQueryへの投入が完了したら、データ準備を行います。データ準備（Data Preparation）とは、データを分析可能な状態にすることを指します。なお、ここまでのプロセスは「データエスノグラフィ入門 #01」を参照してください。

ところで、データが分析可能とはどういう状態でしょうか。以下の三つのポイントで整理します。

1. 分析目的の達成に必要なデータが揃っている
2. 分析しやすいよう構造化されている
3. 分析を妨げる欠損・異常値・表記揺れがない

当たり前ですが、必要なデータが揃っていなければ分析目的を達成することができません。今回の分析目的は「優良化する会員の行動特性を、購買履歴データから把握する」でした。

「優良」が何かにもよりますが、ここではRFMがある水準以上となることと定義します。RFMはRecency（最終購買日） ・Frequency（購買頻度）・Monetary（累積購買金額）の頭文字をとったもので、現在の優良顧客を分析したり、未来に優良化する顧客を予測する指標としてよく用いられます。なお、Monetaryに近い概念として、顧客が企業やサービスに対して生涯で消費する合計金額を表す顧客生涯価値（Life Time Value：LTV）もよく使う指標です。

そうすると、RFMを切り口に会員の行動データを分析することになるため、会員ごとの購買履歴があれば条件を満たすことになります。もちろん、購買金額がわかることが前提です。今回のデータソースでは「購買履歴」がそれにあたります。

一方でRFMは、優良であるという結果を測る指標にすぎないため、なぜ優良化したかの原因を探るには別の情報が必要となります。人の行動を決定づける要因は無数にあり、たとえば優良化の原因としてウェブサイトのUIが使いやすいなども考えられます。ECサイトの売上向上にむけて本格的にPDCAを回すのであれば、RFMを押し上げる原因の仮説をたて、その検証に必要な情報を新たに獲得することも必要です。

とはいえここでは、すでにあるデータから原因を探るほかありません。今回のデータソースでは「会員マスタ」と「商品マスタ」が利用可能であるため、どんな人で、どんな物を買っていると優良化しやすいかを分析することは可能そうです。逆にいうと、その範囲での分析に必要なデータはひとまず揃っているといえます。

分析可能な形になっているか。

次に、分析するにはデータが構造化されている必要があります。データは構造化と非構造化に大別されますが、構造化データ（Structured Data）は、端的にいえば行と列による表形式のデータのことで、CSVがその代表です。逆に表形式ではないものを非構造化データ（Unstructured Data）といい、XMLなどの記述様式に従ったものや、単なるテキスト・画像など全てを含みます。なお、ビッグデータの多くは非構造化データです。

Excelをはじめとして、ここで用いるBigQueryやTableau、あるいはPythonのデータ分析用拡張モジュールであるPandasなど、ほとんどの分析ツールは構造化データであることが前提となっています。したがって、非構造化データは構造化データに変換しなければなりません。

さらに、複数の表に別れている場合、同じ採番体系のキー情報により結合できる必要があります。今回のデータソースでいうと、購買履歴はどの会員がどの商品を買ったかを示すデータですが、それぞれ会員IDと商品IDのみで構成されており、その中身は会員マスタと商品マスタを参照する必要があります。つまり、購買履歴・会員マスタ・商品マスタの間で、会員IDと商品IDが一致している必要があります。当たり前のように思いますが、とくに顧客を示すIDが統一されていないケースも多く、その場合はさらに異なる採番体系のIDを紐づける別のマスタが必要なこともあります。

最後に、データの欠損・異常値・表記揺れを考慮します。例えば、ECサイトなどの会員の情報は会員登録時に入力するものですが、一部が任意となっていることがあり、入力されない場合は欠損となります。今回のデータでいうと、性別を切り口に分析する際に、欠損を考慮せずに女性比率を集計するとミスリードする可能性があります。

また、年齢は会員登録時に入力された生年月日から割り出すことが多いですが、いい加減な情報が入力されてしまい、「2歳」のような常識ではありえない年齢が混入することもあります。これを異常値といい、考慮せずに平均年齢を集計すると、実態を見誤る危険性があります。

さらに、住所の市区町村より以下はフリーテキストで入力されることが多く、同じ市区町村を表すものでも表記が異なる場合があります。このような状態を表記揺れ（同義だが異句の状態）といい、あらかじめ補正しておく必要があります。

なお今回のデータソースは、事前に構造化され、欠損・異常値・表記揺れがない状態に加工されたものであるため、これらを考慮する必要はありません。

選択バイアスを回避する。

データ準備が完了したら、基礎分析を行います。基礎分析（Basic Analysis）とは、データの全体像を俯瞰して分布と偏りを把握することをいい、その主な目的は選択バイアスの回避です。選択バイアス（Selection Bias）とは、分析対象として選ばれたものと選ばれなかったものの間に見られる特性の差により生ずる系統誤差をいいます。すべてのデータを分析対象にできない上に、そもそもデータとして存在しないものもあるため、大なり小なり必ず発生します。例えば、プリペイドカードの購買履歴には、カードの入金額の上限を超える高額商品の購買履歴が含まれていません。

選択バイアスの把握は難しい問題ですが、以下の二つのポイントを抑えるとよいでしょう。

1. 既知の分布との違い
2. 時系列データの開始と終了の問題

例えばECサイトの会員の性別や年齢の分布について、同じ業態で一般的に知られている分布があれば、それと照らし合わせることも有効です。もっとも特定の性別や年齢にターゲットをしぼった商品やサービスを展開している場合は、そこに偏りがあるのは当然でしょう。また、ECサイトと小売店の両方で販売展開している場合に、商品カテゴリごとの売上構成比率がそれぞれで異なることがあります。このようなビジネス特性を考慮することも重要です。

そして、行動データ分析において特に注意すべきなのが、時系列データの開始と終了の問題です。RFMの計測には、初回購入日と最終購入日を正確に把握する必要がありますが、例えば今回利用する2005年1月から2013年12月までの購買履歴データにおいて、2005年1月1日に最初の購買履歴がある会員の初回購入日を2005年1月1日としてもよいのでしょうか。事実かもしれませんが、それ以前に購買履歴はあるもののデータとして選ばれていないだけの可能性もあります。

購買履歴データ以外に、会員の初回購入日がわかるデータがあればよいですが、なければ正しい初回購入日を把握することはできません。その場合は、購買履歴上で最初に登場する購買日が初回購入日である可能性が高い会員のみを対象とする必要があります。これは最終購買日についても同様で、最後に登場する購買日が最終購買日である可能性が高い会員のみを対象とする必要があります。仮に、購買間隔が一年以上開く会員がほとんどいなければ、購買履歴データの最初と最後の一年間に購買履歴が存在する会員を除外すればよいことになります。今回のデータで言い方を変えると、初回購買日が2006年1月以後かつ最終購買日が2012年12月以前の会員のみを対象とすればよいわけです。

では次回以降で、実際にBigQueryとTableauを操作しながら、顧客の分類と行動観察を行なっていきます。

行動データ観察によるユーザー理解。

モバイルアプリのアクセスログや店舗での購買履歴など、あらゆるユーザー行動がデータ化されています。今後は5GやIoTの普及により、生体データや撮影データなどが集約され、さらにビッグデータ化されていくことでしょう。ただ、データは貯めているだけでは何の価値も生みません。分析し、有用な知識を獲得してこそ意味があります。

また、多くのマーケターやビジネスパーソンにとって、ユーザーの行動データから、購買の意思決定プロセスを把握したい、思いもよらないニーズを発見したい、というのは、データ活用におけるもっとも重要な関心ごとのひとつでしょう。

あるコンテンツXの閲覧（事象X）と、ある商品Yの購買（事象Y）には、強い共起性があるから、事象Yの意思決定に事象Xがなんらか関与している可能性が高いのではないか。そのような分析はよく行われることと思います。購買という結果につながる原因がわかれば、さらなる購買向上にむけた対策を講じることが可能となります。二つの事象間の因果関係を明らかにする考え方や手法には因果推論（Causal Inference）¹⁾いまさら聞けない因果推論やベイズ推定（Bayesian Inference）²⁾いまさら聞けないベイズ推定などがありますが、簡単ではありません。

一方で、一人ひとりの行動データをミクロ視点で観察し、時系列に追うことで、ユーザーの意思決定プロセスの理解や発見が進むことがあります。クロスハックではこれをデータエスノグラフィ（Data Ethnography）³⁾データエスノグラフィって？と呼んでいます。エスノグラフィとは、生活者のありのままの行動を観察することで、アンケートやインタビューからは得られない洞察や発見の獲得を目指す手法のことですが、これはそのデータ版と言えます。

そこで今回は、データエスノグラフィ実践の入門編をご紹介したいと思います。なお、分析ツールはGoogle BigQueryとTableau Desktopを用いて進めます。それぞれについては「BigQueryではじめるSQL」「TableauではじめるBI」を参照してください。

データエスノグラフィの手順。

データエスノグラフィは以下の手順で進めます。

1. 分析の背景の整理と目的の明確化
2. データ準備と基礎分析
3. ユーザーの分類と選定
4. 行動データの観察
5. 代表性の検証

データ分析に限らず、何らかの課題解決をするには、まずその背景を整理し、目的を明確化する必要があります。当たり前の話ですが、失敗するデータ分析の多くは、ここをあいまいにしたまま、とにかく何らかの有用な知識を獲得したいという思いのみで行われており、時間とコストを浪費する結果となっています。

また、データは「存在する」状態と「分析できる」状態では全く異なります。そして多くのデータは分析することを目的に収集されておらず、そもそも構造化されていない、あるいは欠損・異常値・表記揺れ（同義だが異句の状態）を含むこともあります。それらを加工し「分析できる」状態にすることをデータ準備（Data Preparation）といいます。

さらに、あまねく全てのデータを準備することはできないため、必然的に選択が行われ、偏りが必ず発生します。これを選択バイアス（Selection Bias）といいます。例えば、プリペイドカードの購買履歴には、カードの入金額の上限を超える高額商品の購買履歴がそもそも含まれていません。おそらくクレッジトカードなどの他の決済手段で購買しているのでしょう。このような偏りのあるデータで無邪気にRFM分析などを行うと、ミスリード（Misslead）を起こします。

選択バイアスを無くすことが理想ですが、現実には不可能であるため、データの全体像を俯瞰して分布と偏りを把握し、分析を進める上での前提条件として捉えておくことが重要です。その作業を基礎分析（Basic Analysis）といいます。

ここまで完了してようやくデータエスノグラフィが実施可能となるわけですが、とはいえすべてのユーザーの行動を観察するわけには行きません。そこで、似たユーザーをセグメント（Segment）に分類し、観察すべきセグメントを選定します。

観察すべきセグメントが決まれば、その中から数名のユーザーを抽出し、一人ひとりの行動データをミクロ視点で観察し、何人かに共通して見られる典型的な行動パターンを分析します。例えば、アパレルのモバイルアプリのアクセスログと店舗での購買履歴のデータであれば、「来店前に会員向け先行情報を閲覧」「来店中にポイントを確認」「来店後にコーディネート機能を利用」などの行動パターンを捉えていきます。

これがわかれば、先行情報を閲覧したセグメントは、閲覧しなかったセグメントと比べて購買しているかという疑似実験（Quasi Experiment）を行うことで、先行情報の因果効果を明らかにする因果推論が可能となります。

ただし、行動観察から捉えた行動パターンは、観察したその数名にのみ見られるものかもしれません。そこで代表性の検証が必要となります。代表性（Representativeness）とは、調査対象者全体の中から抽出された一部の対象者の調査結果が、調査対象者全体の結果を、偏りなく正確に反映出来ているかどうかのことです。（※代表性の検証の方法は最終回に説明）

ECサイトの継続率をどう上げるか。

では、データエスノグラフィの実践を進めて行きましょう。まずは分析の背景の整理と目的の明確化を行います。

あなたは、とある総合ECサイトの責任者です。ECサイトでは、F2転換率が重要であると言われています。この”F”は購買頻度（Frequency）のことで、F2転換率とは初回購買から二回目購買への転換率（Conversion Rate）を意味します。一般的に、新規会員の獲得よりも、既存会員のリピート購買促進のほうがコスト効率が高いため、F2転換率は重要な指標となります。とはいえF2転換した会員が、その後も継続的に購買してくれる、いわゆる優良会員になるとは限りません。

そこで今回の分析目的を「優良化する会員の行動特性を、購買履歴データから把握する」とします。なおそこには、まだ優良化していな会員を意図的に優良化するためのヒントがあることは言うまでもありません。

分析対象データは、とある総合ECサイトの会員の購買履歴データで、概要は以下のとおりです。

• 種類：総合ECサイトの会員の購買履歴
• 期間：2005年1月〜2013年12月（9年間）
• 会員数：639,777人
• 購買数：7,599,650件（平均11.9件/人）

データソースは以下の３つを使用します。

まずはこれらのデータをBigQueryに投入します。データセット名とテーブル名は任意ですが、この後の解説で使う名前と合わせておきたい方は、データセット名を「DE」、テーブル名はファイル名をそのまま設定しておきましょう。投入が完了すると、このような状態になります。

次回は、データ準備と基礎分析について見て行きます。

サブクエリはWITH句。

前回は検索の基本構文であるSELECT文と、集計と正規化の基本構文であるGROUP BY句について説明しましたが、今回は非正規化の基本構文であるJOIN句を中心に見ていきましょう。

練習用データ「E-Commerce Data」をBigQueryで操作します。なお、BigQueryと練習用データの準備は「BigQueryではじめるSQL #01」を参照してください。

非正規化（Denormalization）とはデータの重複を許容することです。データが重複すると、データの追加・更新・削除における処理が冗長化するため、メンテナンス効率を重視する場合はなるべく排除しますが、処理速度を重視する場合はそれを犠牲にして、あえて非正規化を行います。

練習用データ「E-Commerce Data」は、とあるECサイトの購買履歴データで、各レコードには「CustomerID」（顧客ID）が紐づいているため、各顧客IDをグループとみなし、それぞれの購買回数に基づいた顧客ランクの集計が可能です。

その顧客IDごとの顧客ランクを、購買履歴と合わせて参照したい場合は、購買履歴の各レコードに、該当する顧客IDの顧客ランクを保持しておくと便利です。すなわち非正規化を行うということです。この非正規化を以下の手順で進めます。

1. 購買履歴データから、顧客IDごとの顧客ランクを集計する。
2. 購買履歴データの各レコードに、上記1で集計した顧客IDごとの顧客ランクの列を結合する。

このように、前のクエリの出力をもとに後のクエリを行うこと、あるいはその「前のクエリ」のことをサブクエリ（Subquery）といいます。サブクエリの記述方法には、後のクエリのFROM句に前のクエリを記述する方法もありますが、構文が視覚的に煩雑になるため、それを回避したい場合にWITH句を用います。WITH句を用いたサブクエリの構文は以下のようになります。

WITH ビュー名 AS ( サブクエリ ) クエリ

ちなみに、サブクエリの出力は実体を持たない仮想的なテーブルですが、それをビュー（View）といいます。また、構文中のASはAS句といい、ここではサブクエリが出力したビューに名前をつける役割を担います。

前回の「BigQueryではじめるSQL #03」で行った顧客IDごとの顧客ランクの集計をサブクエリとして、後のクエリに利用できるようWITH句を用いて以下の例文のように記述します。

列結合による非正規化はJOIN句。

それでは、購買履歴データの各レコードに、上記で集計した顧客IDごとの顧客ランクの列を結合して、非正規化を行います。このように列方向に結合することを列結合といい、列結合による非正規化にはJOIN句を用います。構文は以下のとおりです。

SELECT 列名, 列名, … FROM テーブル名（ビュー名） AS 略称 JOIN テーブル名（ビュー名） AS 略称 ON 結合条件式

さきほどのサブクエリと組み合わせると、例文は以下のようになります。

上記の例文全体の意味は、テーブル「ECData」（略称「ED」）と顧客ランクの集計結果であるビュー「CRank」（略称「CR」）を、列「CustomerID」が一致する場合に列結合し、列「InvoiceNo」「StockCode」「UnitPrice」「CustomerID」「CustomerRank」を出力する、となります。青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

なお、例文中のASはAS句といい、ここではテーブルやビューに略称をつける役割を担います。略称は必須ではありませんが、つけておくと便利です。というのも、列結合ではテーブル間で列名が重複することが多く、その場合はどのテーブルの列かを「テーブル名.列名」の形で明記する必要があるのですが、テーブル名が長いとSQL文が冗長となり、可読性が損なわれるからです。この例文では「ED.CustomerID」がそれにあたります。

また、列結合には内部結合と外部結合があります。内部結合は結合条件に合致するレコードが双方にあるものだけを残す結合方式で、INNER JOINを用います。ちなみに、単にJOINと記述するとINNER JOINと同じ意味になります。つまり上記例文のJOINは内部結合となります。

一方で、外部結合は結合条件に合致するものが双方になくても残す結合方式で、OUTER JOINを用いますが、左右どちらも残す場合はFULL OUTER JOIN、左のみ残す場合はLEFT OUTER JOIN、右のみ残す場合はRIGHT OUTER JOINと、区別して指定する必要があります。

ビッグデータ分析に便利な構文。

複数のテーブルを列方向に結合することを列結合というのに対し、行方向に結合することを行結合といい、UNION句を用います。なお行結合では、結合するテーブルの列の構成が一致していることが前提となります。構文は以下のとおりです。

SELECT 列名, 列名, … FROM テーブル名（ビュー名） UNION SELECT 列名, 列名, … FROM テーブル名（ビュー名） 

ちなみに、上記のように単にUNIONと記述すると、結合するテーブル間で重複するレコードは削除され、ユニークなものだけが残ります。重複を許容したい場合はUNION ALLと記述します。

行結合は、日時で分割して蓄積や集計したレコードを統合する場合などで利用されます。すなわち、ビッグデータ分析には便利な機能です。なお、大量のレコードを日時などで分割して管理することをパーティショニングといいます。

この他にも、ビッグデータ分析では集計関数＋OVER句をよく用います。これは、通常の集計処理をGROUP BY句を使った正規化状態で行うのに対し、非正規化状態のまま、特定のグループごとに集計処理を行う方法です。そのグループをウィンドウ（Window）といい、PARTITION BY句で指定します。なお、この場合の集計関数は、分析関数やウィンドウ関数とも呼ばれます。構文は以下のとおりです。

SELECT 集計関数 OVER( PARTITION BY 列名 ) FROM テーブル名（ビュー名）

これを利用すれば、購買履歴などの時系列データの集計処理を行う場合に、サブクエリでGROUP BY句を使って集計し、その結果をJOIN句を使って時系列データに列結合する、という煩雑な処理をする必要がなくなり、とても便利です。

なお、時系列データの分析については、別の記事にて詳しく説明する予定なので、UNION句やOVER句の具体的な使い方や例文の紹介はその機会に譲りたいと思います。

また、この「BigQueryではじめるSQL」で触れたもの以外にも、SQLには多くの便利な構文・関数・演算子があります。とりわけBigQueryで利用可能なものについては、GCPのBigQuery公式リファレンスサイトに詳しいため、こちらをご参照されることをお勧めします。

検索はSELECT文。

SQLによる検索の基本構文はSELECT文、集計と正規化の基本構文はGROUP BY句になりますので、こちらを中心に見ていきましょう。

練習用データ「E-Commerce Data」をBigQueryで操作します。なお、BigQueryと練習用データの準備は「BigQueryではじめるSQL #01」を参照してください。

SELECT文は検索対象のテーブル（Table）と列（Column）の名前を指定する形で記述します。BigQueryの場合、テーブル名はデータセット名と合わせて記述し、その間をドット「.」で結びます。また、列名は複数の指定が可能で、その間をカンマ「,」で区切ります。構文と例文は以下のようになります。

SELECT 列名, 列名, ... FROM テーブル名（ビュー名）

ちなみにビュー（View）とは、テーブルの一部を抽出あるいは複数のテーブルを結合するなどして作成した実体をもたない仮想的なテーブルのことで、SQL文中のサブクエリ（Subquery）の出力がそれにあたります。サブクエリについては次回説明します。

また、検索対象となる行（Record）の条件や数を指定する場合は、それぞれWHERE句とLIMIT句を用います。構文と例文は以下のとおりです。

SELECT 列名, 列名, ... FROM テーブル名（ビュー名） WHERE 条件式 LIMIT 行数

なお、WHERE句には条件式を指定しますが、検索対象となる列名と、演算子や定数などを組み合わせて表現します。この例文でいうと「UnitPrice >= 10」がそれにあたります。そして、この例文全体の意味は、テーブル「ECData」で、列「UnitPrice」が10以上の行を100行だけ抽出し、列「InvoiceNo」「StockCode」「UnitPrice」を出力する、となります。青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

集計はGROUP BY句。

集計と正規化の基本構文であるGROUP BY句は、SELECT文と組み合わせて使います。内容の説明は後述するとして、構文と例文はこのようになります。

SELECT 列名, 集計関数 AS 列名, ... FROM テーブル名（ビュー名） GROUP BY 列名

集計（Aggregation）とは、データ内のあるグループ（Group）について、頻度・合計値・平均値などを計算することをいいます。グループの軸には性別や年代などさまざまあり、この軸のことをディメンション（Dimension）ともいいます。

練習用データ「E-Commerce Data」は、とあるECサイトの購買履歴データで、各レコードには「CustomerID」（顧客ID）が紐づいているため、各顧客IDをグループとみなし、それぞれの購買回数を集計することができます。

上記の例文全体の意味は、テーブル「ECData」で、グループの軸「CustomerID」ごとに、列「CustomerID」と、行数の集計結果である「InvoiceCount」を出力する、となります。こちらも、青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

なお、例文中のCOUNTは集計関数（Aggregate Function）と呼ばれ、行数を集計するものになります。集計関数は他に、合計値を集計するSUMや、平均値を集計するAVGなどがあります。

また、例文中のASはAS句といい、ここでは集計関数の出力列に名前をつける役割を担います。つまり「COUNT(*)」の出力列に「InvoiceCount」という名前をつけることを意味します。AS句はこの他にも、SELECT文で出力されたテーブルに名前をつける機能もあります。こちらは次回のWITH句やJOIN句のところで説明します。

ちなみに、ここでもう少し踏み込んで、各顧客IDごとの顧客ランクを集計する方法を見てみます。顧客ランクの集計条件を、購買回数が300回以上を「A」、100回以上を「B」、それ未満を「C」と定義すると、例文は以下のようになります。なお、例文中のCASEはCASE句という条件分岐の基本構文のひとつで、分岐が多い場合に使います。条件分岐には他にIF句があり、こちらは分岐がひとつの場合に使います。

上記の例文全体の意味は、テーブル「ECData」で、グループの軸「CustomerID」ごとに、列「CustomerID」と、顧客ランクの集計結果（集計条件は、購買回数が300回以上を「A」、100回以上を「B」、それ未満を「C」とする）である「CustomerRank」を出力する、となります。こちらも、青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

正規化もGROUP BY句。

GROUP BY句は、集計の他に正規化の役割を持ちます。正規化（Normalization）とはデータの重複を排除することです。

練習用データ「E-Commerce Data」においては、StockCode（商品コード）とUnitPrice（商品単価）が重複しているはずです。なぜなら商品コードとは商品管理の最小単位であるため、商品単価が一意に定義されているはずだからです。すなわち、商品コードと商品単価の1対1の対応表を別テーブルで保持しておけば、購買履歴のテーブルとして保持する必要があるのは商品コードだけでよいことになります。

では、商品コードと商品単価の1対1の対応表を取り出して正規化してみましょう。例文はこのようになります。

上記の例文全体の意味は、テーブル「ECData」で、グループの軸「StockCode」ごとに、列「StockCode」と、列「UnitPrice」の任意の値を列名「UnitPrice」として出力する、となります。こちらも、青い［実行］ボタンをクリックして、出力結果を確認してみましょう。

なお、例文中のANY_VALUEも集計関数のひとつで、グループ内の指定した列の任意の値を取り出すものであり、データの重複を正規化する場合によく用います。

また、このように正規化された対応表データをマスタデータ（Master Data）といい、商品コードをキーとしたものを商品マスタ、顧客IDをキーとしたものを顧客マスタといいます。逆に、購買履歴などの発生事象の時系列データをトランザクションデータ（Transaction Data）といいます。

次回は「BigQueryではじめるSQL」最終回、非正規化の基本構文であるJOIN句を中心に見ていきます。