DEV Community: toshihiro shishido

You Set Up GA4 E-commerce — But Can't Find the Drop-off Points

toshihiro shishido — Tue, 12 May 2026 22:40:11 +0000

"GA4 ecommerce events are firing — but I still can't tell where customers are dropping off."

This is the most frequent question I hear from EC operators who finished setup but stalled before turning numbers into fixes. Setup is done; reading the numbers as fix-driving signals is not.

This article walks through how to visualize drop-offs from view to purchase stage-by-stage in GA4, and how to pick the right action — in a three-layer structure of setup HOW, interpretation WHY, and improvement ACTION.

TL;DR

Build the funnel in 5 stages: view → add-to-cart → checkout start → payment info → purchase. Stage-level drop-off makes the leaking step obvious
Read numbers in two axes: industry comparison + stage comparison. Compare against industry-typical rates, not absolute values. The biggest stage-to-stage gap is where to focus
Match the action to the stage: view→cart is a landing page issue, cart→checkout is shipping/stock, checkout→purchase is form length / payment options. Wrong stage targeting wastes campaign spend

1. What a 5-stage funnel looks like

EC funnel analysis is a method to visualize the drop-off path to purchase. With GA4's standard e-commerce events, you can observe all five stages with zero additional implementation.

The five stages are view_item → add_to_cart → begin_checkout → add_payment_info → purchase. Calculating the pass-through rate at each step decomposes site-wide CVR into stage-level drop-off.

If your site CVR is 1.5% with a view→cart rate of 8% and a cart→purchase rate of 18%, the biggest leak is at the very first stage. Looking at CVR alone, you only see "low overall" and your fixes scatter — but splitting by stage tells you exactly where to focus.

2. The 5-step GA4 setup

If your GA4 ecommerce setup is done, building the funnel takes about five minutes in the exploration report.

Step 1 — Verify view_item, add_to_cart, begin_checkout, and purchase fire in the GA4 "Realtime" report. Shopify default integration fires automatically; custom themes sometimes miss events.

Step 2-3 — Create a new exploration via "Explore" → "+" → "Funnel exploration." Build from a blank canvas. For each step, set "event name = view_item" etc. and choose "continue indirectly" so drop-off across multiple sessions is captured. EC behavior frequently spans sessions, so indirect continuation is the standard choice.

Step 4-5 — Add segments for new/returning, device, and channel. The standard period is last 28 days vs. prior 28 days. Use the "Share" button to make the funnel visible to your team for weekly review cadence.

3. Reading the numbers — industry typical values

Pass-through rates vary widely by industry. Read against industry-typical values, not against absolute thresholds.

Apparel typically shows a view→cart rate of 5-8%, which is low but not abnormal — browsing behavior is high. Food EC, by contrast, is 12-18% because visits are driven by immediate need.

Before deciding "our 6% view→cart rate means we need to fix the landing page," check the industry-typical value first. A 5-8% range may mean status quo is fine. Significant improvement potential exists only at stages clearly below typical.

4. Stage-by-stage actions

Once you've identified the abnormal stage, separate actions by stage. Wrong-stage targeting wastes campaign spend, so mapping cause to action sets the priority.

view→cart drops point to product page appeal: photo quality, pricing visibility, review count, stock display. Landing-page changes move the numbers quickly here.

cart→checkout drops point to shipping, stock-out, or forced signup. Adjusting free-shipping thresholds and adding guest checkout are standard fixes.

checkout→purchase drops point to form length and payment options. Trimming form fields and adding Apple Pay / Amazon Pay are usually effective.

Wrapping up

Once you see "which stage is leaking," the next layer is which channel cohort is leaking at that stage. Compare channel-level (paid search / paid social / organic / direct) funnel pass-through in GA4 segments, identify the inefficient channel, and judge ad spend efficiency with ROAS.

Funnel analysis answers "where is revenue leaking?" — it pairs with RPS (revenue per session) and channel-level ROAS to answer "where to invest budget?"

What about you? Which stage of the funnel typically leaks most for your store? Do you read drop-off rates against industry typical, or against a target you set internally? Curious to hear how others approach the read.

You Finished GA4 for Shopify. Here's What to Actually Measure

toshihiro shishido — Tue, 12 May 2026 02:18:07 +0000

"I finished setting up GA4 ecommerce for my Shopify store, but where do I actually look to make decisions?" This is the most common question I get right after a GA4 ecommerce setup is completed.

GA4's report screen fills up with menus: Monetization, Acquisition, Conversions, Ecommerce Purchases. The data is there. The signal worth acting on is not always obvious. This article walks through how to read the numbers and turn them into ad decisions in four ordered steps — the WHAT and WHY after the HOW.

TL;DR

Three metrics carry the post-setup analysis: RPS (Revenue Per Session), AOV (Average Order Value), CVR (Conversion Rate)
Shopify admin shows absolute revenue. GA4 shows source-level breakdown. RPS unifies both into one comparable number
Four ordered steps: ① Overall RPS → ② Channel RPS → ③ AOV/CVR split → ④ Next-month budget allocation
Three logic traps that trip up the read even when setup is perfect: CVR-only judgment, site-wide AOV, sessions-as-success

1. Three Metrics That Matter After Setup

After GA4 ecommerce setup is complete, the metrics worth focusing on narrow down to three: RPS, AOV, CVR.

View	Metrics visible	Strength	Weakness
Shopify Admin	Total revenue / orders / AOV	Absolute final results	No channel breakdown
GA4	Channel sessions / purchases / revenue	Channel-level comparison	Revenue gap vs Admin
RPS (unified)	Revenue per session	Cross-channel efficiency	Requires calculation

A "revenue +20% MoM" line in the Shopify admin panel does not tell you whether AOV rose, sessions grew, or CVR improved. Even GA4's source breakdown shows the relationships, not the next move.

RPS makes the decision concrete. "Google Ads RPS dropped from $1.20 to $0.98" tells you acquisition efficiency is degrading — likely from creative fatigue or traffic-quality decay. Pair it with AOV and CVR to narrow the root cause further.

2. Revenue Analysis in 4 Ordered Steps

Post-setup analysis works better with a fixed order. Run the same four steps every month and decision quality and speed both step up.

Step	What to look at	GA4 location	Next action
1 Overall RPS	Revenue per session	Monetization + Acquisition Sessions	Compare vs industry median
2 Channel RPS	Channel-level efficiency	Acquisition default channel group	Rank by RPS
3 AOV / CVR split	Root cause of decline	Custom report	Audience vs LP fix
4 Next-month budget	Reallocation priority	Dashboard summary	Scale / Hold / Cut

A concrete example: compare "Meta RPS $0.80, AOV $60, CVR 1.3%" against "Organic Search RPS $2.20, AOV $80, CVR 2.75%." Meta is low on both AOV and CVR — the creative is pulling a low-value audience that also fails to convert. Audience pivot (new creative) before LP tweaks is the right call. This kind of decision drops out naturally when you run the four steps in order.

3. Three Logic Traps in Reading the Numbers

Even with a clean setup, three logic traps in reading the numbers themselves trip up many teams.

Pitfall	Example	Blind spot	Correct metric
1 CVR-only judgment	Cut Meta budget at CVR 0.8%	AOV difference	RPS-based judgment
2 Site-wide AOV	Whole-site AOV $75	Per-channel AOV gap	Channel-level AOV
3 Sessions = success	Meta 10,000 sessions/mo	Inefficient spend	RPS × Sessions = revenue

Pitfall 3 is the one I see most often in stores with clean GA4 data. "We have so much traffic from Meta" feels like success, but if Meta RPS is half the Organic Search RPS, half that budget is going to "buy session count" rather than revenue. Treat absolute counts with suspicion when you have RPS available.

4. ROAS vs RPS — When to Use Which

"Why not just use ROAS?" comes up often. ROAS (Return on Ad Spend) is critical for ad investment but only works on channels with known spend. Organic Search, Direct, and Referral have no defined ROAS.

The practical pattern: use RPS for the whole picture, ROAS for paid channels only. The two play complementary roles — RPS judges acquisition efficiency across the funnel, ROAS judges return on each paid dollar.

5. Next Step — Turn GA4 Setup Into Revenue Decisions

Manually computing channel-level RPS in GA4 every month takes 30–60 minutes per cycle. Over time the work becomes a chore, leading to "skip analysis this month" → "ad decisions revert to gut feel" — a classic failure pattern.

RevenueScope auto-visualizes channel-level RPS, AOV, and CVR from your GA4 ecommerce data. If GA4 ecommerce is already set up, installation takes five minutes with no extra config. Revenue, AOV, RPS, and CVR — the four core metrics, plus Sessions on the dashboard for a 5-KPI card layout — let you run the four steps with zero manual work every month.

What is your monthly cadence for reading GA4 ecommerce data? Do you run a fixed order of steps, or open whatever feels relevant first? I'd love to hear how other teams structure the post-setup analysis loop.

Your CVR Is Up But AOV Dropped. The 4-Domain Fix for EC Revenue

toshihiro shishido — Mon, 11 May 2026 01:41:44 +0000

"We ran a coupon and CVR went up, but revenue did not." "We raised the free-shipping threshold and AOV went up, but order count dropped." EC operators hear these almost every month. The cause is usually the same: CVR and AOV tend to move in opposite directions, and the team is only watching one of them.

This article focuses on lifting CVR and AOV at the same time, covering the trade-off structure, four compatible domains, phase-based priorities, and measurement pitfalls.

TL;DR

CVR and AOV are two factors in Revenue = Sessions × CVR × AOV. Pushing one usually drops the other
Compatible tactics fall into four domains that lift both at once: recommendation accuracy, value-bundle design, pre-purchase information, post-purchase follow
Priorities shift by business phase: early-stage protects CVR, scale-up adds AOV, mature drives LTV
Joint-axis judgment: use RPS (Revenue Per Session) = CVR × AOV

1. The Revenue Decomposition

CVR is the share of visitors who buy. AOV is the per-order revenue. EC revenue decomposes into these plus session count.

Sessions sit on the acquisition side (ads, SEO, brand search). CVR and AOV are on-site experience metrics, and their tactical levers overlap. That overlap is why pushing one usually moves the other in the opposite direction.

2. Why Joint Lift Is Hard — Four Trade-offs

Four representative trade-offs where buyer psychology pulls in opposite directions:

#	Tactic	CVR	AOV	Why it conflicts
1	Heavy discount coupons	up	down	Lower buy threshold but smaller per-order revenue
2	Raise free-ship threshold	down	up	Visitors who fall short of the threshold drop
3	Push high-price bundles	down	up	Single-item buyers drop
4	Push low-price items	up	down	Easier to convert but average order shrinks

Baymard Institute research shows cart-abandonment reason #1 is "extra costs like shipping are too high" (48%). Most "lift one metric" tactics drop the other; joint lift needs a different category of tactics.

3. Four Domains That Lift Both

Tactics that lift CVR and AOV together share one shape: they do not block purchase intent and they add per-order value.

A Recommendation accuracy: "Frequently bought together" modules on product / cart pages. High-precision cross-sell delivers AOV +10–30%
B Value-bundle design: Not discount-bundles. Sell combinations single items cannot ("morning + night skincare set," "3-variety coffee tasting set"). Value, not price
C Pre-purchase information: Stock status, delivery dates, return policy. Undisclosed shipping costs strongly correlate with cart abandonment
D Post-purchase follow: Cart-recovery emails, post-purchase complement emails, member-only early access. Lifts second-and-onward AOV plus LTV (+20–40% in some studies)

4. Priority — Where to Start

Sequence the four domains by business phase. Running AOV tactics before traffic stabilizes drops CVR and shrinks revenue.

Early-stage (sessions unstable): Protect CVR first. Start with Domain C (pre-purchase information)
Scale-up (sessions stable): Add Domain A (recommendation) and Domain B (value-bundle). Add AOV without dropping CVR
Mature (high repeat rate): Domain D (post-purchase follow) becomes central. Membership programs grow LTV

5. Measurement Pitfalls

Even with the right tactics, broken measurement makes the "up / down" call wrong.

#	Pitfall	Fix
1	Bots in CVR denominator	Recalculate using bot-filtered sessions
2	AOV using pre-discount price	Net revenue (post-discount) / order count
3	Ignoring device / channel splits	Decompose by device, channel, landing page

Pitfall #3 is the silent one. Mobile AOV typically runs 20–40% below desktop. A rising mobile share alone makes overall AOV look like it is dropping.

The cleanest joint view is RPS (Revenue Per Session) = CVR × AOV. If AOV rises but CVR drops by the same magnitude, RPS is flat and the tactic delivered no real joint lift.

Summary

Pushing CVR or AOV in isolation tends to drop the other
Joint-lift tactics fall into four domains: recommendation accuracy, value-bundle design, pre-purchase information, post-purchase follow
Sequence by business phase: early-stage, scale-up, mature, with different priority domains in each
Measurement: filter bots, use post-discount AOV, decompose by device / channel
Use RPS = CVR × AOV as the unified judge against measurement distortion

Detailed examples and the decision flow are in the original LP: How to Increase CVR and AOV Together.

Question for the community: When you found CVR moving in the opposite direction of AOV, what was the first tactic you tried to balance them? I'm curious whether Domain A (recommendation) or Domain C (pre-purchase info) is the more common first move in practice.

LTV (Customer Lifetime Value) Calculation. 5 Common Methods for EC Operators

toshihiro shishido — Sat, 09 May 2026 03:23:15 +0000

"My executive team wants LTV in our monthly report. But there are like four different formulas online — how do I pick the right one?"

This is one of the most common questions we hear from EC operators. LTV (Customer Lifetime Value) is widely used as a metric, but at least five common calculation methods exist. Pick the wrong one, and your business decisions rest on a shaky foundation.

TL;DR

There are five common LTV calculation methods: Simple, Gross Margin, Cohort, LTV/CAC, and DCF. Choose by business stage and product
LTV alone cannot drive investment decisions. View it together with CAC, with LTV/CAC = 3:1 as a baseline
The three prerequisite metrics are AOV, RPS, and purchase frequency. Without stable measurement of these, LTV figures lack foundation

Why "five methods" matters

LTV looks deceptively simple. The textbook formula is:

LTV = AOV × Purchase Frequency × Customer Lifespan

But ask any operator running a real Shopify store, and you'll get a different number depending on what they include — gross margin, cohort retention, CAC, future cash flow discount. These produce different LTVs by 2-3x for the same business. The question is not "which formula is correct" but "which formula fits this stage of the business."

The five methods at a glance

1. Simple LTV — early-stage EC

LTV = AOV × Purchase Frequency × Customer Lifespan

The simplest formula, also presented in Shopify's official documentation. AOV ¥5,000 × 3 orders/year × 2 years = LTV ¥30,000. Sufficient when gross margin and customer ID linkage aren't yet structured. Note: revenue-based, so margin differences are not reflected.

2. Gross Margin LTV — scale-up EC

LTV = (AOV × Gross Margin) × Orders × Years

Once you start serious ad investment, profit-based LTV is essential. Otherwise you hit the "LTV looks fine but no profit" trap. With 30% gross margin: ¥9,000 gross-margin LTV. Translation: keep CAC under ¥9,000.

3. Cohort LTV — repeat-rate driven

LTV = Cohort cumulative revenue ÷ Cohort customers

Highest accuracy because it's based on observed values. Customer ID linkage is mandatory. Bain & Company has long noted that retention improvements have outsized impact on profit, and cohort-level visibility directly drives continuous improvement.

4. LTV/CAC ratio — investment decision

LTV/CAC = LTV ÷ CAC (baseline: 3:1)

Strictly speaking, this is not a formula for calculating LTV — it's an investment-decision lens using the LTV/CAC ratio. The four formulas for LTV calculation proper are 1, 2, 3, and 5 here.

The "LTV/CAC = 3:1" baseline widely used in SaaS also applies to EC. Below 1 = unprofitable acquisition, above 3 = room to scale spending. The appropriate ratio varies by industry and product, so use your own channel-level actuals.

5. DCF LTV — high-AOV / subscription EC

LTV = Σ(Annual CF / (1 + r)^n)

Discounts future cash flows to present value. Used for subscription EC and high-AOV products in 3-5-year investment decisions. Discount rate (typically 5-10%) heavily influences output, so document your assumptions explicitly.

The three-tier framework — AOV → RPS → LTV

All five methods share a common assumption: that AOV and purchase frequency are already being measured stably. Without that foundation, LTV figures lack reliability.

The three prerequisite metrics:

Metric	Unit	Role	Relationship to LTV
AOV	per order	Order efficiency	Starting point of LTV formula
RPS	per session	Revenue per visit	Acquisition efficiency that creates LTV
CAC	per customer	Acquisition cost	Denominator of LTV/CAC ratio

In practice: build a state where AOV and RPS are measured monthly with stability, then compute LTV quarterly. There's no need to view LTV daily — but AOV and RPS should be visible every day.

LTV/CAC investment decision zones

LTV/CAC ratio	State	Recommended action
Below 1	New acquisition is loss-making	Pause ads, or improve product first
1-2	Recoverable but thin margin	Decompose by channel, cut high-CAC channels
2-3	Healthy range	Maintain + improve AOV/CVR to lift the ratio
Above 3	Room to scale spending	Increase ad budget, open new channels

Critical caveat: this baseline must be viewed at channel and cohort level. Even if total LTV/CAC = 3, if Paid sits at 0.8 and Organic at 5.0, the right call is to pause Paid acquisition. Averages mislead.

Four common measurement pitfalls

Pitfall	What happens	Treatment
One-time customers	Single-purchase customers drag down the average	Split "first purchase only" vs "repeat"
Fixed measurement period	Fixing lifespan to 3 years undervalues new customers	Use observed lifespan months by cohort
Pre/post discount mixing	Heavy coupon usage inflates AOV	Match AOV practice — use post-discount
Channel allocation	Mixing ad-acquired with Organic customers	Split cohorts by initial-touch channel

Operating LTV alongside its prerequisite metrics

The summary:

LTV has five common calculation methods. Choose by business stage and product
LTV alone does not enable investment decisions. Use LTV/CAC = 3:1 as the baseline
The three prerequisite metrics are AOV / RPS / Purchase Frequency
Realistic operation: LTV quarterly, AOV and RPS visible daily
Decompose LTV/CAC by channel and cohort — averages mislead

I'm building RevenueScope, a tool that automatically expands the prerequisite metrics — AOV, RPS, CVR — by channel and device on the dashboard. It doesn't compute LTV directly, but it's designed to surface "the data foundation underneath LTV" — the kind of view that's missing when teams jump straight to LTV reporting.

Discussion

What LTV formula does your team currently use, and what tripped you up the first time? Curious to hear from other operators — especially the "looked good in the spreadsheet but didn't survive contact with reality" stories.

How Three Shopify ECs Reallocated Ad Budget by RPS for +5-20% Revenue

toshihiro shishido — Fri, 08 May 2026 04:51:34 +0000

"Where should I push my ad budget, and by how much?" This is the most common question we hear from Shopify EC operators in the ¥10-50M monthly revenue range. Pushing budget to the highest-CVR channel does not lift revenue. Pushing to the highest-ROAS channel only adds operating overhead. Without a single decision axis, budget allocation drifts and performance plateaus.

TL;DR

Three illustrative case studies — apparel (+15%), general goods (+8%), food/D2C (+22%) — demonstrate the Revenue Per Session (RPS) -first ad-budget reallocation workflow
The framework is shared: ① anchor on industry RPS median, ② plot each channel on RPS × CVR four-quadrant, ③ shift budget from low-RPS into high-RPS channels
Case C (food/D2C) failed in the first three months because measurement gaps (UTM drift, Safari ITP cookie loss, last-touch-only attribution) skewed the numbers driving the decisions

Why RPS, not CVR

Revenue Per Session (RPS) = Revenue ÷ Sessions. It captures revenue efficiency in a single number that integrates AOV (average order value) and CVR (conversion rate). The relationship is RPS = AOV × CVR.

If you watch only CVR, you can miss the AOV crash that cancels out the CVR lift. We see this often: "CVR went from 2.0% to 3.5% — winning!" — except AOV dropped from ¥6,000 to ¥3,500 and RPS barely moved (¥120 → ¥122.5). Revenue did not change.

RPS as the primary axis answers the operational question — "which channel actually generates revenue?" — with one number.

Note: RPS is not yet a widely standardized industry term. We use it because it captures the AOV-CVR composite in a single metric.

Three-Case Overview

The shared framework: plot each channel on a two-axis (RPS × CVR) quadrant. Shift budget from Q3 (both low) into Q2 (both high) or Q1 (high RPS / low CVR).

Case A: Apparel EC — Channel Rebalancing for RPS+15%

Starting point: ¥25M monthly revenue. 70% of ad budget on Meta. Meta CVR 2.1%, Google Search 1.4%, organic 1.8% — Meta looked dominant.

The gap: On RPS, Meta was ¥72, Google Search ¥110, organic ¥95. Meta AOV (¥3,400) was less than half of Google Search AOV (¥7,800). Meta drove high-volume, low-AOV traffic.

Action: Cut Meta to 40%, reallocate to Google Search (20%), organic SEO (20%), retargeting (10%). Switched Meta to catalog ads prioritizing higher-AOV items.

Outcome: Overall RPS ¥85 → ¥98 (+15%). Revenue ¥25M → ¥28.4M. Meta CVR dropped 2.1% → 1.7%, but AOV climbed ¥3,400 → ¥4,800, so Meta RPS itself improved ¥72 → ¥82. Past the apparel industry median of ¥90.

A high-CVR channel is not automatically a high-efficiency channel. Channels with low AOV "drive volume without driving revenue."

Case B: General Goods EC — AOV Lift for RPS+8%

Starting point: ¥12M monthly revenue. Even budget split. RPS ¥75, near the lower end of estimated industry median ¥80-100. Increasing ad spend no longer produced proportional revenue.

The gap: Per-channel RPS was tightly clustered (¥68-82). Channel mix wasn't the bottleneck. Sitewide AOV ¥3,200 was.

Action: Kept channel mix. Site-side investment: free-shipping threshold ¥3,500 → ¥5,000, "frequently bought together" module, Klaviyo cart-recovery, hero/CTA A/B test.

Outcome: Overall RPS ¥75 → ¥81 (+8%). AOV ¥3,200 → ¥4,100, CVR slight drop (1.6% → 1.55%). Revenue ¥12M → ¥12.95M.

When per-channel RPS is tight, reallocating channels won't move RPS. Sitewide AOV lift becomes the higher-priority lever.

Case C: Food/D2C EC — Failure, Then Measurement Fix for RPS+22%

The largest lift — and the one that failed first.

Starting point: ¥48M monthly revenue. D2C food. CVR 3.2% (food median ~3.0%). RPS ¥125, below median ¥135.

Initial failure (months 1-3)

The team adopted RPS-first decisions but pushed budget to the wrong channel because of measurement gaps:

UTM drift: utm_source=facebook and Facebook were tagged as separate channels, undercounting Meta-attributed RPS
Cookie limits: Safari ITP suppressed Meta-attributed conversions
Last-touch only: Assist effect ignored, organic search undervalued

The team cut Meta and shifted to Google Search — wrong call. Three months in, RPS moved ¥125 → ¥128 (+2.4%). Revenue ticked up, but retargeting cuts likely cost some repeat-purchase opportunities.

Measurement fix (months 4-6)

Rebuilt the measurement layer:

UTM auto-normalization: lowercase + trim across all utm_source variants
dataLayer redundancy: capture revenue from GA4 ecommerce dataLayer.push as a parallel path
Last-touch + assist hybrid: last-touch primary, assist visible for any touch within 3 clicks

Outcome: RPS ¥128 → ¥152 (+18.8%). Cumulative ¥125 → ¥152 (+22%). Revenue ¥48M → ¥58.56M. Past the median of ¥135.

RPS-first decisions presuppose accurate measurement. If UTM drift, cookie loss, and attribution model are not handled, the very numbers driving the decision are skewed.

Industry Median Anchor

Industry RPS medians vary 2-3× across categories. Without an industry-anchored starting point, you misread your own headroom.

Three Common Decision Axes

Anchor on industry RPS median — know whether you're below or above
Plot each channel on RPS × CVR matrix — shift Q3 budget into Q2 or Q1
Measurement accuracy is a precondition — UTM, cookie loss, attribution all matter

The Japanese B2C EC market reached ¥26.1 trillion in 2024. Migrating from CVR-only judgment to RPS-as-primary is mostly a KPI configuration change in your dashboard — not a tooling overhaul.

What's your team using as the primary axis for ad-budget decisions today — CVR, ROAS, or something composite? Have you run into the same measurement-layer failures Case C did?

Your CVR Is Up But Revenue Isn't: The RPS+CVR Fix for EC Ad Budgets

toshihiro shishido — Thu, 07 May 2026 01:38:22 +0000

"We increased budget on a high-CVR ad and revenue did not grow." I hear this from EC operators every month. CVR (conversion rate) is improving but the monthly revenue is flat — or worse, declining. The team thinks the campaign is working because CVR is up, but the P&L disagrees.

The cause is almost always the same: CVR is being used as the sole judgment metric, and AOV (average order value) is dropping in the background. Revenue Per Session (RPS) — the composite of AOV × CVR — is the metric that actually moves with revenue, and it often moves opposite to CVR. If you only watch CVR, you systematically miss the cases where the campaign is killing your top line.

Note on terminology: I use Revenue Per Session (RPS) below. RPS is not a standardized industry metric in the way ROAS or LTV are — it is RevenueScope's core metric. I spell out the full term on first mention.

TL;DR

RPS is an absolute revenue-efficiency metric; CVR is an intermediate purchase-rate metric. From RPS = AOV × CVR, when AOV drops, RPS can fall even as CVR rises.
3 patterns produce CVR-RPS divergence: bundle discounts, low-price funneling, and aggressive coupons. All three look like "CVR success" while burning revenue.
A 2-axis quadrant chart of RPS and CVR turns ad budget allocation into a clean decision: prioritize Q2 (high RPS × high CVR), apply AOV-lifting to Q4 (the CVR trap zone), withdraw from Q3, scale Q1.

The CVR-RPS divergence problem

CVR and RPS measure different things, even though they sound related.

CVR = Purchase Sessions ÷ Total Sessions (a percentage). It's an intermediate metric — the rate of conversion.
RPS = Revenue ÷ Sessions (a currency value). It's an absolute metric — actual revenue per visit.

The two are linked by RPS = AOV × CVR, which means CVR is just one input. Concrete numbers: AOV ¥6,000 with CVR 2.0% gives RPS ¥120. If CVR climbs to 3.0% but AOV falls to ¥3,500, RPS becomes ¥105 — actually worse. The dashboard says "CVR up 50%" while revenue per visit dropped 12.5%. The CVR improvement does not imply a revenue improvement.

The reason this misjudgment is so common: GA4 surfaces CVR prominently in standard reports, while RPS is a derived metric that requires a small extra step to compute. Operators read what's in front of them.

The 3 traps where CVR rises while RPS falls

When CVR moves opposite to AOV (or sessions shrink in parallel), three specific patterns produce a fall in RPS.

Trap 1: Bundle discounts pull down AOV. A "10% off second item" promotion can push CVR from 2.0% to 3.5%, but AOV often drops from ¥6,000 to ¥3,500 in the process. The math: ¥3,500 × 0.035 = ¥122.5 RPS, versus the ¥120 baseline. A 42% AOV drop in exchange for a 2.1% RPS gain is not a successful initiative.

Trap 2: Low-price product funneling. A "¥980 trial product" funnel pushes CVR up sharply (2.0% → 6.0%, a 3x lift) but destroys AOV (¥6,000 → ¥1,200, a 5x drop). The result: RPS goes from ¥120 to ¥72, a 40% decline. Outside of a deliberate LTV-recovery model, the monthly numbers are bad.

Trap 3: Site-wide coupon distribution. 10-20% off coupons across the catalog look like a CVR win, but AOV drops by the discount amount and the math repeats from Trap 1.

The shared structure across all three: directional divergence between CVR and RPS. Treating "CVR up = success" guarantees you'll fall into at least one of these patterns.

The RPS × CVR quadrant: a decision framework

To make this visible at a glance, plot ad channels (or LPs, or product pages) on a 2-axis chart with CVR on the x-axis and RPS on the y-axis.

The four quadrants give you a direct action mapping:

Q1: High RPS × Low CVR — high-AOV product hit, scale candidate. Increase budget.
Q2: High RPS × High CVR — best revenue efficiency, top priority. Maximize allocation.
Q3: Low RPS × Low CVR — largest improvement room, withdrawal candidate. Reduce budget or rebuild LP.
Q4: Low RPS × High CVR — the CVR trap zone. AOV-lifting initiatives required.

The decision flow is three steps:

Compute monthly RPS and CVR for each ad channel.
Plot into the four quadrants.
For Q4 channels, judge as "not eligible for budget allocation unless AOV is lifted" instead of "keep because CVR is high."

Q4 is the most easily misjudged. "Good channel because CVR is high" is the wrong read — most Q4 channels are sitting on Trap 1, 2, or 3 and need an AOV intervention before they deserve more budget.

How to apply this in monthly budget reviews

In monthly ad budget reviews, the order I recommend is:

Revenue — outcome metric, overall picture.
RPS — primary axis for cross-channel comparison.
AOV and CVR — decomposition of why RPS moved.
Sessions — inflow scale check.

Treat CVR as a supporting metric and never let CVR alone drive budget decisions. The migration from CVR-only judgment to RPS-as-primary is mostly a KPI configuration change in your dashboard — not a tooling overhaul.

The Japanese B2C EC market reached ¥24.8 trillion in 2024, and the quality of ad budget allocation directly drives growth. The teams that get this right at SMB scale (¥10-50M monthly revenue) tend to be the ones that graduate to enterprise scale, while the teams stuck on CVR-only judgment plateau there.

If you want the full version with formulas, references, and the GA4 implementation details, I wrote a longer article on it: RPS vs CVR: A Two-Axis Framework for EC Ad Budget Allocation.

What's the most surprising CVR-RPS divergence you've seen in your own ad data? Curious where Trap 1, 2, or 3 has bitten others.

2026 EC Measurement — Why SMB ECs Should Skip MMM and Focus on 2 Things

toshihiro shishido — Wed, 06 May 2026 02:35:16 +0000

"Should we adopt MMM (Marketing Mix Modeling) too?" "Do we need incrementality measurement at ¥50M monthly revenue?" Since the start of 2026, EC operators have been asking these questions in rapid succession. LinkedIn, X, and overseas SaaS vendor blogs are full of headlines like "2026 is the year of MMM revival," "AI changes measurement," and "Full Cookieless transition." Many SMB EC operators do not know where to start.

The short answer: the 2026 EC measurement landscape has 5 trends, but SMB ECs do not need to chase all of them. I designed RevenueScope for SMB EC operators in Japan (¥10-50M monthly revenue), and after a year of conversations with operators about what trends actually move their P&L, my honest take is that 4 of the 5 trends are premature for sub-¥1B businesses.

TL;DR

The 2026 EC measurement landscape has 5 trends (MMM, Incrementality, AI in analytics, Profit-centric KPIs, Cookieless). Only ¥1B+ enterprises should pursue all 5. SMB ECs narrow to 1-2 by revenue range.
Priority by revenue range: under ¥10M/mo → Cookieless only; ¥10-50M → Cookieless + AI; ¥50-100M → add Profit-centric KPIs; ¥100M-1B → add Incrementality; ¥1B+ → all 5.
The 2 things SMB ECs actually need in 2026: Cookieless tracking (mandatory · regulatory + browser shifts) and AI in analytics (low investment · stepwise adoption · 5-10 hours/month reclaimed for revenue activities).

The 5 trends in one map

Here is the landscape compressed into one table — adoption layer, required resources, SMB EC fit:

Trend	Primary adopters	Required resources	SMB EC fit
1. MMM	Enterprise (¥10B+)	3yrs data, stats team	✕ Not fit
2. Incrementality	D2C / large apps	A/B infra, analysts	△ Limited
3. AI in analytics	All EC (spreading)	AI-embedded tools	○ Stepwise
4. Profit-centric KPI	Margin-aware EC	Cost data integration	△ ROAS ext.
5. Cookieless	All EC (mandatory)	Server-side tracking	◎ Required

The recurring pattern: the 3 trends generating the most LinkedIn buzz (MMM, Incrementality, Profit-centric KPI) are the 3 trends with the steepest data + talent + investment requirements. Tools have democratized — Google open-sourced Meridian as MMM in 2024 — but tooling availability is not the same as fit. ECs without 3 years of weekly-granularity data, a stats hire, or ¥5M-¥20M for model build cannot adopt MMM regardless of how accessible the open-source tool is.

Why MMM and Incrementality are premature for SMB ECs

The Adverity 2026 Marketing Predictions argue that MMM × Incrementality is becoming the 2025-2026 standard for ad effectiveness measurement. That's true at enterprise scale. But the resource requirements bite hard at SMB scale:

MMM: 3+ years weekly data · stats team · ¥5M-¥20M initial · 20-40 hours/month ops
Incrementality: A/B test design (3-6 months minimum) · analyst · ¥2M-¥10M initial · 10-20 hours/month ops

For a ¥30M/month revenue operator running a 3-person marketing team, that's a sequence of "find a stats hire, accumulate 3 years of data, spend ¥10M+, run experiments for 6 months before any signal." The opportunity cost of that time is creative A/B testing, LP optimization, customer interviews — the things that actually move ¥30M/month revenue toward ¥50M/month.

The right move at SMB scale is to graduate into MMM/Incrementality after you've crossed ¥1B/month, not to anchor a ¥30M operator with enterprise tools.

The 2 trends that actually matter for SMB EC: Cookieless + AI

Cookieless: mandatory regardless of scale

Cookieless is the only trend where "must do it" applies to every SMB EC. Apple ITP, Mozilla ETP, Chrome's third-party cookie phase-out, plus Japan's revised Telecommunications Business Act (External Transmission Rules, June 2023) which mandates cookie/tag purpose disclosure for any site using GA4 or ad tags. There is no "we're too small for this" exemption.

The implementation has 4 areas:

First-party cookie migration — switch to own-domain cookies (visitor_id, session_id)
Server-side tracking — GTM Server-Side / Cloudflare Workers (optional but recommended at scale)
Consent management — CMP and 4-item disclosure
DataLayer design — dataLayer.push event standardization

Items 1 and 4 are non-negotiable. Items 2 and 3 are scale-dependent (server-side tracking matters more once your ad spend hits 7 figures monthly).

AI in analytics: lowest barrier, highest ROI for SMB

AI in analytics is the most accessible of the 5 trends. Generative AI for weekly report automation, anomaly detection, keyword suggestion — these features have flooded marketing tools in 2025-2026. Adverity launched "Adverity Intelligence" (Dec 2025) as an AI-agent analytics product.

Resource requirements:

Data: tool-internal (no external integration needed)
Talent: prompt design only (no statistician)
Initial investment: ¥0-¥0.5M
Monthly ops: 2-5 hours

The ROI math: if AI report automation saves 5-10 hours/month, that time goes to ad creative A/B tests and LP improvements — work that has direct revenue impact at SMB scale.

Caveat from Adverity's "Data Quality for AI Readiness" (Mar 2026): CMOs estimate 45% of the data they rely on is incomplete, inaccurate, or out of date. AI on broken data outputs broken summaries. The prerequisite is consistent dataLayer event design — which loops back to Cookieless work.

RevenueScope's stance: honest disclosure on each trend

I designed RevenueScope around a 5-KPI focus (Revenue / AOV / RPS / CVR / Sessions) for SMB ECs at ¥10-50M monthly revenue. Here is where each trend lands:

Trend	RS support	Alternative / disclosure
1. MMM	✕ No	Recommend Meridian / Triple Whale at enterprise scale
2. Incrementality	△ Alternative	Channel-level RPS diff as proxy
3. AI in analytics	○ Partial	5-KPI auto-summary (Q3 2026 roadmap)
4. Profit-centric KPI	✕ No	Triple Whale Profit Calculator / Hyros / self-built BI
5. Cookieless	◎ Standard	dataLayer + first-party cookies

If you need MMM, Incrementality, or Profit-centric KPIs now, you have outgrown a 5-KPI focus product. Graduate to Triple Whale, Hyros, or Looker + BigQuery — that's the right call at ¥100M+/month. RevenueScope is built for the operators between "GA4 is too noisy" and "we need MMM." That window is roughly ¥10-50M monthly revenue, and that's where I want to be excellent rather than mediocre across all 5 trends.

The decision framework

If you're trying to answer "which 2026 trend should I prioritize?" for your own EC business, the question is your monthly revenue:

Under ¥10M/mo: Cookieless only. Focus the rest of your time on growing to ¥30M.
¥10-50M/mo: Cookieless + AI. Use AI to reclaim 5-10 hours/month for revenue activities.
¥50-100M/mo: + Profit-centric KPIs. ROAS-only judgment starts masking losses at this ad spend level.
¥100M-1B/mo: 4 of 5 (add Incrementality). MMM still gated by 3-year data.
¥1B+ (Enterprise): All 5 trends in scope.

The 2026 EC measurement strategy that works for SMB ECs is narrower, not broader. The instinct to chase every LinkedIn-trending technique is the most reliable way to over-invest and under-execute.

If you want the full analysis with sources, I wrote a longer-form article on it: 2026 EC Measurement: 5 Trends and Which One You Should Prioritize.

What's your read — are you seeing the same 5 trends play out, and where does your operation land on the revenue-range model? Curious to hear what's working at your scale.

The Hidden TCO of Self-Hosting Your EC Revenue Dashboard in 2026

toshihiro shishido — Tue, 05 May 2026 22:55:19 +0000

"If we self-host Matomo or Umami, the revenue dashboard is free, right?" That's one of the most common questions I hear from SMB EC operators in Japan. The short answer: license-fee-free is not TCO-free. After laying four options side-by-side at Japanese freelance rates, self-hosted dashboards land at ¥460K-880K per year — 4-7x the cost of a focused SaaS like the one I'm building.

I've been building RevenueScope for the Japan SMB EC market, so I have a stake in this comparison. But the math here is structural, not promotional: when you account for build hours, ongoing ops, server costs, and learning curve, "free" OSS quietly becomes one of the most expensive choices on the table.

This post walks through the TCO breakdown, the three hidden cost layers most operators miss, and a 3-question framework that decides between self-hosted and SaaS in about 60 seconds.

TL;DR

Self-hosting Matomo, Umami, or rolling your own GA4+Looker Studio dashboard runs ¥460K-880K per year at a ¥5,000/hour Japanese freelance rate (industry-average estimates, not measured ground truth).
A focused SaaS option for SMB EC — RevenueScope Growth at ¥9,800/month (~¥117K/year) — sits 4-7x lower on TCO.
The hidden cost is a three-layer stack: opportunity cost (40 build hours not spent on revenue work), learning curve (Matomo configs, GA4 event design, Looker DAX), and upgrade churn (OSS major versions, GA4 API breaks). License-fee-zero hides all three.

Why "TCO" matters more than license fees

The "OSS is free" intuition only counts software license cost. Real total cost of ownership for an EC operator pulls in at least four other line items:

Initial build hours — server setup, tracking install, dashboard build, first-pass QA
Monthly ops hours — data quality checks, tracking fixes, new metric requests, incident response
Server cost — VPS / cloud / storage
Learning curve — docs, Stack Overflow, internal wiki, knowledge transfer

Counted as labor at ¥5,000/hour (the Japanese freelance marketing/data-analyst median), self-hosted TCO climbs into the high hundreds of thousands of yen — quickly.

The second concept that operators tend to miss is opportunity cost. Forty hours spent building a Matomo dashboard is forty hours not spent on creative A/B tests, LP iterations, or email segmentation work. For a JPY-10M-monthly EC, those forty hours represent roughly 25% of a working month — directly tradeable against revenue work.

License-fee-zero and TCO-zero are different numbers. That's the starting point for any honest comparison.

One-year TCO across four options

I lined up Matomo On-Premise, Umami v3, GA4 + Looker Studio, and RevenueScope Growth at industry-average estimates (not measured ground truth — your numbers will vary).

The annual numbers (rounded, ¥5,000/hr labor):

Matomo self-hosted — ~¥880K (40h build + 8h/mo ops + ¥3K/mo hosting + 16h learning)
Umami self-hosted — ~¥460K (20h build + 4h/mo ops + ¥2K/mo hosting + 8h learning)
GA4 + Looker Studio — ~¥500K (16h build + 6h/mo ops + 12h learning; product is free, your time isn't)
RevenueScope Growth — ~¥117K (¥9,800/mo plan + ~0.5h/mo to actually look at the dashboard)

The "free" intuition collapses the moment you add 40 build hours and 6-8 ongoing ops hours per month at Japanese freelance rates. The license is the small line item; labor is everything else.

The three hidden cost layers

Beyond the headline numbers, three layers of hidden cost stack on top of self-hosting and account for most of the gap between OSS and SaaS economics.

Layer 1 — Opportunity cost. Forty hours building Matomo is forty hours not running creative A/B tests or shipping LP improvements. For JPY-10M-monthly EC, that's roughly 25% of a working month redirected away from revenue work. The TCO row "build hours = ¥200K" is the direct cost; the indirect cost (campaigns not run, pages not improved) is often larger.

Layer 2 — Learning curve. Matomo's admin surface is dense; custom report authoring is close to writing SQL by hand. GA4 demands real care around event design, custom dimensions, and the data layer. Looker Studio adds calculated-field syntax (DAX-adjacent) plus BigQuery SQL knowledge if you take the connector route. Each one has a real ramp before the dashboard becomes operational.

Layer 3 — Upgrade churn. OSS ships major versions; GA4 breaks API contracts; Looker Studio re-skins UIs. Matomo schema migrations, GA4 export schema changes that retroactively break your queries, Looker chart configs that need re-doing — these arrive a few times a year and don't fit cleanly into the "monthly ops hours" budget. SaaS providers absorb this churn on your behalf.

Stack the three layers together and the gap between "Matomo at ¥880K" and "RevenueScope at ¥117K" stops looking like a margin choice. It looks like a structurally different cost model.

A 3-question decision framework

For SMB EC operators wondering which side they fall on, three binary questions resolve it in about 60 seconds.

Q1 — Are you a JPY-10M-50M monthly Shopify / BASE / STORES / EC-CUBE operator? If yes, continue. If under JPY-10M, GA4 + Looker Studio with a hand-built dashboard is usually proportionate. If over JPY-1B, you're in BI-tool territory (Tableau, Looker, Mode).

Q2 — Do you want engineering and ops hours pointed at revenue work, or at dashboard maintenance? If revenue work, lean toward SaaS. If dashboard work is part of how you want to spend the team, OSS makes sense — and it's a legitimate choice when you have an in-house philosophy around tooling ownership.

Q3 — Are Revenue, AOV, RPS, CVR, plus Sessions enough? If yes — that's RevenueScope's deliberate scope cap (4 core metrics + Sessions = 5 KPI cards). If you need MMM, MTA, margin, LTV, inventory, or in-app ROAS computation, look at full-stack tools (Triple Whale category) instead.

Note: RevenueScope intentionally does not compute ad-spend ROAS in-app. Ad consoles (Meta, Google, TikTok) already surface ROAS natively; calculating it again in a separate tool just doubles the surface area to maintain. Delegating ROAS to the tool best positioned to compute it is a deliberate scope decision.

When self-hosting genuinely makes sense

To be clear about when OSS or DIY is the right answer:

Compliance-driven — when first-party customer-data residency on your own servers is a hard requirement (large enterprise, regulated industries)
Engineering-rich teams — when in-house engineers are already comfortable with Linux server ops and treat tooling as part of the platform
Bespoke metrics — when you need indicators no SaaS will model out of the box, and you want full control over the schema
Above JPY-1B/month — at large scale, SaaS per-event pricing can flip; self-hosting can become the cheaper option

For SMB EC with marketing teams of 1-3 and no dedicated engineer, none of these usually apply. That's the population where the TCO gap matters most — and where a focused SaaS earns its keep by removing the three hidden cost layers entirely.

Closing

"OSS is free" is technically true and operationally misleading. License-fee-zero stops mattering once you count 40 build hours and 6-8 monthly ops hours at ¥5,000/hour. The real question for an SMB EC operator isn't "free vs paid" — it's "do I want my team's hours pointed at revenue work or at dashboard maintenance?"

The full breakdown — per-option TCO math, suitability profiles, and references — is at Matomo / Umami / GA4+Looker Studio Self-Build vs RevenueScope: 1-Year TCO for EC Revenue Dashboards. For the prior post in this series (full-feature SaaS comparison, not self-build), see Triple Whale vs RevenueScope.

Triple Whale vs RevenueScope — A 7-Axis Comparison for SMB EC Brands

toshihiro shishido — Mon, 04 May 2026 23:33:08 +0000

"Can Triple Whale work for a Japanese ecommerce brand? How is it different from RevenueScope?" These are the two questions I hear most often from operators. The short answer: the two tools live in deliberately different scope zones — they're complements far more than competitors.

I've been building RevenueScope for the Japan SMB EC market, so I have a stake in the comparison. But after pulling May 2026 official data from both sides and lining them up across seven axes, the conclusion is structural, not promotional: Triple Whale and RevenueScope solve different problems for different buyers.

This post is an honest 7-axis breakdown plus a 4-criterion decision framework, written for operators who want to pick the right tool the first time.

TL;DR

Triple Whale uses GMV-tiered pricing — Free / Starter / Advanced / Custom monthly rates flex according to a 7-step trailing-12-month GMV slider (<$250K through $350M+). The platform tracks $55B+ in revenue across 60,000+ brands.
RevenueScope is built for Japan SMB EC and limits itself to core 4 metrics — Revenue, AOV, RPS, CVR — plus Sessions, displayed as five KPI cards. It installs through GTM in five minutes via dataLayer pickup, ships in Japanese, and runs on three fixed plans (¥2,980 / ¥9,800 / ¥29,800 / month).
The seven axes (language, feature scope, technical needs, pricing, ad-API integration, supported platforms, Japan-market readiness) trace a clean split — pick Triple Whale when English-first teams need full-stack measurement, pick RevenueScope when Japanese-first teams want lean, opinionated weekly KPI rituals.

Triple Whale — what it actually does

Triple Whale (triplewhale.com) was founded in Israel in 2021. As of May 2026 it positions itself as the "complete intelligence platform for ecommerce — Measurement. Analytics. AI. Creative. Automation."

The pricing structure tells you a lot about the buyer profile. Plans are GMV-tiered: Free / Starter / Advanced / Custom monthly rates flex with the trailing-12-month GMV band a brand sits in.

Even at the Free tier, Triple Pixel (cross-device identity resolution) is included. So is "AI Visibility for ChatGPT" — a feature that surfaces how a brand is mentioned in ChatGPT outputs. Bundling AI Visibility into a free tier is a deliberate signal about where the platform sees the next attention surface.

Beyond pricing, the headline features are:

Triple Pixel — cross-device / cross-platform identity resolution
Moby AI — assistant for chat / agents / forecasting / image and video generation
Compass — MMM, MTA, and incrementality testing in one suite
Sonar — enrichment automations powering email/SMS flows
Self-Serve Analytics — 75+ pre-built dashboards
Data Platform — SQL Editor (Advanced and up)

Customers include Marine Layer, Travelpro, Peloton, OUAI, Origin, True Classic, and Milk Bar — a SMB-to-enterprise D2C mix. The platform's name — "ecommerce intelligence platform" — is honest about its scope ambition: full-stack from ad investment efficiency (MMM/MTA/Incrementality) through inventory, subscription, and creative analytics.

Seven axes of difference

I lined the two tools up across seven axes using May 2026 official data.

Looking at the map, the functional overlap is small. Triple Whale connects 60+ ad APIs directly and computes ROAS in-app. RevenueScope rides on dataLayer pickup, leans on GA4 ecommerce settings, and explicitly delegates ROAS calculation to GA4 / ad-platform consoles. The two tools intersect at "what visitors and orders happened on the storefront," but diverge sharply on what to do with that data.

The axis I personally find most decisive is Japan-market readiness. As of May 2026 I cannot find Triple Whale Japan pricing pages, JPY billing options, or a Japan office in public sources. The UI is English, support runs on US hours, and documentation is English-only. Shopify storefront currency display in JPY is fine, but UI / support / pricing are English + USD by default.

For a team where every weekly KPI review needs to happen in Japanese — including non-bilingual operators who have to challenge the numbers — that's not a minor friction. I've watched solo founders adopt English tools and stop opening them after week three.

The four-criterion decision framework

I distilled the 7 axes into 4 binary criteria you can run yourself in about 60 seconds.

The criteria:

Language — English-first team or Japanese required?
Feature depth — do you need MMM / MTA / SQL / margin / inventory / ROAS in-app, or are core 4 metrics + Sessions enough?
Engineering — can you leverage SQL Editor / custom Pixel / MMM, or are you GTM-only?
Ad-API integration — do you need 60+ direct integrations with ROAS computed in-app, or is UTM + dataLayer aggregation enough?

If all four lean Triple Whale, pick Triple Whale. If all four lean RevenueScope, pick RevenueScope. If they're mixed, the criterion you cannot compromise on becomes the decisive axis.

In my experience the failure mode I see most often is a Japanese SMB EC team adopting a full-stack tool and never actually using it. Configuration density goes up, weekly review friction goes up, and the dashboard becomes a graveyard. RevenueScope's deliberate scope cap — core 4 metrics + Sessions = 5 KPI cards — is a design decision specifically against this failure mode. Constraint is the value, not the limitation.

Two often-overlooked dimensions

Two factors get under-discussed in tool comparison posts and matter more than they look:

Data ownership / residency. Triple Whale operates on US data centers. For Japanese EC operators, this surfaces a documentation question under Japan's revised Telecommunications Business Act (external transmission rules) and the Personal Information Protection Act: how confidently can you account for "third-party processor" responsibility? RevenueScope runs production on Supabase's Northeast Asia (Tokyo) region. Data residency in Japan is a deliberate operational choice, not a marketing line — for compliance-conscious operators it's a real evaluation axis.

Onboarding-to-mastery time. Both tools install fast (Triple Whale 15 minutes, RevenueScope 5 minutes). But "configured" is not "operational." Triple Whale's surface area — Moby AI, Compass, Pixel, Sonar, SQL Editor — requires a meaningful internalization period before weekly rituals stabilize. RevenueScope's 5 KPI card cap drops this period close to zero. Comparison posts almost always omit this dimension; it usually decides whether the tool actually gets used.

When you might use both

Some brands run both tools. A typical split: Japan operations on RevenueScope daily, global MMM on Triple Whale quarterly. The functional scopes don't overlap, so the cost of running both is mostly the per-seat fee — not duplication of effort.

If you've ever seen a team try to migrate from one full-stack analytics tool to another, you'll recognize how unusual it is to have two tools that genuinely complement instead of competing. That's the structural artifact of designing-for-different-buyers from day one.

Closing

Pick Triple Whale when you have an English-first team, want full-stack measurement (MMM/MTA/SQL/inventory/ROAS in one app), and can leverage 60+ direct ad-API integrations. Pick RevenueScope when you have a Japanese team, want a 5 KPI card weekly ritual, run on GTM, and are fine delegating ROAS calculation to your ad consoles.

Full breakdown with detailed pricing tables, source URLs, and Japan-market notes is at Triple Whale vs RevenueScope: Pricing, Features & Japan EC Comparison.

Curious what other operators have hit when picking between full-stack vs focused tools — happy to swap notes in the comments.

Industry RPS Benchmarks 2026 — Where Your DTC Brand Stands Across Apparel, Food, Beauty, Electronics, and SaaS

toshihiro shishido — Sun, 03 May 2026 12:38:22 +0000

"OK, I understand the RPS formula. But is our RPS — actually — high or low compared to our industry?" Right after I published the RPS-definition guide last week, this was the most common question I got back from EC operators. They want to know where they sit, not just how to compute the number.

Knowing your RPS is $1.20 means nothing if you don't know whether that's the industry median, the top quartile, or the bottom quartile. Ad investment decisions start with positioning yourself.

The challenge: industry RPS benchmarks for the Japan market barely exist as published data. Wolfgang Digital, IRP Commerce, Dynamic Yield, and Yotpo all publish industry slices — but currency conversion and market-specific differences leave gaps. This post combines publicly available global benchmarks with an industry AOV × CVR estimation model to give you a baseline for positioning.

⚠️ All numbers below are estimation-model representative values, not measured. Verify against your own environment.

💱 Note on currency: USD figures use a simplified ¥100/$ conversion for round-number readability. At spot rate (~¥150/$), divide JPY values by 1.5 for actual USD equivalents.

TL;DR

RPS varies 2–10x across industries. Apparel $0.90 / Food D2C $1.35 / Beauty $1.10 / Electronics $2.00 / SaaS B2B $3.00 (medians, USD, estimated). AOV and CVR characteristics multiply, so cross-industry "average RPS" comparisons mislead decisions.
Your "position" relative to industry median is the decision starting point. Below 80% of median → prioritize CVR/AOV improvement. 120%+ → room to scale ad spend. 200%+ → channel-expansion phase.
Industry RPS doesn't work as a single metric. Pair with ROAS in a 2x2 quadrant to simultaneously judge "efficient investment" and "loss-free allocation." RPS = acquisition efficiency. ROAS = investment recovery.

Why industry-blind RPS comparison structurally misleads

Cross-industry "average RPS" comparison fails for three structural reasons.

Structure 1: AOV varies 10x+ across industries. Electronics single-order AOV easily reaches $300+. Apparel D2C averages $60. SaaS B2B year-1 contract value spans $500–$5,000. A 10x AOV gap means a 10x RPS gap, even at identical CVR.

Structure 2: CVR varies 3–5x. Food D2C averages 3–5% (repeat-purchase). Electronics CVR runs 0.5–1.5% (long consideration). SaaS B2B Visitor-to-Lead is 1–3%.

Structure 3: Session quality differs. SaaS B2B is "long-consideration" — multiple visits over weeks. Apparel is impulse-driven, often one-and-done. Electronics is "comparison-shopping" via price-comparison sites. The "weight" of a single session varies dramatically by industry.

A concrete example of how this misleads: an EC site at $1.50 average RPS. An apparel-only operator would judge "above industry median ($0.90) — strong." An electronics-only operator at the same $1.50 would judge "below industry median ($2.00) — improvement needed." Same $1.50, opposite decisions.

5-industry RPS medians and top-25% (estimation model)

Industry	AOV median (USD)	CVR median	RPS median	RPS top-25%
Apparel/Fashion	$60	1.5%	$0.90	$2.00
Food/D2C	$45	3.0%	$1.35	$2.80
Beauty/Cosmetics	$55	2.0%	$1.10	$2.50
Electronics/PC	$250	0.8%	$2.00	$5.00
SaaS B2B (year-1 ARR)	$500	0.6%	$3.00	$8.00

Sources: Yotpo Fashion Benchmarks 2025, IRP Commerce 2025, Dynamic Yield 2025, METI E-Commerce Survey 2024 (FY). Estimation model — not measured.

Quick read across the table:

Apparel: Low AOV, mid CVR. Volume-driven business. Repeat-rate improvement is the lever to top-25%.
Food/D2C: Highest median in the set. Repeat-purchase model lifts first-CVR.
Beauty: Subscription-driven stability, but first-purchase friction is the choke point.
Electronics: High AOV, low CVR. Each session is high-stakes — SEO and comparison-site visibility matter most.
SaaS B2B: Very high AOV, low CVR. Visitor-to-Lead → Lead-to-Customer 2-stage funnel is standard.

Self-diagnosis in 4 steps

Pull monthly Revenue and Sessions from GA4. Revenue from Monetization → eCommerce purchases. Sessions from Lifecycle → Acquisition. Use a 28-day window to absorb day-of-week variance.
RPS = Revenue ÷ Sessions. Example: $15,000 / 12,000 = $1.25.
Compare to industry median. Apparel: $0.90 median, $2.00 top-25% → $1.25 sits between median and top-25%.
Efficiency ratio = your RPS ÷ industry median. Use the table below for the action verdict.

Efficiency ratio	Verdict	Recommended action
Under 0.5	Significantly below	Channel-level RPS to identify cause. CVR vs AOV outlier diagnosis
0.5–0.8	Below average	CVR improvement (forms, cart-abandonment) or AOV (free-shipping threshold, cross-sell)
0.8–1.2	At average	Maintain + analyze gap to top-25%
1.2–1.5	Above average	Scale ad spend. Shift budget to high-RPS channels
1.5–2.0	Top-25% level	New ad-channel pilot
Over 2.0	Industry top tier	Channel expansion / new market opening

Below-average RPS — three improvement priorities

For operators in the 0.5–0.8 range, the priority order is CVR improvement → AOV increase → session-quality improvement.

CVR is the highest-ROI lever. Lifting CVR from 1.5% to 2.0% raises RPS by 33%. Faster effect than AOV plays. Tactical priorities: checkout-flow optimization, cart-abandonment recovery, re-visit promotion (browsing history, wishlist, newsletter opt-in). Per Baymard Institute's research, checkout process optimization alone has lifted CVR by an average of 35.26% in their case studies.

AOV plays come second — only when repeat-purchase exists. Stepped free-shipping threshold raises ($50 → $60 in CVR-stable range), cross-sell at the purchase moment, bundle discounts (3+ items, 20% off). The gotcha: free-shipping threshold raises can backfire if customers "$X short of free shipping" drop off — AOV up × CVR down ends up dropping RPS. Always monitor CVR alongside.

Session-quality improvement (ad-targeting tightening, LP optimization, channel-level reallocation) is the long-term play. Slow to show, but compounds.

Above-average RPS — ad-budget scaling decisions

Operators above 1.2x efficiency are in budget expansion phase. The next decision is "which channel, how much more."

The mandatory analysis is channel-level RPS. Even if total RPS is $1.50, an internal split of Google Ads $2.00 / Meta Ads $0.80 means you should shift Meta budget to Google. Visualize channel-level RPS gaps and concentrate spend on high-RPS channels.

Scaling procedure: identify top 3 channels by RPS. Cross-check against current budget allocation × Sessions. Pilot +20% monthly budget into the top channel. Check 2-week RPS trend. If RPS holds, scale further.

For operators stable above 1.5x efficiency, new-channel exploration is the next step. TikTok Ads, Pinterest Ads, LinkedIn Ads (B2B) — pilot in untouched channels matching industry characteristics at $1,000–$3,000 monthly.

RPS × ROAS — the 4-quadrant ad-judgment

RPS is powerful but never complete on its own. Pair with ROAS for a 2x2 decision frame.

ROAS \ RPS	RPS high	RPS low
ROAS high	🟢 Scale investment (ideal)	🟡 Will grow with sessions (invest in SEO, not ads)
ROAS low	🟡 Efficiency-improvement room (CVR/AOV)	🔴 Consider exit

🟢 RPS high × ROAS high: ideal. Scale channel budget.
🟡 RPS high × ROAS low: low traffic, high unit value. SEO/Organic is the lever, not more ad spend.
🟡 RPS low × ROAS high: high traffic, low efficiency. CVR/AOV improvement = big upside.
🔴 RPS low × ROAS low: exit that channel or radical rethink.

ROAS asks "how efficient is each ad dollar?" RPS asks "how productive is each session?" Together they cover both axes that matter for budget allocation. ROAS without RPS leaves you blind to scale; RPS without ROAS leaves you blind to ad cost.

This is the lens we built RevenueScope around — open the dashboard and channel-level RPS sits next to industry benchmarks, so the "next channel to fund" decision becomes a 1-minute read instead of a spreadsheet hunt.

Question for the dev.to crowd: What's your go-to source for industry RPS or RPV benchmarks? Most published data I find is either heavily skewed to one geo (Wolfgang for EU, Shopify for US) or buried inside paid reports. Curious what others have found that's actually usable for cross-industry positioning.

ROAS Isn't Profit: Why Japanese SMB EC Needs Gross-Margin-Aware ROAS

toshihiro shishido — Sat, 02 May 2026 01:01:18 +0000

"ROAS is at 300%, so we're profitable." I've watched this sentence get accepted in marketing meetings, signed off on slides, and used to justify scaling spend — and then watched the same campaigns produce a money-losing month-end P&L.

The bug is small but expensive: ROAS at 3x ad spend can still lose money once gross margin enters the picture. ROAS 100% is not breakeven, and using it as a mental shortcut for "we recovered the ad spend" is the most common ad-ops mistake I see in Japanese SMB EC.

This post lays out the fix: derive breakeven ROAS from gross margin, then pair ROAS with RPS (Revenue Per Session) so you can judge both efficiency and scale. Both ideas take five minutes to internalize and durably change how you allocate ad budget.

TL;DR

ROAS = Ad-driven Revenue / Ad Spend x 100%. Revenue-based, not profit-based — gross margin is not in the formula.
ROAS 100% is not breakeven. The real bar is Breakeven ROAS = 1 / gross margin x 100%. At 30% margin, that's 333%. At 50%, it's 200%. At 10% (thin-margin retail), it's 1,000%.
ROAS alone hides scale. ROAS 500% on a campaign that drives 10 sessions/month is a rounding error. Pair ROAS with RPS so "efficiency" and "scale" land on the same screen.

Why ROAS 300% can still be a loss

The standard ROAS formula is:

ROAS = Ad-driven Revenue / Ad Spend x 100%

The numerator is revenue, not profit. Revenue still has cost of goods, shipping, and payment fees baked in. So ROAS 100% means "revenue roughly equals ad spend" — which leaves you with whatever the gross margin lets through, and nothing else.

Worked example: 30% gross margin, $1,000 ad spend, $3,000 revenue (ROAS 300%).

Gross profit = 3,000 x 30% = $900
Ad spend = $1,000
Net result: $100 loss

ROAS 300% on a 30%-margin product is a loss. The mental model "ROAS x means I made x times my ad spend" treats ROAS as if it were ROI. It isn't.

Breakeven ROAS = 1 / gross margin x 100%

Once you accept that gross margin is the missing variable, the fix is mechanical:

Breakeven ROAS = 1 / Gross Margin x 100%

Gross Margin	Breakeven ROAS	Ad Spend $1,000 → Required Revenue
10%	1,000%	$10,000
20%	500%	$5,000
30%	333%	$3,333
40%	250%	$2,500
50%	200%	$2,000
60%	167%	$1,667

A few patterns fall out immediately:

Thin-margin verticals (food, low-ticket D2C around 10-20%) need ROAS in the 500-1,000% range just to break even. "ROAS 400% campaign performing well" reads completely differently here than at 50% margins.
Mid-margin EC (general retail, electronics around 20-30%) lands at 333-500% breakeven. Industry-average ROAS quotes of "300-500%" sit dangerously close to the loss line.
High-margin verticals (cosmetics, branded apparel at 50-70%) can survive at 167-200% ROAS. Aggressive customer-acquisition campaigns make sense here in a way they don't elsewhere.

The single most useful thing I've done as a result of this is to set target ROAS = breakeven ROAS x 1.2 — a 20% margin of safety above the loss line. For a 30%-margin product that's 333% x 1.2 = 400% as the operating target, not "300-500% because that's what the industry quotes."

If your ad team can't tell you the gross margin off the top of their head when they hand you a ROAS report, that's the gap to close before any other optimization.

Why ROAS alone misjudges ad budget

The second failure mode is subtler. Compare two campaigns running at the same $1,000 monthly ad spend:

Campaign A: ROAS 500%, 10 sessions/month, $5,000 in revenue
Campaign B: ROAS 250%, 500 sessions/month, $25,000 in revenue

Pure ROAS ranking puts A at 2x B. But B is doing 5x the revenue. ROAS measures efficiency; it cannot measure scale. If you allocate budget by ROAS alone, you systematically over-fund efficient-but-tiny campaigns and under-fund larger campaigns that are doing the actual revenue work.

The fix is RPS (Revenue Per Session) = Revenue / Sessions, paired with ROAS in a 2x2:

State	Decision
High ROAS x High RPS	Winning channel — scale budget
High ROAS x Low RPS	Room to grow scale — expand audience / bidding
Low ROAS x High RPS	Ad spend too high — optimize bids / creative
Low ROAS x Low RPS	Channel mismatch — stop or rebuild

ROAS asks "how efficient is each ad dollar?" RPS asks "how productive is each session?" Together, they cover both axes that matter for budget allocation. ROAS without RPS leaves you blind to scale; RPS without ROAS leaves you blind to ad cost.

The mental model: Revenue = ROAS x Ad Spend = RPS x Sessions

Once you have both metrics in place, ad operations collapse into a clean dual-equation:

Revenue = ROAS x Ad Spend       (ad investment lens)
Revenue = RPS  x Sessions       (traffic and efficiency lens)

Every initiative ultimately moves one of these levers:

Ad spend up → sessions up → scale grows (assuming RPS holds)
Targeting refinement → ROAS up → efficiency improves
LP / UX optimization → CVR up → RPS up
AOV plays (bundles, free-shipping thresholds) → AOV up → RPS up

When initiatives are framed by which lever they move, prioritization gets a lot easier. "We're improving the LP" → that's an RPS bet, judge it on RPS lift. "We're expanding the keyword list on a winning campaign" → that's a sessions bet, judge it on absolute revenue, not ROAS preservation.

This is the lens we built RevenueScope around: open the dashboard and Revenue / RPS / AOV / CVR / ROAS for every channel sit on a single screen, with the gross-margin-aware breakeven line visualized so "ROAS 300% reads as profit" stops happening. The tool is opinionated about it — Revenue First, ad-spend decisions made against gross-margin-aware breakeven, not industry-average ROAS quotes.

A practical checklist before your next ad-budget meeting

Document your gross margin by SKU group or campaign group. Even rough numbers beat "we don't know."
Compute breakeven ROAS = 1 / gross margin x 100% for each segment.
Set target ROAS = breakeven ROAS x 1.2 (or higher if your CFO is conservative).
Add RPS to the dashboard alongside ROAS for every channel.
Use the 2x2 (ROAS x RPS) to decide scale / optimize / stop, not raw ROAS rankings.

The cost of doing this is one spreadsheet and a willingness to retire "ROAS 300% = profitable" from team vocabulary. The upside is that ad-budget allocation stops being a coin flip on margin-blind metrics.

Question for the dev.to crowd: When you've handed off margin-aware ROAS to a non-finance ad team, what slowed adoption? Mine has been "but the platform shows ROAS 300% as green" — the visual reinforcement of the wrong threshold is a real problem. Curious how others have unhooked teams from the platform's default reading.

Stop Ranking Ad Channels by Sessions: Use RPS (Revenue Per Session) Instead

toshihiro shishido — Thu, 30 Apr 2026 22:10:31 +0000

"Google Ads vs. Meta Ads — same budget, which one is more efficient?" I hear this question almost every week from ecommerce operators. Most of them compare by sessions, and that almost always leads to the wrong answer.

I made the same mistake myself once. Meta Ads was driving 1.5x the sessions of Google Ads, so I shifted budget. End of month, total revenue was down.

The fix was a simple division: revenue ÷ sessions, by channel. The metric is called RPS (Revenue Per Session), and it's the only number that compares revenue efficiency across ad channels apples-to-apples.

TL;DR

RPS = Revenue ÷ Sessions. It's the only metric that says "how much revenue per visit." With the relationship AOV × CVR = RPS, it folds AOV and CVR into one number — the integrated decision axis.
Sessions alone misjudges ad channels. Cheaper sessions ≠ revenue-generating sessions. RPS is the right axis for budget allocation across paid channels.
AOV-only or CVR-only optimization hits a hidden trap. Raising free-shipping thresholds raises AOV but drops CVR — and RPS goes down. Only RPS reveals "is this initiative actually good for the business?"

Why Sessions-Based Comparison Misjudges Ad Channels

Ad reports lead with sessions. "Meta Ads has 12,000 sessions this month, Google Ads has 8,000. Meta is winning." This reading is wrong almost every time.

Sessions tells you how many people came. It doesn't tell you how much revenue they brought. Same $10,000 budget across three channels:

Google Ads: 8,000 sessions, $9,600 revenue → RPS $1.20
Meta Ads: 12,000 sessions, $9,600 revenue → RPS $0.80
TikTok Ads: 20,000 sessions, $8,000 revenue → RPS $0.40

By sessions, TikTok wins handily. By RPS, Google Ads is 3x more efficient than TikTok. The exact opposite conclusion.

The mistake I made was the same shape: Meta Ads was driving more sessions, but the traffic mix had lower average AOV and CVR, so the quality per session was worse. Budget moved in the wrong direction. Ad budget allocation should be judged by RPS, not sessions.

Why AOV-Only and CVR-Only Optimization Hit a Trap

The other strength of RPS is that it folds the interaction between AOV and CVR into a single number.

Take raising the free-shipping threshold from $50 to $80. AOV jumps from $62 to $74 (+19%). Looks great. But customers who were "$20 short of free shipping" drop off, taking CVR from 2.4% to 1.8% (-25%). Net effect: RPS goes from $1.49 to $1.33 (-11%). AOV-only reads as a win. RPS reveals it's a loss.

The reverse pattern works too. A 3-item, 20%-off bundle: AOV $48 → $52 (+8%), CVR 2.0% → 2.6% (+30%), RPS $0.96 → $1.35 (+41%). When AOV and CVR move together, RPS jumps dramatically.

The shared structure: maximizing a single metric usually sacrifices another. Discounts to lift CVR drag AOV down. Thresholds to lift AOV drag CVR down. When the three metrics move independently, you need RPS as the integrated axis to judge the net effect.

How to Compute RPS in GA4 (and Why It's Painful)

GA4 has a metric called Average purchase revenue per user, which is conceptually close — but it's per user, not per session. If one user visits 3 times before purchasing, the per-user view counts that as 1 user with 1 purchase. The per-session view counts 3 sessions with 1 purchase. Ad-channel decisions need the second one.

To get session-level RPS in GA4, you need an Exploration with a custom calculation: "Total revenue (purchase) ÷ Sessions" — and the denominator must include sessions that didn't purchase. Standard reports won't surface this directly, which is where most operators get stuck.

The cleaner approach is to join sales data and session logs in your data warehouse and compute it in SQL:

SELECT
  channel,
  SUM(revenue) / COUNT(DISTINCT session_id) AS rps
FROM
  sessions s
LEFT JOIN
  orders o ON s.session_id = o.session_id
GROUP BY
  channel

One query, channel-level RPS. The real value of RPS comes from channel comparison, so you want an environment that can produce this granularity.

The "Sessions × RPS" Worldview

Once RPS is in place, ecommerce decision-making collapses into a simple equation:

Revenue = Sessions × RPS

Every initiative ultimately moves one of these two axes:

SEO and paid ads → move sessions
Thresholds and bundles → move RPS via AOV
UX and LP optimization → move RPS via CVR

Operators with reliable RPS measurement can judge any initiative across two axes — "did sessions grow?" and "did RPS move?" — and ad investment, channel selection, and LP optimization priorities all become genuinely data-driven.

I've been building RevenueScope on this exact premise: open the dashboard and channel-level RPS is right there, so the next budget decision lands in under a minute.

What's your current RPS by channel? If your dashboard shows sessions but not RPS, the channels you're scaling might not be the channels that drive revenue. Curious to hear from anyone who's flipped from sessions-comparison to RPS-comparison — what changed?