イベントの操作
イベントとは、Interact API と直接対話する、設計環境における Interact の 3 つの構成要素の 1 つです。Interact API と連携するようにタッチポイントをコーディングする場合には、postEvent メソッドを使用してイベントを参照します。Interact API で使用されるイベントの名前は、設計環境における構成時のイベントの名前と一致していなければなりません。この名前には大/小文字の区別はありません。
イベントでは、事前に定義されている以下のアクションが 1 つまたは複数トリガーされます。
*
再セグメントのトリガー: ランタイム環境で、訪問者のセッションの現在の日付を使用して、インタラクティブ・チャネルに関連付けられている現在のオーディエンス・レベルのすべてのインタラクティブ・フローチャートを再び実行します。
インタラクションを設計する際には、特定のフローチャートを指定しない限り、再セグメントでは、このインタラクティブ・チャネルに関連付けられているすべてのインタラクティブ・フローチャートが現在のオーディエンス・レベルを使用して再び実行されること、および、オファーに対するあらゆる要求はすべてのフローチャートが完了するまで待機させられるということに留意してください。1 回の訪問における再セグメントの数が多すぎると、顧客が気付くほど、タッチポイントのパフォーマンスに影響が及ぶことがあります。
大量の新規データがランタイム・セッション・オブジェクトに追加された後には、顧客を新規セグメントに入れる必要があります。そのような新規データは、Interact API からの要求 (オーディエンスの変更など) または顧客による操作 (ウィッシュ・リストやショッピング・カートへの新規アイテムの追加など) によってもたらされる可能性があります。
*
オファー・コンタクトをログに記録: ランタイム環境で、データベース・サービスについて勧められたオファーにフラグを付けて、そのオファーをコンタクト履歴に記録します。
Web 統合の場合、ベスト・プラクティスは、オファーを要求するのと同じ呼び出しでオファー・コンタクトをログに記録して、タッチポイントとランタイム・サーバー間の要求の数を最小限に抑えることです。
タッチポイントが訪問者に提示されたオファーの処理コードを戻さない場合、ランタイム環境は、勧められるオファーの最新リストをログに記録します。
*
オファー承認をログに記録: ランタイム環境で、データベース・サービスについて選択されたオファーにフラグを付けてレスポンス履歴に記録します。
*
オファー拒否をログに記録: ランタイム環境で、データベース・サービスについて選択されたオファーにフラグを付けてレスポンス履歴に記録します。
複数のオファーのログ記録のアクションを含むイベントを作成する場合、Interact API は、関連付けられているオファーについて同じアクションを実行するということに留意してください。したがって、相反するオファー承認とオファー拒否の両方をログに記録するイベントは作成しないでください。ただし、オファー・コンタクトとオファー承認をログに記録するイベント、またはオファー・コンタクトとオファー拒否をログに記録するイベントを作成することは、ご使用の環境において役に立つ場合があります。
デフォルトで、ランタイム環境では、2 つのタイプのレスポンス (オファー承認とオファー拒否) をトラッキングすることができます。構成プロパティー「accept」「reject」を使用して、「オファー承認をログに記録」イベントと「オファー拒否をログに記録」イベントで記録されるレスポンスのタイプを変更することができます。
また、Interact API では、イベントを使用して、API でイベント・パラメーターによって定義されたアクションをトリガーすることもできます。それらのイベントには、カスタム・テーブルへのロギング、複数のレスポンス・タイプのトラッキング、特定のフローチャートを指定して実行といった処理が含まれます。System Reaction が定義されていないイベントをいくつか作成することや、予約イベント・パラメーターと共に使用するために同じシステム反応 (「コンタクトのログ記録」など) を含むイベントを複数作成することが必要な場合があるかもしれません。
ログに記録するレスポンス・タイプごとに 1 つずつというように、「オファー承認のログ記録」アクションを含むイベントを複数作成する場合や、別々のレスポンス・タイプをログに記録するため、あらゆる postEvent 呼び出しに使用する、「オファー承認をログに記録」アクションを含むイベントを 1 つ作成する場合があります。
例えば、レスポンスのタイプごとに、「オファー承認をログに記録」アクションを含むイベントを 1 つずつ作成するとします。UA_UsrResponseType テーブル [as Name(code)] で、Explore (EXP)、Consider (CON)、Commit (CMT) というカスタム・レスポンスを定義します。それから、3 つのイベントを作成して、それらに LogAccept_Explore、LogAccept_Consider、LogAccept_Commit という名前を付けます。3 つのイベントは、すべて、まったく同じ (オファー承認をログに記録」アクションが含まれている) ですが、Interact API を使用して作業するユーザーが区別できるようにするため、異なる名前が付けられています。
または、「オファー承認をログに記録」アクションを含むイベントを 1 つ作成して、すべてのカスタム・レスポンス・タイプに使用することもできます。例えば、それに LogCustomResponse という名前を付けるとします。
Interact API を使用して作業する場合、これらのイベントには機能上の違いはありませんが、命名規則によってコードがわかりやすくなることがあります。また、それぞれのカスタム・レスポンスに別々の名前を付ければ、「チャネル・イベント・アクティビティー・サマリー」レポートに、より正確な情報が表示されるようになります。
予約パラメーターおよび postEvent メソッドについて詳しくは、「Interact 管理者ガイド」を参照してください。
システム定義のイベント
「イベント」タブには、デフォルトのカテゴリーである「システム定義済みカテゴリー」が表示されます。このカテゴリーのイベントは、編集、追加、または削除することはできません。このカテゴリーには、Interact API に対応するイベントが含まれます。それらのイベントすべてについて、タッチポイントで発生する頻度を「チャネル・イベント・アクティビティー・サマリー」レポートで監視することができます。
そのようなイベントには、以下のものがあります。
*
*
*
*
*
*