この手順でできることは、2026年8月26日（水）予定でLINEヤフー広告の検索広告（ショッピング）に追加される統合計測タグとコンバージョンAPIについて、何が使えるようになるのかを整理し、移行時に重複計測や計測漏れを起こさない順番で切り替えることです。「入れれば数字が合う」という話ではなく、むしろ入れ方を間違えるとこれまでより数字が合わなくなる箇所が3つあります。そこを先に押さえます。
2026年8月26日に追加される4つの仕組み
公式告知によると、検索広告（ショッピング）で統合計測タグ（ビジネスマネージャー発行タグまたは広告アカウント発行タグ）を指定したコンバージョン測定ができるようになり、あわせてコンバージョンAPIも利用できるようになります。アクセストークンを発行すれば、ブラウザーを経由せずサーバーサイドから直接コンバージョンデータを送れます。
| 追加されるもの | 実務上の意味 |
|---|---|
| 統合計測タグの指定 | 広告アカウントごとに別のタグを貼らず、1本のタグで複数の広告種別を計測できる |
| コンバージョンAPI | サーバーから直接送信するため、ブラウザー側の制限に左右されにくい |
| transaction_idによる重複排除 | タグとAPIの両方で同じ注文が届いても、二重計上を防げる |
| クロスデバイス計測の精度向上 | 複数の識別情報を使い、スマホで見てPCで買った経路を拾いやすくなる |
この4つのうち実務でいちばん効くのは、3つめのtransaction_idです。重複排除の仕組みがあるからこそ、タグとAPIを併用するという選択が現実的になります。どちらか一方に寄せる必要がなくなり、ブラウザー経由で取れる分はタグで、取りこぼす分はAPIで補う構成が組めるからです。
なお、何も設定していない場合に8月26日で数字が動くことはありません。今回の告知は対応の「開始」であり、既存の計測を止める内容ではありません。これまで管理画面で発行したコンバージョン測定タグをサンクスページに設置して運用してきたなら、その計測はそのまま続きます。新しい経路は広告主側が設定して初めて有効になります。
サーバーサイド計測で埋まる範囲を先に確定する
ブラウザー経由の計測が取りこぼす場面
取りこぼしが起きるのは、タグが実行されない、あるいは実行されても識別情報が届かない場面です。現場でよくあるのは次のケースです。
- 広告ブロッカーが有効なブラウザーで、タグ自体が発火しない
- トラッキング防止機能でCookieの保持期間が短縮され、クリックとCVが紐づかない
- 決済は完了しているが、サンクスページに到達する前に離脱している
- 決済代行サービス側のドメインでサンクスページが表示され、自社ドメインのタグが動かない
コンバージョンAPIはこの経路をサーバー側に移します。注文が確定した時点で自社のサーバーからLINEヤフー側へ直接データを送るため、ブラウザーで何が起きていたかに左右されにくくなります。仕組みとしては、ブラウザーという不安定な中継点を一つ外している、と理解しておくと迷いません。
それでも合わない数字は残る
先に書いておくと、コンバージョンAPIを入れてもカート側の受注件数とは一致しません。理由は計測経路とは別のところにあります。
- 母集団が違う：広告媒体のコンバージョンは広告に接触した人の注文だけを数える
- 集計日が違う：媒体は広告クリックの日付、カートは注文日で集計するのが一般的で、日をまたぐ注文がずれる
- 対象外の経路がある：公式告知では電話発信コンバージョンの計測機能は提供されないとされており、電話注文の比率が高い商材ではその分が丸ごと抜ける
サーバーサイド計測が埋めるのは「取れたはずなのに取れていなかった分」であって、定義の違いによる差ではありません。 この線引きを持たずに導入すると、数字が増えた理由を説明できなくなります。
比較する相手は、カート側の数字ではなく自社の過去のコンバージョン数にしてください。同じ期間・同じCV定義で導入前の2週間と導入後の2週間を並べれば、増分がこれまで取りこぼしていた分だと解釈できます。CPAやROASの目標値は計測できるCVの数を前提に決めているので、計測が変わったら目標も見直す、という順番を忘れないでください。
広告レポートの集計作業に時間を取られていませんか？ADminiなら無料で始められます。無料で試してみる →
移行で事故が起きやすい3箇所
1. 従来版タグと新しいタグを同じページに併設する
いちばん危ないのがここです。公式告知でも、従来版のタグと新しいタグを同一ページに併設すると重複計測のリスクがあると案内されています。移行期に「念のため両方残しておこう」と考えるのは自然ですが、その判断がそのままCV数の水増しにつながります。
安全な進め方は次の順番です。
- テスト環境か、影響範囲の小さいコンバージョンポイントを1つ選ぶ
- そこだけ新しいタグへ切り替える
- 数字が想定どおりかを確認する
- 問題なければ本番のサンクスページへ広げる
切り替え当日は、管理画面のコンバージョン数を1時間単位ではなく翌日以降の確定値で見てください。反映の遅れを重複と誤認して元に戻す、という二度手間がよく起きます。
2. 既存のスニペットID計測との共存を設定しないまま進める
スニペットIDを使った既存の計測を続けながら新しいタグへ移る場合、告知では個別の実装設定が必要とされています。ここを飛ばすと、片方の経路だけが有効になったり、両方が独立して数え始めたりします。
すでにタグマネージャーで複数の計測タグを管理している構成ほど、着手前に「どのタグがどの条件で発火するか」の一覧を作っておく価値があります。トリガー条件・発火ページ・対応する広告種別の3列で足ります。
3. transaction_idを送っていないのに併用を始める
タグとAPIを併用するなら、transaction_idは必須の前提です。重複排除は同じ注文を同じIDで識別できて初めて働くので、APIの送信側で注文番号を渡していなければ単純に二重に数えられます。
自社のカートシステムで注文番号をどのタイミングで確定しているかを、開発担当かカートの提供元に先に確認しておくと実装の手戻りが減ります。確認する内容は「注文確定時に一意な注文番号が発行されるか」「その値をサンクスページとサーバー側の両方から参照できるか」の2点です。
まとめ
- 追加されるのは統合計測タグ・コンバージョンAPI・transaction_idによる重複排除・クロスデバイス精度向上の4つ。既存の計測が止まるわけではないので、慌てて切り替える必要はない
- タグとAPIを併用するならtransaction_idが前提。渡していない状態で併用すると単純に二重計上になる
- 従来版タグと新タグの同一ページ併設は避ける。影響範囲の小さいCVポイントから順に切り替え、確定値で確認する
- 数字の比較相手はカートの受注件数ではなく自社の過去のCV数。増分が取りこぼし分であり、目標CPAはそれに合わせて見直す
今週やることは、いま検索広告（ショッピング）のコンバージョンをどのタグでどのページから取っているかを1枚のメモに書き出すことです。移行の判断も、事故の切り分けも、この現状把握がないと始まりません。
よくある質問
LINEヤフー広告の検索広告（ショッピング）でコンバージョンAPIはいつから使えますか
公式告知では2026年8月26日（水）に提供開始の予定とされています（変更の可能性あり）。同時に、ビジネスマネージャー発行タグまたは広告アカウント発行タグを指定した統合計測タグでのコンバージョン測定にも対応します。利用にはアクセストークンの発行など広告主側の設定が必要で、提供開始日に自動で切り替わるものではありません。
いま設置している計測タグは2026年8月26日以降も使えますか
使えます。今回の告知は新しい計測経路への対応開始であり、従来のコンバージョン測定タグを終了するという内容ではありません。ただし従来版のタグと新しいタグを同じページに併設すると重複計測のリスクがあるため、移行するときは「両方残す」のではなく、確認しながら順に切り替える進め方が安全です。
計測タグとコンバージョンAPIを両方使うと二重計測になりませんか
transaction_idを送っていれば重複排除が働き、同じ注文が両方の経路から届いても二重には計上されません。逆に言えば、注文番号にあたるtransaction_idをAPI側で渡していない状態で併用すると、単純に二重計上されます。併用を検討する場合は、自社のカートシステムで注文番号がいつ確定するかを先に確認してください。
コンバージョンAPIを入れれば、カート側の受注件数と数字が一致しますか
一致しません。広告媒体のコンバージョンは広告に接触した人の注文だけを数えるため母集団が異なり、媒体はクリック日、カートは注文日で集計するのが一般的なため期間もずれます。また電話発信コンバージョンは今回の計測機能の対象外です。サーバーサイド計測が埋めるのは取りこぼし分であり、定義の違いによる差は残ります。
図解・表つきの完全版はこちら：LINEヤフー広告の検索広告（ショッピング）が計測タグとコンバージョンAPIに対応する｜8月26日から変わる計測経路と、移行で事故が起きやすい3箇所
広告レポートの集計作業に時間を取られていませんか？ADminiなら無料で始められます。無料で試してみる →
この記事が役に立ったら LGTM をいただけると励みになります！