AD OPERATIONS
広告運用TikTok広告のコンバージョン計測｜Pixel・Events APIの設計と検証手順
株式会社Sunday Park / 公開：2026.10.05
TikTok広告の計測は、タグを設置してイベントが一度届けば終わりではありません。同じ購入を二重に数えていないか、広告の成果にどう帰属しているか、実際の受注と何が違うかまで確認します。Webサイト向けのPixelとEvents APIを中心に、広告担当と実装担当が共通で使える検証手順を整理します。
CONTENTS / この記事で分かること
記事の全体像を図で確認する
- 成果を定義購入成功・受付完了の時点を決める
- 送信経路PixelとEvents APIを設計
- 重複排除同じ行動のIDをそろえる
- 動作を試す正常・失敗・再送を確認
- 照合する受信・広告帰属・実受注を分ける
コンバージョン計測を、四つの段階に分ける
TikTok広告のWeb計測では、まず「何を成果にするか」を決めます。購入ボタンを押したこと、決済画面に進んだこと、実際に購入が完了したことは別の行動です。広告で増やしたい行動と、送信するイベントの意味を一致させます。
| 段階 | 確かめること | 主な確認先 |
|---|---|---|
| 行動の定義 | 決済成功やフォーム受理を成果と呼んでいるか | サイト仕様・受注管理 |
| イベント送信 | 意図した瞬間に、正しい値で送られるか | ブラウザー・サーバー・テストイベント |
| 重複排除 | 同一行動を複数経路から送っても重複扱いできるか | イベント詳細・event_idの対応 |
| 広告への帰属 | 設定した条件の下で広告成果に含まれているか | 広告レポート・帰属設定 |
本記事はWebサイトの計測を扱います。アプリ内行動やTikTok Shop、広告内で完結するフォームは、設定対象や確認場所が異なります。広告出稿の全体像はTikTok広告の出し方を先に確認してください。
担当者は、広告アカウント、データソース、対象ドメイン、成果イベント、実装方法、確認責任者を一枚にまとめます。本番と検証環境でIDが混ざる、別サイトのPixelを広告に紐付けるといった初歩的なずれを、コードを書く前に防ぎます。
PixelとEvents APIは、実装経路と保守体制から選ぶ
PixelはWebサイトのブラウザー側から行動を共有する仕組み、Events APIは企業のサーバーや対応する連携基盤などを通じてデータを共有する仕組みです。TikTok公式のEvents API解説は、Webコンバージョン目的の前提としてPixelまたはEvents APIを挙げ、重複排除をしたうえでの併用を推奨しています。
すでにECカートの連携を使っているなら、まず何が自動で送られているかを調べます。その上にGTMや独自コードを重ねると、同じ行動の送信元が増える場合があります。連携を追加する前に、Pixel ID、対象イベント、ブラウザー側とサーバー側の役割を棚卸ししてください。
GTM、パートナー連携、独自実装のどれが適するかは、今後の変更担当まで含めて決めます。独自実装なら、API応答の確認、失敗時の再送、設定変更後の検証を担う人が必要です。APIアクセストークンなどの秘密情報はブラウザーに置かず、権限を管理できるサーバー側で扱います。
Events APIを入れるだけで、失われたイベントがすべて回復したり、同意やプライバシー対応が不要になったりするわけではありません。正しい発生タイミング、必要な照合情報、許可されたデータ共有、重複排除がそろって初めて、計測の改善に使えます。
WORK & INSIGHT
配信を支える、実際の制作物。
Sunday Parkが広告運用、記事LP、広告動画用のモデル撮影、動画制作を支援した2案件です。運用会社を比較するときは、配信設定の担当だけでなく、次に必要な素材を誰が用意するかまで確認できます。 掲載案件での特定媒体・機能の利用や導入成果を示すものではありません。制作物の参考としてご覧ください。
株式会社ユーグレナ様
CONC リンクルインジェクション
広告運用と、記事LP・モデル撮影・動画制作を支援。制作物をまとめて確認できる支援事例です。
- 担当範囲
- 広告運用・記事LP制作・広告動画用のモデル撮影・動画クリエイティブ制作
株式会社MEJ様
C COFFEE EQUOL & ISOFLAVONES
「エクオールラテ」という訴求コンセプトを設計。広告運用、記事LP、撮影、動画制作まで支援しました。
- 担当範囲
- 訴求コンセプト設計・広告運用・記事LP制作・広告動画用のモデル撮影・動画クリエイティブ制作
- 広告運用・記事LP・撮影・動画制作の担当範囲を分ける。
- 配信後の課題を、原稿・素材・編集のどこへ戻すかを決める。
- 成果数値を比較する際は、期間・費用・計測条件を別途確認する。
掲載している商品説明・価格・キャンペーンは制作時点の内容です。掲載制作物だけから、配信成果や個別案件の費用を判断することはできません。
イベント名より先に、発生条件と値を設計する
以下は架空の収納用品ECの記入例です。注文作成と購入が同時に確定する単純な決済を仮定し、非同期決済や後払いは含めません。実際には、注文受付と入金完了が異なる事業もあるため、経理・開発担当と成果の時点を合わせます。
| イベント | 発生条件 | 確認する値・制御 |
|---|---|---|
| ViewContent | 対象の商品詳細を表示 | 商品IDが表示商品と対応 |
| AddToCart | カート追加の処理が成功 | 追加ボタンの単なるクリックと区別 |
| InitiateCheckout | 購入手続きを開始 | 購入完了と混ぜない |
| Purchase | サーバーで購入成功を確認 | 同一購入の識別、value、currency |
TikTok公式の標準イベント一覧で名称と推奨パラメータを確認します。例として購入金額3,800円なら、valueは数値の3800、currencyはJPYと設計します。税込・送料込みかなど、自社で使う金額の定義も記録し、受注側と比較するときにそろえます。この数値は教材用です。
問い合わせでは、送信ボタンのクリックを受理完了と同一視しないことが重要です。入力エラー時は成果にせず、正常に受付できた応答で記録します。外部予約サイトへ移るだけなら、予約成立を測れたとはいえません。外部側で取得できる完了情報と接続方法を確認します。
名称変更にも注意してください。公式のイベント名更新ガイドは、SubmitFormからLead、CompletePaymentからPurchaseへの変更と既存設定の継続動作を案内しています。一方、標準イベント一覧にはSubmitFormの掲載もあります。既存タグを一律に置き換えず、使う連携ツールの現行仕様と実際の受信名を照合し、必要な変更だけを行います。
PixelとEvents APIの併用では、同じ行動に同じevent_idを渡す
TikTok公式の重複排除解説では、同じ行動を両方の経路から送る場合、両方にevent_idを渡す必要があるとしています。イベント名に当たるeventとevent_idの対応が重要です。片方で購入、もう片方で別イベントとして送っても、同じ成果の重複として意図どおり処理されるとは限りません。
架空の購入を「purchase-demo-0042」という識別子で管理するとします。ブラウザーとサーバーが同じ購入についてPurchaseを送るときは、両方でこの値を使います。送信元ごとにランダムな別IDを生成したり、再送のたびに新しいIDへ変えたりしない設計にします。別の購入には別の識別子を使います。
更新ボタンや戻る操作で完了ページを再表示した場合も確認します。同じ購入の再表示なのか、新しい購入なのかをアプリケーション側で区別できる必要があります。APIの再試行を含む制御を実装し、媒体側の重複排除だけにすべてを任せないようにします。
重複排除の対象は同じ行動の重なりです。PixelでAddToCart、Events APIでPurchaseだけを送るように、行動が重ならない場合とは分けて考えます。保持・到着時間などの詳細条件は公式資料を確認し、ブラウザー側が先、サーバー側が先、再送が発生した場合のそれぞれを検証します。
正常系だけでなく、失敗・再読み込み・同意条件を試す
TikTokはPixel設定の公式ガイドで、Pixel Helper、テストイベント、診断の三つの確認方法を案内しています。Pixel Helperだけではサーバー側の全経路を確認できないため、実装ログとEvents Managerを合わせて確認します。
| 試す操作 | 期待する状態 | 保存する証拠 |
|---|---|---|
| 通常の購入成功 | 意図したイベントと金額を受信 | テスト識別子・時刻・受信内容 |
| 決済失敗／フォーム入力エラー | 購入・受付完了を送らない | エラーと送信ログ |
| 完了画面の再読み込み | 新しい購入として増えない | 同一event_idの対応 |
| サーバー送信の再試行 | 同一行動を再識別できる | 再送回数・応答・重複排除状況 |
| 同意の拒否・変更 | 自社の適用要件に沿う送信制御 | ブラウザーとサーバー両方の確認 |
| 実機のアプリ内ブラウザー | 遷移・購入・計測が意図どおり動く | 端末・OS・操作経路 |
テスト注文は通常受注と区別できる形で準備し、個人情報をむやみに検証資料へ残さないようにします。確認後は本番の公開版、データソースの選択、広告側の最適化イベントも照合します。GTMで保存しただけで公開していなければ、本番に反映されません。
「受信した」「広告の成果になった」「売れた」を照合する
Events Managerの公式説明では、総イベント数に広告へ帰属したものと帰属していないものが含まれます。受信状況の表示には遅延もあり、受信したすべてがTikTok広告のコンバージョンになるわけではありません。
架空の一日で受注管理が100件、イベント受信が98件、広告レポートが24件だったとしても、直ちに76件の計測漏れとはいえません。100件は全流入、24件は広告への帰属条件を満たした成果という違いがあり得ます。まず対象期間、タイムゾーン、購入の定義、キャンセルの扱い、帰属期間、表示している列をそろえます。数字は関係を示す仮定です。
受注に対してイベントが少なければ、送信対象の条件、同意による制御、エラー、外部決済経路、反映遅延を点検します。イベントが多ければ、二重実装、再読み込み、再送、複数商品の処理で購入イベントを繰り返していないかを確認します。広告成果だけが違う場合は、帰属設定と計測基準を調べます。
各媒体が同じ購入に貢献したと判断する場合もあるため、複数媒体のCVを単純に足して受注総数と比較しません。媒体内の改善判断と、事業全体の売上・利益の評価を併記する運用にします。
データ共有と、改修後の再検証までを運用に含める
計測の精度を上げるためでも、入力欄の内容をそのまま送ってよいわけではありません。TikTok公式の禁止データ共有の確認案内は、イベントの値だけでなくURL、UTM、カスタムイベントやオーディエンスの名称も点検対象にしています。センシティブな内容や不要な個人情報が混ざらないよう確認します。
同意や通知などの適用要件は地域・事業・実装で変わるため、責任者と確認してください。ハッシュ化は、無条件に共有してよい根拠にはなりません。Advanced Matchingなどの追加機能も、送るデータと目的を理解してから採用します。
- データソース・対象ドメイン・所有者・担当者を記録した
- クリックと処理成功を区別し、イベントと金額の定義を残した
- 同じ行動のeventとevent_idを送信経路間で対応させた
- 正常・失敗・再読み込み・再送を実際に試した
- 同意条件とデータ共有範囲をブラウザー・サーバー両方で確認した
- 公開後の受信、広告レポート、受注管理を照合した
- フォーム・決済・EC連携の改修時に再テストする担当を決めた
仕様確認日：2026年10月5日（日本時間）。本記事の記入例は実装コードや動作保証ではありません。利用する連携方式の最新仕様に合わせて、検証環境と本番で確認してください。
参考情報・出典
- TikTok：イベントAPIについてPixelとの併用推奨とWeb計測の前提（2026年10月5日・日本時間確認）／確認：2026-10-05
- TikTok：Standard Events and Parameters標準イベントと推奨パラメータ。SubmitForm表記も確認（2026年10月5日・日本時間確認）／確認：2026-10-05
- TikTok：Updated Standard Events名称更新と既存設定の扱い。現行一覧との表記差に留意（2026年10月5日・日本時間確認）／確認：2026-10-05
- TikTok：Event Deduplicationeventとevent_idによる重複排除（2026年10月5日・日本時間確認）／確認：2026-10-05
- TikTok：Set up and Verify PixelPixel Helper・テストイベント・診断（2026年10月5日・日本時間確認）／確認：2026-10-05
- TikTok：Events Manager monitoring and diagnostics受信イベントと広告帰属の違い、反映遅延（2026年10月5日・日本時間確認）／確認：2026-10-05
- TikTok：Prohibited data sharing notificationsURLやイベント名を含む共有データの点検（2026年10月5日・日本時間確認）／確認：2026-10-05