マーケティング データ ウェアハウスの構築

この記事では、以前は利用できなかったリマーケティング リストを作成するために、複数のソースからデータを収集する方法について説明します。これらのリストを使用すると、顧客の全体像を把握できます。顧客とブランドの関わり方を理解することで、ライフタイム バリュー(LTV)を高め、より深いマーケティング分析を行うことができます。

マーケティング担当者の役割は、従来型のキャンペーンの実施からリアルタイムのエンゲージメントに変化しています。データ収集と遡及的なパフォーマンス分析が主流だったマーケティング手法も変わり、現在のマーケティング担当者は、データに基づいた顧客の分析、パフォーマンス主導の戦略立案、プロアクティブなターゲティングを行う必要があります。

この新しいアプローチによって新たな課題が生まれています。たとえば、ストレージの価格の継続的な低下は、データが指数関数的に増加している現状には好ましい傾向ですが、データを分析するためにデータをどのように集約するのかは課題として残されています。次のような課題もあります。

  • データソースがサイロ化され、フォーマットも多様。
  • 分析ツールや、抽出、変換、ロード(ETL)ツールが多種多様で、実装が難しいことがある。
  • 技術リソースが不足している。
  • テストとプロトタイプを柔軟に行うことができない。

この記事では、これらの要素について検討し、独自のデータで扱うワークフローの作成方法を解説します。この記事は、構造化クエリ言語(SQL)の基本的な知識がある方を対象にしています。機械学習に関連する部分については、データ アナリストやデータ サイエンティストの助けが必要になる場合があります。

使用例

以下では、オンラインで化粧品を販売している架空の会社について考えてみます。あなたはマーケティング部門の責任者です。DevOps チームの技術的なサポートを最小限に抑えながら、主要な分析業務を行いたいと考えています。IT リソースは限られていますが、データ サイエンティストのサポートはあります。

主な課題は、広告費の投資収益率(ROI)を追跡してマーケティング予算を最適化することですが、次のようなデータの問題があります。

  • データが、Google アナリティクス 360、顧客管理(CRM)システム、キャンペーン マネージャーなどのプロダクトに散在している。
  • 顧客データと販売データは CRM システムに保存されている。
  • 一部のデータは、クエリを実行できる形式になっていない。
  • データを分析し、結果を他の組織と共有するツールがない。

この記事のアプローチでは、このような懸案事項に対し次の解決策の概要を示します。

  • 共通の保管場所にデータを収集する。
  • データを変換して異なるソース間でデータの照会や結合ができるようにする。
  • 標準のレポート API では使用できないレポート ディメンションを利用する。
  • 機械学習を活用してユーザーのグループを発見する。

これらの作業を行うことで、これまで利用できなかったリマーケティング リストを作成できます。

アーキテクチャ

次のアーキテクチャ図は、さまざまなソースからデータを取り込み、リマーケティングの決定を行うまでのプロセスを表しています。

データの取り込みからリマーケティングの意思決定まで
図 1: データの取り込みからリマーケティングの意思決定までの流れ
  • この図で、一部のデータセットは色が淡くなっています。これは、この記事で説明している特定のユースケースの一部ではないことを示しています。ただし、同じ方法で問題に対処できる場合もあります。たとえば、この記事ではキャンペーン マネージャーのデータで Google アド マネージャーや YouTube のクエリを実行する方法について説明しますが、BigQuery にエクスポートされたデータでも同じことができます。
  • ダイアグラムに「More advanced」というセクションがあります。データを中央に集約すると、データ サイエンティストによって機械学習などの高度な作業にデータを使用できます。

機能要件

このセクションでは、以下の機能要件で使用する技術オプションについて説明します。

  • データの収集と保管
  • データの変換
  • データの分析
  • データの可視化
  • データの有効化

データの収集と保管

インサイトを得るためにまず必要なことはデータの集約です。Google のデータなど、最も重要なマーケティング チャネルやデータソースから情報を効率的に収集できる技術を選択する必要があります。

BigQuery のストレージ機能とクエリエンジンを利用すること、さまざまなソースからデータを取り込むことができます。ここでは、次のようなデータを収集します。

  • Google 広告: BigQuery Data Transfer Service では、Google マーケティング プラットフォーム、Google 広告、YouTube などのソースから、データをスムーズかつ自動的に取り込めます。
  • アナリティクス 360: データの更新頻度を確認して、10 分から 1 日までの範囲で、要件に最適なオプションを選択します。アナリティクス 360 では、BigQuery に直接接続できます。
  • 自社データ: CRM や PoS(Point Of Sale)などのソースからデータを取り込めます。多くの場合、このデータの取り込みは bq コマンドライン ツールAPIウェブ UI を使用してオフラインで行います。データはローカルで、または Cloud Storage から読み込めます。巨大なデータセットやデータレイクの構築を検討している場合、Cloud Storage をおすすめします。
データ収集プロセス
図 2: データの収集と統合。

変換

ここでは、データの分析準備について説明します。巨大なデータセットで一貫性を維持するには、クリーニングや再フォーマットが必要になります。しかし、コーディングの手間はかけたくありません。たとえば、スケーリングや分散変換が可能なビジュアル ツールを使用し、コーディングなしでデータをクリーンアップしたいと思います。

BigQuery では、テーブル間での一括変換やビューの使用が可能です。 しかし、より高度な変換が必要な場合は、プログラミングが少なく、複雑なパイプラインでテラバイト規模のデータを扱えるビジュアル ツールのほうが望ましいでしょう。

たとえば、Other_data フィールドなどの Key-Value 文字列がキャンペーン マネージャーのアクティビティ テーブルにエクスポートされているとします。

key1=value1&key2=value2&...keyN=valueN

この文字列を次のような列と値のテーブルに分割します。

key1 | key2 | … | keyN
----------------------
val1 | val2 | … | valN

キー名を列にすると、他のテーブルとの結合が容易になります。キーには、CRM ユーザー ID、商品リスト、UTM(Urchin Tracking Module)データなどのカスタム情報を含めることができます。

Cloud Dataprep by Trifacta にはレシピという機能があり、変換の定義に使用できます。レシピは分散環境のシーンの背後で実行される一連のタスクです。

Cloud Dataprep レシピ

レシピを定義すると、Cloud Dataprep by Trifacta はデータの表示方法をプレビューします。次のスクリーンショットのように、変換されたデータが保存されるときに、treatments、products、concerns、membership などの新しい列が追加されます。

変換後のデータの保管

Cloud Dataprep by Trifacta は、BigQuery などのさまざまな入出力ソースに対応しているため、この事例に適した選択肢となります。 Cloud Dataprep by Trifacta では、キャンペーン マネージャーからインポートした BigQuery データセットを読み取り、その結果を BigQuery に保存できます。

分析

クリーンアップしたデータを一元的に保存したら、分析を行い、インサイトを得ることができます。BigQuery でデータを扱えるようにすると、次のような利点があります。

  • たとえば Google アド マネージャーのレポート API や UI で処理できるデータなどよりも大きなデータに対して、クエリを実行できます。
  • UI やレポート API では必ずしも利用可能でない、詳細なデータにアクセスできます。
  • 共通キーを使用して、複数のソースのデータを処理し、結合できます。

このセクションの残りの部分では、利用可能なデータに対して実行できる処理について説明します。このセクションは 2 つの部分に分かれています。

  • 標準分析。構造化クエリ言語(SQL)の基本的な知識が必要です。主に次の 2 種類の分析を行います。

    • ビジネスで何が起きているかを把握する、記述的分析
    • 事象が発生している理由を理解する、診断的分析
  • 機械学習ベースの分析。データ アナリストやデータ サイエンティストが必要ですが、次のような新しい分析が可能になります。

    • 履歴データを使用して結果を予測する、予測分析
    • 結果を予測して戦略を準備する、処方的分析

標準分析

広告関連の商品では、毎日数ギガバイト、あるいはテラバイト単位のログデータが生成される可能性があり、分析も容易ではありません。すぐに使用できるレポートツールでは、クエリ可能なディメンションが限られる場合もあり、必ずしも正しい結合を提供するわけではありません。つまり、使用可能なすべての生データにクエリを行えず、代わりに集計を提供します。

記述的分析や診断的分析を行うには、ビッグデータにクエリを実行する必要があります。このような分析を行うには、スケーラブルなアーキテクチャが必要です。しかし、このようなアーキテクチャを最小限のオーバーヘッドと妥当なコストで構築することは容易ではありません。特に、技術リソースが限られている場合はなおさらです。この状況を解決する方法の 1 つは BigQuery です。BigQuery は数秒でテラバイト規模のデータを照会可能なストレージ / クエリエンジンで、サーバーを設定する必要はありません。

BigQuery でクエリを実行する最も簡単な方法はインタラクティブ UI を使用する方法です。その他の方法については、データのクエリをご覧ください。

高度な分析と充実化

技術的な知識がある場合や、チームにデータ アナリストやデータ サイエンティストがいる場合は、予測アルゴリズムを実行して詳しい情報を取得して、それをデータセットに再度取り込むこともできます。たとえば、次のような作業が可能です。

  • 教師なし機械学習を使用して、顧客を類似オーディエンスにクラスタリングする。
  • 回帰分析を行い、販売数または顧客の LTV を予測する。
  • コメントなどを使用して、商品の感情分析を行う。

機械学習ではアルゴリズムが重要ですが、良い予測ができるかどうかは、モデルのトレーニングに使用できるデータの量と品質で決まります。BigQuery でデータを取り込んだ後は、次のものが必要になります。

  • さまざまな GCP コンポーネントをリンクしてデータ サイエンス タスクを簡素化できる、インタラクティブ ツール。
  • 最小限の DevOps でトレーニングと予測を実施できる、機械学習プラットフォーム。

AI Platform では、管理されたスケーラブルな方法で TensorFlow モデルを実行し、トレーニングと予測の両方を行うことができます。また、ハイパー パラメータ調整などの機能も追加できます。TensorFlow は、Google が公開した最先端のオープンソース ソフトウェア(OSS)の数値計算ライブラリです。

Cloud Datalab では、BigQueryCloud Storage、AI Platform などの GCP プロダクトや、Cloud Natural Language などの Perception API に接続する機能を追加したサービスとして、Jupyter ノートブックが提供されています。データ サイエンティストは、Cloud Datalab でインタラクティブな分析セッションを実行し、これらのプロダクトを活用できます。Cloud Datalab には、NumPyPandas などの標準ライブラリが用意されています。

たとえば Cloud Datalab では、Natural Language の予測機能を使用して感情分析などを行えます。次のヒストグラムは、商品やブランドに対して顧客の大多数が好意的な印象を持っていることを表しています。

x = pd.Series(df.avg_sentiment, name="sentiment")
fig, ax = plt.subplots()
ax.set_title("Avg. Sentiment For All Products")
ax = sns.distplot(x, ax=ax)

感情分析

可視化する

BigQuery UI で SQL クエリを記述したり、ノートブックで Python コードを入力するのが面倒に感じることがあるかもしれません。たとえば、次のような状況について考えてみてください。

  • 管理者が、実用的な情報が表示されるダッシュボードにすぐにアクセスしなければならない。
  • 技術的に詳しくないアナリストが、データをスライスして分析しなければならない。

Google データポータルを使用すると、技術者以外のユーザーでも、事前に構成されたテンプレートを使用して、共有可能なビジネス ダッシュボードを簡単に作成できます。このツールには、いくつかの利点があります。

  • ドラッグ&ドロップでデータにアクセスできる。
  • 実用的なダッシュボードを作成して、共同作業を行うことができる。
  • 事前構築されたダッシュボードを意思決定者と共有できる。

次の例では、複数のソースからのデータを表示しています。

  • 中央の行の左側には Google アナリティクス 360 のレポートが表示され、右側にはキャンペーン マネージャーが表示されています。
  • 上部の行の中央の列に表示されているグラフには、LTV に対する顧客のエンゲージメントが青い点でプロットされています。

異なるソースのデータを表示

有効化

コードとダッシュボードの両方からアクセスできる共通の場所で、データを操作できるプラットフォームで生データを使用すると、マーケティングに関するさまざまな決定が可能になります。次に例を示します。

  • 頻度がキャンペーンあたり、ユーザーあたりのコンバージョンに与える影響についての記述的分析。 この情報は、特定のユーザーリストに対するリマーケティング キャンペーンの頻度を決める際に役立ちます。 BigQuery からキャンペーン マネージャーの生データにアクセスすることで、このような情報を得られます。

  • キャンペーンとウェブサイトの動作が販売に及ぼす影響を理解する診断的分析。 このような分析を行うには、SQL ステートメントを使用して、ビッグデータ上で ID の結合を作成します。

  • 特定のユーザーの LTV についての予測分析。 特定のユーザー グループの値を予測することで、効果的なマーケティング キャンペーンを実施できます。前述の図の青い点のグラフを例にとると、ブランド エンゲージメントが制限されているユーザー グループでは、ユーザーのエンゲージメントが高いほど購入の可能性が高いことがわかります。 この分析情報は、データを結合して機械学習で顧客セグメントを構築し、LTV を予測することで得られます。

  • 商品に対する感情についての処方的分析。 コメントと評価の推移を分析すると、特定のユーザー グループが特定の特性を持つ商品をどのように感じるかを予測することで、不正確なターゲティングを防ぐことができます。このタスクは、たとえば感情分析と顧客のセグメント化を使用することで実施できます。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...