はじめに：ブラウザ計測だけでは取りこぼす

「TikTok広告を回し始めたけれど、管理画面のコンバージョン数が実際の注文数より明らかに少ない」。最近、中小ECの方からこうした相談をいただくことが増えました。原因の多くは、ブラウザ側だけで計測している、いわゆる「Pixelだけの状態」にあります。

TikTok広告の標準的な計測は、サイトに設置したTikTok Pixel（ブラウザで動くタグ）でコンバージョンを拾う仕組みです。ところが、このブラウザ計測には取りこぼしがつきまといます。広告ブロッカーやトラッキング防止機能でタグそのものが読み込まれないことがありますし、ページ遷移の途中で離脱されればイベントが送られません。スマートフォンでアプリ内ブラウザからサイトに来たケースなど、Cookieやスクリプトの挙動が不安定な環境も少なくありません。

つまり、ブラウザ計測だけに頼っていると、実際には発生しているコンバージョンの一部が「なかったこと」になります。広告管理画面の数字が実態より小さく見え、その不正確なデータをもとに機械学習が最適化を進めるため、配信効率まで落ちてしまう、というのが今の広告運用が抱える典型的な悩みです。

特にTikTokのようにスマートフォンからの流入が中心の媒体では、この影響が大きく出やすい傾向があります。アプリ内で動画を見て、興味を持ってサイトに飛び、後日あらためて購入する、といった行動の途中で計測が途切れると、その広告がもたらした成果がまるごと見えなくなります。成果が見えなければ、「TikTokは効果がない」と誤って判断してしまうことにもつながりかねません。

この記事では、その取りこぼしを補う手段として「Conversions API（CAPI）」と「サーバーサイドGTM」を取り上げます。具体的な設定画面の操作は仕様変更が早いため、ここでは「考え方」と「全体の流れ」を中心に整理していきます。読み終えたあとに、自社で何から手をつければよいかの見取り図を持ち帰っていただくことを目指します。

対象として想定しているのは、TikTok広告をある程度の予算で運用していて、計測の精度に不安を感じている中小ECや個人事業主の方です。専門のエンジニアがいなくても流れがつかめるよう、用語はできるだけかみ砕いて説明します。

この記事は2026年6月時点の一般的な情報をもとにした解説です。TikTok広告やGTMの管理画面の仕様、API仕様、各種ポリシーは頻繁に変わります。導入時は必ず最新の公式ドキュメントをご確認ください。

Conversions API（CAPI）が必要な理由

Conversions API（以下CAPI）は、ブラウザを経由せず、サーバーから直接TikTok側へコンバージョン情報を送る仕組みです。TikTokではこの仕組みを「Events API」と呼ぶこともありますが、考え方は同じで、サーバー間（Server to Server）でイベントを送信します。

ブラウザ計測がなぜ取りこぼすのかを、もう少しかみ砕いておきます。ブラウザ上のタグは、ユーザーの端末という「自社の管理が及ばない場所」で動いています。そのため、ブロッカーで止められる、ネットワークが不安定で送信が途切れる、ページ遷移が速すぎて発火前に画面が切り替わる、といった事情に左右されます。これらは実装の良し悪しだけでは防ぎきれません。

サーバー計測は、この「管理外で動く」という前提を変えます。自社が管理するサーバーから送るため、外的な要因に左右されにくく、送信の成否も自分たちで確認できます。これがCAPIの根本的な強みです。

ブラウザ計測（Pixel）とCAPIの違いを整理すると、次のようになります。

  • Pixel（ブラウザ計測）: ユーザーの端末上で動くタグが、購入や問い合わせなどのイベントを送る。手軽だが、ブロッカーや離脱、ブラウザ環境の影響を受けやすい。
  • CAPI（サーバー計測）: 自社が管理するサーバーから、イベントを直接送る。ブラウザの制約を受けにくく、取りこぼしを減らせる。

ポイントは、CAPIはPixelの「置き換え」ではなく「補完」として使うのが基本だということです。両方を併用することで、ブラウザでしか取れない情報（ページの細かな行動など）と、サーバーだから確実に取れる情報（決済完了の事実など）を、お互いに補い合えます。

なぜ補完が成り立つかというと、サーバーは注文処理の「結果」を確実に把握しているからです。ブラウザ側でタグが発火しなかった注文でも、サーバーが処理した注文であればCAPI経由で送れます。結果として、管理画面のコンバージョンが実態に近づき、最適化の土台となるデータの質が上がります。

もうひとつの利点は、サーバー側のほうが豊富な情報を扱える点です。たとえば注文金額や注文番号、購入された商品などは、サーバーが確実に持っている情報です。ブラウザ計測ではタイミングや実装の都合でこうした値が抜け落ちることがありますが、サーバー起点なら漏れにくくなります。送れる情報が増えれば、広告側のマッチング精度も上がりやすく、レポートの信頼性が高まります。

ただし、CAPIを入れたからといって、ブラウザ計測の取りこぼしが完全にゼロになるわけではありません。あくまで「これまで取れなかった分の一部を取り戻す」ものだと理解しておくと、導入後の数字の変化を冷静に評価できます。導入前後で何件のコンバージョンが増えたかを記録しておくと、効果の説明がしやすくなります。

サーバーサイドGTMの構成

CAPIを送る方法はいくつかありますが、中小ECにとって比較的扱いやすいのがサーバーサイドGTM（以下sGTM）を経由する方法です。

通常のGTM（ウェブコンテナ）はブラウザ上でタグを動かします。一方sGTMは、自社が管理するサーバー上にタグ処理用のコンテナを置き、そこを中継地点として各ツールへデータを送ります。データの流れは、おおまかに次のようになります。

  1. ブラウザ（ウェブコンテナ）が、購入などのイベントを自社のsGTMサーバーへ送る。
  2. sGTMサーバーが受け取ったイベントを整理し、TikTokのCAPI向けに整形する。
  3. sGTMサーバーから、TikTokへサーバー間でイベントを送信する。

この構成のメリットを、もう少し具体的に挙げてみます。

  • 計測ロジックを集約できる: ブラウザにベタ書きするタグを減らせるため、送信内容の管理が一箇所で済みます。修正もsGTM側だけで完結しやすくなります。
  • ブロッカーの影響を受けにくい: 自社ドメインのサーバーを経由する構成にすると、ブラウザ側のトラッキング防止機能の影響を受けにくくなります。
  • 複数媒体に配りやすい: TikTokだけでなく、他の広告媒体やGA4にも同じイベントを配りたい場合、中継地点があると見通しがよくなります。
  • 送信前にデータを整えられる: 不要な情報を落としたり、形式を整えたりする処理をサーバー側で挟めます。各媒体の要件に合わせやすくなります。

一方で、sGTMはサーバーを動かし続けるためのインフラ（多くの場合クラウド上の実行環境）が必要になり、その分の運用コストと知識が求められます。サーバーの監視や、想定外のアクセス増に備えた設計など、ブラウザ計測にはなかった運用の手間も発生します。小規模なうちは、この手間が成果に見合わないこともあります。

そのため、「まずPixelをきちんと設置し、取りこぼしが課題になってからsGTM＋CAPIへ進む」という順序が、無理のない進め方だと考えています。広告費がまだ小さい段階では、Pixelの正しい設置と、コンバージョン地点の正確な定義のほうが優先度は高いです。広告費が増え、数%の取りこぼしが金額として無視できなくなってきたら、CAPI導入を検討するタイミングだと判断できます。

sGTMを使わずに送る選択肢

補足として、CAPIを送る方法はsGTM経由だけではありません。代表的な選択肢を挙げておきます。

  • ECプラットフォームの公式連携を使う: 利用しているカートシステムにTikTok連携アプリがあれば、それを入れるだけでCAPI相当の送信が行える場合があります。最も手軽です。
  • 自社サーバーから直接APIを叩く: 注文処理のプログラムに、TikTokのAPIへ送る処理を組み込む方法です。柔軟ですが、開発と保守の負担が大きくなります。
  • sGTMを中継地点にする: 本記事の主題の方法です。複数媒体への送信や、計測ロジックの一元管理がしやすいのが利点です。

どれが最適かは、使っているカートシステム、開発リソース、扱う媒体の数で変わります。まずは公式連携で足りないか確認し、足りなければsGTMや直接APIを検討する、という順で考えると無駄が少なくなります。

イベント送信の設計

実装に入る前に、設計で押さえておきたい点が2つあります。重複排除と、Pixelとの併用です。どちらも、後から直そうとすると影響範囲が広くなりがちなので、最初に方針を固めておくことをおすすめします。

event_id による重複排除

CAPIを導入すると、同じ1件のコンバージョンが「Pixel（ブラウザ）」と「CAPI（サーバー）」の両方から送られる状況が生まれます。何も対策しないと、1件の注文が2件に数えられてしまいます。

これを防ぐのが、イベントごとに付ける一意の識別子です。TikTokでは event_id（イベントID）と呼ばれる値を使います。同じコンバージョンに対しては、Pixel側とCAPI側で同じ event_id を付けて送ります。すると受け取ったTikTok側が「これは同じイベントだ」と判断し、片方にまとめてくれます。

設計上のコツは、event_id を「注文ごとに一意で、ブラウザとサーバーの両方から同じ値を参照できる」形にすることです。たとえば注文番号やトランザクションIDをもとに生成すると、両者で値を揃えやすくなります。具体的なフィールド名や必須要件は変わりやすいので、最新の公式ドキュメントで確認してください。

逆に避けたいのは、ブラウザ側とサーバー側でそれぞれ別々にランダムな値を発番してしまうことです。これでは値が一致せず、重複排除が働きません。「どこか一箇所で発番し、その値を両方が参照する」という流れを最初に決めておくのが安全です。

ブラウザPixelとの併用

重複排除の仕組みが整っていれば、PixelとCAPIは安心して併用できます。むしろ併用が前提です。

  • Pixelは、ページ閲覧やカート投入など、ブラウザ上の行動を細かく拾うのが得意です。
  • CAPIは、決済完了など「確実に起きた事実」を取りこぼさず送るのが得意です。

両者を event_id でひも付けながら併用することで、カバー範囲が広がり、かつ二重計上を避けられます。「PixelをやめてCAPIに一本化する」という発想ではなく、「役割の違う2本立てで穴を埋める」と捉えると設計しやすくなります。

なお、重複排除がうまく働くためには、両方のイベントが「同じイベント名・同じ識別子」で送られていることが前提になります。Pixel側は購入イベント、CAPI側は別名のイベント、といったずれがあると、TikTok側が同一とみなせず重複排除が効きません。実装の際は、イベント名と event_id の組み合わせを両者で揃えることを最初に決めておくと、あとからの手戻りが減ります。

実装の流れ

ここからは全体の流れを順に追います。各手順の具体的なUI操作は最新の公式ドキュメントに従ってください。

着手前に、次の3点が準備できているかを確認しておくとスムーズです。

  • TikTok広告のアカウントと、計測したいコンバージョン地点（購入完了ページなど）が明確になっていること。
  • すでにTikTok Pixelが設置され、ブラウザ計測が一通り動いていること。
  • sGTMを動かすサーバー環境を用意できる見込みがあること。

これらが整っていない場合は、まずそこから着手します。特に、Pixelが正しく動いていない状態でCAPIだけ足しても、全体像が把握しづらくなります。土台がぐらついたまま上を積み上げると、不具合の原因がどこにあるか分からなくなりがちです。

  1. TikTokのイベント設定を確認する: TikTok広告の管理画面（イベントマネージャ）で、計測したいコンバージョン（購入、問い合わせなど）と、CAPI連携に必要なトークンなどの情報を確認します。
  2. sGTMサーバーを用意する: サーバーサイド用のGTMコンテナを作成し、タグを動かすための実行環境を立ち上げます。
  3. ウェブコンテナからsGTMへ送る: ブラウザ側のウェブコンテナを、自社のsGTMサーバーへイベントを送る設定にします。このとき、注文情報や event_id を含めて渡せるようにします。
  4. sGTMでTikTok向けにタグを設定する: sGTM側で、受け取ったイベントをTikTokのCAPI向けに送るタグを設定します。TikTok公式が提供するタグテンプレートが使える場合は、それを利用すると設定が簡単になります。提供状況や名称は変わるため、最新の公式情報を確認してください。
  5. Pixelとの重複排除を合わせ込む: ブラウザのPixelとCAPIで、同じコンバージョンに同じ event_id が渡るようにします。
  6. テストして検証する: 実際にテスト注文を行い、TikTokのイベントマネージャ側で正しく受信されているか、重複していないかを確認します。GTMのプレビュー機能と合わせて検証すると原因を切り分けやすくなります。

この流れの途中で数字が合わない場合、原因の多くは「どの段階でデータが欠けているか」の切り分け不足です。ブラウザからsGTMに届いていないのか、sGTMからTikTokへの送信が失敗しているのか、それとも届いてはいるが重複排除でまとめられているのか、で対処は変わります。各段階を順番に確認していくと、原因にたどり着きやすくなります。GA4でも似たトラブルが起きやすいので、計測のデバッグ手順については GA4移行でデータが欠けるときのGTMデバッグ手順 も参考にしてみてください。

検証では、いきなり本番の全トラフィックに適用せず、まずテスト用のイベントで動作を確認するのが安全です。意図しないデータが大量に送られてから気づくと、レポートが汚れてしまい、後始末に手間がかかります。小さく試し、確認できてから範囲を広げる、という進め方を徹底してください。

よくあるつまずき

実装の現場でよく見かけるつまずきを、いくつか挙げておきます。事前に知っておくと、原因の切り分けが速くなります。

  • コンバージョンが二重に計上される: PixelとCAPIで event_id が揃っていない、またはイベント名がずれているケースです。まず両者の値が一致しているかを確認します。
  • CAPI側のコンバージョンが増えない: sGTMからTikTokへの送信が失敗していることが多いです。送信先の設定値や認証情報が正しいか、エラーが出ていないかを確認します。
  • 注文金額が送られていない: ブラウザからsGTMへ値を渡す段階で、金額などの情報が抜け落ちていることがあります。中継地点であるsGTMに何が届いているかを確認すると、欠けている箇所が見えます。
  • テスト時の数字が本番に混ざる: テスト用のイベントと本番のイベントを区別せずに送ってしまうと、レポートが不正確になります。テスト用のフラグや環境を分けておくと安全です。

いずれも「データの流れのどこで起きているか」を意識すれば切り分けられます。ブラウザ、sGTM、TikTokの3点を順にたどる癖をつけておくとよいでしょう。

同意・規約の注意

技術的に送れることと、送ってよいことは別の問題です。CAPIではサーバーからユーザーに関する情報を送るため、同意とポリシーの扱いには特に注意が必要です。ブラウザ計測のときよりも「自社の責任でデータを送っている」という意識が求められます。

⚠️ CAPIで送るデータの範囲は、最終的に「ユーザーの同意」と「適用される法令・各サービスの利用規約」に従って決まります。同意していないユーザーのデータをサーバー経由だからといって送ってよいわけではありません。プライバシーポリシーへの記載、同意管理（CMP）との連携、TikTokをはじめ各媒体の利用規約とデータ取り扱いポリシーの遵守を、導入前に必ず確認してください。判断に迷う場合は専門家への相談も検討してください。

同意の取り扱いとサーバーサイド計測の組み合わせ方については、サーバーサイドGTM × Consent Mode v2で広告計測精度を維持する2026年の最適解 で詳しく整理しています。CAPIを本格的に運用するなら、同意モードとの連携はセットで考えておきたいテーマです。

実務上は、「同意を得たユーザーのコンバージョンだけをCAPIで送る」「同意状態をsGTMまで正しく引き継ぐ」といった設計が必要になります。同意したかどうかの情報がサーバー側に渡っていなければ、サーバーは判断できません。同意管理の仕組みと計測の仕組みは、別々に作るのではなく、最初から一体で設計することが大切です。

まとめ

TikTok広告のコンバージョンAPIをサーバーサイドGTMで実装する流れを整理しました。要点を振り返ります。

  • ブラウザのPixelだけでは、ブロッカーや離脱、環境の影響でコンバージョンを取りこぼす。
  • CAPIはサーバーから直接イベントを送ることで、その取りこぼしを補える。Pixelの置き換えではなく補完として使う。
  • sGTMを中継地点にすると、計測ロジックを一箇所に集約でき、見通しがよくなる。
  • PixelとCAPIを併用する際は、event_id による重複排除で二重計上を防ぐ。
  • 同意・規約の扱いは技術とは別問題。送る前に必ず要件を確認する。

まずはPixelを正しく設置し、取りこぼしが事業の判断に影響し始めたタイミングでCAPI＋sGTMへ進む、という順序がおすすめです。いきなり完璧な構成を目指すより、現状の計測がどこで欠けているかを把握することが先決です。

計測は「正確であること」自体が目的ではなく、正しい判断のための土台です。数字が実態に近づけば、どの広告に予算を寄せるべきか、どのクリエイティブが効いているかが見えてきます。仕様は変わりやすいので、設定の細部は最新の公式ドキュメントを確認しながら、小さくテストして、一歩ずつ精度を上げていってください。