データ同期における訪問者IDまたはアカウントIDのマージの処理方法

最終更新日: 2026年11月02日 19:54

Pendoが訪問者IDまたはアカウントIDをマージすると（再マッピングとも呼ばれます）、Pendo内の過去のデータが書き換えられ、新しいIDに関連付けられます。データ同期は、すでに配信先に配信済みのデータを書き換えることはありません。マージ後、配信先には、マージ前に配信されたデータには古いIDが、マージ後に配信されたデータには新しいIDが含まれることになります。

この記事では、マージの影響を受けるエクスポートデータ、マージの実行中にエクスポートを管理する方法、および配信先にすでにあるデータの整合性を取る方法について説明します。

マッピングファイルの形式やサポートされているマージの種類など、マージプロセス自体の詳細については、訪問者IDまたはアカウントIDのマージを参照してください。

このガイダンスは、すべてのデータ同期の配信先に適用されます。テーブル名、ファイル名、列名は配信先によって異なります。お使いの配信先に該当する名前については、データ同期のスキーマ定義を参照してください。

マージがデータ同期に与える影響

データ同期は、IDのマージを検知しません。Pendoは内部的に過去のデータを書き換えますが、書き換えたデータを配信先に配信することはありません。マージの実行中および完了後、データ同期は次のことを行いません。

すでに配信済みのデータを再発行または置き換える。
古いIDに関連付けられたレコードを削除する。
クラウドストレージの配信先にあるエクスポートマニフェストを修正する。以前のエントリはそのまま残り、マージが発生したことを示す情報はマニフェストに含まれません。

訪問者がマージされると、Pendoはマージされた訪問者レコードを更新済みとしてマークするため、次回の継続的なメタデータ更新エクスポートでは新しいIDとともに配信されます。古いIDのレコードは配信先にそのまま残ります。

配信先の履歴は分断された状態になります。マージ前に配信されたエクスポートには古いIDが、マージ後に配信されたエクスポートには新しいIDが含まれます。この分断を解消する責任はお客様のチームにあり、配信先のデータの整合性を取るに記載されているいずれかの方法を使用してください。

注: 匿名の訪問者と識別済みの訪問者を結び付けるアイデンティティマッピングは別のプロセスであり、すでにエクスポートに反映されています。IDのマージによって、アイデンティティマッピングデータのエクスポート方法が変わることはありません。

マージの影響を受けるデータ

訪問者IDまたはアカウントIDを含むすべてのエクスポートが影響を受けます。次の表に、これらのIDがどこに表示されるかを示します。

データ	含まれるID	影響を受ける要因
イベントデータ（すべてのイベント、および一致したページ、フィーチャー、トラックイベントのデータ）	各行に訪問者IDとアカウントID	訪問者IDおよびアカウントIDのマージ
訪問者データ	訪問者ID、訪問者IDのハッシュ値、識別済みの訪問者ID、および訪問者が属するアカウントIDs	訪問者IDおよびアカウントIDのマージ
アカウントデータ	アカウントIDおよびアカウントIDのハッシュ値	アカウントIDのマージ
訪問者およびアカウントのメタデータ	配信先の種類によって異なります	配信先の種類によって異なります
ページ、フィーチャー、トラックイベント、ガイドの定義	なし	影響を受けません

イベントデータは、影響を受けるデータの中で最も量が多くなります。すべてのイベント行に両方のIDが含まれるため、数千人の訪問者のマージでも数億件のイベント行に影響する可能性があります。まずイベントデータを中心に整合性の計画を立ててください。

メタデータが訪問者またはアカウントとフィールドごとに1行として配信される場合、各行にIDが含まれているため、マージの影響を受けます。クラウドストレージの配信先では、メタデータのスキーマファイルにはフィールド定義のみが含まれ、IDは含まれないため、影響を受けません。値自体は訪問者ファイルおよびアカウントファイルに含まれています。

訪問者データおよびアカウントデータには、IDから導出され、ID変更時に変化するIDのハッシュ値が含まれます。このハッシュ値は自分で計算することはできません。ハッシュ値を使用して結合、パーティション分割、または重複排除を行う場合は、マージ後にエクスポートされた訪問者データまたはアカウントデータから新しい値を取得してください。

マージ開始前に

Pendoがマージを開始する前に、次のタスクを完了してください。

マッピングファイルを保管しておきます。 Pendoに提供する新旧IDのCSVファイルは、配信先の整合性を取る際に使用するマッピングと同じものです。
カスタムメタデータをエクスポートします。 カスタムメタデータは新しいIDに引き継がれず、データ同期のエクスポートはPendo内のデータの現在の状態を反映します。マージで失われたカスタムメタデータは、復元するまでエクスポートに含まれません。詳細については、カスタムメタデータを復元するを参照してください。
マージ中のエクスポートの扱いを決定します。 選択肢については、次のセクションを参照してください。

マージ中のエクスポートを管理する

マージの実行中は、データ同期を一時停止することも、継続することもできます。最適な方法は、イベントデータとアカウント・訪問者メタデータとで異なります。どちらの方法を選んだ場合でも、マージ前のデータには古いIDが含まれているため、後で配信先の整合性を取る必要があります。

イベントデータ

イベントエクスポートをオフにする、お客様側での読み込みを一時停止する、または通常どおり継続する、のいずれかを選択できます。これら3つの方法はすべて復旧可能です。エクスポートをオフにして一部の期間のデータを取りこぼした場合でも、後から取得できます。クラウドストレージの配信先の場合は、不足している日付の1回限りのエクスポートを作成してください。ウェアハウスの配信先の場合は、Pendoサポートに連絡してデータを補完してもらってください。

イベントエクスポートをオフにすると、Pendoはそのエクスポートに対する新しい遡及エクスポートの作成を停止します。すでにキューに入っている遡及エクスポートは引き続き配信されるため、約24時間以内に停止します。

イベントデータは復旧可能であるため、レポートのニーズに基づいて選択してください。

一時停止すると、整合性を取るための単一の切り替えポイントが得られます。マージが完了するまで、データは古い状態のままになります。
継続すると、データを最新の状態に保てます。配信先には、古いIDと新しいIDの両方が存在する期間が生じます。

アカウントおよび訪問者のメタデータ

ウェアハウスの配信先では、マージ中もアカウントデータおよび訪問者データは通常どおり同期され続けます。整合性を取るまで、特別な対応は必要ありません。

クラウドストレージの配信先では、アカウントおよび訪問者のエクスポートは、サブスクリプション内のすべてのアカウントまたは訪問者を配信する1回限りのエクスポート、または過去24時間以内に更新されたアカウントまたは訪問者のみを配信する継続的なメタデータ更新エクスポートとして利用できます。日付範囲を指定したエクスポートはないため、継続的なエクスポートの欠落を埋めるには、すべてのアカウントデータまたは訪問者データを再読み込みするしかありません。

欠落を避けるには、Pendo側ではエクスポートを実行したままにし、お客様側での読み込みを一時停止してください。データ同期でアカウントまたは訪問者のエクスポートをオフにしたり、一時停止したりしないでください。読み込みを一時停止している間は、次のことを行います。

現在の位置を記録します。 Pendoは、お客様がどのエクスポートを読み込んだかを追跡しません。再開する場所がわかるように、エクスポートマニフェストから、最後に読み込んだエクスポートのcounter値を記録してください。
一時停止は30日以内にとどめます。 エクスポートマニフェストには、過去30日間（移動ウィンドウ）のエクスポートが一覧表示され、それより古いエクスポートは表示されなくなります。ほとんどのマージは2週間以内に完了しますが、大規模なマージはさらに時間がかかる場合があるため、マージの完了を待つのではなく、待機中のエクスポート数を確認してください。

マージ中も読み込みを継続する場合

マージの実行中もエクスポートの読み込みを継続する場合、整合性を取るまでの間、次のような状態になります。

マージ開始後に配信されるエクスポートには、新しいIDが含まれます。すでに読み込み済みのレコードは、古いIDのままです。
古いIDに関連付けられたレコードは更新されなくなりますが、削除はされません。
同じ訪問者またはアカウントが2つのIDの下に存在することになるため、個別の訪問者数またはアカウント数のカウントが過大になります。

クエリ実行時にIDをマッピングする方法を使用すれば、すでに新しいIDを持つレコードはマッピングをそのまま通過するため、この混在期間を追加の作業なしで処理できます。代わりにIDをその場で更新する方法を使用する場合は、同じプロセスを複数回実行しても同じ結果になるようにしてください。特に、新しいIDを持つレコードがすでに配信先に存在している可能性がある多対1のマージには注意が必要です。

重要: Pendoがマージの完了を確認するまでは、整合性を取る作業を開始しないでください。Pendoが過去のデータをまだ書き換えている間に配信されたデータは、お客様が行った変更を上書きしてしまう可能性があります。

配信先のデータの整合性を取る

Pendoがマージの完了を確認したら、配信先のデータの整合性を取る方法を選択します。次の表を参考に、方法を選択してください。

条件	使用する方法
イベント履歴が大規模で、書き換えが主なコストになる場合	クエリ実行時にIDをマッピングする
データ量が少ない場合、または継続的なマッピングのないクリーンな状態にしたい場合	データを再読み込みする
変更できないダッシュボードで過去のレコードを使用する必要がある場合	IDをその場で更新する

イベントデータとアカウント・訪問者データとで、異なる方法を使用することもできます。たとえば、アカウントデータおよび訪問者データは再読み込みし、イベントデータはクエリ実行時にマッピングすることができます。

クエリ実行時にIDをマッピングする

配信先には古いIDをそのまま保持し、データをクエリする際に新しいIDに解決します。通常、イベントデータ量が多い場合に最適な方法です。

マッピングファイルを出力先に永続テーブルとして読み込みます。
影響を受ける各データセットについて、左結合（LEFT JOIN）を使用してデータセットをマッピングテーブルと結合するビューを作成します。このビューは、一致するものがある場合は新しいIDを返し、ない場合は元のIDを返します。
レポートや後続のクエリは、基になるテーブルではなくこれらのビューを参照するようにします。

たとえば、イベントデータに対するビューは次のようになります。テーブル名と列名は、お使いの出力先のものに置き換えてください。

CREATE VIEW events_current_ids AS
SELECT e.*,
       COALESCE(m.new_id, e.visitor_id) AS current_visitor_id
FROM events e
LEFT JOIN id_mapping m
  ON m.old_id = e.visitor_id;

このアプローチには、次のような利点があります。

作業量はイベント履歴ではなく、マッピングのサイズ（通常は数千行）に応じて決まります。イベント履歴は数十億行に達することもあります。
データは削除されません。マッピングに誤りがある場合や変更があった場合は、マッピングテーブルを修正します。
最初に収集されたIDの記録が保持されるため、不一致を調査する際に役立ちます。
多対1のマージには追加の処理は必要ありません。複数の古いIDが1つの新しいIDに解決され、正しく集計されます。

マッピングテーブルは、データモデルの永続的な一部になります。参照するのはビューのみであるため、レポートやその他の後続の利用者には単一のID列が表示されます。

注：多対1のマージでは、複数の古い訪問者レコードまたはアカウントレコードが1つの新しいレコードに解決され、それらのメタデータが競合することがあります。マージ後のレコードにはPendoが保持した値が格納されるため、古いレコードを自分で結合するのではなく、マージ後に配信されたレコードを使用してください。

データを再読み込みする

影響を受けるデータを出力先から削除し、Pendoから再度読み込みます。このアプローチにはマッピングロジックが不要で、継続的な複雑さも残りませんが、計算コストと所要時間はデータ総量に応じて増加します。

影響を受けるテーブルまたはデータを出力先から削除します。
データを再度リクエストします。クラウドストレージの出力先の場合は、削除したデータの1回限りのエクスポートを作成します。ウェアハウスの出力先の場合は、Pendoサポートにお問い合わせください。
クラウドストレージの出力先の場合は、エクスポートを出力先に読み込みます。ウェアハウスの出力先では、データは自動的に読み込まれます。

再読み込みは、アカウントデータや訪問者データに特に適しています。マージ後に存在するすべての訪問者またはアカウントが、新しいIDとともに配信されるためです。

注：イベントのバックフィルには期間の制限があります。クラウドストレージの出力先の場合、1回限りのエクスポートで直近3暦年分をカバーできます。ウェアハウスの出力先の場合は、利用可能な範囲についてPendoサポートにお問い合わせください。バックフィルで対応できない範囲より古いイベントデータは、マッピングまたは更新を行ってください。

IDをその場で更新する

出力先の履歴レコードを更新し、新しいIDを含むようにします。この方法は完全な再読み込みよりコストが低く、永続的なマッピングも不要であるため、既存のダッシュボードはそのまま動作し続けます。ただし、最もエラーが発生しやすい方法でもあり、元に戻すにはデータを再読み込みするしかありません。

手順はマージの種類によって異なります。

1対1のマージ（各古いIDが1つの新しいIDになるケース）：

マッピングファイルを出力先にテーブルとして読み込みます。
影響を受ける各データセットで、マッピングテーブルからID列を更新します。見落とされがちなイベントデータも含めてください。
マッピングテーブルを削除します。

多対1のマージ（複数の古いIDが1つの新しいIDになるケース）：

マッピングファイルを出力先にテーブルとして読み込みます。
訪問者データおよびアカウントデータから、古いIDに関連付けられたレコードを削除します。
マージされた訪問者またはアカウントを、新しいIDで読み込みます。継続的なメタデータ更新エクスポートでは、マージ後の訪問者が配信されます。マージされたすべてのレコードを確実に取得するには、訪問者データまたはアカウントデータを再読み込みしてください。
イベントデータでは、1対1のマージの場合と同様に、マッピングテーブルからID列を更新します。複数の古いIDが1つの新しいIDを指すのは想定どおりです。
マッピングテーブルを削除します。

警告：多対1のマージでは、訪問者レコードまたはアカウントレコードをその場で更新したり、自分で結合したりしないでください。Pendoはすでにそれらを新しいID配下に結合しています。2つの古いレコードを同じ新しいIDに更新すると、同じIDを持つ2つのレコードが作成され、これがマージ後に重複キーエラーが発生する最も一般的な原因になります。

カスタムメタデータを復元する

復元が必要な内容は、メタデータの取得元によって異なります。

Web SDKおよびSegment.ioのメタデータは新しいIDに引き継がれます。操作は必要ありません。
SalesforceおよびHubSpotのメタデータは引き継がれません。新しいIDでレコードが一致するようにインテグレーションを更新すると、インテグレーションの次回の同期時にメタデータが再び入力されます。
カスタムメタデータは引き継がれず、再入力もされません。マージ前に作成したエクスポートから復元してください。

カスタムメタデータのエクスポートをアップロードする前に、その中の古いIDをマッピングファイルの新しいIDに置き換えてください。Pendoに存在しないIDを含むCSVをアップロードすると、それぞれについて新しい空のレコードが作成されます。

カスタムメタデータは、CSVアップロードまたはメタデータAPIを使用して復元できます。手順と制限については、カスタムメタデータフィールドを管理するを参照してください。復元された値は、次回のメタデータエクスポートに含まれます。

ヒント：メタデータAPIの各呼び出しは5分以内に完了する必要があり、完了しない場合は408 Request Timeoutエラーが返されます。大規模な復元を行う場合は、この制限内に完了するようレコードをバッチに分割してください。

マージ後のエクスポートに残る古いIDのトラブルシューティング

マージが完了した後もエクスポートに古い訪問者IDまたはアカウントIDが表示される場合、Pendoのインストール外にある送信元がまだそれらを送信していることが通常の原因です。よくある原因は、メタデータAPI呼び出し、定期的なCSVアップロード、IDマッピングが更新されていないインテグレーションです。これらはいずれも、マージ後に古いIDのレコードを再作成する可能性があります。

これらのレコードにはイベントがなく、［初回訪問（First Visit）］の値もありません。また、訪問者数やアカウント数の集計を実際より多くカウントしてしまいます。

削除するには：

古いIDをまだ送信しているすべてのインテグレーション、アップロードプロセス、パイプラインを更新します。
空のレコードを削除するには、Pendoサポートにお問い合わせください。

重要：送信元を更新する前にレコードを削除すると、次に送信元がデータを送信したときに再び作成されます。