データウェアハウス統合は、Web Experimentation および Feature Experimentation モジュールのプレミアムアドオンとして提供されています。詳細については、カスタマーサクセスマネージャーにお問い合わせください。
- Redshift cluster type: 使用する Redshift のソースが Provisioned クラスターか Serverless ワークグループかを選択します。
- Redshift cluster ID: Provisioned クラスターの場合は、そのクラスター ID を入力します。
- Redshift serverless workgroup: Serverless ソースの場合は、Redshift Serverless ワークグループの名前を入力します。
- Region: Redshift クラスターが存在するリージョンコードを入力します。
- Database: コンバージョンデータを含むデータベースを入力します。
- Frequency: Kameleoon がゴールデータを更新する頻度を選択します。
- Query: Amazon Redshift からコンバージョンデータを取得する SQL クエリを記述します。
クエリ形式
クエリは次の特定の形式に従う必要があります：SELECT visitor_id, conversion_timestamp FROM your_events_table
ここで、visitor_id は訪問者の一意の ID を表す列で、conversion_timestamp はコンバージョンが発生した正確な時刻を表す列です。Amazon Redshift では、conversion_timestamp 列は Timestamp 型の列である必要があります。
各コンバージョンに収益を関連付ける場合は、クエリを次の代替形式に従わせる必要があります：
SELECT visitor_id, conversion_timestamp, revenue FROM your_events_table
ここで、revenue は各コンバージョンの収益を含む列です。
より複雑なクエリでは、次のようにサブクエリを作成して、この形式に従うことができます：
SELECT visitor_id, conversion_timestamp, revenue FROM ( {your_original_query} ) AS subquery
Kameleoon がコンバージョンデータをポーリングする仕組み
Kameleoon は、ゴールの背後にある Amazon Redshift のコンバージョンデータを、選択した Frequency に従ってポーリングし、タイムスタンプでフィルタリングするWITH 句をクエリに追加します。実行のたびにイベント履歴全体を再読み込みするのではなく、Kameleoon は増分でポーリングします。各ポーリングジョブは最後に成功したポーリング時点を記録し、次回の実行では、その時点以降の新しいレコードの時間枠だけをクエリします。この時間枠だけをクエリすることで、Kameleoon がすでにインポートしたデータを再スキャンしないため、各ポーリングが高速になります。Kameleoon はコンバージョンをその頻度で収集しますが、実験結果にマージするのは 1 日に 1 回だけです。
ポーリングは常に前方に進むため、最後に成功したポーリング時間枠よりも前のタイムスタンプで Amazon Redshift に到着したレコードを、Kameleoon が見逃すことがあります。遅延レコードは、データパイプラインがコンバージョンイベントを書き込むのに時間がかかるために発生します。そのため、Kameleoon が所属する時間枠をすでにポーリングした後で、レコードが Amazon Redshift に到着します。見逃しを防ぐには、Customer Success Manager に依頼して、下記のインジェスチョン時間枠をパイプラインの通常の到着遅延に合わせてください。
Kameleoon は、遅延レコードのタイムスタンプが、まだポーリングしていない時間枠に含まれている間だけ、そのレコードをインポートします。ポーリング時点が 1 日を超えると、Kameleoon はその日を再読み込みしないため、その日の遅延行や修正済みの行はインポートしません。
インジェスチョン時間枠
既定では、Kameleoon は、ゴールのコンバージョンイベントが発生してから Amazon Redshift のウェアハウスで利用可能になるまでの間に、最大 1 時間を許容します。ポーリング時間枠は、この遅延を自動的に考慮します。パイプラインで Amazon Redshift へのイベント書き込みに 1 時間を超える時間がかかる場合（例：バッチ処理や夜間の ETL ジョブが原因の場合）、その遅延レコードはポーリング時間枠の外に落ち、取りこぼされます。Customer Success Manager に連絡し、遅延をパイプラインの実際の到着遅延に一致するように延長してください。失敗したポーリングとスキーマの変更
ポーリングが失敗すると、ポーリング時点は元の位置のままになります。ポーリング時点とは、Kameleoon がレコードのインポートを完了した時刻のことです。そのため、次の定期ポーリングは同じ時点から開始し、同じ時間枠を再試行します。クエリが再び成功すると、Kameleoon はその時間枠のレコードをインポートします。 スキーマの変更は、何が変わったかによって、結果に次の 2 通りのどちらかの影響を与えます：- クエリが想定する列がない、または名前が変更された: ポーリングは失敗し、Kameleoon は失敗を記録します。ポーリング時点は進まないため、クエリがテーブルに再び一致するまで、後続の実行で時間枠を再試行します。
- 列名は変わらないが、意味が変わった: ポーリングは成功し、ポーリング時点は進みます。Kameleoon は、同じ名前の列が想定どおりの訪問者識別子、タイムスタンプ、収益を保持しているかを確認しないため、エラーがなくても結果が誤る可能性があります。
訪問者識別子
Kameleoon はvisitor_id の値を使用して、各コンバージョンのクレジットを受け取る訪問者を識別します。そのため、この値は、Kameleoon がその訪問者について既に持っている識別子と一致する必要があります。既定では、この値は Kameleoon の訪問者コードです。デバイス間の履歴照合を設定すると、Kameleoon は訪問者コードではなく、デバイス間照合のカスタムデータ内の識別子と visitor_id を照合します。
インジェスチョン前にクエリを実行する
ゴールを保存する前に、Run Query をクリックして、Kameleoon でクエリを直接テストできます。テストでは次のことができます：- リアルタイムで接続を確認する。
- 認証情報とアクセス権が正しいことを確認する。これにより、最初のデータインポートを待たずに問題をすぐに検出できます。
- データの構造とアクセス性を検証する。
Amazon Redshift ゴールの使用
ゴールを使用するには、実験またはパーソナライゼーションを設定するときに、設定ステップでゴールを選択して、Amazon Redshift データベースの特定のコンバージョンを追跡・分析します。Kameleoon は、これらのコンバージョンを 1 日 1 回、実験結果とマージします。 ゴールを実験で設定する方法については、キャンペーンでゴールを設定するを参照してください。データ保持
Amazon Redshift からインポートされたコンバージョンデータは、Kameleoon では訪問データになり、Kameleoon の標準のデータ保持ポリシーに従います。保持期間については、データ保持ポリシーを参照してください。訪問者データの削除
認証が必要な Data API エンドポイントPOST /visit/forget を使用して、Kameleoon に保存されている訪問者データのコピーを削除できます。リクエストの形式については、Remove data for several visitorsを参照してください。このエンドポイントは、Amazon Redshift データベースのテーブルを削除しません。