LINEヤフー広告の検索広告（ショッピング）が計測タグとコンバージョンAPIに対応する｜8月26日から変わる計測経路と、移行で事故が起きやすい3箇所

コンバージョン数が媒体の管理画面とカート側の受注件数で合わない。広告運用者の方から相談を受ける内容のうち、いちばん解決に時間がかかるのがこれです。原因は一つではなく、ブラウザーの制限、計測タグの設置場所、CV定義のずれが混ざっているからです。LINEヤフー広告の検索広告（ショッピング）については、2026年8月26日（水）予定で、この混ざりものの一部を切り分けられる仕組みが増えます。統合計測タグとコンバージョンAPIへの対応です。ただし「入れれば数字が合う」という話ではありません。むしろ入れ方を間違えると、これまでより数字が合わなくなる箇所が3つあります。

2026年8月26日に何が使えるようになるのか

統合計測タグ・コンバージョンAPI・重複排除の3点が加わる

加わるのは、計測の経路を選べるようにする仕組みです。公式告知によると、検索広告（ショッピング）で統合計測タグ（ビジネスマネージャー発行タグまたは広告アカウント発行タグ）を指定したコンバージョン測定ができるようになり、あわせてコンバージョンAPIも利用できるようになります。アクセストークンを発行すれば、ブラウザーを経由せずサーバーサイドから直接コンバージョンデータを送れます。

追加されるもの	実務上の意味
統合計測タグの指定	広告アカウントごとに別のタグを貼らず、1本のタグで複数の広告種別を計測できる
コンバージョンAPI	サーバーから直接送信するため、ブラウザー側の制限に左右されにくい
transaction_idによる重複排除	タグとAPIの両方で同じ注文が届いても、二重計上を防げる
クロスデバイス計測の精度向上	複数の識別情報を使い、スマホで見てPCで買った経路を拾いやすくなる

この4つのうち、実務でいちばん効くのは3つめのtransaction_idです。重複排除の仕組みがあるからこそ、タグとAPIを併用するという選択が現実的になります。どちらか一方に寄せる必要がなくなり、ブラウザー経由で取れる分はタグで、取りこぼす分はAPIで補う構成が組めるからです。

何も設定していない場合、8月26日に数字は動くのか

動きません。今回の告知は対応の「開始」であり、既存の計測を止めるという内容ではありません。これまで管理画面で発行したコンバージョン測定タグをサンクスページに設置して運用してきたなら、その計測はそのまま続きます。新しい経路を使うかどうかは、広告主側が設定して初めて有効になります。

とはいえ、判断を先送りする理由にはなりにくい状況です。ディスプレイ広告では計測タグと新しいコンバージョンAPIの提供がすでに進んでおり、検索広告（ショッピング）が加わることで、LINEヤフー広告の中で広告種別をまたいだ横断計測が同じ土台に揃います。同じ商品の成果をディスプレイと検索で別々のタグ体系から集めている状態は、集計のたびに定義の照合が必要になります。商品単位の実績を見る動きは商品一覧画面の提供開始でも進んでおり、計測の土台を揃えておくほど、そこで見える数字の信頼度が上がります。

サーバーサイド計測で埋まる穴と、埋まらない穴

ブラウザー側の計測が取りこぼす場面

取りこぼしが起きるのは、タグが実行されない、あるいは実行されても識別情報が届かない場面です。具体的には、広告ブロッカーが有効なブラウザー、トラッキング防止機能でCookieの保持期間が短縮される環境、サンクスページに到達する前に離脱するが決済自体は完了しているケース、決済代行サービス側のドメインでサンクスページが表示されるケースなどが挙がります。

コンバージョンAPIは、この経路をサーバー側に移します。注文が確定した時点で自社のサーバーからLINEヤフー側へ直接データを送るため、ブラウザーで何が起きていたかに左右されにくくなります。仕組みとしては、ブラウザーという不安定な中継点を一つ外している、と理解しておくと迷いません。同じ考え方は媒体をまたいで共通で、計測環境の断片化への対応という文脈で各媒体が同じ方向に進んでいます。

それでも合わない数字は残る

ここは先に言っておきます。「コンバージョンAPIを入れればカート側の受注件数と一致する」わけではありません。一致しない理由は計測経路とは別のところにあります。

まず、広告媒体のコンバージョンは広告に接触した人の注文だけを数えるため、そもそも母集団が違います。次に、媒体側は広告クリックの日付で計上する一方、カート側は注文日で集計するのが一般的で、日をまたぐ注文がずれます。さらに、公式告知では電話発信コンバージョンの計測機能は提供されないとされており、電話注文の比率が高い商材ではその分が丸ごと抜けます。サーバーサイド計測が埋めるのは「取れたはずなのに取れていなかった分」であって、定義の違いによる差ではありません。この線引きを持たずに導入すると、数字が増えた理由を説明できなくなります。

導入前後で比較するなら、比べる相手は自社の過去のコンバージョン数です。同じ期間・同じCV定義で、導入前の2週間と導入後の2週間を並べ、増分がどのくらいかを見る。増えた分はこれまで取りこぼしていた分だと解釈でき、目標値の見直しにも使えます。CPAやROASの目標値は計測できるCVの数を前提に決めているので、計測が変わったら目標も見直す、という順番を忘れないでください。

移行で事故が起きやすい3箇所

従来版タグと新しいタグを同じページに併設する

いちばん危ないのがここです。公式告知でも、従来版のタグと新しいタグを同一ページに併設すると重複計測のリスクがあると案内されています。移行期に「念のため両方残しておこう」と考えるのは自然ですが、その判断がそのままCV数の水増しにつながります。

安全な進め方は、テスト環境か、影響範囲の小さいコンバージョンポイントを1つ選んで先に切り替え、数字が想定どおりかを確認してから本番のサンクスページに広げる順番です。切り替えの当日は、管理画面のコンバージョン数を1時間単位ではなく翌日以降の確定値で見てください。反映の遅れを重複と誤認して元に戻す、という二度手間がよく起きます。

既存のスニペットID計測との共存を設定しないまま進める

スニペットIDを使った既存の計測を続けながら新しいタグへ移る場合、告知では個別の実装設定が必要とされています。ここを飛ばすと、片方の経路だけが有効になったり、両方が独立して数え始めたりします。すでにタグマネージャーで複数の計測タグを管理している構成ほど、どのタグがどの条件で発火するかの一覧を先に作っておく価値があります。

transaction_idを送っていないのに併用を始める

タグとAPIを併用するなら、transaction_idは必須の前提だと考えてください。重複排除は同じ注文を同じIDで識別できて初めて働くので、APIの送信側で注文番号を渡していなければ、単純に二重に数えられます。自社のカートシステムで注文番号をどのタイミングで確定しているか、開発担当かカートの提供元に先に確認しておくと、実装の手戻りが減ります。

計測を整えたあとに残るのは、媒体ごとに違う定義の数字を並べて全体を判断する作業です。LINEヤフー広告のコンバージョンとGoogle広告・Meta広告のコンバージョンは、計上のタイミングもアトリビューションの考え方も揃っていません。ADmini（アドミニ）は各媒体のデータを1画面に集約し、項目名を揃えた表として持てるので、定義の違いを踏まえたうえで並べて比較できます。月3,980円のPlusプランでも1日あたり約133円で、集計作業を外注する費用とは桁が違います。

ADminiの媒体データ1画面集約とピボット集計で、媒体をまたいだCVとコストの比較が毎朝同じ形で見られます。ADminiなら無料で始められます。無料で試してみる →

まとめ

先に限界を書いておきます。今回の対応で解決するのは計測経路の問題だけで、CV定義のずれ、集計期間のずれ、電話注文のような計測対象外の経路は残ります。これらを一緒くたにして「計測を強化したのに数字が合わない」と結論づけると、次に何を直せばよいかがわからなくなります。

そのうえで、検索広告（ショッピング）でコンバージョンAPIが使えるようになる意味は小さくありません。取りこぼしていた分が見えるようになれば、実際のCPAは下がって見えます。見え方が変わるだけで判断が変わる指標を扱っている以上、切り替えの前後で何がどう変わったかを自分で説明できる状態にしておく必要があります。ADmini（アドミニ）のようなツールで媒体横断の数値を毎日同じ形で残していれば、その説明は前後比較の表を出すだけで済みます。

まず今週やることは、いま検索広告（ショッピング）のコンバージョンをどのタグでどのページから取っているか、1枚のメモに書き出すことです。移行の判断も、事故の切り分けも、この現状把握がないと始まりません。

ADminiの媒体データ1画面集約とExcel・CSVアップロードで、広告の数字と自社の受注データを同じ表に並べられます。ADminiなら無料で始められます。無料で試してみる →

よくある質問

LINEヤフー広告の検索広告（ショッピング）でコンバージョンAPIはいつから使えますか

公式告知では2026年8月26日（水）に提供開始の予定とされています（変更の可能性あり）。同時に、ビジネスマネージャー発行タグまたは広告アカウント発行タグを指定した統合計測タグでのコンバージョン測定にも対応します。利用にはアクセストークンの発行など広告主側の設定が必要で、提供開始日に自動で切り替わるものではありません。

いま設置している計測タグは2026年8月26日以降も使えますか

使えます。今回の告知は新しい計測経路への対応開始であり、従来のコンバージョン測定タグを終了するという内容ではありません。ただし従来版のタグと新しいタグを同じページに併設すると重複計測のリスクがあるため、移行するときは「両方残す」のではなく、確認しながら順に切り替える進め方が安全です。

計測タグとコンバージョンAPIを両方使うと二重計測になりませんか

transaction_idを送っていれば重複排除が働き、同じ注文が両方の経路から届いても二重には計上されません。逆に言えば、注文番号にあたるtransaction_idをAPI側で渡していない状態で併用すると、単純に二重計上されます。併用を検討する場合は、自社のカートシステムで注文番号がいつ確定するかを先に確認してください。

コンバージョンAPIを入れれば、カート側の受注件数と数字が一致しますか

一致しません。広告媒体のコンバージョンは広告に接触した人の注文だけを数えるため母集団が異なり、媒体はクリック日、カートは注文日で集計するのが一般的なため期間もずれます。また電話発信コンバージョンは今回の計測機能の対象外です。サーバーサイド計測が埋めるのは取りこぼし分であり、定義の違いによる差は残ります。