訪問者のアクションによってトリガーされるイベントの定義

イベントの例

イベントの命名と Interact API

Interact API と連携するようにタッチポイントをコーディングする場合には、postEvent メソッドを使用してイベントを参照します。Interact API で使用されるイベントの名前は、設計時環境における構成時のイベントの名前と一致していなければなりません。イベント名の先頭文字は英字にする必要があります。それに続く文字は、文字、10 進数 (半角または全角)、アンダースコアーが可能です。この名前には大/小文字の区別はありません。

イベントのモニター

タッチポイントでこれらすべてのイベントが発生する頻度をモニターする場合は、チャネル・イベント・アクティビティー・サマリー・レポートを参照してください。

事前定義アクション

イベントでは、事前に定義されている以下のアクションが 1 つ以上トリガーされます。

• 再セグメンテーションのトリガー: ランタイム環境では、訪問者のセッションの現行データを使用して、対話式チャネルに関連付けられた現在のオーディエンス・レベルに対応するすべての対話式フローチャートが再び実行されます。

  対話の設計時に特定のフローチャートを指定しない限り、再セグメンテーション・アクションによって、この対話式チャネルに関連付けられたすべての対話式フローチャートが現在のオーディエンス・レベルを使用して再び実行され、オファーに対するどのような要求もすべてのフローチャートが完了するまで待機させられます。1 回の訪問における再セグメンテーションの数が多すぎると、顧客が気付くほど、タッチポイントのパフォーマンスに影響が及ぶことがあります。

  意味のある新規データがランタイム・セッション・オブジェクトに追加された後、顧客を新規セグメントに配置します。 意味のある新規データとは、例えば、Interact API からの要求 (オーディエンスの変更など) の新規データや、顧客アクション (お気に入りリストまたはショッピング・カートへの新規項目の追加など) の新規データなどです。

• オファー・コンタクトをログに記録: ランタイム環境で、データベース・サービスについて勧められたオファーにフラグを付けて、そのオファーをコンタクト履歴に記録します。

  Web 統合の場合、オファーを要求するのと同じ呼び出しでオファー・コンタクトをログに記録して、タッチポイントとランタイム・サーバー間の要求の数を最小限に抑えてください。

  Interact が訪問者に提示したオファーの処理コードをタッチポイントが戻さない場合、ランタイム環境は、勧められるオファーの最新リストをログに記録します。

• オファー承認をログに記録: ランタイム環境で、データベース・サービスについて選択されたオファーにフラグを付けてレスポンス履歴に記録します。

• オファー拒否をログに記録: ランタイム環境で、データベース・サービスについて選択されたオファーにフラグを付けてレスポンス履歴に記録します。

• ユーザー式のトリガー:式アクションとは、Interact マクロを使用して定義できるアクションのことです。これには、関数、変数、および演算子が含まれます (EXTERNALCALLOUT を含む)。任意のプロファイル属性に式の戻り値を代入することができます。

  「ユーザー式のトリガー」の横にある編集アイコンをクリックすると、標準の「ユーザー式」の編集ダイアログが表示されます。 このダイアログを使用して、オーディエンス・レベル、結果を代入するオプションのフィールド名、および式自体の定義を指定することができます。

• イベントのトリガー: 「イベントのトリガー」アクションを使用して、このアクションによってトリガーするイベントの名前を入力することができます。既に定義されているイベントを入力すると、そのイベントがこのアクションの実行時にトリガーされます。入力するイベント名が存在しない場合、このアクションにより、指定されたアクションでそのイベントが作成されるようになります。

イベント、ロギング、および Interact API

オファーをログに記録する複数のアクションが含まれたイベントを作成した場合、Interact API は、関連付けられたオファーについて同じアクションを実行します。したがって、オファー承認とオファー拒否の両方をログに記録するイベントは作成しないでください。それらは相互に矛盾するからです。ただし、オファー・コンタクトとオファー承認をログに記録する単一のイベント、またはオファー・コンタクトとオファー拒否をログに記録する単一のイベントを作成することは、ご使用の環境において役に立つ場合があります。

デフォルトで、ランタイム環境では、2 つのタイプのレスポンス (オファー承認とオファー拒否) をトラッキングすることができます。構成プロパティー「accept」と「reject」を設定することにより、「オファー承認をログに記録」イベントと「オファー拒否をログに記録」イベントで記録されるレスポンスのタイプを変更することができます。

Interact API は、イベントを使用して、API でイベント・パラメーターによって定義されたアクションをトリガーすることもできます。それらのイベントには、カスタム・テーブルへのロギング、複数のレスポンス・タイプのトラッキング、特定のフローチャートを指定して実行といった処理が含まれます。場合によっては、システム反応が定義されていないイベントをいくつか作成したり、予約イベント・パラメーターと共に使用するために同じシステム反応 (「コンタクトのログ記録」など) のイベントを複数作成したりする必要があります。

「オファー承認をログに記録」アクションを含むイベントを複数 (ログに記録するレスポンス・タイプごとに 1 つ) 作成することもできます。あるいは、「オファー承認をログに記録」アクションを含むイベントを 1 つだけ作成し、別々のレスポンス・タイプをログに記録するために使用するすべての postEvent 呼び出しに使用することもできます。

例えば、レスポンスのタイプごとに、「オファー承認をログに記録」アクションでイベントを作成します。UA_UsrResponseType テーブルの [名前 (コード)] で次のカスタム・レスポンスを定義します。「参照 (EXP)」、「考慮 (CON)」、および「確定 (CMT)」。その後、3 つのイベントを作成し、それらに LogAccept_Explore、LogAccept_Consider、および LogAccept_Commit という名前を付けます。3 つのイベントは、すべて同じ (「オファー承認をログに記録」アクションが含まれている) ですが、Interact API を使用して作業するユーザーが区別できるようにするため、異なる名前が付けられています。

また、「オファー承認をログに記録」アクションで単一のイベントを作成して、すべてのカスタム・レスポンス・タイプに使用することもできます。これには、例えば LogCustomResponse という名前を付けます。

Interact API を使用して作業する場合、これらのイベントには機能上の違いはありませんが、命名規則によってコードがわかりやすくなることがあります。また、それぞれのカスタム・レスポンスに別個の名前を付けると、「チャネル・イベント・アクティビティー・サマリー」レポートに表示される情報が、より正確になります。

独自のカスタム・コンタクト・コードを使用して、postEvent 呼び出しで使用することができます。これを実行するには、新しいコンタクト・ステータス・コードを UA_ContactStatus に追加し、コンタクト・イベントが通知されるたびに、それを利用します。カスタム・コンタクト・コードを実行時環境で定義することもできます。カスタム・コンタクト・コード用に UI に追加されたアクションは、システム・テーブル上のもののアクションを上書きします。

例:

Campaign システム・テーブル UA_ContactStatus に、コンタクト・ステータス・コード「OPEN」、および CountasContact 列に「1」のカスタム・エントリーを追加しました。UI で、構成設定 Interact | services | contactHist | contactStatusCodes の下に、コード「OPEN」およびアクション「None」を追加する場合、「OPEN」コンタクト・ステータス・コードが postEvent 呼び出しで使用されると、正しいコンタクトとはみなされません。そのため、UA_ContactStatus テーブルに設定したアクションよりも、UI に設定したアクションの方が優先されます。

予約パラメーターおよび postEvent メソッドについて詳しくは、「Interact 管理者ガイド」を参照してください。