AWS Entity Resolution と HAQM Neptune を使用して顧客の 360 度ビューを作成

この記事は Create a 360-degree view of your consumers using AWS Entity Resolution and HAQM Neptune (記事公開日: 2024 年 4 月 24 日) を翻訳したものです。

マーケターや広告担当者は、ウェブ、モバイル、コンタクトセンター、ソーシャルメディアなど、様々なチャネルで効果的なマーケティングや広告体験を提供するために、消費者データが統合されたビューを必要としています。例えば、消費者がブランドのウェブサイトでスニーカーを探している場合、マーケターは消費者の時間と労力を節約するために、最も関連性の高い商品を表示したいと考えます。マッキンゼーの調査によると、71% の消費者がブランドからのパーソナライズされたやりとりを期待しており、76% の消費者がパーソナライズされていないやりとりに不満を感じているとのことです。しかし、パーソナライズされた体験を提供するためには、企業はウェブ、モバイル、メール、ソーシャルメディアなど、複数のタッチポイントにわたる消費者データを取り込み、照合し、クエリを実行して、消費者を理解するために統合されたビューを作成する必要があります。

このブログ記事では、AWS における組み合わせ可能なアーキテクチャパターンについて説明します。このパターンは、データエンジニアリングチームが顧客の 360 度ビューをマーケターに提供するために必要な、データの取り込み、マッチング、クエリのソリューションを構築する際に役立ちます。このブログでは、AWS Entity Resolution と HAQM Neptune を使用して、高精度、低コスト、かつ柔軟な設定が可能な統合顧客ビューを開発するために、関連する顧客情報をどのように接続するかを学びます。
AWS Entity Resolution は、複数のアプリケーション、チャネル、データストアにまたがって保存されている顧客、製品、取引情報、医療記録などの関連レコードを、より簡単にマッチング、リンク、拡張することができるサービスです。そして、HAQM Neptune は、優れた拡張性と可用性を実現するように設計されたサーバーレスのグラフデータベースです。

統合された顧客ビューは、マーケターが高精度なパーソナライゼーションキャンペーンを展開することを可能にし、それにより顧客エンゲージメントとブランドへの信頼を高めることができます。現在、企業はメールでのやり取り、店舗での購入、ウェブサイトの訪問など、異なるチャネルを通じて収集された関連する顧客記録を接続するために、何ヶ月もの開発時間を費やして、データマッチングやデータクエリのソリューションを構築しています。さらに、一度構築したこれらのソリューションは、ファーストパーティデータ管理システムの最新の変更に合わせて更新し続ける必要があります。例えば、システムは新規に入ってくる匿名の顧客記録を、既知の顧客 ID と継続的に紐付けなければなりません。これらのソリューションは構築、維持、顧客データの変更への対応にコストがかかるため、結果として不正確になったり、耐久性が低下したり、運用や保守が困難になる可能性があります。

使用する AWS サービスの紹介

AWS Entity Resolution は、関連する顧客情報、製品コード、または取引情報コードをより正確にリンクするために、ルールベース、機械学習 (ML) モデル駆動、およびデータサービスプロバイダーマッチングなどの高度なマッチング技術を提供します。

HAQM Neptune は、マネージド型のグラフデータベースで、顧客行動とキャンペーンのマッピング、レコメンデーションエンジンの構築、カスタマージャーニーの表現、統合された顧客ビューの可視化など、密接に関連したデータセットを持つアプリケーションをミリ秒単位のレイテンシーでサポートします。HAQM Neptune 上の 360 度顧客グラフは、顧客の行動や関係性をたどることで、製品やコンテンツのレコメンデーション、そして世帯の識別において、より正確な結果を導き出すことができます。

例：ファーストパーティ識別子を使用した匿名顧客データと既知の顧客データの接続

デジタルコンテンツを利用するユーザーの多くは、匿名の訪問者です。彼らは名前、メールアドレス、電話番号などの識別可能な情報を共有することなく、ウェブやモバイルの様々なページを閲覧するため、匿名訪問者として分類されます。Forbes の事例データによると、ウェブサイトトラフィックの約 90% が匿名訪問者で構成されているとのことです。匿名訪問者を特定する最初のステップは、ウェブサイトトラフィックの収集です。ウェブやモバイルからのクリックストリームイベントを通じて、識別済みユーザーと匿名訪問者のトラフィックを収集し、HAQM Simple Storage Service (HAQM S3) などのデータレイクに保存できます。HAQM S3 は、事実上、どこからでもあらゆる量のデータを取得できるように構築されたオブジェクトストレージです。次に、これらの匿名訪問者を既知の訪問者記録とマッチングおよびリンクして、顧客の完全な、つまり統合されたビューを開発する必要があります。顧客を包括的に理解することで、マーケターは認知度とエンゲージメントを高めるためのパーソナライズされたメッセージやキャンペーンを作成することができます。

例を用いて理解しましょう。誰かが 1 日に数回あなたのページを訪問したものの、サインインせず、メールアドレスなどの個人情報を提供する操作も行わなかった場合、一連のクリックストリームデータは存在しますが、これらのイベントを特定のユーザーに紐付けるための識別記録がない状態になります。これは下図 Figure 1 の Click 1 と Click 2 で示されている状態です。しかし、ユーザーがサインインまたは購入 (Click 3) を行った時点で、そのユーザーは個人識別情報を提供することになり、それまでの全てのクリックストリームイベント履歴をそのユーザーに紐付け、アクセスパターンをより良く理解する機会が得られます。

以下の図において、MatchRule1 は、入力されるイベントをリンクし、特定のグループ (Group 1) にマッチングするために AWS Entity Resolution 内で設定されたルールを表しています。

Figure 2 でこの例をさらに発展させると、同じ世帯の複数のユーザーが共通のデバイス (Click 4) や異なるデバイス (Click 5) からあなたのページにアクセスした場合、ユーザーのクリックストリームデータから収集されたイベント記録を使用して、これらのセッションを相互にリンクすることができます。このリンケージにより、世帯単位でのカスタマージャーニーについてより多くの情報が得られます。

このようなソリューションを構築するために、以下のようなハイレベルの設計を考えてみましょう。クリックストリームイベントはウェブサイトやアプリから発生し、データレイクにストリーミングされます。これらのイベントが到着すると、AWS Entity Resolution は、サービス内で定義したルールを使用して、適切なマッチグループにイベントを振り分けます。マッチグループとは、互いに関連があると判断されたレコードのグループです。AWS Entity Resolution からの出力は、HAQM Neptune への入力として使用され、そこで顧客関係を理解するためのプロパティグラフが構築されます。以下の Figure 3 は、このようなソリューションを実装するための全体的なアーキテクチャと設計を示しています。HAQM Neptune 内のプロパティグラフは、分析を実行し、以下のような質問に答えるための基礎となります：

1. 顧客の基礎となるメタデータ項目は何か？
2. 顧客間で共有されているデバイスは何台あるか？
3. 共有デバイスでつながっている複数の顧客間で共有されている、様々な識別情報 (IP アドレス、メールアドレスなど) は何か？

ユーザーの操作から生成される典型的なクリックストリームイベントには、IP アドレス、イベントのタイムスタンプ、デバイス情報 (デバイスファミリー、ブラウザやオペレーティングシステムとそれらのバージョンなど) といった情報が含まれています。さらに、login_id などの要素も含まれていますが、匿名訪問者の場合は、サインインやそれに準ずるアクションを行わない限り、空の値が入ります。以下で、クリックストリームイベントを表すスキーマとサンプルレコードを考えてみましょう。

サンプルイベントレコード

AWS Entity Resolution でこのデータスキーマを解決するためには、まず、サーバーレスのデータ統合サービスである AWS Glue でテーブルを作成する必要があります。このテーブルは、入力されるクリックストリームデータを保持する HAQM S3 バケットを指します。次に、AWS Entity Resolution 内でスキーママッピングを定義し、サービスにデータの解釈方法を指示する必要があります。クリックストリームイベントの属性の多くは個人を特定できる情報ではありませんが、解決には重要であるため、適切な MatchKey 名を持つ Custom String (カスタム文字列) としてマークします。以下の図は、クリックストリームイベント用に AWS Entity Resolution 内で定義されたスキーママッピングを示しています。

注目すべき点 : 3 つのフィールドが同じ MatchKey「userIdentifier」を持っています。これは、これらのフィールドの 1 つ以上がユーザーのマッチグループを解決する上で重要だからです。以下のシナリオを考えてみましょう :

1. 2 つ以上のイベントの IP アドレス (ip_address) が同じ場合、それらは同じマッチグループに属している可能性があります
2. 2 つ以上のイベントのクッキー ID (s_cookie) が同じ場合、それらは同じユーザーに属します
3. 2 つ以上のイベントのログイン ID (login_id) が同じ場合、それらは同じユーザーに属します

したがって、これら 3 つのフィールドに同じ MatchKey を設定することで、解決プロセス中にサービスがこれらのフィールドの 1 つ以上を比較することが可能になります。

timestamp と page_class という2つのフィールドは、パススルーカラムとしてマークしています。これは、これらのフィールドが解決プロセスには参加しないものの、AWS Entity Resolution からの出力が HAQM Neptune などの後続のソースに取り込まれる際に必要となる可能性があるためです。

次に、AWS Entity Resolution サービス内でルールベースのマッチングワークフローを作成する必要があります。このワークフローは、先ほど定義したスキーママッピングとともに、クリックストリームデータ (AWS Glue テーブルとして表現) を入力ソースとして設定します。処理の頻度として「Automatic (自動) 」を選択することで、新しいデータが到着した際に、マッチングワークフローが既に解決済みのマッチグループに対して新しいデータを継続的に解決します。このプロセスにおいて、サービスは新しいデータが既存のマッチグループに属するかどうかを識別し、属さない場合は新しいマッチグループを形成します。

自動処理のためには、入力ソースとなる HAQM S3 バケットで、サーバーレスのイベントバスである HAQM EventBridge の通知をオンにしておく必要があることにご注意ください。

上の図に示すように、AWS Entity Resolution 内で、userIdentifier を単一のルールとするルールベースのマッチングワークフローを作成する必要があります。このルールは、入力されるクリックストリームデータを評価し、同じ特性を持つレコードを単一のマッチグループにリンク、およびマッチングします。同じマッチグループ内のすべてのレコードには、同じ MatchID が割り当てられます。MatchID は、AWS Entity Resolution によって生成される固有の ID であり、各マッチグループ内のすべてのレコードに適用されます。

AWS Entity Resolution サービスは、ワークフロー作成プロセス中に指定された HAQM S3 バケットに、マッチングワークフローの出力を書き込みます。

マッチングワークフローの出力には、(デフォルトで) すべての入力フィールドに加えて、システムによって生成された以下のフィールドが含まれます : MatchRule、MatchID、InputSourceARN 。MatchRule は、マッチが発生した場合に、そのマッチの条件となったルールの名前を表します。一方、MatchID は、AWS Entity Resolution サービスによって生成され、各レコードに割り当てられる固有の ID です。2つ以上のレコードがルールによってマッチングされた場合、それらは同じマッチグループに属し、同じ MatchID を持ちます。

結果の説明

分かりやすさのために、この例では一部の列のみを含めています。 マッチングワークフローの Run-1 では、2 つのクリックストリームイベント (Click 1、Click 2) が、IP アドレス 192.168.117.155 に基づいてグループ化されています。これは、ip_address、s_cookie、または login_id を使用してイベントを同じ MatchID でグループ化する MatchRule「Rule 1」によるものです。

Input (Run-1):

Output (Run-1):

その後、新しいクリックストリームイベントが到着した際、そのイベントの 1 つが Click1・Click2 と同じ ip_address を持ち、さらに login_id を含んでいました。AWS Entity Resolution は、この新しいイベント (Click3) を前の 2 つのイベントとマッチングし、出力テーブルに示されているように、同じ MatchID を継承します。さらに出力には、そのマッチグループで以前に関連付けられたレコード (Click1 と Click2) も含まれていますが、これらは「recordid」のみが入力され、他の関連列はすべて空となっています。

Input (Run-2): 

Output (Run-2):

HAQM Neptune 内でのデータ接続

AWS Entity Resolution によってデータがマッチングされ、HAQM S3 に保存された後、マーケターは統合された顧客ビューを用いて実用的なインサイトを導き出すためのダウンストリームアプリケーションを構築することができます。製品レコメンデーション、製品アクティベーション、顧客の世帯特定は、あいまいさが解消されたユーザーとその収集された行動をリンクする一般的なユースケースです。HAQM Neptune は、あいまいさが解消されたエンティティ間の追加の関係性やリンクを特定するのに役立つサービスの 1 つです。

例えば、レコメンデーション領域を考えてみましょう。一般的なレコメンデーション手法として、製品評価などのユーザー行動データの分析に基づく強調フィルタリングがあります。強調フィルタリングにおける顕著な課題は「コールドスタート」問題です。これは、履歴データが存在しないユーザーに対してレコメンデーションエンジンが提案を生成できない場合に発生します。この問題は、クリックストリームデータソースの場合のような匿名訪問者を含むシナリオで特に顕著です。このコールドスタートの課題は、あいまいさが解消された新規の匿名顧客、潜在的な世帯、およびそれらの行動を収集し、既知のユーザープロファイルに「リンク」することで対処できます。AWS Entity Resolution は既知および未知のユーザーのあいまいさを解消し、HAQM Neptune のようなグラフデータベースは履歴フットプリントを形成するための関係性を生成できます。Figure 1 は、グラフデータベースが匿名ユーザーイベントと既知のユーザーイベントを使用して顧客の単一ビューを形成する方法を示すワークフローを示しています。HAQM Neptune は、Click1 (匿名メタデータ) 、Click2 (匿名メタデータ) 、および Click3 (既知のユーザーログイン、jon@doe.com ) 間のリンクを保存できます。

AWS Entity Resolution から HAQM Neptune へのデータ移行方法を見ていきましょう。このソリューションのパートでは、あいまいさが解消されたデータを保存するための HAQM Neptune クラスターが必要になります。データの一括ロード、クエリ、およびグラフの可視化を行うために、HAQM Neptune workbench が必要になります。これは、HAQM SageMaker AI 上でホストされる対話型開発環境 (IDE) で、コードの実行と可視化のための Jupyter と Jupyter notebooks を提供します。HAQM SageMaker AI は、あらゆるユースケースにおける ML モデルの構築、トレーニング、デプロイに使用されます。この IDE は、クエリと HAQM Neptune 管理操作を簡素化できる「ノートブックマジック」も提供します。HAQM Neptune クラスターとこの workbench は、AWS CloudFormation のクイックスタートテンプレートを使用して作成できます。AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティのリソースのモデル化、プロビジョニング、管理を可能にします。ユーザーは、この例で使用される AWS サービスの料金に対して責任を負います。コスト見積もりについては、AWS Pricing Calculator をご覧ください。

グラフデータモデルの選択は、私たちが答えたい質問に依存します。今回は、「何人の消費者またはグループが 1 つのデバイスを共有しているか？」という質問に答えるためにグラフモデルを使用します。これにより、4 つのノードと 2 つのエッジを持つデータモデルが作成されます。

ノード

1. Group (グループ) : AWS Entity Resolution によって割り当てられた MatchID
2. Device (デバイス) : クリックストリームイベントから得られる統合されたデバイスの詳細
3. IP : クリックストリームイベントから得られる IP アドレス
4. Login (ログイン) : ユーザーのログイン ID

エッジ

1. HAS_IP : Group ノードから IP ノードへの関係
2. HAS_DEVICE : Group ノードから Device ノードへの関係
3. HAS_LOGIN : Group ノードから Login ノードへの関係

データモデルが作成されたら、AWS Entity Resolution の出力用 HAQM S3 バケットから HAQM Neptune workbench で定義されたデータモデルへのデータ変換を開始できます。以下のコードサンプルでは、データを Gremlin 一括ローダーフォーマットに変換し、bulkload/nodes または bulkload/edges プレフィックスの下の HAQM S3 バケットに書き出します。

# Read from AWS Entity Resolution output s3 bucket
import awswrangler as wr
df = wr.s3.read_csv('s3://s3_path/s3_filename')

ノードとエッジを作成します。

## Create group nodes
sor = df[['MatchID']].drop_duplicates().dropna()
sor['~id'] = 'Group-'+sor['MatchID']
sor['~label'] = 'Group'
sor['MatchID:String'] = sor['MatchID']
wr.s3.to_csv(sor, 's3://s3_path/bulkload/nodes/groups.csv', columns = ['~id', '~label', 'MatchId:String(single)'], index = False)

## Create login nodes
lg= df[['login_id', 'RecordId']].drop_duplicates().dropna(subset='login_id')
lg['~id'] = 'Login-'+lg['login_id']
lg['~label'] = 'Login'
lg.rename(columns= {'RecordId': 'RecordId:String', 'login_id': 'login_id:String(single'}, inplace = True)
wr.s3.to_csv(lg, 's3://s3_path/bulkload/nodes/login.csv', columns = ['~id', '~label', 'Login:String(single)', 'recordId:String'], index = False)

## Create device nodes
df['system_id'] = df[['user_agent_device_family','user_agent_os_version','user_agent_os_family']].astype(str).replace('nan', np.nan).sum(1, skipna = True).replace(0, np.nan)
device_nodes = df[['system_id', 'RecordId']].drop_duplicates().dropna(subset='system_id')
device_nodes['~id'] = "Device-" + device_nodes['system_id']
device_nodes['~label'] = "Device"
device_nodes.rename(columns = ['RecordId': 'RecordId:String', 'system_id': 'system_id:String(single)', inplace = True)
wr.s3.to_csv(device_nodes[['~id', '~label', 'system_id:String(single)']], 's3://s3_path/bulkload/nodes/Devices.csv',index = False
)
## Create IP nodes
ip = df[['ip', 'RecordId']].drop_duplicates().dropna(subset='ip_address')
ip['~id'] = 'IP-'+ip['ip']
ip['~label'] = 'IPAddress'
ip.rename(columns= {'RecordId': 'RecordId:String', 'ip_address': 'ip_address:String(single)'}, inplace = True)
wr.s3.to_csv(ip[['~id', '~label', 'ip_address:String(single)', 'recordId:String']], 's3://s3_path/bulkload/nodes/ips.csv',index = False)

## Group to login edges
has_login= df[['MatchID', 'login_id']].drop_duplicates().dropna(subset='login_id')
has_login['~to'] = "Login-"+ has_login['login_id']
has_login['~from'] = "Group-"+ has_login['MatchID']
has_login['~label'] = "HAS_LOGIN"
has_login['~id'] = has_login['~label'] +'-' + has_login['~from'] + has_login['~to']
wr.s3.to_csv(has_login, 's3://s3_path/bulkload/edges/has_login.csv', columns = ['~id', '~label', '~from', '~to'], index = False)

## Group to Ip edges
has_ip= df[['MatchID', 'ip_address']].drop_duplicates().dropna()
has_ip['~to'] = "IP-"+ has_ip['ip_address']
has_ip['~from'] = "Group-"+ has_ip['MatchID']
has_ip['~label'] = "HAS_IP"
has_ip['~id'] = has_ip['~label'] +'-' + has_ip['~from'] + has_ip['~to']
wr.s3.to_csv(has_ip, 's3://s3_path/bulkload/edges/has_ip.csv', columns = ['~id', '~label', '~from', '~to'], index = False)

## Group to Device edges
in_group = df[['system_id', 'MatchID']].drop_duplicates().dropna()
in_group['~to'] = "Device-"+ in_group['system_id']
in_group['~from'] = "Group-"+ in_group['MatchID']
in_group['~label'] = "HAS_DEVICE"
in_group['~id'] = in_group['~label'] +'-' + in_group['~from'] + in_group['~to']
wr.s3.to_csv(in_group, 's3://s3_path/bulkload/edges/has_device.csv', columns = ['~id', '~label', '~from', '~to'], index = False)

すべての変換が完了したら、ノートブックマジックを使用して一括ロードを実行します。ロードを実行するには、HAQM Neptune IAM ロールと HAQM S3 バケットの詳細が必要になります。

%load -s s3://s3_path/bulkload --store-to loadres

ロードが失敗した場合、load_status ノートブックマジックを使用してロードのステータスとエラーを検証してください。

%load_status {loadres['payload']['loadid']} --errors

あいまいさが解消された識別子の可視化とクエリ

HAQM Neptune は、オープンソースのグラフ可視化ツールである Graph Explorer や、HAQM Neptune workbench を含む、複数の可視化オプションをサポートしています。HAQM Neptune workbench は、コードの実行に加えて、グラフクエリ言語の探索もサポートしています。このブログでは、解決された識別子間の相互接続を理解し、一般的な質問に答えるために、HAQM Neptune workbench でのクエリ例とグラフの可視化を紹介します。

「グループが与えられた場合、そのグループに関連するメタデータ項目と AWS Entity Resolution によって統合された RecordID を見つける」

%%oc

Match (g:Group {`~id`:'Group-a3806aa4fb593e7f856fba938c24ab19'})-[:HAS_IP | :HAS_DEVICE | :HAS_LOGIN]->(p)

return g.`~id` as MatchID, labels(p) as MetadataType, p.`~id` as ElementMap, collect(p.RecordId)

結果 :

可視化 :

「グループが与えられた場合、同じデバイスを共有する他のすべてのグループまたは消費者を見つける」

Match (g:Group {`~id`:'Group-f10509080d994778a8989142ca0891ea'})-[:HAS_DEVICE]->(d)
with d
Match (g2)-[i:HAS_DEVICE]->(d)
return g2.`~id` as Groups, d.system_id as Device

結果 :

可視化 :

「デバイスが与えられた場合、そのデバイスを使用したすべてのグループと、そのグループに関連するすべての IP アドレスを取得する」

Match (g:Group)-[:HAS_DEVICE]->(d:Device {`~id`:'Device-Mobile Safari3.0.5iOS'})
with g, d
Match (g)-[:HAS_IP]->(addr)
return g.MatchID as MatchID, addr.ip_address as IPAddress, d.system_id as Device

結果 :

可視化 :

まとめ

AWS Entity Resolution と HAQM Neptune を統合することで、匿名訪問者間のネットワークと相互接続を理解することができます。HAQM Neptune 上の 360 度顧客グラフにより、企業は特定された消費者の履歴データに基づく製品レコメンデーションの迅速化など、ほぼリアルタイムの製品レコメンデーションのための高度な分析を活用することができます。

このソリューションアーキテクチャは、重複を特定することでデータ品質を向上させ、エンティティ間の関係性を理解することで、イノベーション、分析、およびコンプライアンスを推進することができます。

開始するには、AWS Entity Resolution と HAQM Neptune にアクセスしてください。

エンドツーエンドのデータ管理ニーズに対しては、HAQM Connect Customer Profiles というマネージドサービスも利用できます。このサービスは、80 以上の SaaS アプリケーションのデータコネクターからのデータ取り込み、統合プロファイルの作成 (重複プロファイルを削除するためのエンティティ解決を含む) 、低レイテンシーのデータアクセスを提供し、エージェントが顧客一人ひとりに合わせたサービスを提供するために必要な顧客インサイトを提供します。関連する顧客情報の完全なビューを一箇所で得られることで、企業はよりパーソナライズされた顧客サービスの提供、より関連性の高いキャンペーンの実施、顧客満足度の向上を実現できます。AI を活用したコンタクトセンターである HAQM Connect を使用して統合顧客プロファイルを構築する方法についての記事や、Choice Hotels が統合された旅行者プロファイルを構築するために HAQM Connect Customer Profiles をどのように活用したかについて、動画をご覧いただけます。

 
本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文はこちら。