fbc + em + ph 統合CAPIペイロードを唯一実現するsGTMネイティブASP。 postback時代に設計された計測基盤では構造的に不可能だった精度を、設計段階から作り直しました。 日本国内B2C事業者のCV計測基盤を、サーバーサイドに一気に引き上げます。
日本国内で流通するpostback型ASPは、postback時代の計測プロトコルを前提に設計されています。 ただしこの設計思想では、Meta・TikTokのアルゴリズムが求める"CAPIによる高品質な学習シグナル"を構造的に送れません。 これは個別サービスの優劣ではなく、設計思想の世代差の問題です。
既存ASPはクリック識別子（fbc）をpostback経由で送るのが主流。em・phといったPII系ハッシュを同一リクエストで送れないため、Meta側のアルゴリズムがユーザー同定に使える情報量が根本的に不足します。
ASP経由のpostbackはURLクエリパラメータでの送信が基本設計。PII（em/ph）のSHA-256ハッシュは長く、クエリで扱うには無理があります。CAPIが求める`user_data`ネストJSONの構造をpostbackでは表現できません。
同一CVをMeta / Google / Yahoo / TikTok / LINEへ送る場合、既存ASPは各プラットフォームを個別連携で管理。重複排除キーの統一設計がなく、同一ユーザーが複数媒体でダブルカウントされる問題が構造的に残ります。
track-19DDはsGTMネイティブ設計のASP。 既存ASPが"後付けでCAPIを載せた"のに対して、設計の起点からサーバーサイド前提で作り直しているため、 他社では構造的に到達できない実装が可能です。
同一CVイベントに対して、クリック識別子（fbc/fbp）・メール（em）・電話（ph）・外部ID（external_id）をsGTMが一度に束ね、Metaへ単一リクエストで送信します。 これは構造上、他ASPで実現できない構成です。
同一CVがブラウザPixel・CAPI・postbackから複数回発火すると、広告管理画面のCV数が実態からズレ、 Meta・TikTokのアルゴリズムは誤った学習データで最適化してしまいます。 track-19DDは全イベントに統一event_idを付与し、媒体側で確実に重複排除されることを保証。 パートナーの収益を、正確な数字の上に立たせます。
Stape公式パートナー（Partner ID: bbmbgajd）として、Stape StoreのreStore機能をフル活用。 フォーム入力した em / ph / external_id をサーバーサイドに永続化し、後続のすべてのCAPIリクエストで復元してEMQを最大化します。
感情や印象ではなく、機能の有無で比較します。 下記項目はCAPI時代の計測品質を左右する必須機能です。現行のASP選定は、このマトリクスを元に稟議書を作成できる状態になっています。
| // Feature | track-19DD | 従来ASP A | 従来ASP B |
|---|---|---|---|
| fbc + em + ph 統合CAPIペイロード unified CAPI in single request | 完全対応 | 不可 | 不可 |
| fbc 送信 fbc transmission | 対応 | 対応 | 対応 |
| em (hashed email) 送信 SHA-256 email hash | 対応 | 一部対応 | 不可 |
| ph (hashed phone) 送信 SHA-256 phone hash | 対応 | 不可 | 不可 |
| sGTMネイティブ設計 server-side GTM native | ネイティブ | 非対応 | 非対応 |
| Stape Store / reStore server-side user enrich | Partner連携 | 不可 | 不可 |
| LIFF × fbc ブリッジング LINE webview fbc bridge | 対応 | 不可 | 不可 |
| Yahoo CAPI (_ly_c / _ly_rt) Yahoo server-side conv | 対応 | postbackのみ | postbackのみ |
| MCV多段計測 micro-conversion funnel | 任意多段 | 最終CVのみ | 最終CVのみ |
| 重複排除キー統一（event_id） unified dedup key | 全媒体統一 | 媒体別 | 媒体別 |
| EMQ平均スコア Event Match Quality avg. | 9.2 / 10 | 6.0 / 10 | 5.5 / 10 |
| BigQuery連携 raw event log export | 標準搭載 | オプション | 不可 |
| BOTCHAN / ecforce 連携 chatbot + cart CV track | 実装済み | 要カスタム | 要カスタム |
| Meta公式 CAPI Gateway 相当 first-party CAPI infra | 相当 | 非該当 | 非該当 |
Webフロント・LIFF・チャットボットからの全イベントを、Stape上のsGTM (track-19DD container) が一元受信。 Stape Storeでユーザーデータをエンリッチした上で、5つのプラットフォームにCAPIで同時配信します。BigQueryへの生ログ出力も標準搭載。
3つの代表的な実装パターンを紹介します。どれも既存ASPでは実現が難しいケースで、track-19DDのsGTMネイティブ設計によって初めて成立しています。 それぞれ継続運用中です。
YahooがsGTM公式テンプレート未公開の期間中に、Stape製JSON HTTP requestタグでカスタム実装。_ly_c / _ly_rt cookieをサーバーサイドで永続化し、postback経路では取りこぼしていたCVを全てYahoo広告のアルゴリズムに反映。
ブラウザPixel・CAPI・postbackの3経路から同一CVが複数発火していた環境に対して、全イベントにevent_idを統一する設計を実装。Meta管理画面のCV数が実態と一致し、誤った学習データによるCPA高騰を解消。アルゴリズムの学習精度が劇的に向上しました。
BOTCHAN / ecforce のフォーム各ステップで発生するマイクロコンバージョン（email入力、電話入力、カート到達、決済完了）を独立したCAPIイベントとしてMetaに送信。最適化対象の粒度を細かくすることで、学習速度を劇的に改善。
track-19DDの導入は、既存の計測基盤を止めずに並行稼働で進めます。 本番切り替えの判断は、並行運用で品質を確認してから行うので、導入リスクを最小化した状態で移行を完了させられます。
お問い合わせフォームまたは直接ご連絡ください。現行計測構成のヒアリングを実施します。
CAPI要件・LIFF連携・MCV設計を確定。Stape環境とsGTMコンテナの構成案を提示します。
sGTMコンテナ構築、CAPIテスト、既存ASPと並行稼働してデータ品質を検証。
本番切替後はダッシュボードと週次レポートで継続的に最適化。Stape運用保守込み。
track-19DDは月間CAPIイベント数に応じたスライド課金を採用しています。 導入時のコンサルティング・sGTM構築・運用保守を含むフルサービス契約です。具体金額は、現行配信量・プラットフォーム数・計測要件をヒアリングの上で提示します。
初期構築・sGTM運用・CAPI実装・ダッシュボード提供・週次レポートを含む統合サービス。 現行配信量・必要プラットフォーム数・カスタム要件を踏まえ、最適なプランを設計します。
track-19DDの技術詳細・導入条件・料金レンジは、直接のお問い合わせにのみご案内しています。 プロダクトにご興味のある事業者様は、下記フォームよりご相談ください。原則2営業日以内にご返信します。