Adobe Analytics の Data Workbench を使用すると、アナリストは複数のチャンネル間で訪問者のアクティビティを照会できます。この記事では、クエリに 1 人の訪問者データを統合する方法を示します。
この記事は厳密に簡略化されたイラストです。例えば、各訪問者のデータは実際のストリングの代わりに参照／ポインターで構成され、異なるソースからのデータは、訪問者の識別子を確定するために前処理が必要になる場合があります。
抽象ビュー
このダイアグラムでは複数のソースが1つのデータセットに結合される方法を示します。 各セクションを見てみましょう。
Raw ログデータ
左側にログソースがあります。この例では、Web サーバーログとストア内トランザクション（POS）を使用しています。Data Workbench では、訪問者識別子およびタイムスタンプがある限り、どのイベントログデータも取得できます。
この時点では保管されているので、Web ログには訪問者がウェブサイトで何をするか表示されますが、POS ログでは、ストア内データのみが表示されることに注意してください。
データアーキテクチャ
中央には、データセットアーキテクチャがあります。これは、各ログのソースがどのように収まる必要があるかを定義します。また、より読みやすいフォームにどのように変換する必要があるかも説明します。
処理された訪問者のデータ（データセット）
最後に、すべてのチャネルからのイベントデータが 1 人の訪問者データに保存されます。これは、1 人の匿名扱いの訪問者のすべてのイベントデータを保持するカードと類似しています。これには、ストアの場所で訪問者が何を購入したかに加えて、ウェブ上で何を行ったかも含まれます。
簡単に言うと、左側の Raw 入力データはテンプレートとしてデータアーキテクチャを使って、右の処理された訪問者データに流れています。
もっと見てみる
データ例を使用してこのプロセスを再度一通り説明しましょう。
Web サーバーログから、各ログエントリがデコードされ、スキーマの関連する次元に配置されます。この例では、訪問者「匿名 001」は、1 つの製品を購入し、店頭受取を選択しました。
店内トランザクションも同じ訪問者に対してデコードされます。この人物は、次の日にその商品をピックアップし、さらに 2 つのアイテムをレジに追加することにしました。
次に、アクティビティデータがクエリーに適した形式に変換されます。 この場合、製品 SKU は参照変換を使用してその製品名に置き換えられます。
すべてのチャネルからのデータを組み合わせると、1 つのカード上で訪問者データを取得します。
このカードは、1 人の匿名顧客が 1 つのアイテムをオンラインで注文し、それを店で受け取り、追加のアイテムを購入したことを示しています。元の入力データとは異なり、1 つのカードにより異なるチャネル間の訪問者のアクティビティが全体的に明らかになります。
クエリーの実行
1 つの訪問者のデータが処理されるので、今度は次の分析クエリーを考慮してみましょう。
「Web で受取り注文をしたクライアントの間で、追加のアイテムは、その店でいくつ購入されましたか。また、どの製品が店頭での追加として人気でしたか？」
上記のカードを見ることで、クエリエンジンは次のように集計するはずです。
店頭受取り指標として +1 訪問者
、追加の購入ディメンションとして「USB ケーブル」に +1 製品
、追加の購入ディメンションとして「ケールチップス」に +1 製品
他のすべてのカードにこのマイクロクエリーを繰り返して、最終的にすべてのデータセットで回答が得られます。
パフォーマンスの考慮
このアプローチには次のようなメリットがあります。
- カードは自己完結型なので、マイクロクエリーはより少ないコストをかけた外部参照で完了します。
- これらのカードは、並列処理のために簡単に配布できます。
データセット
すべてのカードはデータセットとして知られるカードホルダーに保存され、そのファイル名のために一般的に「temp.db」と呼ばれます。
このホイールを回転し続けると、各カードが 1 つずつ評価されます。同じカードが再度表示されると、1 つの流れが終了し、データセット全体が評価されたことが分かります。
次の記事のこちらでデータセットの全体のライフサイクルを説明します。
