Self-Build vs RevenueScope: 1-Year TCO for EC Revenue Dashboards

"If we self-host Matomo, Umami, or GA4+Looker Studio we can build a free revenue dashboard, right? Why pay a monthly fee for RevenueScope?" Lately we hear this question often from Shopify EC operators in the ¥10M-¥50M GMV/month tier. The short answer: "OSS is free" is an accounting misconception — self-building generates ¥440K-¥880K of hidden 1-year cost (priced at the ¥5,000/hr Japanese freelance marketer rate). This article lines up four options — Matomo, Umami, GA4+Looker Studio, and RevenueScope — on 1-year Total Cost of Ownership and maps the threshold at which an operator should switch.

TL;DR#

1. Self-hosting OSS or GA4+Looker Studio generates ¥440K-¥880K of 1-year TCO at ¥5,000/hr equivalent. RevenueScope Growth is ¥117,600/year (¥9,800 × 12) — a 4-7× TCO advantage.
2. The hidden cost of "free" OSS is a 3-layer stack: opportunity cost on time (hours not spent on revenue activity), learning curve (Matomo configuration / GA4 event design / Looker DAX), and upgrade response (OSS major versions, GA4 API spec changes).
3. The decision flow is simple: SMB EC operators who want to redirect engineer/operator hours to revenue activity → RevenueScope; large enterprises that hold OSS as a corporate philosophy → Matomo / Umami; teams already invested in GA4+BigQuery → Looker Studio is enough.

1. Why TCO comparison matters#

The "OSS is free, so the cost is zero" view only counts software licensing. The real Total Cost of Ownership for an EC operator includes at least four elements beyond licensing:

• Initial setup hours: server configuration, tracking installation, dashboard build, initial QA
• Monthly operational hours: data quality checks, tracking fixes, new metric additions, troubleshooting
• Server costs: VPS / cloud / storage
• Learning costs: documentation reading, troubleshooting research, internal knowledge transfer

Treated as work hours, "free" OSS still costs rate × time in human capital. At the ¥5,000/hr freelance marketer / data analyst rate, the annual TCO of self-building easily climbs into the ¥hundreds-of-thousands range [4].

Opportunity cost as a complement#

Beyond TCO sits opportunity cost. If an EC operator spends 40 hours on self-build, those 40 hours can no longer go into ad creative, product page improvement, email marketing, or social media — all activities that move revenue. For an operator at ¥10M GMV/month, 40 hours equals roughly 25% of one month's working days, equivalent to direct revenue-impacting work lost.

We start the comparison from the recognition that "OSS license fee = 0" and "TCO = 0" are not the same thing.

2. The four options#

We line up four realistic options that Japanese SMB EC operators consider:

2.1 Matomo On-Premise#

Matomo is a GPLv3-licensed OSS Web Analytics tool. It comes in an On-Premise edition you self-host and a paid Matomo Cloud edition [1]. This article evaluates the On-Premise TCO assuming "self-build". Tracking, reports, and custom events are standard, but EC-focused Revenue / RPS / AOV dashboards are not in the standard template — you build them yourself with custom reports.

2.2 Umami v3#

Umami is an MIT-licensed lightweight Web Analytics tool [2]. It runs on Node.js + PostgreSQL and is small enough to fit on free tiers of Vercel / Railway / Fly.io. Pageviews, bounce rate, and referrer reports are standard, but — like Matomo — there is no out-of-the-box EC Revenue dashboard, so custom events plus custom reports are required.

2.3 GA4 + Looker Studio#

GA4 is Google's free Web Analytics tool with native ecommerce event support. Looker Studio (formerly Data Studio) is a free BI tool that connects directly to GA4 and lets you build custom dashboards [3]. For deeper analysis, GA4 → BigQuery export with SQL aggregation is possible, though BigQuery query costs apply separately.

2.4 RevenueScope#

RevenueScope is an EC-measurement SaaS designed for Japanese SMB EC. Out of the box it shows core 4 metrics — Revenue, AOV, RPS, CVR — plus Sessions in a 5-card KPI dashboard. The technical stack (GTM 5 minutes + dataLayer + GA4) is intentionally simple so a dedicated engineer is not required.

3. 1-Year TCO comparison table#

We line up the annual TCO of each option at the ¥5,000/hr Japanese freelance marketer / data analyst rate. Assumptions (industry-average estimates — actual hours vary by company; please measure in your own environment):

• Hourly rate: ¥5,000 (median freelance contract rate). For internal staff time at ¥10,000/hr, double the TCO.
• Target environment: Tier-1 Shopify EC at ¥10M-¥50M GMV/month, running a revenue dashboard (channel-level Revenue / RPS / AOV / CVR).

* Industry-average estimates (not measured). Actuals vary heavily with operational conditions, OSS version, in-house engineer maturity, and existing assets (e.g., whether GA4 is already in production).

3-1 Reading the numbers#

• Matomo Self-Host ≈ ¥800K: assumes installing the On-Premise edition on your own server and building EC-focused Revenue / RPS / AOV custom reports. Matomo Cloud reduces setup hours but adds a license fee in the several-hundred-euro/month range.
• Umami Self-Host ≈ ¥460K: lightweight implementation keeps setup short, but EC Revenue measurement still requires dataLayer integration plus custom event design.
• GA4+Looker ≈ ¥500K: Looker Studio itself is free, but GA4 event design + BigQuery export design (if needed) + Looker chart design accumulate as learning costs.
• RevenueScope Growth ≈ ¥120K: GTM 5-minute install, leverages existing dataLayer, zero additional configuration. Monthly ops is "look at the dashboard" — tens of minutes.

The intuition that "self-hosting OSS or GA4+Looker is free" collapses once you account for 40h of initial setup and 6-8h/month of operations.

4. When each option fits#

TCO alone is not the right judgement axis. Each option has its own strengths, so match against your situation.

4-1 When Matomo On-Premise fits#

• Large enterprises that prioritize personal data protection (storing customer data on company-controlled servers is a hard requirement) [5][6]
• Teams that already operate Linux servers and have engineers fluent in that environment
• Operators who want a self-designed revenue dashboard (custom metrics that the standard offering does not cover)
• Large-scale EC at ¥1B+ GMV/month, where flat-rate SaaS becomes less efficient than self-hosting

4-2 When Umami fits#

• Lightweight Web Analytics is the goal and EC-specific features are not needed
• Solo developers / startups running on free tiers of Vercel / Railway / Fly.io
• Engineering organizations that hold "simple = virtuous" as an implementation philosophy

4-3 When GA4 + Looker Studio fits#

• Teams with GA4 already in production who want to minimize incremental cost
• Organizations with in-house analysts who can leverage BigQuery export with SQL
• Teams operating under a "stay within the Google ecosystem" constraint

4-4 When RevenueScope fits#

• Shopify / BASE / STORES / EC-CUBE operators in the ¥10M-¥50M GMV/month tier
• 1-3 marketing operators, no dedicated engineer
• GA4 ecommerce tracking already in place (zero additional configuration)
• Operators who want to make investment decisions on the core 4 metrics (Revenue / AOV / RPS / CVR) plus Sessions = 5 KPI cards
• Teams whose core operation is "look at the dashboard weekly and reallocate ad budget"

For details on RPS, see RPS (Revenue Per Session): formula and examples. For AOV, see What is AOV (Average Order Value).

5. Three traps in "free"#

Even when OSS or GA4+Looker Studio is "free on the books", real-world operations stack up costs in three layers.

5-1 Trap 1: Time opportunity cost#

If you spend 40 hours building Matomo, those 40 hours leave revenue activity. For an operator at ¥10M GMV/month, 40 hours ≈ 25% of one month's working days. The opportunity cost — A/B-testing ad creative, improving LPs, designing email segments — sits on a different axis from the "¥200,000 of initial setup" line in the TCO table and must be evaluated separately.

5-2 Trap 2: Learning curve#

Even with strong documentation, OSS and Looker Studio carry non-trivial learning costs the first time:

• Matomo: vast configuration surface; custom report syntax close to SQL
• GA4: event design, custom dimensions, dataLayer mechanics — all complex
• Looker Studio: calculated-field syntax close to DAX; SQL knowledge once BigQuery is connected

Getting from "documentation read" to "working dashboard" stacks up costs that don't show up on the license line — documentation reading, Stack Overflow searches, internal wiki maintenance.

5-3 Trap 3: Upgrade response#

OSS has periodic version bumps, GA4 has API spec changes, Looker Studio has UI revisions and connector spec changes:

• Matomo major version bump: schema changes can require migration work
• GA4 API spec change: BigQuery export schema shifts can break existing queries
• Looker Studio UI revision: chart configuration may need to be rebuilt

These are unplanned operational costs that occur a few times per year and are hard to fold into the "monthly ops hours" estimate. SaaS vendors absorb them on the user's behalf, so user-side cost is zero.

6. Self-build vs SaaS decision flow#

We collapse the framing above into a flow you can run mechanically.

6-1 Q1: Are you a Shopify / BASE / STORES / EC-CUBE operator at ¥10M-¥50M GMV/month?#

• Yes → go to Q2
• No (under ¥10M GMV) → GA4+Looker Studio is enough. Build core 4 metrics into a self-made dashboard and operate
• No (¥1B+ GMV) → consider BI tools (Tableau / Looker / Mode)

6-2 Q2: Do you want to redirect engineer / operator hours to revenue activity?#

• Yes → RevenueScope. ¥9,800/month recovers ¥440K-¥880K of opportunity cost
• No (you want to self-build OSS as a corporate philosophy) → Matomo / Umami / GA4+BigQuery

6-3 Q3: Are core 4 metrics (Revenue / AOV / RPS / CVR) + Sessions = 5 KPI cards enough?#

• Yes → RevenueScope (5-metric specialization philosophy)
• No (you also want MMM / MTA / margin / LTV / inventory / ROAS calculation) → consider full-stack tools like Triple Whale covered in our previous article

Note: RevenueScope intentionally does not include ad-investment ROAS calculation (direct ad-API integration is out of scope). Metrics that can be measured in the ad platform's own console are best viewed where they are already optimized — that is the operational-load-minimization design philosophy. See The Right Way to Design Marketing KPIs for details.

7. Where RevenueScope sits: a substitute, not a complement#

By this point, RevenueScope's positioning should be clear. It is not a complement to OSS or GA4+Looker Studio — it is a substitute purpose-built for Japanese SMB EC at ¥10M-¥50M GMV/month.

7-1 Why "substitute, not complement"#

• GA4 covers the traffic measurement / recording layer. That layer stays as GA4 — RevenueScope does not compete with it.
• The revenue dashboard layer built on top of Matomo / Umami / GA4+Looker Studio is what RevenueScope replaces. Same layer, same purpose (operating a revenue dashboard).
• Self-building generates ¥440K-¥880K/year in TCO; RevenueScope handles the same operation for ¥120K/year. Because the feature scope overlaps, the relationship is substitution, not complementation.

7-2 How to think about revenue-dashboard design#

Whether you "build it yourself" or "use a SaaS", the metrics that belong on a revenue dashboard are essentially the same. The most important decision is what to show and what not to show — that is what determines whether the dashboard gets used long-term. RevenueScope adopts the design choice of deliberately narrowing to "core 4 metrics + Sessions = 5 KPI cards". See The Right Way to Design a Revenue Dashboard for the full design rationale.

7-3 Threshold for switching from self-build to RevenueScope#

If you are already self-building, the value of switching can be judged on three points:

• You want to redirect 6h+/month of operational hours to revenue activity → switch recommended
• You spend 20h+/year on OSS / GA4 upgrade response → switch recommended
• The team has a "no one knows this configuration" knowledge silo → switch recommended

Conversely, if "OSS as a corporate philosophy" is non-negotiable, your engineers are already proficient, or your existing GA4 + BigQuery investment is large, continuing self-build is rational.

Summary#

• Self-building a revenue dashboard with OSS (Matomo / Umami) or GA4+Looker Studio generates ¥440K-¥880K of 1-year TCO at the ¥5,000/hr equivalent rate
• RevenueScope Growth handles the same operation at ¥120K/year (¥9,800/month) — 4-7× TCO efficiency
• The hidden cost of "free" OSS is a 3-layer stack: time opportunity cost, learning curve, upgrade response
• For ¥10M-¥50M GMV/month operators with no dedicated engineer who are satisfied with core 4 metrics, RevenueScope is the lowest-friction option
• For corporate-philosophy OSS operators, mature in-house engineers, or ¥1B+ GMV/month large-scale EC, Matomo / Umami / GA4+BigQuery remains rational

The intuition that "OSS is free, so cost is zero" is a meaningful accounting misconception under TCO. For a ¥10M-¥50M GMV/month operator, 40 hours is a scarce resource that should go into A/B-testing ad creative or improving the LP. Spend 40 hours on tool construction or on revenue activity is the real meaning of TCO comparison.

For details on RevenueScope pricing, see the pricing page. For product philosophy, see About — the Revenue First view. For comparison with full-stack tools (Triple Whale and similar), see Triple Whale vs RevenueScope.

References#

[1] Matomo "Matomo On-Premise — Self-hosted Web Analytics" https://matomo.org/matomo-on-premise/

[2] Umami "Introduction" https://umami.is/docs

[3] Google "Data Studio documentation" https://cloud.google.com/looker/docs/studio

[4] Levtech Freelance "マーケティングのフリーランスの単価相場は？安定して案件を得る方法も紹介" (Japanese only) https://freelance.levtech.jp/guide/detail/31879/

[5] Ministry of Internal Affairs and Communications (Japan) "自分に関する情報が第三者に送信される場合、自身で確認できるようになります。" (Japanese only) https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html

[6] Personal Information Protection Commission (Japan) "個人情報の保護に関する法律についてのガイドライン（通則編）" (Japanese only) https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/