変換テーブルのデータ・ソース

通常の統合では、以下のように、オンライン (SaaS) のデータ・ソースとオンプレミス・データ・ソースの両方にアクセスする可能性があります。

• Web データは、Web チャネル・インターフェースからの情報が含まれる Web データマートで使用可能です。
• データは、SaaS IBM Digital Analytics ソリューションから IBM Digital Analytics Export (registrationid) および Livemail (その他の Web 関連データの場合) を使用してエクスポートできます。
• 顧客データ・ソース (データベースやフラット・ファイル (オンプレミス) など)。

以下の図は、データ・ソースを変換テーブルにフィードする方法を示しています。変換テーブルは、 IBM Digital Analytics registrationID と IBM Campaign オーディエンス ID (この例では、CustomerID) を使用して、複数製品にまたがるレコードを関連付けます。

以下の例では、変換テーブルにデータを設定する方法を決定する際に検討可能な、さまざまなシナリオを示しています。これらのシナリオは、複数データベースにまたがり、同じエンティティーに対応するレコードを識別するために、データ・マッチングを使用する例を示しています。

シナリオ 1: Web データと以下で同一のキー: IBM Campaign

シナリオ 1 では、Web データと顧客データの両方に同一のキー「RegistrationID」が含まれています。RegistrationID でマッチングを行い、対応するレコードを識別することができます。

シナリオ 2: Web データと Campaign で異なるキー、1 つの固有キーのバインディング

シナリオ 2 では、Web データはキーとして RegistrationID を使用し、顧客データはオーディエンス ID (CustomerID) を使用します。キーをバインドするために、E メール・アドレスが使用されます。

シナリオ 3: Web データと IBM Campaign で異なるキー、複数の固有キーのバインディング

• シナリオ 3a: 1 つのテーブルで複数の固有キーのバインディング
• シナリオ 3b: 複数のテーブルで複数の固有キーのバインディング
• シナリオ 3c: 複数のデータベースで複数の固有キーのバインディング (図はなし)

以下の例は、シナリオ 3a の『1 つのテーブルで複数の固有キーのバインディング』を示します。このシナリオでは、Web データはキーとして RegistrationID を使用し、顧客データはオーディエンス ID (CustomerID) を使用します。キーをバインドするために、E メール・アドレスと、追加の固有に識別するデータ・フィールド (Customerdata1、Customerdata2) が使用されています。

以下の例は、シナリオ 3b の『複数のテーブルで複数の固有キーのバインディング』を示します。このシナリオでは、Web データはキーとして RegistrationID を使用し、複数のディメンション・テーブルからのデータがビューを使用して表示されます。この結合されたビューは、キーとしてオーディエンス ID (CustomerID) を使用します。キーをバインドするために、E メール・アドレスと、いくつかの固有に識別するデータ・フィールドが使用されています。いずれの例でも、変換テーブルは次に RegistrationID と CustomerID を使用して個々のレコードを識別します。

API 呼び出しを使用したセグメント・データのキャプチャー

以下の図は、変換テーブルが Campaign と Digital Analytics の間で選択をマップする方法を示しています。IBM Digital Analytics セグメント・データと関連する情報は、IBM Campaign フローチャートで使用するために、API 呼び出しを使用してキャプチャーされます。