Metaのオフラインイベントセットはデータセットへ移行｜来店・成約データの送り直し手順

この記事のポイント

• 旧Offline Conversions APIは2025年5月に終了し、オフラインイベントセットはデータセットへ統合されたが、オフライン計測はCAPIで続いている。
• 来店・成約データの送信にはaction_sourceへphysical_storeを指定する。event_timeが7日より古いイベントが1件でも混ざると、リクエスト全体が失敗する。
• 過去分は7日分ずつに分け、order_idを付けて送ると、全件失敗と二重計上の両方を避けられる。
• 手動CSV・連携ツール・自社API連携のどれで送っていたかを切り分け、送信先をデータセットIDへ替えることが、その日のうちにできる復旧の第一歩になる。

ある日を境に、来店や成約の件数がMeta広告の管理画面でぴたりと増えなくなる。エラー表示も出ていない。広告の配信は普通に動いているのに、オフラインの成果だけがゼロのまま。こうした状況に心当たりがあるなら、原因は設定ミスではなく、Metaのオフラインイベントセットがデータセットへ移行した仕様変更である可能性が高いです。

この記事では、何が終わり何が残ったのかを整理したうえで、自社の送信経路を切り分け、データセットへ再接続し、過去分を送り直すところまでを順に説明します。詳細はアカウントの状況で異なるため、画面表記は2026年時点の一般的な構成を前提にしています。

Metaのオフラインコンバージョンは何が廃止されて何が残ったのか

図1: 廃止されたものと続くもの

Metaのオフラインコンバージョンで終わったのは、旧Offline Conversions APIと旧オフラインイベントセットという「入れ物と送信口」であり、来店・成約をMeta広告の成果に戻す計測そのものは、データセットとConversions API（CAPI）で続いています。まず早見表で整理します。

項目	状態	備考
Offline Conversions API	終了	Graph API v16.0の終了とともに停止
オフラインイベントセット	データセットに統合	送信先はデータセットIDになる
オフライン計測そのもの	継続	CAPIでaction_sourceにphysical_storeを指定
過去に送ったデータ	要確認	公式は移行を明言していない

Offline Conversions APIの終了（Graph API v16.0）

Offline Conversions APIは、Graph API v16.0の終了に合わせて2025年5月に使えなくなりました。このAPIを直接叩いていた自社開発の連携だけでなく、内部でこのAPIを呼んでいた連携ツールも同時に影響を受けます。止まった側の画面には目立つ警告が出ないことが多く、成果がゼロのまま気づかれにくい点が厄介です。

オフラインイベントセットはデータセットに統合

データセットとは、Webのピクセルイベントとオフラインイベントを同じ入れ物でまとめて扱う、Metaの計測データの単位です。旧オフラインイベントセットは独立した入れ物でしたが、現在はイベントマネージャのデータセットに一本化されています。これに伴い、送信先として指定するIDも、オフラインイベントセットIDからデータセットIDに替わりました。

来店・成約の計測はCAPIのphysical_storeで継続

来店や成約をMetaに返す方法は消えていません。Conversions API（CAPI）にaction_sourceを「physical_store」として送れば、オフライン購入として扱われます。つまり「廃止」という言葉の印象とは逆に、やるべきことは計測の放棄ではなく、送信口の付け替えです。

オフラインコンバージョンが反映されなくなった原因はどこにあるのか

送信経路を洗い出す担当者

反映が止まった原因は、手動CSVアップロード、Zapier・POS・CRM連携ツール、自社開発のAPI連携のどの経路で送っていたかによって、止まった場所が異なります。先に経路を特定すると、無駄な設定いじりを避けられます。

手動CSVアップロードの場合

イベントマネージャからCSVを手で上げていた場合は、アップロード先として旧オフラインイベントセットを選べなくなっていないかを確認します。データセットを選んで上げ直す必要があり、列名や形式が旧テンプレートのままだと取り込みで弾かれます。担当者の引き継ぎで「いつもの手順」が残っているだけの運用では、画面の変化に気づくまでに時間がかかりがちです。

Zapier・POS・CRM連携ツールの場合

Zapierなどのノーコード連携は、旧Offline Conversionsのアクションに依存していました。Zapierのヘルプでは、2025年5月のGraph API v16.0の終了とともに該当アクションが止まったと案内されています。スプレッドシートからZapierで流す構成は中小企業に多く、CAPI用のアクションへ組み直さない限り、エラーが目立たないまま送信が止まった状態が続きます。POSやSalesforce・HubSpotなどのCRM連携も同様で、連携設定の送信先がオフラインイベントセットIDのままになっていないかが最初の確認点です。

LiveRampのドキュメントでも、連携側は送信先をオフラインイベントセットIDからデータセットIDへ切り替える必要があったと案内されています。国内のツールでも同じ事情が起こりうると考えておくのが無難です。

自社開発のAPI連携の場合

自前でOffline Conversions APIを呼んでいたなら、エンドポイントとペイロードの両方を作り直す必要があります。送信先をデータセットIDにし、CAPIのイベント形式（event_name、event_time、action_source、user_data）へ変えます。ログ上は4xxエラーが出続けているのに、監視の対象外で放置されているケースもあるため、まず直近のレスポンスログを見るところから始めてください。

オンライン側のピクセルが原因ではないかと迷う場合は、Metaピクセルのイベントが反映されない時の切り分けで先にオンライン計測の健全性を確認しておくと、原因の範囲を狭められます。

オフラインイベントセットをデータセットに移行する手順

移行は、イベントマネージャで現状を確認し、データセットを作るか既存のものに統合するかを決め、広告アカウントへ関連付ける、という順で進めます。

既存の変換状況とデータセットIDを確認する

イベントマネージャを開き、データソースの一覧に旧オフラインイベントセットが残っているか、データセットとして自動変換されているかを見ます。変換済みであれば、データセットIDが表示されます。このIDが、連携ツールやCSVの新しい送信先になります。なお、旧データの扱いについて公式は移行を明言していません。画面上の履歴を確認し、必要なら手元に退避しておくのが安全です。

作り直すか既存データセットに統合するかの判断

判断の軸は単純です。すでにピクセルを紐づけたデータセットがあるなら、そこにオフラインイベントも統合するほうが望ましく、旧オフラインイベントセットが自動変換されていないときに限って新規作成を考えます。

Conversios Blogの解説では、データセットを新しく作り直すとオーディエンスや学習がリセットされ、学習モードに戻る場合があると指摘されています。この記事で触れられているオムニチャネル広告は日本での提供範囲が限られるため、そのまま当てはめるべきではありません。ただ、作り直しより既存データセットへの統合を優先する根拠としては参考になります。

切り替え順は、新しい送信を有効にして数値が確認できてから旧設定を片付ける、ではありません。次章で触れる二重計上を避けるため、旧連携を止めてから新連携を有効にします。

広告アカウント・ビジネスポートフォリオへの割り当て

データセットは、広告アカウントに割り当てて初めて、その広告アカウントの最適化や列表示で使えます。ビジネスポートフォリオの設定でデータセットへのアクセス権を確認し、対象の広告アカウントを関連付けてください。複数アカウントを運用している場合、片方だけ割り当て漏れになる失敗が起こりやすいところです。

来店・成約データをCAPIで送り直すやり方

図2: 過去分は7日ずつ分割して送る

CAPIで来店・成約を送り直すには、action_source・event_time・event_nameの必須項目をそろえ、識別子でマッチ率を確保し、過去分は7日ずつに分けて送ります。Meta for Developersの「Sending Offline Events Using the Conversions API」が、この仕様の一次情報です。

必須項目：action_source・event_time・event_name

action_sourceには「physical_store」を指定します。event_nameは購入ならPurchase、リード系なら対応する標準イベント名を使います。event_timeはUnix時間で、ここが最大の落とし穴です。event_timeが7日より古いイベントが1件でもリクエストに混ざると、そのリクエスト全体が失敗します。一部だけ弾かれるのではなく、全件が落ちる点に注意してください。

マッチ率を上げる識別子（external_id・電話・メール）

Metaが来店者を広告接触者と結び付ける手がかりは、メールアドレス、電話番号、external_idなどの識別子です。メールと電話はハッシュ化して送ります。CRMの顧客IDをexternal_idとして一貫して持たせると、イベントマッチ品質が安定しやすいと言われます。整備の考え方は顧客データのマッチ率を上げる手順で詳しく扱っています。電話受注が中心の場合は、電話・チャット問い合わせをCAPIで計測する設計も役立ちます。

過去分は7日ずつ分割してorder_id付きで送る

公式ドキュメントには、アップロードは62日以内という記述と、event_timeは7日以内という制限が併記されています。2か月前のデータを送りたいときは、この2つが衝突するため、そのまま一括では送れません。実務では、対象期間を7日ずつに区切り、1リクエストに入れるイベントをその範囲に収めて順番に送る形になります。このとき、各イベントにorder_idを必ず付けてください。再送や重複が起きても、order_idをキーに重複排除が働くためです。

送り直しで二重計上しないための確認ポイント

二重計上を防ぐ要点は、新旧の連携を同時に動かさないことと、重複排除が効く範囲を理解しておくことの2つです。

旧連携を止めてから新しい連携を有効にする

LiveRampの案内では、旧フィードを止めてから新しいCAPIフィードを有効にする順番をとり、二重送信を避けています。国内のPOS・CRM連携でも、同じ順序で切り替えるのが安全です。Zapierなら旧Zapをオフにしてから新Zapをオンにする、自社バッチなら旧ジョブの停止を確認してから新ジョブを動かす、といった具合です。「念のため両方動かしておく」が、最も典型的な事故のもとになります。

重複排除はオフライン同士のみ・最大7日

Metaの重複排除は、オフラインイベント同士でしか機能しません。同じ購入をピクセルとオフラインの両方で送ると、突き合わせは行われないため、二重に数えられます。しかも排除の対象は、基本的にorder_idが一致するイベントで、期間は最大7日です。7日を超えて再送した同一注文は、別のイベントとして扱われる可能性があります。

この前提から、送り直しのチェックリストは次のようになります。

• 注文・来店ごとに一意のorder_idを付けているか
• 過去分の再送が、すでに送信済みの期間と重なっていないか
• 同じ成約を、ピクセルとオフライン送信の両方で返していないか

移行後に成果が広告マネージャに出ているか確認する方法

確認は、イベントマネージャでの受信状況、広告マネージャの列設定、最適化対象の設計の3段で行います。

テストイベントとイベントマッチ品質を見る

イベントマネージャのテストイベントで、送ったイベントが届いているか、action_sourceがphysical_storeになっているかを確認します。あわせてイベントマッチ品質のスコアを見て、識別子が足りているかを判断します。受信されているのにマッチ品質が低い場合は、ハッシュ化の前処理や、メール・電話の表記ゆれを疑ってください。

オフライン購入の列を追加する

広告マネージャの列のカスタマイズで、オフライン購入に関する指標を追加します。列が未設定だと、データが届いていても画面には出ません。アトリビューション期間の設定によって数値が変わる点にも注意が必要です。Meta広告のアトリビューション期間を確認しておくと、「出ない」のか「別の期間に入っている」のかを切り分けられます。

カスタムコンバージョンで最適化対象にするか

オフラインの成約を入札の最適化対象にするなら、カスタムコンバージョンを作る選択肢があります。標準イベントとカスタムコンバージョンの違いを踏まえ、標準イベントで足りるか、成約額やステージで切り分ける必要があるかで決めます。

Click Here Digitalの解説では、CRMの商談・成約ステージをCAPIで返し、コンバージョンリードで最適化するのがMetaの推す流れだと整理されています。ただし効果の数値は出典ごとに異なり、検証されたものではありません。送り直しを復旧で終わらせず、リードの質まで見るかどうかは、自社のCRM運用の成熟度に合わせて決めるのが現実的です。インスタントフォームで取得したリードの成約を返す設計も、この延長にあります。店舗集客の設計に悩む場合は、来店目的がない中での店舗集客設計も参考になります。

Google広告のオフラインコンバージョンとの違いと媒体横断の運用

MetaとGoogle広告は、どちらもオフライン成果を返せますが、識別子と期限の考え方が違います。Google広告では、広告クリック時のIDを保持して取り込む運用が基本です。一方、Metaはメールや電話などの顧客識別子でマッチさせ、7日のevent_time制限とorder_idによる重複排除を前提とします。比較の詳細は、Google広告のオフラインコンバージョンとの違いにまとめています。

観点	Meta（CAPI）	Google広告
主な手がかり	メール・電話・external_id	クリックIDや拡張コンバージョン
時間の制約	event_timeは7日、アップロードは62日目安	取り込み期限は別規定
重複排除	オフライン同士・order_id・最大7日	注文IDなどで制御

両媒体へ同じ成約データを返すなら、CRMを正としてorder_idと顧客識別子を一元管理し、媒体ごとに出力形式だけ変える設計が扱いやすいです。送信日も揃えず、媒体ごとの期限に合わせて別々にジョブ化しておくと、片方の失敗が他方を巻き込みません。

よくある質問

Q：Metaのオフラインコンバージョンは廃止されたのですか？

廃止されたのは旧Offline Conversions APIと旧オフラインイベントセットの仕組みです。オフライン計測そのものは、データセットとConversions API（CAPI）にaction_source=physical_storeを指定して送る形で続いています。

Q：旧オフラインイベントセットに入っていた過去のデータは消えますか？

自動でデータセットへ変換されたかどうかで扱いが変わります。公式は移行について明言していないため、イベントマネージャで旧データの有無とデータセットIDを確認し、必要な履歴は手元に退避しておくことをおすすめします。

Q：2か月前の来店データを今から送れますか？

公式には、アップロードは62日以内という目安と、event_timeは7日以内という制限が併記されています。そのため、対象を7日分ずつに分け、order_idを付けて順番に送ります。失敗した場合は、そのリクエストに7日より古いイベントが混ざっていないかを確認してください。

Q：Facebook広告でオフライン購入が広告マネージャに表示されないのはなぜ？

主な原因は、列設定にオフライン購入が入っていない、アトリビューション期間が合っていない、識別子が足りずマッチ率が低い、の3点です。この順に確認すると、切り分けが早く進みます。

Q：Zapierでの連携が止まったときはどう直せばいいですか？

旧Offline Conversionsのアクションを、CAPI向けのアクションへ組み直します。送信先はオフラインイベントセットIDではなく、データセットIDに変更してください。旧Zapを止めてから新Zapを有効にすると、二重送信を避けられます。

オフラインイベントセットのデータセット移行は、送信経路の特定、再接続、7日刻みの送り直しという順で進めれば、当日中に片が付く作業です。真策堂ではこうした観点で、来店・成約データの計測設計や媒体横断の運用についてご相談を受けています。自社の経路の切り分けや移行の優先順位に迷われたときは、お気軽にご相談ください。