⚖️

Triple Whale と RevenueScope｜計測哲学とアーキ設計の違いを比較

2026/05/05に公開

EC計測ツールを比較するとき、機能数の多寡 で並べる記事は多い。一方で 設計思想の違い を整理した記事は少ない。本稿は Triple Whale と RevenueScope を 計測哲学とアーキテクチャ設計 の軸で並べ、両者がなぜこの形に着地したのかを解読します。
結論を先に出すと、両者は「機能スコープを広く取って情報密度を上げる派」と「機能スコープを狭く絞って迷う要素を減らす派」の対比で、住み分けに落ちる構造です。

 1. 計測哲学 — 「何を測るか」より「何を測らないか」両者の出発点を端的に言語化するとこうなります。


哲学
Triple Whale
RevenueScope


計測の射程
「測れるものは全部測る」
「投資判断に必要なものだけ測る」

価値提供軸
情報の網羅性 (intelligence platform)
意思決定の速度 (5 KPIカード)

設計の中心問い
What can we measure?
What must we measure to act?

拡張方向
縦横に拡張 (MMM → MTA → Subscription → SQL → Sonar)
拡張せず深さで勝負 (コア4指標固定)

Triple Whale は 「ecommerce intelligence platform」 を自称する通り、ad investment efficiency (MMM/MTA/Incrementality) から在庫・サブスク・creative analysis までフル機能を志向しています。測れるものは全部測り、その中から事業者が必要なものを取捨選択する設計です。
一方の RevenueScope は 「売上から逆引きするアクセス解析」 を自称し、Revenue・AOV・RPS・CVR の コア4指標 + Sessions = 5 KPIカードに意図的に絞っています。「測らないこと」を意思決定する設計です。広告投資ROAS算出のような「広告管理画面側で完結できる指標」はあえて持たない。
設計判断としては、「ダッシュボードの情報密度を上げる」ことと「ダッシュボードを使い続けてもらう」ことは時にトレードオフになる という前提に基づいています。スコープを絞ることで運用負荷を最小化し、毎週のダッシュボード閲覧で迷う要素を消す — この設計判断が成り立つのは、ターゲットを 日本SMB EC (マーケ担当1-3名・エンジニア専任なし) に絞っているからです。

 2. アーキ設計 — データ取得経路の対比哲学の違いはアーキにそのまま落ちます。

 Triple Whale: Pixel + 広告API直連型[ユーザー] → [Triple Pixel JS] → [Triple Whale Storage (US)]
                ↓
         [cross-device identity resolution]
                ↓
[Meta/Google/TikTok/etc 60+ Ad APIs] → 直接連携
                ↓
       [Compass: MMM / MTA / Incrementality]
                ↓
       [75+ pre-built dashboards / SQL Editor]
主要な技術判断：

identity resolution を自前で持つ: cross-device / cross-platform で「同一ユーザー」を確定する Pixel を中核に置く

広告API直連で配信データを内包: Meta Marketing API / Google Ads API などから配信データを直接取得し、ROAS を内製

MMM/MTA/Incrementality を Compass に統合: 広告投資効率測定の3モデルを単一プロダクトに集約

データ保管 US: グローバル展開 D2C ブランド前提の保管地
このアーキは 「広告投資効率測定の責務をツール内に内包する」 という哲学的判断の帰結です。広告API側の仕様変更や障害もツール側で吸収する代わりに、ベンダーロックインの強さを引き換えに取ります。

 RevenueScope: dataLayer 相乗り型[ユーザー] → [GTM tag (1つ)] → [dataLayer.push (purchase event)]
                ↓
         [RevenueScope tracker JS (~4KB)]
                ↓
[Supabase Edge Functions (Northeast Asia/Tokyo)]
                ↓
       [PostgreSQL: visitor / session / purchase]
                ↓
       [5 KPI cards: Revenue / AOV / RPS / CVR / Sessions]
主要な技術判断：

identity resolution を持たない: ファーストパーティ Cookie の visitor_id のみ。cross-device は意図的にスコープ外

dataLayer に相乗り: GA4 eコマース実装 (dataLayer.push({ event: 'purchase', ... })) を直接読み取り、追加実装ゼロ

広告API は持たない: Meta/Google等の広告API直接連携なし。UTM パラメータと dataLayer purchase イベントの集計のみ

データ保管 Tokyo: 日本SMB EC前提
このアーキは 「広告投資効率測定の責務を外部に委任する」 という哲学的判断の帰結です。設定変更や新規広告媒体の追加への追従しやすさを取る代わりに、cross-channel で一貫した attribution は提供しません。

 3. 7軸スコープマップ哲学とアーキの違いは、機能スコープの違いに帰着します。
7軸で並べたとき、両者の機能の重なりは小さい。Triple Whale は広告API直連によるフル機能、RevenueScope は dataLayer 相乗りでコア4指標 + Sessions のみ。重なるのは「ストアフロントで起きた visitor / session / purchase の集計」だけで、その先の attribution / ROAS 算出 / MMM への展開は両者で完全に分岐します。

 4. 価格設計の哲学的整合価格モデルもそれぞれの哲学に整合した設計です。

 Triple Whale: GMV連動段階制直近12ヶ月のGMV帯に応じて、各プランの月額が動的に変動します。
GMV帯：<$250K → $5M → $15M → $40M → $100M → $175M → $350M+
GMV連動の段階制は 「事業規模が大きくなれば、ツールが提供する価値も大きくなる」 という前提に立ちます。intelligence platform を自称する以上、規模に応じた価値スケーリングを価格構造で表現する必要がある — 哲学と価格設計の整合です。

 RevenueScope: 固定3プランセッション数とサイト数による固定3プラン。GMV連動はしません。


プラン
月額
セッション/月
監視サイト
データ保持


Starter
¥2,980
1万
1
14ヶ月

Growth
¥9,800
5万
5
24ヶ月

Scale
¥29,800
20万
10
36ヶ月

固定3プランは 「事業規模に依存せず、セッション数だけで選べる」 設計判断です。GMV情報を事前に共有するコミュニケーションコストをゼロにし、検討の摩擦を最小化する — シンプル特化の哲学と価格設計の整合です。

 5. 4つの判定基準 — 設計哲学のどちら側に立つか実際の選定では4軸で判定可能です。

言語要件: 英語チーム / 日本語必須

必要機能: フル機能 / コア4指標で十分

必要技術: エンジニアあり / GTM運用のみ

広告API統合: 内包したい / 外部委任で十分
4つすべてが Triple Whale 側に振れているなら Triple Whale、すべてが RevenueScope 側に振れているなら RevenueScope。ミックスする場合は「最も外せない軸」が決定軸 になります。
設計哲学の観点で言い換えると：

「測れるものは全部測りたい」 派 → Triple Whale

「測らないことの価値を信じる」 派 → RevenueScope

 6. データオーナーシップという見落とされがちな軸設計判断には「機能仕様」以外に 「データ保管地」 という観点もあります。Triple Whale はUSデータセンター運用、RevenueScope は Supabase Northeast Asia (Tokyo) リージョン運用です。
日本市場の事業者にとっては、改正電気通信事業法（外部送信規律）と個人情報保護法の観点で 「個人関連情報の取扱者をどこまで自社責任として説明できるか」 という論点が発生します。データ保管地として日本リージョンを採用しているかどうかは、compliance を気にする事業者にとっては評価軸になります。

 7. まとめ — 設計思想で選ぶ両者は機能数の多寡で並べると優劣論争になります。設計思想の対比で並べると住み分けの構造が見えます：

Triple Whale: 「測れるものは全部測る」哲学 → 広告API直連 + Pixel + MMM/MTA/SQL のフル機能 → 英語チーム + フル機能要件 + エンジニアあり前提

RevenueScope: 「測らないことの価値を信じる」哲学 → dataLayer相乗り + コア4指標 + Sessions = 5 KPIカード → 日本語チーム + シンプル運用 + GTM運用のみ前提
両者を 併用するブランドも存在しえます（日本市場の運用は RevenueScope で日次・グローバル全体の MMM 分析は Triple Whale で四半期、など）。機能スコープが重ならないからこその選択肢です。
詳細な実機データ・参考文献・ペルソナ別判定は本家記事を参照：
Triple Whale vs RevenueScope｜価格・機能・日本対応の違い

 参考Triple Whale 公式 https://www.triplewhale.com/
Triple Whale Pricing https://www.triplewhale.com/pricing
総務省 改正電気通信事業法（外部送信規律） https://www.soumu.go.jp/menu_news/s-news/01ryutsu02_02000408.html
個人情報保護委員会 ガイドライン https://www.ppc.go.jp/personalinfo/legal/

哲学	Triple Whale	RevenueScope
計測の射程	「測れるものは全部測る」	「投資判断に必要なものだけ測る」
価値提供軸	情報の網羅性 (intelligence platform)	意思決定の速度 (5 KPIカード)
設計の中心問い	What can we measure?	What must we measure to act?
拡張方向	縦横に拡張 (MMM → MTA → Subscription → SQL → Sonar)	拡張せず深さで勝負 (コア4指標固定)

プラン	月額	セッション/月	監視サイト	データ保持
Starter	¥2,980	1万	1	14ヶ月
Growth	¥9,800	5万	5	24ヶ月
Scale	¥29,800	20万	10	36ヶ月

1. 計測哲学 — 「何を測るか」より「何を測らないか」

2. アーキ設計 — データ取得経路の対比

Triple Whale: Pixel + 広告API直連型

RevenueScope: dataLayer 相乗り型

3. 7軸スコープマップ

4. 価格設計の哲学的整合

Triple Whale: GMV連動段階制

RevenueScope: 固定3プラン

5. 4つの判定基準 — 設計哲学のどちら側に立つか

6. データオーナーシップという見落とされがちな軸

7. まとめ — 設計思想で選ぶ

参考

Discussion