Klaviyo のデータウェアハウス イベント インポートについて理解する

このページで学べること

データウェアハウスのイベント インポート を使用してウェアハウスからイベント データを Klaviyo に同期する方法について説明します。これにより、Klaviyo のネイティブな外部連携（例: POS システム、サポート プラットフォーム、カスタム アプリケーション）以外を起点とする行動データを使って、セグメント、フロー、レポート作成を強化できます。

データウェアハウス イベント インポートとは？

データウェアハウスイベントのインポートにより、Klaviyo はデータウェアハウスに直接接続し、イベントデータを含むウェアハウスのテーブルまたはビューからの インポート同期を設定できます。

ソース テーブルの各行は、Klaviyo では 1 つのイベントとして扱われます：

• 行のタイムスタンプ、メトリック名、識別子によって、何が起きたか、いつ、誰に対してが定義されます。
• 追加の列は、セグメンテーション、フロー、分析で使用できるイベントプロパティになります。

イベントのインポートは、プロファイルのインポートと同じデータウェアハウスのインポート インフラストラクチャ上に構築されていますが、プロファイルではなく、Klaviyo のイベント取り込みパイプラインを対象としています。

データウェアハウスのイベント インポートはどのように機能しますか？

Klaviyo を倉庫に接続し、イベント同期を設定した後：

1. Klaviyo が構成済みのテーブルまたはビューに対して、データウェアハウスにクエリを実行します。
2. 各実行時に、Klaviyo は 変更検知タイムスタンプ が最後に成功した同期より新しい行のみを読み取ります。これにより、テーブル全体を再処理せずに増分インポートを行えます。
3. 各行は次のとおり処理されます：
   • Klaviyo は、同期設定中に選択したオプションに基づいて メトリック名（イベント タイプ）を決定します。単一の選択済みメトリック、またはソース テーブル内の指定されたメトリック名列の値に基づいて動的に決定されます。
   • イベント タイムスタンプ、プロファイル識別子、および任意の 一意の ID、値、値の通貨 は、同期設定中に構成したフィールド マッピングに基づいて設定されます。
   • 残りの列はすべて列名をプロパティ名として使用し、イベントプロパティとして取り込まれます。3 つのアンダースコアを含む列名（例: parent___child1、parent___child2）は、子プロパティを持つイベントプロパティ（parent）を作成するために使用できます。
4. Klaviyo は結果のイベントをアカウントに読み込みます。これらは、セグメンテーション、フロー、分析で他のカスタム API メトリックと同様に動作します。

インポートは 繰り返しの頻度（例：1 時間ごと）で実行されるため、データウェアハウス内の新規または更新された行は定期的に Klaviyo のイベントに変換されます。

始める前に

イベント インポート同期を作成する前に、次の要件が満たされていることを確認してください。

• アカウントでは、アドバンストKDPとデータウェアハウスのインポートを利用できます。
• Klaviyo で データウェアハウス接続を作成し、検証しました。必要なサービス アカウントとスキーマの詳細については、データウェアハウスのサポートセンター記事を参照してください。
• ソース テーブルまたはビューには、以下の必須列が含まれています。
• ウェアハウスで、必要なテーブル／ビューを Klaviyo のサービスユーザーに公開するための十分な権限があること。

イベントのソーステーブル構造

イベントデータを正しくインポートできるようにするには、ソーステーブルまたはビューが Klaviyo の必須フィールドと構造を満たしている必要があります。

必須フィールド

データウェアハウスのイベントインポート V1 では、次の列が必須です：

オプションフィールド

これらのフィールドは、該当する場合は 推奨 されますが、必須ではありません：

イベントプロパティ

テーブル内のその他すべての列は、イベントプロパティとして扱われます：

• 列は フラット化されたプロパティ としてインポートされ、列名が Klaviyo でそのままプロパティ名として使用されます。
• すべてのプロパティを明示的にマッピングする必要はありません。マッピングされていない列はイベントプロパティとして含まれます。
• ネストされた JSON は、必要に応じて個別のプロパティ値内（例：明細項目の JSON オブジェクト）に保存できますが、プロパティ名自体はトップレベルの列から取得されます。

Klaviyo はイベントプロパティに対してベストエフォート型の型解析を実行します。また、イベントのインポート設定の一部としてフィールドごとの変換ロジックは提供しません。

一般的なユースケース

顧客がデータウェアハウスのイベント インポートを使用する一般的な用途：

1) オフラインまたは POS イベントのインポート

倉庫から店頭またはオフラインのイベント（例：POS 購入、返品、予約）を取り込み、他の Klaviyo イベントやメトリックと同様に動作するようにします。

例：

• In-Store Purchase 注文合計、店舗所在地、支払い種別があるイベント
• Appointment Completed スタッフメンバー、サービスの種類、所要時間を含むイベント

2) サービスとサポートのインタラクション

チケット作成、解決、返品などの サポートおよびサービス イベント を同期して顧客タイムラインを充実させ、サービス履歴に基づくメッセージングを可能にします。

例：

• Support Ticket Created および Support Ticket Resolved
• Order Returned 理由コードと返金額を含む

3) モデル化または派生イベント

warehouse-modeled behaviorsを、Klaviyo でより使いやすいイベントに変換します。

例：

• High Churn Risk ウェアハウス内のモデルから生成されたイベント
• Lifecycle Milestone Reached 顧客がカスタム ライフサイクル モデルでステージを移動したときのイベント

データウェアハウスのイベント インポート同期を設定

1) データウェアハウスに接続します

まだウェアハウスを接続していない場合：

1. Klaviyoで、[アドバンストKDP] > [データ管理] > [同期]と進みます。
2. Add data warehouse をクリックし、データウェアハウス コネクタを選択します。
3. データウェアハウスのインポートの概要記事からリンクされている該当の接続ガイドに従って、プラットフォームの接続手順を完了してください。

Klaviyo では、アカウントあたり 1 つのアクティブなデータウェアハウス接続をサポートしています。

2）新しいイベント インポート同期を作成する

データ ウェアハウスを接続したら：

1. [アドバンストKDP] > [データ管理] > [同期]と進み、データウェアハウスの接続を選択します。
2. [Import data]（初めてインポートを設定する場合）を選択するか、既存の接続の場合は [Create sync]／[Add sync] をクリックします。
3. データタイプの入力を求められたら、（プロファイルではなく）イベントを選択してください。
4. インポートするイベントが含まれているウェアハウス内のテーブルまたはビューを選択します。

3) 必須フィールドをマッピングする

次に、ウェアハウス テーブルの列を、Klaviyo で必須のイベント フィールドにマッピングします。

イベントのインポート設定では、次の項目のマッピングを指定する必要があります。

• イベントのタイムスタンプ
• メトリック名（設定で選択する定数、または行ごとにメトリック名を含む列のいずれか）
• プロファイル識別子（少なくとも 1 つ）
• 変更検出タイムスタンプ

推奨フィールドをマッピングすることもできます：

• ユニーク ID
• 値
• 値の通貨

明示的にこれらのコア フィールドにマッピングしない残りの列は、自動的に イベントプロパティになります。

設定 UI では、複数の列を同じトップレベル フィールドにマッピングできないようにし、保存を許可する前に必須フィールドがすべて存在することを検証します。

4）同期の頻度と履歴の範囲を選択します

イベントのインポートを保存する場合：

• Klaviyo は、繰り返し同期を定期的な頻度（通常は 1 時間ごと）で実行するようにスケジュールします。
• 各実行では、変更検出タイムスタンプ が前回の成功した実行よりも新しい行のみが処理されるため、インポートは増分になります。

履歴のバックフィルについては、次のいずれかを行うことができます：

• イベントのインポート先として、関連するすべての履歴イベントがすでに含まれているテーブルまたはビューを指定するか、
• まずは専用の履歴テーブルから始め、後で継続的な更新のために変更データキャプチャ（CDC）に基づくビューに切り替えます。

インポートされたイベントが Klaviyo でどのように動作するか

インポート後：

• 各行は、Klaviyo の カスタム API メトリックのイベントとして表示されます。
• マッピングした（または定数として設定した）メトリック名によって、プロダクトに表示されるイベントタイプ名（例: Placed Order）が決まります。
• すべてのプロファイル識別子は、可能な限り既存のプロファイルに解決されます。それ以外の場合、Klaviyo は、他のイベント取り込み経路と同様に、提供された識別子フィールドを使用して新しいプロファイルを作成します。

これらのイベントは次の用途に使用できます：

• ユーザーのアクションに基づいてセグメントを作成し、イベント プロパティでフィルタリングします。
• フローをトリガーし、フィルターします。
• 他のソースからのイベントと並行して、メトリックとレポート作成で行動を分析します。

制限事項とベストプラクティス

データウェアハウスのイベント インポートを使用する際は、次の点に注意してください：

• イベントインポートの V1 は、イベントデータのみに重点を置いています。プロファイルプロパティは、プロファイルのインポートまたはその他のサポートされている方法で更新する必要があります。
• 変更検出タイムスタンプはイベント タイムスタンプと異なる必要があります。両方に同じ列を使用すると、初回同期後に過去のイベントを安全にインポートできなくなる可能性があります。
• 最適な速度を得るには、変更検知フィールドを新しいテーブルが作成された時点のタイムスタンプに設定します。レコードはこの値を使用して同期サイクルでバッチ処理されるため、すべての履歴レコードの変更検出タイムスタンプが狭い範囲にある場合（例：新しいテーブルを作成するジョブのタイムスタンプ）、履歴レコードをインポートする時間を短縮できます。
• 可能であれば、重複排除を改善し、その後のデバッグを容易にするために、イベントごとに安定した 一意の ID を使用してください。
• テーブルに、異なる列セットを持つ複数のイベント タイプ（メトリック）が含まれている場合でも、通常はまとめて問題ありません。特定の行で NULL になっている列は、Klaviyo ではそのイベントに対して単に無視されます。
• 複雑なネストされたオブジェクト（例：明細行配列）については、可能な場合は複数の列にフラット化することを推奨します。特に、セグメンテーションやフローで使用する予定のプロパティについては推奨します。

```

• 変更検出タイムスタンプは現在の日付付近にまとめてください。Klaviyo は 1 時間単位のウィンドウでデータを読み取り、テーブル内で最も古い変更検出タイムスタンプから前方に反復処理します。いずれかの行に変更検出タイムスタンプが過去のかなり前の日時で含まれている場合（例：他がすべて最近なのに、2023 年の単一レコードがある場合）、Klaviyo は各同期サイクルでその日付以降の 1 時間ごとの各ウィンドウをすべてスキャンするため、履歴バックフィルの同期時間が遅くなります。
• 1 時間の変更検出タイムスタンプウィンドウ内で、単一の行数が約 100,000 行を超えないようにしてください。同じ 1 時間ウィンドウを共有する行が多すぎると、同期クエリがタイムアウトする可能性があります。

推奨される Snowflake クラスタリング キーの設定

Snowflake テーブルの場合、変更検出タイムスタンプ列でクラスタリングすると、Klaviyo のクエリで不要なマイクロパーティションをスキップできるため、同期時間と Snowflake のコンピュートコストの両方を削減できます:

ALTER TABLE your_schema.your_table CLUSTER BY (your_change_timestamp_column);