データウェアハウス連携は、Web Experimentation および Feature Experimentation モジュールのプレミアムアドオンとしてご利用いただけます。詳細については、カスタマーサクセスマネージャーまでお問い合わせください。
visitor_id 列と conversion_timestamp 列を返す必要があります。また、各イベントの発生後、少なくとも 72 時間はデータをクエリできる状態を保つ必要があります。
ゴールを作成する前に、プロジェクトで Snowflake 連携を有効化してください。
Snowflake ゴールを作成する
Snowflakeからコンバージョンを読み取るゴールを作成するには、ゴールの作成の Data warehouse tracking フローに従い、Datawarehouse integration ドロップダウンから Snowflake を選択します。すると Step 1で、Snowflake 固有の次のフィールドが求められます：- 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は、各コンバージョンの収益を含む列です。
より複雑なクエリの場合は、元のクエリをサブクエリで囲むことで、この形式を維持できます：
Kameleoonがコンバージョンデータをポーリングする仕組み
Kameleoonは、設定した頻度で、ゴールの背後にある Snowflakeのコンバージョンデータをポーリングします。その際、タイムスタンプでフィルタリングするWITH 句をクエリに追加します。実行のたびにイベント履歴全体を再読み込みするのではなく、Kameleoonは増分でポーリングします。各ポーリングジョブは、最後に成功したポーリング地点を記録し、次の実行では、その地点以降に追加された新しいレコードの時間枠だけをクエリします。Kameleoonはすでにインポートしたデータを再スキャンしないため、この時間枠だけをクエリすることで、各ポーリングを高速に保てます。Kameleoonは設定した頻度でコンバージョンをポーリングしますが、実験結果にマージするのは 1 日 1 回だけです。
ポーリングは常に前方へ進むため、最後に成功したポーリング時間枠よりも古いタイムスタンプを持つレコードが Snowflakeに到着した場合、Kameleoonはそのレコードを取りこぼす可能性があります。遅延レコードは通常、データパイプラインがコンバージョンイベントを書き込むのに時間がかかるために発生します。その結果、Kameleoonがそのレコードの属する時間枠をすでにポーリングした後に、レコードが Snowflakeに到達します。レコードの取りこぼしを防ぐには、カスタマーサクセスマネージャーに依頼して、インジェスチョン時間枠をパイプラインの通常の到着遅延に合わせて延長してください。
Kameleoonは、遅延レコードのタイムスタンプがまだポーリングしていない時間枠に含まれている場合にのみ、そのレコードをインポートします。ポーリング地点が 1 日を完全に過ぎると、Kameleoonはその日を再読み込みしないため、その日の遅延した行や修正された行はインポートしません。
インジェスチョン時間枠
デフォルトでは、Kameleoonは、ゴールのコンバージョンイベントが発生してから Snowflake ウェアハウスで利用可能になるまでに、最大 1 時間の遅延を許容します。ポーリング時間枠は、この遅延を自動的に考慮します。パイプラインがイベントを Snowflakeに書き込むのに 1 時間以上かかる場合（たとえば、バッチ処理や夜間の ETL ジョブが原因の場合）、その遅延して到着したレコードはポーリング時間枠の外に出てしまい、取りこぼされます。遅延時間をパイプラインの実際の到着遅延に合わせて延長するには、カスタマーサクセスマネージャーにお問い合わせください。ポーリングの失敗とスキーマの変更
ポーリングが失敗しても、ポーリング地点は変わりません。ポーリング地点とは、Kameleoonがレコードをインポート済みの時刻のことです。そのため、次にスケジュールされたポーリングは同じ地点から開始し、同じ時間枠を再試行します。クエリが再び実行されると、Kameleoonはその時間枠のレコードをインポートします。 スキーマの変更が結果に影響する方法は、何が変わったかによって、次の 2 つのいずれかです：- クエリが期待する列が存在しないか、名前が変更された場合： ポーリングは失敗し、Kameleoonは失敗を記録します。ポーリング地点は進まないため、クエリがテーブルに再び一致するまで、以降の実行は時間枠を再試行します。
- 列の名前は変わらないが、意味が変わった場合： ポーリングは成功し、ポーリング地点が進みます。Kameleoonは、同名の列が依然として期待する訪問者識別子、タイムスタンプ、収益を保持しているかどうかを確認しません。そのため、エラーは表示されなくても、結果が誤っている場合があります。
訪問者識別子
Kameleoonはvisitor_idの値を使用して、各コンバージョンのクレジットを受け取る訪問者を特定します。そのため、この値は、Kameleoonがその訪問者について既に保持している識別子と一致している必要があります。デフォルトでは、この値は Kameleoonの訪問者コードです。クロスデバイス履歴調整を設定している場合、Kameleoonは訪問者コードの代わりに、クロスデバイス履歴調整の一意の識別子としてマークしたカスタムデータと visitor_idを照合します。
インジェスチョン前にクエリを実行する
ゴールを保存する前に、Kameleoonでクエリを直接テストできます。テストにより、次のことが可能になります：- リアルタイムで接続を確認する。
- 認証情報とアクセス権が正しいことを確認し、最初のデータインポートを待たずに問題をすぐに検出する。
- データの構造とアクセス可能性を検証する。
Snowflake ゴールを使用する
ゴールを作成したら、Kameleoonのキャンペーンに組み込めます。実験またはパーソナライゼーションを設定する際、finalization pageの Goals セクションでこのゴールを選択できます。その後、このゴールを使用して、Snowflake データベースの特定のコンバージョンを追跡・分析できます。 実験でゴールを設定する方法については、キャンペーンでゴールを設定するを参照してください。データ保持
Snowflakeからインポートしたコンバージョンデータは、Kameleoonで訪問データになり、Kameleoonの標準のデータ保持ポリシーに従います。保持期間については、データ保持ポリシーを参照してください。訪問者データを削除する
Data API エンドポイントPOST /visit/forgetを使用すると、Kameleoonが保持する訪問者データを削除できます。このエンドポイントには認証が必要です。リクエストの形式については、Remove data for several visitorsを参照してください。このエンドポイントは、Snowflake データベースのテーブルを削除しません。