Cox AutomotiveがAmazon Neptuneを活用したIDグラフでデジタルパーソナライゼーションを強化

Cox Automotive Inc. は、自動車の購入、販売、所有、利用をすべての人にとってより簡単にする会社です。グローバル企業である同社は34,000以上のチームメンバーと、Autotrader®、Clutch Technologies、Dealer.com®、Dealertrack®、Kelley Blue Book®、Manheim®、NextGear Capital®、VinSolutions®、vAuto®、Xtime® などのブランドファミリーを有しています。5大陸にまたがる数百万の自動車購入予定者や、クライアントである4万の自動車ディーラー、その他多くの自動車関連企業が、今後、何世代にもわたって繁栄できるよう支援することに情熱を注いでいます。

Dealer.comなどのプラットフォームでeコマースのウェブサイトを運営している自動車ディーラーは、サイト訪問者をターゲットに、関連性の高いパーソナライズされたコンテンツを提供する革新的な方法を必要としています。ディーラーは、パーソナライズされたコンテンツを提供するために、買い物客をセグメント化し、関連する広告を表示し、さらにさまざまな買い物客のセグメントごとにパーソナライズされたEメールのドリップキャンペーンを実施するためのツールを必要としています。

従来、ウェブサイト訪問者は、サードパーティCookieを使用して複数のドメインにまたがり追跡されていました。既にいくつかのブラウザはサードパーティCookieの段階的廃止を完了しており、残りのブラウザは2022年までに段階的に廃止される予定です。この変更は、Cox Automotiveがオンラインの買い物客にパーソナライズされたコンテンツを提供する方法に大きく影響を及ぼすものです。

Cox Automotiveの各事業部門は、買収によって統合された後、サイロ化した状態で発展してきました。そのため、事業部門間のデータを統合し、消費者世帯の全体的な360度ビューを作成する必要性が高まっています。

Consumer Insightsのチームは、ブランドをまたいで買い物客のパーソナライゼーションサービスを提供することに注力しています。そのソフトウェアは、消費者、自動車販売店、自動車OEMに提供されています。

2019年10月にConsumer Insightsのチームは、サードパーティのCookieへの依存度を下げつつ、ビジネスユニット間で活用できる世帯の360度ビューを構築するニーズの高まりに対応するため、IDグラフのアプローチを使用することを決定しました。チームは、このIDグラフのニーズに対して、Amazon Neptuneを使用することを決定しました。

Neptuneはフルマネージド型のグラフデータベースサービスです。このサービスでは、高度に接続されたデータセットを使用したアプリケーションを簡単に構築および実行できます。Neptuneは、数十億のリレーションシップを保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用の高性能グラフデータベースエンジンです。Neptuneは、Property Graphと Resource Description Framework (RDF) 標準の両方をサポートしています。

Consumer Insightsのチームはパーソナライゼーション機能を構築するために、IDグラフで、下記を含むいくつかのデータソースを使用しています。

• Pixall Dataと呼ばれるCox Automotive独自のデータ
• 車両の在庫
• 消費者の閲覧履歴
• 車両の取引
• 車両のリード

最初のフェーズでConsumer Insightsのチームは、消費者の閲覧履歴をCRM内のデータ（リードとトランザクション）と結びつけるIDグラフを構築しました。次の図は、チームのアプローチの概要を示しています。それは、マルチチャネルマーケティングのパーソナライゼーションのあらゆる側面を推進するようなIDグラフのビジョンを作り上げながら、現在の課題に対処するアプローチです。

Neptuneが選ばれる理由

Consumer Insightsのチームは、実験として、IDグラフの接続されたデータセットを、マネージド型リレーショナルデータベースやキーバリューストア、インメモリデータベース、グラフデータベースで保存してみました。この実験では、パフォーマンスとTCOに焦点が当てられました。その結果、Neptuneに有利となる重要な技術的側面が2点、明らかとなりました。

1. データモデリングの簡素化 — 従来のリレーショナル・データベースは、その厳格なスキーマと関係性から、グラフ問題のデータモデルを構築する上で難題となっていました。Consumer Insightsのチームは、適切なデータモデルを構築するために何度も試行錯誤を繰り返しました。このデータモデルは、新しい頂点や辺が特定される際にクエリーのパフォーマンスやSQLで目的のクエリーを書くことが難しく、拡張することが困難でした。一方で、データをグラフでモデリングすることで、ビジネスのユースケースを模倣することができました。これは、Neptuneがユースケースに自然にフィットしていることを示す最初の兆候でした。
2. クエリのパフォーマンス — Neptuneはすぐに使用でき、チームのニーズを満たすクエリパフォーマンスを提供することで、チームが最適化に費やす時間を節約してくれました。エッジと頂点が追加されても、クエリのパフォーマンスは悪化しないまま拡張することができました。

IDグラフ

Neptuneが提供するデータモデルの簡略化を明らかにするために、Consumer InsightsチームはIDグラフを下図のように視覚化しました。これは、Cookie、IP アドレス、CRM IDの3つのエンティティ (頂点) 間のリレーションシップを示しています。

この図は、IDグラフで実際に使用されるGremlinクエリを示しています。次に示すクエリは、簡単な手順によってビジターのID解決を容易にするものです。このクエリは、最初に与えられたビジター (request.uid) に対して、グラフを走査し、そのビジターへのエッジを持つCRM IDの頂点を見つけます。そしてそのCRM IDに接続するエッジを持つすべてのビジターIDを特定します。

この時点で、前述の2つのビジターIDが特定されています。この２つのビジターを基に、そのビジターへのエッジを持つすべてのIPアドレスを特定します。そのIPアドレスを基に、IPアドレスに接続されたエッジを持つすべてのビジターIDを見つけることができます。前図では、1件のビジターIDが、グラフを辿ると6件のビジターIDになります。

IDグラフを強化するビジネスプロセス

データベースとしてNeptuneを選択した後、Consumer Insightsのチームは、次のステップとして実際にIDグラフを構築することに着手しました。

IDグラフは、ID解決を提供するパーソナライズマーケティングの中核をなすものです。これは、householding（世帯単位のデータの関連付け）とリードマッピングという、消費者と世帯の360度ビューを作成するための2つの異なるステップ上に構築されています。

Householding

Householdingとは、買い物客や買い物見込みに関するデータについて、「世帯」を特定して結びつけるプロセスのことです。Householdingでは、さまざまなウェブサイト、デバイス、インターネット接続にまたがる匿名の消費者アクティビティ（Cookie）を結びつけることができます。

Cox Automotiveのデータサイエンスチームは、複数のAI/MLベースの確率的プロセス（確率論に基づくプロセス）を実行し、データを拡充し、まとめてマッピングしています。確率的プロセスのアウトプットでは、IPアドレス (IDグラフの頂点) とビジターID (Cookie) の間に1対多のリレーションシップが作成されます。

拡充されたhouseholdingデータにより、Neptuneへ一括ロードするための3つのファイルが作成されます。

• IPアドレス (頂点)
• ビジターID (頂点)
• リレーションシップ (エッジ)

次の表に、IPアドレスの頂点を含むファイルを示しています。

次の表は、ビジターIDの頂点を含むファイルを示しています。

次の表は、IPからビジターへのエッジを含むファイルを示しています。

リードマッピング

リードマッピングのプロセスでは、Cox Automotiveブランドのサイトで記入されたリードフォームからデータが収集されます。リードフォームは、内部で生成されたcrm_id (IDグラフの頂点) とビジターID (自動車購入予定者のCookie) にマッピングされます。

リードマッピングのプロセスにより、Neptuneへ一括ロードするための3つのファイルが作成されます。

• CRM ID (頂点)
• ビジターID (頂点)
• リレーションシップ (エッジ)

次の表は、CRM IDの頂点を含むファイルを示しています。

次の表は、リードビジターIDの頂点を含むファイルを示しています。

次の表は、CRM IDからビジターへのエッジを含むファイルを示しています。

IDグラフをインクリメンタルに更新

この記事の執筆時点では、アイデンティグラフは約5億個のエッジと約4億個の頂点からなり、db.r5.2xlargeインスタンスタイプのNeptuneクラスター上で実行されています。

Householdingのプロセスでは、毎日完全なデータセットが作成され、Amazon Simple Storage Service (Amazon S3) バケットに保存されます。Neptuneのパフォーマンスを最適化するために、Consumer InsightsのチームはAmazon EMRのジョブを開始します。このジョブは、今日の完全なデータと前日のデータセットとの差分ファイルを毎日作成しています。新規の追加や変更は、Neptune バルクロードAPIを使用してNeptuneに一括アップロードするようスケジューリングされています。バルクロードが完了すると、別のEMRジョブが開始され、Gremlin APIを使用して新規の削除が処理されます。最後に、EMRジョブはGremlin APIを使用して、孤立した頂点をすべて削除します。

リードマッピングのデータプロセスでは、増分データセットが作成されS3バケットに格納されます。EMRジョブの始動により、リードマッピングデータセットは毎晩Neptuneへ一括ロードされます。

全体的なソリューションアーキテクチャ

次のブロック図は、Consumer Insightsのチームがビジネスユニットに完全なパーソナライゼーション機能を提供する計画の概要を示しています。この機能は、Neptuneからの世帯とリードのマッチング、そしてDynamoDBからの閲覧履歴を、買い物客のセグメンテーションと車両のレコメンデーションと組み合わせます。Autotrader®、Dealer.com®、Kelley Blue Book®、VinSolutions®などのビジネスユニットにまたがり利用されるダウンストリームのプロセスは、統合された世帯のビューに基づいてコンテンツのパーソナライゼーション、広告ターゲティング、リマーケティング、店舗でのパーソナライゼーションを促進します。黄色で強調表示されたブロックは、IDグラフの基本要素です。このセクションでは、さらにdeep diveし、IDグラフに使用されるアーキテクチャについて紹介します。

NeptuneによるID解決は、その下流のプロセスに対してリアルタイムのクエリ・応答を提供しているため、パーソナライゼーションAPIにとっては、ミッションクリティカルな要素です。したがって、耐障害性、高可用性、およびオペレーションの拡張性は、Consumer Insightsのチームにとって非常に重要です。これらの技術目標を容易にするために、Neptuneのライターノードはdb.r5.2xlargeインスタンスを使用し、複数のアベイラビリティゾーンにまたがる2つのリードレプリカを備えています。いずれのリードレプリカもライターノードと同じインスタンスタイプを使用しています。すべてのREST APIデータのルックアップは、両方のリードレプリカによって処理されます。水平なスケールアウトを可能にするために、クライアントアプリケーションはNeptuneのリーダーノードに直接アクセスするのではなく、Neptuneに組み込まれた負荷分散リーダーエンドポイントを使用します。

次の図は、IDグラフのソリューションアーキテクチャを示すもので、グラフ (Amazon S3、Amazon EMR、バルクローダーを使用)、Multi-AZ のNeptuneリードレプリカ、および組み込みのロードバランサーを段階的に更新する手順を示しています。

結論

Consumer InsightsのチームがNeptuneベースのID解決を展開した結果、個々の Cookieを使用した場合と比較して、平均で1世帯あたり2倍の閲覧履歴を得ることができました。これは、自動車購入予定者に向けた高度にパーソナライズされたコンテンツの作成を直接影響するもので、その結果、エンゲージメントやクリックスルー率、Eメール開封率が向上すると、チームは考えています。

執筆時点では、サードパーティCookieへの依存を減らし、消費者世帯の360度ビューを構築するという当面の目標には対処できています。広告セグメンテーションや車両レコメンデーションといったダウンストリームシステムは、新しいIDグラフと統合されつつあります。これらのダウンストリームプロセスのビジネスへの影響は、その統合が完了した後に定量化されるでしょう。

推奨事項

Consumer Insightsのチームは、IDグラフの構築と統合の9か月にわたるジャーニーを振り返って、グラフのユースケースに着手する他の企業、ソフトウェアアーキテクト、またはソフトウェアエンジニアを支援するために、次の教訓と推奨事項をまとめました。

トレーニングへの投資

チームにはグラフデータベースやNeptuneに関する社内のスキルセットはありませんでした。当初、チームはAWSと協力して12人のSDEを対象とした1日のトレーニングセッションを計画しました。トレーニングでは、GremlinおよびNeptuneのベストプラクティスに則ったグラフデータモデリングとクエリに焦点が当てられました。このトレーニングは、チームのグラフジャーニーにおいて非常に価値あるステップでした。

ベストプラクティスを理解する

ビジネスユースケースを理解し、既存のグラフの実装例から学ぶことは、予期しない誤りを回避する最善策の1つです。チームは、Best Practices: Getting the most out of Neptuneが、最適な技術設計に最も役立ったリソースの1つであると感じました。

PoC のためのNeptuneインスタンスの適正なサイジング設定

PoC を行う際に適切なインスタンスタイプを選択することは、PoCの総コスト、およびデモアプリケーションの構築に費やすエンジニアリングチーム全体の時間に大きな影響を与える場合があります。経験則として、PoCで既存のデータをNeptuneに一括ロードする場合、最大のインスタンスを確保することで、データの一括ロードにかかる全体時間を短縮し、全体のエンジニアリング時間とコンピューティングコストを削減することができます。一括ロードが完了した後に、インスタンスサイズをより小さいインスタンスタイプに切り替えることで、貴重なリソースを節約することができます。

著者について

Carlos Rendon氏はCox AutomotiveのPrincipal Technical Architectです。過去8年間、KBB.com、Autotrader.com、Dealer.com、およびVinSolutionsにおいて、消費者のリアルタイムパーソナライゼーション、車両レコメンデーション、および広告ターゲティングの提供に取り組んできました。

Niraj Jetly氏は、Amazon Web ServicesのNeptune担当のSoftware Development Managerです。AWSに入社以前は15年以上にわたり、CTO、VP-Engineering、Head of Product Managementとして、複数のプロダクトチーム、エンジニアリングチームを率いてきました。Niraj氏は、2014年にCIO of the year、2013年と2016年にトップ100人のCIOに選ばれるなど、15を超えるイノベーション賞を受賞しています。いくつかのカンファレンスで頻繁に講演しており、過去にはNPR、WSJ、The Boston Globeで引用されています。

本ブログの翻訳はソリューションアーキテクトの五十嵐が担当しました。原文はこちらのリンクから参照できます。