DEV Community: toshihiro shishido

Running Ads But Can't Tell Which Ones Actually Sell? Fix This First 2026

toshihiro shishido — Sat, 06 Jun 2026 01:47:15 +0000

You spend on ads every month. You're getting clicks. But asked "which ads actually drove sales?", you can't answer clearly. That happens at a lot of online stores — and it's rarely a skill problem. It's usually a missing measurement foundation.

TL;DR

Ad effectiveness is whether ads drove *sales* — not clicks or impressions
You can't tell which ads worked because the foundation is missing — no conversion tracking, no UTM tags, no link between ads and revenue
Platform dashboards stop at "what happened" — your real revenue and whether buyers were new aren't there
The fix is small — UTM tags, revenue per channel, split new vs returning

Two views of the same ad

The same ad tells you different things depending on where you read the numbers. There's the platform dashboard, and there's your own revenue.

The dashboard records clicks, impressions, and self-reported conversions — what happened. Your own revenue shows how much actually sold, and whether the buyer was new or a returning regular. Real measurement is reconciling the two: which ad truly created sales.

Why the numbers swing

Without conversion tracking and UTM tags, you simply can't connect ads to sales. The symptom: clicks come in, but cost per lead swings 3–4x month to month.

When numbers swing like this, the reflex is "adjust the bids." But the real cause isn't bidding — it's the missing foundation. Running for months with no conversion tracking, spending budget without knowing which ad produced leads, is more common than you'd think. You feel like you're optimizing while running blindfolded. And the platform alone won't save you: Google Ads can say "this keyword converted," but not whether that lead was any good in the CRM.

Three steps that fix it

You don't need a perfect model. You need to realign your own revenue by "which ad it came from."

Add UTM tags so each visit carries which ad it came from
Total real revenue by channel and ad — your confirmed numbers, not each platform's self-report
Split new vs returning — platforms optimize toward the cheapest converters, which skews to existing regulars

That last one matters most. A channel with great-looking numbers may just be counting regulars' repeat visits, while a channel that looks unremarkable is quietly bringing in the most new customers. Splitting new from returning is what tells them apart.

Bottom line

"Which ads work" isn't a mystery you solve with a fancier dashboard. It's a foundation you build: UTM tags, revenue per channel, new vs returning. Align those three and the ad that looked unremarkable but was actually winning new customers tends to show up.

How do you currently tell whether an ad drove new sales versus just reactivating people who'd have come back anyway? Curious what's working for others running lean.

Cutting a Channel on Last-Click Once Doubled Their CPA — Read Attribution Right 2026

toshihiro shishido — Fri, 05 Jun 2026 00:41:32 +0000

"This channel isn't driving conversions." You trust the dashboard, cut its budget — and total revenue quietly falls. The usual culprit is last-click: it assigns the whole sale to the final touch and counts everything upstream as zero. Easy to report, easy to explain to finance — and easy to mislead your budget.

TL;DR

Last-click credits only the final touch — everything that created demand earlier counts as zero
Cutting upstream drops downstream too — kill awareness and the later "search and buy" shrinks with it
Criticism without a move is noise — keep a simple, revenue-first alternative
Ask buyers directly — a one-question survey catches touches clicks never see

How last-click hides the journey

Customers don't search and buy from nowhere. They see something, get curious, then search and convert. Last-click gives 100% of that sale to the last click and zero to the social ad or podcast that started it.

So the touches that build demand look like dead weight on the report — even when they're doing the real work.

The cut that backfired

A real one: a brand spent $40K/month on podcast ads showing just 1.8% of revenue in last-click, so they paused them. Two months later CPA went from $85 to $160 — almost double. The awareness those ads created had vanished, and fewer people searched and bought.

The touch that looked like zero was the front door for the whole funnel.

Act, don't just criticize

"Last-click is bad" solves nothing — the common gripe is that critics never say what to use instead, and fancy causal models are expensive and hard to run. So keep it simple:

Rank channels by your own real revenue, not platform self-reports
Split new vs returning so you don't cut a real acquisition channel
Ask "how did you hear about us?" at checkout — self-reported attribution catches AI-search and review-site touches that never register as clicks

You don't need perfect measurement. Add one more angle to the last-click number and the risk of cutting the wrong channel drops fast.

Bottom line

Last-click writes off the demand-creators upstream. Move budget on it alone and you can dry up the source of your visible conversions. Rank channels by real revenue, split new from returning, and ask buyers directly — then review your main channels from an angle other than last-click.

When a channel shows weak last-click numbers, how do you decide whether it's truly dead weight or an upstream demand-creator? Curious how others avoid cutting the wrong one.

Your Best-ROAS Channel Might Be Your Worst: Split New vs Returning 2026

toshihiro shishido — Fri, 05 Jun 2026 00:40:52 +0000

I'll admit a bad habit of mine: when I shifted budget between channels, I stopped at the dashboard's ROAS and CPA and almost never reconciled it to actual revenue on my own side. The problem is that pouring more into the "best ROAS" channel can quietly backfire — because a high ROAS often means the channel is re-engaging people who would have bought anyway, not winning anyone new.

TL;DR

High-ROAS channels skew to returning buyers — platforms optimize toward the cheapest converters, who are usually existing customers
Split new vs returning with two numbers — total orders and first-time orders; the gap is re-engagement volume
Contribution margin flips the ranking — same ROAS, different product margin, very different profit
Judge new-customer channels on a separate yardstick — harvesting demand ≠ creating it

Why a high ROAS can be a trap

ROAS is a channel's attributed revenue ÷ its spend. It looks clean, but it can't tell you whether that revenue is new or returning. Delivery algorithms chase whoever converts cheapest, and the cheapest converter is usually someone who already knows you and would have come back anyway. So retargeting and brand-search tend to post high ROAS — they harvest demand that already exists.

Cut the "low ROAS" channel and you may be closing the front door for the new customers who'd become tomorrow's repeat buyers. One brand killed its podcast ads for low ROAS — and watched search-driven revenue fall the next quarter, because those ads were creating the demand people later searched for.

Two numbers that do the splitting

You don't need a fancy tool. Per channel, pull total orders and first-time orders. The difference is the volume of returning-customer re-engagement.

A channel with 320 total but only 40 first-time orders isn't acquiring — it's reactivating. A plainer channel with a small gap is doing the real new-customer work. Notice how this can flip the ROAS verdict entirely.

Read profit, not revenue

ROAS measures revenue, not what you keep. Contribution profit = revenue − (COGS + shipping + fees + ad spend). Two channels, ¥500K spend each:

Meta: ROAS 3x, 40% margin → ¥1.5M revenue → ¥100K profit
Google: ROAS 2x, 70% margin → ¥1.0M revenue → ¥200K profit

Meta wins on ROAS and loses on profit. Revenue is vanity, margin is sanity — translate ROAS into profit before you rank channels, and the order changes.

Bottom line

A high ROAS can be re-engagement in disguise. Split each channel's total vs first-time orders to see who actually brings new buyers, and convert ROAS into contribution profit before deciding where to scale. Take three numbers — total orders, first-time orders, rough contribution profit — for your main channels, and the channel truly worth protecting stops hiding.

When you move budget, do you reconcile platform ROAS back to your own revenue and split new vs returning — or mostly trust the dashboards? Curious how others handle it.

Summing Platform ROAS Overstates Your Ad Results — Use MER Instead 2026

toshihiro shishido — Thu, 04 Jun 2026 06:32:13 +0000

Google Ads reports ROAS 400%. Meta reports 350%. On each dashboard, both look great. But add the two numbers together to judge "overall ad efficiency" and you're looking at more revenue than actually exists — because each platform counts the same purchase as its own win. That gap quietly inflates how well you think your advertising is doing.

TL;DR

Platform ROAS gets inflated per channel — each platform counts the same purchase, so summing ROAS exceeds your actual ad-driven revenue
MER = total revenue ÷ total ad spend — one number for whole-business efficiency, immune to cross-platform double-counting
ROAS for per-channel tuning, MER for budget decisions — and watch MER when you scale spend
MER alone still can't tell new from returning — high apparent ROAS often skews to returning buyers who'd have come back anyway

Why summing platform ROAS overstates results

ROAS is a platform's ad-driven revenue ÷ its ad spend. The catch: one customer often touches several ads before buying. See a Meta ad, search on Google, then buy — and both Meta and Google count "that purchase was mine." That's attribution double-counting.

For a store spending ¥1M total (Google ¥500K, Meta ¥500K): Google claims ¥2.0M, Meta claims ¥1.75M — ¥3.75M of claims against ¥3.0M of actual ad-driven revenue. The ¥750K gap is the same purchases counted twice. Summing per-platform ROAS overstates your result by 25%.

What MER is

MER (Marketing Efficiency Ratio) is whole-business total revenue ÷ total ad spend. For that same store, ¥5M total revenue against ¥1M ad spend is MER 500%. Because MER never assigns revenue to a platform, there's no double-counting.

There's a second benefit: non-ad revenue sits in the numerator too. Double your ad spend and if MER drops, that added spend is lowering overall efficiency — a move per-platform ROAS tends to hide, because each platform keeps reporting healthy attributed numbers.

When to use which

Use ROAS for per-channel campaign tuning and creative comparison — it's the daily, actionable number. Use MER to set how much total budget goes where, and to check whether total revenue actually grew when you raised spend.

Refine inside channels with ROAS; decide total spend with MER. Chase per-platform ROAS alone and you miss the state where overall efficiency is falling while every platform still looks fine.

What MER still hides: new vs returning

MER blends everything into one number, so it erases whether revenue came from new or returning customers. Ad platforms push delivery toward whoever buys cheapest — usually returning customers who'd have come back anyway. So channels skewed to returning buyers show high apparent ROAS, while channels reaching genuinely new customers look weak on the spot.

Cut a new-customer channel because its ROAS is low, and you close off the entry point for future repeat buyers. A search channel that harvests existing demand and a social channel that creates new demand shouldn't be judged on the same revenue yardstick. Confirm overall efficiency with MER, but evaluate new-customer contribution separately — by channel, and by new vs returning.

Bottom line

Per-platform ROAS double-counts, so summing it overstates your ad results. MER measures whole-business efficiency in one number and sidesteps that. Refine channels with ROAS, set total spend with MER — and split new from returning so you protect the right channels when budgets tighten.

How does your team handle the platform-ROAS-vs-blended question — do you track MER, or still report channel ROAS separately? Curious how others draw the line.

ROAS vs ROI — The Metric Confusion That Quietly Costs EC Operators Money 2026

toshihiro shishido — Thu, 04 Jun 2026 04:53:00 +0000

Last month a founder I advise told me their "ad ROI was 300%." I had to stop and ask: do you mean ROAS, or actual profit-based ROI? At a 30% gross margin those two numbers tell opposite stories — one looks healthy, the other is a loss. The formulas look so similar that they get swapped silently in the same meeting, and budget decisions quietly go backwards.

TL;DR

ROAS = ad revenue ÷ ad spend × 100. ROI = profit ÷ total investment × 100. The numerator — revenue vs profit — is the whole difference
At 30% gross margin, ROAS 300% is a loss — profit ROI lands around −11%
ROAS is for daily ad optimization, ROI is for total-investment decisions including labor and production costs
When someone says "ROI 300%," ask for the definition before acting on it

The formula difference

Both metrics measure "how much came back," but the numerator is different. ROAS uses revenue (before costs). ROI uses profit (after costs). ROAS also covers ad spend only, while ROI can cover the full investment — labor, production, tools.

Ad platforms auto-report ROAS in real time, so it becomes the default for daily operations. ROI needs internal profit data, so it fits quarterly budget calls.

ROAS 300% can still be a loss

Here's the trap. At 30% gross margin, ¥100K of ad spend driving ¥300K of revenue (ROAS 300%) means ¥210K cost of goods plus ¥100K ad spend — ¥310K total against ¥300K revenue. That's a ¥10K loss. Profit ROI is roughly −11%.

Treat ROAS as ROI and you'll pour more budget into a campaign that's actually bleeding. The fix is a breakeven ROAS reference: 1 ÷ gross margin × 100. At 30% margin that's 333%, so ROAS 300% is below the line.

When to use which

Use ROAS for campaign-level PDCA and channel comparison — it's auto-reported and easy to act on daily. Use ROI when the decision involves costs ad platforms don't see: people, creative, new channels like events or influencers. A practical order: stabilize ad efficiency with ROAS first, then layer in ROI to judge total investment.

Three ways they get mixed up

In practice the confusion shows up in three recurring shapes:

Calling the ad-platform number "ROI." When Google Ads reports "cost efficiency," that's ROAS — it ignores gross margin and labor. Relabeling it ROI means deciding budget on a number that doesn't account for either.
ROAS and ROI side by side in one report. "ROAS 350% / ROI 25%" have different denominators and numerators. The bigger number isn't the better one, and reading them as comparable misrepresents real profitability.
Setting only a ROAS target. "Hold ROAS 300%" works until margin shifts — then the same ROAS means a different profit. Pair the target with a breakeven ROAS so the gap to actual ROI stays visible.

One thing worth being honest about

ROAS only ever sees paid advertising. Organic search, direct, and social organic efficiency are invisible to it. What I'm building with RevenueScope tracks revenue-per-session across all channels in real time — the part ROAS structurally can't show — so you can see which channels actually contribute before you reallocate budget. It's the step after ROAS, not a replacement for it.

Most operators don't need a perfect cross-channel ROI on day one. They need to stop confusing the ad-platform number with profit.

What's the worst ROAS-vs-ROI mix-up you've seen survive a budget meeting?

Why Your EC Revenue Quietly Shrinks Even When New Customers Keep Coming 2026

toshihiro shishido — Thu, 04 Jun 2026 03:13:32 +0000

Last quarter I kept hearing "traffic looks fine, new customers look fine" from an EC operator I was advising. Revenue still drifted down month after month. No one could explain it until we split the revenue line in two: new customers versus repeat customers. The repeat line was falling. Churn was eating the business quietly, and new acquisitions were papering over the gap.

TL;DR

Churn rate = the share of customers who stop buying in a given period — not just subscription cancellations, but EC repeat buyers who quietly disappear
New customers offset the loss, so total customer count stays flat while the quality degrades inside
Two types with different fixes — voluntary churn (customers leave by choice) vs. payment-failure churn (card expired, nobody noticed)
Three reasons it's hard to see — averages dilute the signal, there's a time lag, and failed payments are silent
First move — track repeat-customer revenue separately over time; if the total is flat but the repeat line is falling, that's the signal

Why new customers hide the problem

When new inflow equals outflow, customer count stays flat. The leaky-bucket intuition is real: you can keep pouring water and the level never moves. What changes is the composition. Long-term repeat buyers — who buy more often and spend more per order — get replaced by brand-new buyers who've only ordered once.

Acquiring a new customer costs more than retaining an existing one, so the swap is doubly expensive: you pay more for a customer who buys less.

Voluntary churn vs. payment-failure churn

These two look the same in your revenue report but need opposite responses.

Voluntary churn is intentional: the customer decided to leave. Fixing it means improving your product, pricing, or loyalty loop — real work on the underlying experience.

Payment-failure churn is accidental: the customer's card expired or hit its limit. They didn't decide to leave. A simple notification — "update your card" — brings many of them back. No product changes needed.

Mixing the two wastes effort. Sending loyalty re-engagement offers to people whose card just expired changes nothing.

Three reasons churn stays invisible

Averages smooth it out. "Average purchase count" blends your loyal high-frequency buyers with churned customers who bought once. The loyal buyers carry the average. By the time the average dips, the damage is already months old.

Time lag. Customers don't announce they're leaving. They drift away. The revenue impact shows up three to six months after the behavior change — by which point the gap is large.

Payment failures are silent. A failed charge doesn't appear in your revenue report as "lost revenue." It just doesn't appear at all. Unless you actively check the payment-failure list, you won't know it's accumulating.

Three moves in order of priority

Split repeat-customer revenue over time. Don't wait for the total to fall. Watch the repeat-only line month by month. If it bends down while total is flat, you have a churn problem.
Pull the at-risk segment. RFM analysis surfaces customers who used to buy regularly but haven't recently. Flag them early, before the recency gap widens into permanent departure.
Check payment failures weekly. Pull the list, send the update-card email. This is the fastest ROI move in churn management.

One thing to be honest about

I should be clear: churn rate as a precise number — down to the decimal — requires a CRM-level model per customer. What I'm building with RevenueScope isn't that. It shows revenue split by new vs. repeat customers, by channel, over time — enough to catch the signal early, before the precise diagnosis is needed.

Most EC operators don't need the decimal first. They need to know whether repeat revenue is bending down or not. That's the thing to fix before optimizing anything else.

What's the earliest signal you've found for catching churn before it shows in the revenue line?

Why Bot Traffic Quietly Wrecks Your Channel Evaluation (and Your Budget)

toshihiro shishido — Wed, 03 Jun 2026 13:54:16 +0000

A few days after launching my own site, I opened the analytics and saw one channel jump out: traffic from a video platform had become the single biggest source on a per-day basis. My first reaction was the obvious one — "great, that channel is working, let me lean into it."

It wasn't working. None of those visits were human. They were bots reading the URL I'd pasted into a video description, and I was about to pour effort into a channel that produced exactly zero people. This post is about why bots slip into your channel reports, what kinds of bots actually show up, the expensive misjudgment they cause, and the one simple lens — visits times dwell time — that I now use to catch them.

TL;DR

Bots are 53% of all web traffic — they've passed humans. Thales's (formerly Imperva) report found 53% of all internet traffic was automated in 2025, surpassing human visits (47%) for the second year running — bad bots at 40%, good bots at 13% [1]. With generative AI, automated traffic keeps climbing.
GA4 only auto-removes the known bots. It filters out bots and spiders on the IAB-managed blocklist (the known-bot list), but anything not on that blocklist — including bots that fake a browser user agent — passes straight through. You can't even see how much was excluded [2].
The real loss hits both ad budget and SEO. A path full of 0-second bot sessions can look like your "fastest-growing channel." Believe it and you fund a dead ad path while underrating the boring channel that's actually making money — and on the SEO side, crawler-inflated pages pull effort toward keywords that produce nothing.

What bot traffic is, and why it lands in your channel reports

A bot is simply an automated program opening a page instead of a human. Search engines, social networks, link-preview tools, monitoring services — they all run them. Thales's (formerly Imperva) study put automated traffic at 53% of the entire internet in 2025, with humans at only 47% — the second year running that bots have outnumbered people [1].

The reason bots end up inside your channel breakdown is that many of them get recorded as traffic with a referrer. Paste your site's URL into a social post or a video description, and a bot opens the page to build the preview card. To your analytics, that looks like "a visit from that social or video platform." So a brand-new channel appears to light up — even though no human ever arrived.

The kinds of bots that show up in your data

Not all bots are equal. Some are easy to filter, others blend right into your referral traffic.

Search engine crawlers (Googlebot and friends) walk your pages to build search results. They're well-identified — their name sits in the user agent string — so tools like GA4 auto-exclude most of them.

The ones to watch are the bots that ride in on a referrer. Link-preview bots from social apps and chat tools open the pasted URL to generate a summary card. That shows up as "traffic from that platform," and some of them disguise themselves as a real browser, so analytics tools can't reliably strip them out. SEO crawlers, uptime monitors, price scrapers, and AI-training crawlers can all leak into your traffic too.

Where the real loss happens: bots throw off both ad budget and SEO

This is where it actually costs you. I nearly fell into the trap on my own site. One video-platform path looked like my highest-volume channel within a few days of launch, and I genuinely felt like it was taking off.

Then I dug in. All 9 of those sessions had a dwell time of 0 seconds. A crawler was mechanically opening the URL from my video description — not one human had visited. And I'd been treating it as my best-performing channel. The misjudgment runs along two axes:

Ad investment — you judge a bot-inflated path as a "working channel" and shift budget toward a source with no humans and no revenue, while the boring channel that genuinely produces sales looks unimpressive and gets underrated.
SEO — when crawlers from SEO tools and the like make one page look heavily trafficked, you keep pouring effort into pages and keywords that produce nothing, or write off a promising one as "ineffective."

Both start going wrong the moment you trust the raw traffic count at face value. (For another pitfall where search numbers go missing, see why your Search Console clicks don't add up.)

How to spot and exclude bots: read visits against dwell time

You can't get bots to zero, but you can catch them. The key is behavior. A human who opens a page stays at least a few seconds and often views more than one page. Most bots open a single page and leave at 0 seconds.

Sort your channels by visits times average dwell time and their character separates cleanly:

High volume, near 0-second dwell — suspect bot contamination first. Exclude it and check whether any human visits remain.
High volume with real dwell — your genuine workhorse channel. Safe to invest in.
Low volume but real dwell — small but real traffic. A candidate to nurture.
Repeated hits to the same page at the same time — textbook machine access. Evenly-spaced, identical-page repeats are a bot signature.

GA4 does auto-exclude known bots, but only the ones on the IAB-managed blocklist (the known-bot list). Bots not on the blocklist, or bots hiding their identity, pass right through — and you can't see how much was excluded [2]. So "it's filtered automatically, I'm fine" simply doesn't hold.

Only after removing bots can you judge by revenue

The danger of bot contamination is that you'll never notice it if you only watch traffic counts. The reason I caught my own bad call was that I lined up average dwell time across channels and one path stood out as eerily 0 seconds. Had I only looked at visit counts, I'd still believe it was my best channel.

The same trap shows up in other metrics — traffic with no identifiable source getting dumped into Direct, or last-click attribution piling all the credit onto the final ad. Same root cause: deciding from the slice you can see.

So I've stopped stopping at the traffic count and instead trace each channel through to the revenue it produced. RevenueScope filters known bots up front by user-agent and server signals (about a quarter of our own traffic), and catches the cloaked ones by behavior — a single-page visit with zero dwell gets dropped — so the channels you judge are made of actual humans, scored by revenue rather than raw hits. Anchoring on revenue is the shortest path around this measurement trap.

So here's my question back to you: when one channel suddenly looks like your biggest source, do you lean into it right away — or do you check its average dwell time first and assume some of it might be bots?

(Sorry if my English sounds a bit off — Japanese native, with some help from Google Translate.)

References

Thales, "2026 Bad Bot Report", 2025 [1]
Google Analytics Help, "Bot traffic exclusion", [2]
Google Search Central, "Googlebot", [3]

Why Your Search Console Click Counts Don't Add Up (and How Not to Misread SEO)

toshihiro shishido — Wed, 03 Jun 2026 04:04:02 +0000

The first time I tried to confirm how much organic traffic a few pages were really pulling, the math refused to work. I added up every click in the per-query table in Search Console, and the sum came nowhere close to the overall total at the top of the chart. My first thought was the classic one: something is broken, or I've misconfigured a filter.

Nothing was broken. It turns out this gap is by design, and once I understood why the numbers don't match, I stopped making a much more expensive mistake — quietly writing off pages that looked dead but were actually growing. This post covers what's happening, the real cause (anonymized queries), the costly misread it leads to, and three rules I now use to read Search Console without getting fooled.

TL;DR

Per-query clicks never sum to the overall total — by design. Low-volume queries get dropped from the table. Add up the rows and you'll always fall short of the chart total. Google documents this behavior openly.
The cause is anonymized queries. Queries searched by only a few dozen people, or that contain personal info, are hidden for privacy. But their clicks are still counted in the overall total — which is exactly why the rows don't add up.
Not knowing this leads to bad calls. If you see "0 clicks" on a page and conclude "no SEO value," you may be killing a page that's quietly converting through anonymized searches. Read the data assuming it's incomplete.

What's actually happening

Search Console's performance report gives you two different totals. One is the overall total shown on the chart up top. The other is the sum of the per-query rows in the table below it. Line them up and the table's sum is always smaller.

On my own site's real data, the per-query rows summed to 4 clicks, while the overall total read 61. The missing 57 clicks didn't vanish into a bug. Google's own search blog describes the same thing — they give an example where the rows add up to 450 while the chart total is 550 [1].

The gap doesn't come from two different counting methods. It comes from the simple fact that some clicks are never shown in the table at all. Here's why.

The real cause: anonymized queries

Google deliberately keeps queries that very few people search out of the table. These are anonymized queries. The threshold is roughly "queries not searched by more than a few dozen people over a 2–3 month window," and anything containing personal or sensitive information is excluded too [1]. It's a privacy mechanism — it stops anyone from inferring who searched for what.

The key detail: those hidden clicks are still part of the overall total. They drop out of the per-query table, but they stay in the chart's grand total. That's the whole reason summing the rows never reaches it.

What you're looking at	Treatment of anonymized queries
Overall chart click total	Included (so the number is larger)
Per-query rows	Excluded (so they fall short)
When you filter by a query	Excluded (filtering always shrinks the count)

Google's design philosophy is simple: protect the content of searches (who looked for what), but report the totals honestly. So the grand total is the true number, and only the breakdown is partly hidden. The smaller your site's traffic, the harder each query is to clear that few-dozen-people bar — which means the share of anonymized data is larger on low-traffic sites, exactly where founders look hardest for signal.

Where the real loss happens

The mismatch itself is harmless — it's a spec, not a leak. The actual loss comes when you make decisions without knowing the data is incomplete. The trap usually runs like this:

You open the per-query table and a given page shows 0 clicks.
You conclude "this page produces nothing from search."
You stop improving it, drop the related keywords, and move on.

But 0 clicks in the table can simply mean the clicks are hidden by anonymization. In reality the page may be getting steady clicks from a handful of low-volume searches — a page that was about to grow, stopped by your own hand.

Startups and pages targeting niche, low-volume keywords are the most exposed to this. Their share of anonymized data is high, so they look like "zero results" in the table even when they're not.

Three rules for reading a report you know is incomplete

You can't turn anonymized queries off — they're a permanent part of the spec. So instead I read the data with three rules that assume it's incomplete.

Focus CTR improvements on high-impression pages. Pages with lots of impressions were searched by more people, so anonymization barely touches them and the numbers are trustworthy. The upside is bigger too — these are where you start.
Treat "low impressions, 0 clicks" as a spec, not an anomaly. It may just be hidden from the table while quietly getting clicks. Don't cut it on the basis of a 0; give it time.
Read by page, not by query, as your primary view. Page-level totals are less affected by anonymization and give you a cleaner picture of the whole. Use the per-query view as a supplement, not for summing.

As the matrix above shows, the top priority is pages with high impressions and low CTR. Pages with low impressions get handled carefully, on the assumption that their numbers are missing data.

The bigger pattern: every tool shows you a slice

This isn't only a Search Console quirk. GA4 lumping traffic into "Direct / (none)" when it can't identify the source, or last-click attribution piling all the credit onto the final ad — same root cause. Tools turn the slice they can see into a number and hand it to you. Treat that number as the whole and you'll misjudge.

That's why I've stopped deciding on traffic counts alone and instead trace each session through to the revenue it produced. Impressions and clicks are entry-point numbers. Once you can follow each channel all the way to "how much revenue did that session generate," the gaps in the data stop pushing your budget decisions around.

This is exactly the problem I'm working on with RevenueScope — turning raw, partly-hidden tool data into a form you can actually decide on, anchored on revenue per session rather than raw traffic. The numbers a tool spits out get misread by humans and AI alike when you don't know how they're filtered.

So here's my question back to you: when a page shows 0 clicks in your Search Console query table, do you write it off — or do you check its impressions first and assume the data might just be hidden?

(Sorry if my English sounds a bit off — Japanese native, with some help from Google Translate.)

References

Google Search Central Blog, "A deep dive into Search Console performance data filtering and limits," blog post, October 2022 [1]
Search Console Help, "About Search Console data," help article, [2]
Google Search Central, "Use Google Analytics and Search Console data for SEO," documentation, [3]

What Is CPC? Cost Per Click Formula, Benchmarks, and How to Lower It

toshihiro shishido — Tue, 02 Jun 2026 06:00:14 +0000

Every time I opened my Google Ads or Meta Ads report, the same question nagged at me: this CPC — is it high or not? I'd stare at the number, compare it to whatever benchmark I'd read somewhere, and still have no idea whether I was paying a fair price for my store.

What finally got me unstuck was realizing that CPC is not a number you judge on its own. A cheap click is worthless if nobody buys. This post covers what CPC actually is, the formula, why the price you pay is decided by an auction (not by you), benchmarks by industry and channel, and four levers to lower it — all from the angle of someone running a store, not a textbook.

TL;DR

CPC = Ad spend ÷ Clicks — the entry cost of advertising, measured per click. But it says nothing about whether the click converted.
Cheaper isn't better. Always read CPC alongside the post-click CVR and the revenue it generates. A flood of cheap clicks that don't convert is just a flood of losses.
You don't set the CPC you pay — an auction does. On search ads, your "max CPC" is a bid, but the "actual CPC" depends on Ad Rank (bid × quality score). Raising quality score lowers your real cost more reliably than raising your bid.

What CPC actually is

CPC stands for Cost Per Click — the cost incurred each time someone clicks your ad. It shows up as "cost per click" in both Google Ads and Meta Ads, and its job is to measure the entry cost of advertising on a per-click basis. Line up CPC across campaigns and you can see which one pulls users in most cheaply.

The catch: CPC is a cost up to the click, and nothing beyond it. Whether that person bought, and how much revenue they brought in, is invisible from CPC alone. That's the first trap — collecting a pile of cheap clicks does not move revenue unless they convert.

It's easy to confuse CPC with two neighbors, CPA and CTR. They sit on the same line but measure different points:

Metric	What it measures	Formula
CTR	Share of impressions that got clicked	Clicks ÷ Impressions
CPC	Cost per click	Ad spend ÷ Clicks
CPA	Cost per conversion	Ad spend ÷ Conversions

Advertising flows impression → click → conversion. CTR captures how easily the ad gets clicked, CPC how cheap that click is, CPA the efficiency all the way to a sale. The relationship worth memorizing is CPA = CPC ÷ CVR — which means a low CPC still produces an ugly CPA when CVR is weak.

The formula and a quick example

There's only one CPC formula:

CPC = Ad spend ÷ Clicks

Say you spent $3,000 on ads in a month and got 5,000 clicks. CPC is $3,000 ÷ 5,000 = $0.60. It cost 60 cents to bring one person to your site. That's it for the math — the hard part is interpreting it.

Max CPC vs. actual CPC — the auction decides

Here's the part that surprised me most when I dug in: the "max CPC" you set and the "actual CPC" you're charged are two different numbers.

Max CPC (your bid): the most you're willing to pay per click. You set this.
Actual CPC: what you actually get charged. It's usually lower than your max CPC.

On search ads, ad slots are filled by auction. In Google Ads, your position is calculated as Ad Rank = bid × quality score. Quality score reflects how relevant your ad, keyword, and landing page are to each other — and the higher it is, the better you rank even at a lower bid, which drags your actual CPC down.

So the real lever for lowering actual CPC isn't "bid more." It's "raise your quality score." That ties directly into the four ways below.

Benchmarks by industry and channel (and the pitfall)

CPC swings hard by industry. In a large U.S. benchmark study, search advertising (Google Search) CPC by industry lands roughly here:

In U.S. search advertising the all-industry average CPC is about $5.40, with EC-adjacent industries sitting around $4 [2]. One big caveat: this is U.S. market data in USD — currency and competitive dynamics make it differ from other markets, so treat these as directional, not as your target. Judging CPC purely on an industry benchmark is dangerous. You always have to check it against your own post-click CVR and revenue.

Search ads and social ads are a different game

CPC also shifts by an order of magnitude across channels. Putting search ads (Google Search) and social ads (Facebook) side by side from the same U.S. source makes the gap obvious — social ad CPC runs at roughly one-fifth or less of search ad CPC.

The reason it's not as simple as "pick the cheaper channel": search ads catch high-intent users ("I want this now"), so CPC is high but CVR is high too. Social ads reach a broad latent audience, so CPC is cheap but CVR tends to be low. Choose a channel on CPC alone and you risk buying a flood of cheap clicks that convert at near zero.

Four ways to lower CPC

The levers for lowering actual CPC fall into four groups:

In my experience improving quality score is the highest-leverage one. Since actual CPC is set by "Ad Rank = bid × quality score," a higher quality score ranks you higher without raising your bid, and your actual CPC drops as a side effect. Aligning the message across your ad copy, your keywords, and your landing page is the foundation of that.

One warning, though: for every one of these levers, lowering CPC is not the goal in itself. Halve your CPC and revenue won't budge a cent unless the people clicking actually convert.

Three steps to measure your own CPC

To turn CPC from "a number I stare at in the ad dashboard" into "a number I make decisions with," I run three steps on my own data.

Step 1 — Tag ad traffic with UTM parameters. The CPC in an ad dashboard only covers clicks inside that one platform. Run ads across several channels and you lose track of which ad's visitors generated which revenue. Tagging every ad with a consistent utm_source / utm_medium / utm_campaign lets your site-side analytics consolidate all ad traffic in one place.

Step 2 — Aggregate clicks and revenue by channel. For each UTM-identified channel, line up clicks, ad spend, conversions, and revenue. The key is to use clicks and revenue measured on the site side, not the CPC the ad dashboard reports.

Step 3 — Judge "the revenue-generating CPC" with CPC × CVR. This is where it clicks. Picture three channels: Google Search at a high CPC but solid RPS, Meta retargeting at a mid CPC with decent RPS, and Meta prospecting at the cheapest CPC — but an RPS lower than its own cost per click. The cheapest channel is the one you'd stop. Even at the lowest CPC, if RPS sits below it, every extra click deepens the loss. Only here does CPC turn from "the cheapness of a click" into "the basis for a budget decision."

This is the exact problem I'm working on with RevenueScope — it aggregates the clicks and revenue of UTM-identified ad traffic on a per-channel RPS (revenue per session) basis, so instead of just seeing how cheap a click was, you see whether each click actually generated revenue.

So here's my question back: when you look at your ad reports, do you judge CPC by its absolute number — or against the revenue each click actually brings in?

(Sorry if my English sounds a bit off — Japanese native, with some help from Google Translate.)

References

Dentsu, "Advertising Expenditures in Japan 2024," press release, February 2025 [1]
LocaliQ, "Search Advertising Benchmarks," benchmark report, 2026 [2]
LocaliQ, "Facebook Advertising Benchmarks," benchmark report, 2025 [3]

I Stopped Treating All My Customers the Same — Here's How RFM Analysis Sorts Them by 3 Numbers

toshihiro shishido — Mon, 01 Jun 2026 01:28:59 +0000

For a long time I sent the same email to every customer. New buyers, loyal regulars, people who hadn't come back in months — all got the same "here's our sale" blast. It felt fair. It was actually just lazy, and the results were mediocre: too thin for my best customers, off-key for the ones who'd already drifted away.

What fixed it was RFM analysis — a way to rank customers by three numbers so I could decide who deserved which tactic. This post covers what the three metrics mean, how to score and segment, and how RFM differs from the cohort analysis it always gets mentioned alongside.

TL;DR

RFM = ranking customers by Recency (last purchase date), Frequency (purchase count), and Monetary (total spend)
Score each metric (e.g. 1–5), then read customers by the combination — "R5・F5・M5" is a VIP, "R1・F5・M5" is a loyal customer slipping away
The goal is not sorting — it's deciding who gets which tactic: keep the loyal, win back the at-risk, nurture the new
Focusing budget where it works beats sending everyone the same email
RFM shows the current state of customers; cohort analysis shows the trend by acquisition period — different angles, and they combine well

1. What RFM analysis actually is

RFM evaluates each customer on three metrics and sorts them into groups. The name is just the initials:

R (Recency / last purchase date): how long since they last bought
F (Frequency / purchase count): how many times they've bought
M (Monetary / total spend): how much they've spent overall

Why all three? Because any single metric misleads you. The mistake I kept making was prizing only "customers who spent a lot." That made me treat someone who dropped a big order six months ago and never returned as a loyal customer. Add "did they buy recently (R)" and "how often (F)," and the people who are actually active right now become visible. Since acquiring new customers costs more than retaining existing ones, deciding who to keep ties straight to revenue.

2. Scoring the three metrics

You turn each metric into a score. A 1-to-5 scale is common. Example rules:

R: within 30 days = 5, over six months ago = 1
F: 10+ purchases = 5, only once = 1
M: ¥100k+ total = 5, under ¥5k = 1

Set the cutoffs from your own data — for purchase count, sort customers, give the top 20% a 5, the next 20% a 4, and so on. Then read the combination of the three scores:

Example RFM score	Customer state	Read
R5・F5・M5	Recent, frequent, high-spend	Top customer (VIP)
R5・F2・M2	Just started buying	New / nurture candidate
R1・F5・M5	Once loyal, gone quiet	At-risk (needs win-back)
R1・F1・M1	No purchase for a long time	Dormant customer

That combination shows a customer's current state at a glance — the real strength of RFM. Unlike a single average like ARPU, RFM captures customers not as one lump but as state-based groups.

3. The four steps

Collect data — last purchase date, purchase count, total spend per customer, pulled from your cart system (Shopify, BASE, STORES) or order history
Score — turn R, F, M into scores; three levels (high/medium/low) are fine to start, you don't need a 5-point scale on day one
Segment — group by the combination; fine splits give 9–27 groups, but about five (loyal, stable, new, at-risk, dormant) is enough at first
Decide tactics — this is the real work

The caution that took me a while to learn: segmenting is not the goal. A clean split that doesn't lead to action won't move revenue at all. The value shows up only when you decide "what do I do for these people" after sorting.

4. Tactics by segment

The whole point is changing tactics by group:

Top customers (high R, high F, high M): retention first — early-access sales or thank-you perks so they feel valued
At-risk (low R, high F, high M): once loyal, now quiet — win-back coupons or a "we've missed you" message
New / nurture (high R, low F): drive the second purchase — post-purchase follow-up or recommendations
Dormant (low R, low F, low M): reactivation, but keep the budget modest — this group responds weakly

Win-back tactics for at-risk customers are the most cost-effective of the bunch, because retaining existing customers is cheaper than acquiring new ones and contributes more to revenue. To measure the effect, track how each treated group's revenue changes afterward — which is much easier when you have channel- and tactic-level revenue lined up to compare.

5. RFM vs cohort analysis

The method most often confused with RFM is cohort analysis. Both sort customers, but from different angles:

RFM: classifies current customers by recency, frequency, and monetary value. Answers "who gets what."
Cohort: groups customers by when they were acquired (January cohort, February cohort) and tracks repeat rate over time. Answers "when does churn tend to happen."

They aren't opposed — you combine them. In my case, cohort analysis showed churn tended to hit around 60 days after the first order. So I used RFM to pull out customers whose R was starting to slip, and acted before day 60 arrived. That one move recovered a chunk of repeat revenue I'd been quietly losing.

How I check this without rebuilding a report every month

Tying a tactic back to revenue means lining up revenue by channel and tactic — and that's exactly where session-centric tools make you do extra filter work each month. That's the problem I'm working on with RevenueScope — it lines up revenue (RPS and AOV) by channel from actual revenue data, so "did this win-back tactic actually move sales" becomes a number you can read directly instead of a report you rebuild.

When you look at your customers, do you treat them as one average — or sort them by state and act per group?

(Sorry if my English sounds a bit off — Japanese native. I used Google translate.)

I Tracked Revenue Per User for 6 Months — Here's Why ARPU Beats ARPPU for Channel Decisions 2026

toshihiro shishido — Wed, 27 May 2026 06:31:38 +0000

For a while I looked at "average order value" and called it my per-user revenue. It felt close enough. It wasn't — because AOV is per order, not per person, and it hides the fact that most of my users weren't buying at all.

The metric that fixed my thinking was ARPU. This post covers what ARPU actually is, how it differs from ARPPU, and why the denominator matters more than people think.

TL;DR

ARPU = revenue ÷ all users. Non-buyers count. That's the whole point
ARPPU = revenue ÷ paying users only. Always higher than ARPU because the denominator is smaller
ARPU = CVR × ARPPU — so when ARPU is low, you can tell whether it's a conversion problem or a spend-per-buyer problem
Use ARPU for channel investment decisions, ARPPU for unit economics
ARPU benchmarks vary wildly by business type — compare within your quadrant, not across industries

1. What ARPU actually is

ARPU (Average Revenue Per User) divides revenue by total users in a period:

ARPU = Revenue ÷ Total Users

¥3M monthly revenue, 1,000 users → ARPU is ¥3,000. Buyers, window shoppers, free members — everyone is in the denominator. That's what makes it useful: when ARPU drops, you decompose it.

ARPU = CVR × ARPPU

This decomposition tells you whether the problem is "not enough people buying" or "each buyer spending too little." That distinction drives completely different fixes.

2. ARPU vs ARPPU — the denominator is different

ARPPU (Average Revenue Per Paying User) narrows the denominator to paying users only:

ARPPU = Revenue ÷ Paying Users

Same ¥3M revenue, 200 paying users → ARPPU is ¥15,000. That's 5× the ARPU of ¥3,000, and the multiplier is exactly the inverse of CVR (20%). The ARPU = CVR × ARPPU relationship in action.

When to use which:

Channel investment → ARPU: it captures conversion differences between channels
Unit economics → ARPPU: it isolates spend per buyer, better for measuring cross-sell effects
Growth tracking → both: if ARPU rises, was it CVR or ARPPU or both?

One thing that tripped me up: "average order value" (AOV) ≠ ARPPU. AOV is per order; ARPPU is per person. If someone orders twice in a month, they diverge. In my case, one product category had an AOV of ¥8,000 but ARPPU was ¥12,000 because repeat buyers were averaging 1.5 orders per month. I was underestimating the value of that segment until I looked at the per-person number.

The practical rule: use ARPU when you're deciding which channels deserve more budget (it bakes in conversion rate). Use ARPPU when you're working on increasing spend per buyer (cross-sell, bundles, upsell). Use both when you want to understand why overall revenue per user changed.

3. ARPU benchmarks depend on business type

There's no universal "good ARPU." What determines the benchmark is product price, repeat frequency, and monetization model. I've seen ARPU range from ¥200 for a low-ticket accessories store to ¥15,000+ for a subscription cosmetics brand — comparing them directly would be meaningless.

Four patterns:

High price × high repeat (supplements, cosmetics subscriptions): highest ARPU. Subscription LTV drives it
High price × low repeat (electronics, furniture): big per-order but infrequent, so monthly ARPU is moderate
Low price × high repeat (food, daily necessities): small orders add up. Moderate to low ARPU
Low price × low repeat (sundries, accessories): lowest ARPU. CVR improvement is the priority

Borrowing someone else's industry average is a trap. Figure out which quadrant you're in and benchmark against similar types. The only legitimate comparison is between businesses in the same quadrant — a subscription supplement brand benchmarking against a one-off electronics store is comparing apples to furniture.

To raise ARPU, there are only two levers: raise CVR (get more visitors to buy) or raise ARPPU (get each buyer to spend more). Knowing which quadrant you're in tells you which lever has more headroom.

4. Getting ARPU by channel with SQL

If you want to compare ARPU across acquisition channels, you need revenue and user counts per channel. Here's a query that produces ARPU, ARPPU, and CVR in one pass:

WITH channel_stats AS (
  SELECT
    utm_source AS channel,
    COUNT(DISTINCT user_id) AS total_users,
    COUNT(DISTINCT CASE WHEN has_purchase THEN user_id END) AS paying_users,
    SUM(revenue) AS total_revenue
  FROM sessions
  WHERE session_date >= '2026-05-01' AND session_date < '2026-06-01'
  GROUP BY utm_source
)
SELECT
  channel,
  total_revenue / NULLIF(total_users, 0) AS arpu,
  total_revenue / NULLIF(paying_users, 0) AS arppu,
  paying_users::FLOAT / NULLIF(total_users, 0) AS cvr
FROM channel_stats
ORDER BY arpu DESC;

The ARPU = CVR × ARPPU relationship holds in the output. When a channel has low ARPU, you can immediately see whether it's a CVR problem (lots of visitors, few buyers) or an ARPPU problem (buyers aren't spending much). That distinction points you to completely different fixes — acquisition optimization vs. upsell/cross-sell.

5. 3 steps to measure your own ARPU

Step 1: Pull last month's revenue

Start with total revenue from your ecommerce platform or GA4's ecommerce report. If you can break it out by channel, do — the differences show up in the next step.

Step 2: Divide by user count

Divide revenue by total users to get ARPU. Also divide by paying users to get ARPPU alongside it. The gap between the two numbers is your CVR effect. In GA4, "Active users" is the closest metric for the denominator.

Step 3: Decompose with ARPU = CVR × ARPPU

Identify whether the bottleneck is low CVR or low ARPPU. If you run this per channel (using the SQL above or your analytics tool), you'll see which channels convert revenue effectively and which ones just bring traffic.

6. Why this is hard to see in GA4

GA4 is session-centric. Ecommerce purchase amounts are available, but to see "how many users came, how many bought, and how much per user" by channel, you need exploration reports with careful filter configuration. Switching between "all users" and "paying users only" adds more filter overhead. And if you want to track ARPU over time by channel, you're rebuilding that exploration report every month. The SQL approach above works if you have the data in a warehouse, but most small ecommerce teams don't have that pipeline set up.

That's the problem I'm working on with RevenueScope — it lines up RPS (revenue per session) and AOV by channel from actual revenue data, so the "is it a CVR problem or a unit economics problem" decomposition becomes straightforward.

When you look at per-user revenue, do you use all users as the base — or just buyers?

(Sorry if my English sounds a bit off — Japanese native. I used Google translate.)

CAC Looks Simple Until You Realize It Means Nothing Without LTV 2026

toshihiro shishido — Tue, 26 May 2026 03:20:04 +0000

For a long time I judged my marketing on one number: how cheap it was to get a conversion. It felt rigorous. It wasn't — because cost per acquisition on its own can't tell you whether a customer was worth acquiring.

This post is the small mental model that fixed that for me: what CAC actually is, how it differs from CPA, and why it only means something when you put LTV next to it.

TL;DR

CAC = total acquisition cost ÷ new customers. Include labor and tools, not just ad spend
CPA is per action, CAC is per customer — and CAC has a wider cost scope
A CAC number alone is meaningless. Read it against LTV at a 3:1 benchmark
CAC tolerance is set by gross margin and repeat rate, not by your industry label
GA4 is session-first, so lining up CAC and LTV by channel is a manual chore

1. What CAC actually is

CAC (customer acquisition cost) is what it costs to win one new customer:

CAC = total acquisition cost ÷ new customers

Spend 1,000,000 yen across ads, marketing labor, and tools in a month, gain 200 new customers, and CAC is 5,000 yen. The part people skip is the cost scope — enter only ad spend and you've basically computed CPA, not CAC. Real CAC includes the labor and tooling behind acquisition.

2. CAC vs CPA

CPA = ad spend ÷ conversions, a per-action metric for ad efficiency. CAC = total cost ÷ new customers, a per-customer metric for business-wide efficiency. Same person converts twice on day one? CPA counts two, CAC counts one customer. Use CPA to tune ads, CAC to decide how much to invest overall.

3. The number is meaningless without LTV

A CAC of 5,000 yen is neither good nor bad until you know what that customer is worth over time.

The common benchmark is LTV ÷ CAC = 3. Below 1x you lose money per customer. Around 3x is healthy. Well above 5x, you might be underspending and leaving growth on the table. This is the part that broke my old "lowest cost per click wins" habit.

4. Tolerance depends on margin and repeat rate

High-margin, high-repeat products (subscription supplements, cosmetics) give a big LTV, so a higher CAC still pays back over reorders. Thin-margin one-off products can't afford much. That's why borrowing someone else's "average CAC" is a trap — derive your tolerance from your own margin and repeat rate.

5. Why this is a chore in GA4

To get CAC right you match each channel's spend, new customers, and their LTV. GA4 is built around sessions and doesn't hold ad spend or customer IDs, so CAC by channel means pulling data from elsewhere and dividing by hand. Distinguishing a cheap-but-one-off channel from an expensive-but-loyal one means wanting CAC and LTV on one screen.

That's the problem I'm building RevenueScope for — it lines up revenue, RPS, and AOV by channel from a revenue-first view, so you can tell which channel's customers keep buying and can therefore afford a higher CAC.

When you judge a channel, do you go by what it costs to acquire — or by what those customers are worth over time?