- Warehouse: クエリする Snowflake ウェアハウスを入力します。
- Frequency: Kameleoon がゴールデータを更新する頻度を定義します。
- Database: コンバージョンデータを含むデータベースを入力します。
- Schema: コンバージョンデータを含むスキーマを入力します。
- Query: Snowflake から必要なデータを取得する SQL クエリを定義します。
クエリ形式
クエリは特定の形式に従う必要があります:SELECT visitor_id, conversion_timestamp FROM your_events_table
ここで、visitor_id は訪問者の一意の ID を表す列で、conversion_timestamp はコンバージョンが発生した正確な時刻を表す列です。Snowflake では、conversion_timestamp 列は Timestamp 型の列である必要があります。
各コンバージョンに収益を関連付けたい場合、クエリは代替形式に従う必要があります:
SELECT visitor_id, conversion_timestamp, revenue FROM your_events_table
ここで、revenue は各コンバージョンの収益を含む列です。
より複雑なクエリの場合、次のようにサブクエリを作成することでこの形式に従うことができます:
WITH 句が追加されて、Snowflake ウェアハウスで毎時実行されます。コンバージョンは毎時収集されますが、実験結果にマージされるのは 1 日に 1 回のみであることに注意してください。
Kameleoon がコンバージョンデータをポーリングする仕組み
Kameleoon は、実行のたびにイベント履歴全体を再読み込みするのではなく、Snowflake のコンバージョンデータを差分方式でポーリングします。各ポーリングジョブは直前に成功したポーリング地点を記録し、次回の実行ではその地点以降に追加された新しいレコードの時間枠のみをクエリします。この時間枠のみをクエリすることで、Kameleoon はすでに取り込んだデータを再スキャンすることがなく、各ポーリングを高速に保てます。 ポーリングは常に前方へ進むため、直前に成功したポーリング時間枠より古いタイムスタンプで Snowflake に到着したレコードを、Kameleoon が取りこぼす場合があります。遅延レコードは通常、データパイプラインがコンバージョンイベントを書き込むのに時間がかかることで発生し、その結果、Kameleoon がすでにそのレコードの属する時間枠を通過した後になって、レコードが Snowflake に到達します。レコードの取りこぼしを防ぐには、以下のインジェスチョン時間枠を、パイプラインの通常の到着遅延に合わせて設定してください。インジェスチョン時間枠
デフォルトでは、Kameleoon はコンバージョンイベントの発生から Snowflake ウェアハウスで利用可能になるまで最大 1 時間を許容し、ポーリング時間枠はこの遅延を自動的に考慮します。パイプラインがバッチ処理や夜間の ETL ジョブなどにより、イベントを Snowflake に書き込むのに 1 時間以上かかる場合、これらの遅延レコードはポーリング時間枠の対象外となり、取りこぼされます。パイプラインの実際の到着遅延に合わせて遅延時間を延長するには、カスタマーサクセスマネージャーにお問い合わせください。インジェスチョン前にクエリを実行する
インジェスチョンタスクを保存する前に、Kameleoon で直接クエリをテストできます。テストにより以下が可能になります:- リアルタイムで接続を確認する。
- 認証情報とアクセス権が正しいことを確認し、最初のデータインポートを待たずに問題を即座に検出できるようにする。
- データの構造とアクセス可能性を検証する。
