複数のレスポンストラッキングフローチャートの使用

社内ですべてのキャンペーンに対して1つのレスポンストラッキングフローチャートを使用することもできます。 1つのアクションテーブルのみを使用する場合、システム管理者は、通常、そのアクションテーブルにデータを書き込むようにセッションフローチャートをセットアップします。

ただし、Campaignの実装によっては、個別にレスポンストラッキングフローチャートを関連付ける場合など、複数のアクションテーブルの使用が必要となる場合があります。

次のような場合、複数のレスポンストラッキングフローチャートを使用します。

オーディエンスレベルごとにレスポンストラッキングを行う

リアルタイム処理要件とバッチ処理要件がある

大量のデータの重複を避けたい

状況に応じて固有のデータをハードコードする

カスタムレスポンス処理ロジックが必要

オーディエンスレベルごとにレスポンストラッキングを行う

(必須)レスポンスの受信とトラッキングを行う各オーディエンスレベルに対して、それぞれレスポンストラッキングフローチャートが必要です。 レスポンスプロセスは着信セルのオーディエンスレベルで動作し、自動的にそのオーディエンスレベルの適切なレスポンス履歴テーブルへの書き込みを行います。 2つの異なるオーディエンスレベル、たとえば顧客と世帯に対してレスポンストラッキングを行う場合、2つのレスポンスプロセスが必要となり、通常、これらは2つのレスポンストラッキングフローチャートに実装されます。

リアルタイム処理要件とバッチ処理要件がある

(必須)レスポンストラッキングセッションの大部分がバッチフローチャートであり、定期的にアクションテーブルに入力されるイベントを処理します(たとえば、顧客の買い物データを夜間に処理するなど)。 レスポンストラッキングの実行頻度は、アクションテーブルへの入力に使用されるトランザクションデータの可用性に依存します。

たとえば、異なるチャネル(Webとダイレクトメール)からのレスポンスを処理する場合、着信トランザクションデータの可用性が各チャネルによって異なるので、個々にレスポンス処理セッションが必要になる場合があります。

大量のデータの重複を避けたい

(オプション)大量のトランザクションデータ(1日に何百万もの販売トランザクションが発生する場合など)を評価しなければならない場合、アクションテーブルに対してETL (抽出、加工、書き込み)を行うのではなく、ソースデータに対して直接マッピングを行うレスポンストラッキングフローチャートを構築することが必要になる場合があります。

たとえば、書込みプロセスが電子商取引システムの購入トランザクション履歴テーブルから直接トランザクションをプルし(特定の日付範囲に基づいて)、レスポンスプロセスで、この書込みプロセスから直接このテーブル内の列にマッピングを行うレスポンストラッキングフローチャートを構築できます。

状況に応じて固有のデータをハードコードする

(オプション)異なる複数のチャネルなど、状況に応じて固有データ(レスポンスタイプなど)をハードコードすることが必要になる場合があります。 たとえば、チャネル(「コールセンター」など)固有の特定のレスポンスタイプ(「照会」など)をトラッキングしたい場合、これらのレスポンスをフィルタするユーザ定義項目を作成し、レスポンス処理フローチャートでこの項目を使用してコールセンターデータベースからすべての照会をプルできます。 1つのアクションテーブルにデータを書き込むよりも、ユーザ定義項目を使用してレスポンストラッキングに必要なデータを作成し、ソースから直接データをプルする方が便利な場合があります。

カスタムレスポンス処理ロジックが必要

(オプション) レスポンスの帰属先を判断するための独自のルールを記述する必要がある場合、カスタムレスポンストラッキングロジックを実装するレスポンストラッキングフローチャートを作成できます。 たとえば、「3つ購入で1つ無料」のオファーへのレスポンダを識別する必要がある場合、個人が対象レスポンダであるかどうかを判断する複数のトランザクションが必要になります。 対象個人を検出した上で、レスポンスプロセスにそれらを入力し、処理コードと適切なレスポンスタイプを使用してレスポンスを記録することができます。