Forem: toshihiro shishido

GA4's 'Direct / (none)' is mostly measurement loss, not user behavior

toshihiro shishido — Fri, 24 Apr 2026 05:57:06 +0000

When you open GA4 and see "Direct / (none)" sitting at 30%, 40%, sometimes higher — what's the first thought that goes through your head?

For a long time, mine was: "Brand is finally landing. People are coming back directly."

Then I dug in. Almost every time, that interpretation is wrong. Direct / (none) is mostly measurement loss, not user behavior. And once you accept that, the next question stops being "is this good?" and becomes "how much of this can I recover?"

How GA4 actually decides "Direct / (none)"

The Google Analytics docs are explicit about this. A session falls into Direct / (none) when both of the following are true:

Translation: "We have no idea where this user came from."

In a healthy setup, that bucket should be tiny — bookmarks, direct URL typing, email clients that strip referrers. The fact that it's 30% or 40% for so many sites is not a signal of brand strength. It's the size of your measurement blind spot.

The 20% / 40% threshold

The rough heuristic I use when reviewing ad performance dashboards:

If you write "Paid Search ROAS = 400%" in a board deck while Direct / (none) is 45% of sessions, that 400% is almost certainly inflated. A non-trivial chunk of those Paid Search clicks are being mis-classified into Direct, and the channel that did drive the conversion is getting double credit on the rest.

The 5 causes (and 8 of 10 are fixable in-house)

Direct / (none) bloat traces back to two root mechanisms: missing campaign parameters or lost referrer. The five most common patterns, ranked by how often I encounter them:

Missing utm_source — ads, newsletters, LINE messages, QR codes shipped without UTM. Most common by a wide margin.
In-app browser taps — LINE, Instagram, Facebook in-app browsers either don't pass Referer or send a custom value (com.facebook.katana) that GA4 doesn't recognize as a social source.
HTTPS → HTTP downgrade — the W3C Referrer Policy spec deliberately strips Referer on protocol downgrades. If your funnel passes through any HTTP intermediate page, the referrer is gone before it reaches you.
Redirect intermediaries — bit.ly, lin.ee, t.co, internal redirect chains. Server redirects vary by browser, JavaScript redirects almost guarantee referrer loss.
Referrer policy — modern browsers default to strict-origin-when-cross-origin, which only passes the hostname. Stricter sites (no-referrer) pass nothing at all.

Of these five, only the last one (referrer policy on third-party sites) is genuinely outside your control. The other four — missing UTMs, in-app browser handling, protocol downgrades, redirect chains — are all recoverable through your own implementation. That's where the "8 out of 10" framing comes from.

A 10-minute health check

If you read this and want to know where your own site stands, here's the minimum-viable diagnostic:

That last step is where the diagnosis happens. If Direct sessions concentrate on mobile + specific landing pages, you're looking at an in-app browser problem. If they spike at the same time as a campaign launch, you have a UTM gap. If they cluster by country, you're hitting referrer policy variation.

So what?

The thing I find genuinely useful about this framing is that it converts a vague "Direct / (none) is going up" worry into a measurable, recoverable problem. The fix isn't a new tool. It's a habit:

Track Direct / (none) ratio monthly. Annotate the 20% and 40% lines on your dashboard. When it crosses, decompose before you re-baseline anything.

I'd be curious to hear how high Direct / (none) is on the sites you work on, and whether anyone has cracked the in-app browser case more cleanly than "ensure UTMs are set on every share link." Drop a comment — I'll learn from it too.

This post is an English re-edit of an article originally published on RevenueScope. Full Japanese original (with diagnostic flowchart and 5-cause frequency breakdown):

→ GA4の『Direct / (none)』が増える5つの原因と診断・対処

I'm building RevenueScope — a revenue-first analytics layer that sits next to GA4 for eCommerce teams. One of the things it does is automatically re-classify sessions trapped in Direct / (none) back to their probable original channel using domain heuristics. Built because manually fixing this in spreadsheets is a problem nobody should still be doing in 2026.

References

Google Analytics Help — "Default channel group" — 2026-04
W3C — "Referrer Policy" — 2026-04
Google Analytics Help — "[GA4] Direct traffic" — 2026-04

71% of stores have GA4 installed. Only 11% actually use it. Here's what's broken.

toshihiro shishido — Thu, 23 Apr 2026 09:53:01 +0000

If you ask a Japanese marketer "have you installed GA4?", most will say yes. A 2022 survey of 1,009 web marketing professionals in Japan found 71% already had GA4 installed[1] — and that was before Universal Analytics sunset.

If you ask the same people a follow-up question — "have you set up report automation in GA4?" — the answer drops to 11%[2].

One country. One tool. A 60-point gap between "installed" and "actually using."

This post walks through what Japanese market surveys tell us about that gap, why it exists, and what it implies for anyone shipping analytics tooling — not just in Japan. Because the pattern here isn't a Japan-specific quirk. It's the default state of any organization that treats "install GA4" as the finish line.

TL;DR

GA4 adoption in Japan: 71%. Report automation: 11%. Full-custom setup: 23%.
50.7% of marketers in a 2024 Japanese survey cite "how to actually use the data" as their biggest pain point — above setup, above integrations.
The gap between "installed" and "used" is not a training problem. It's a dashboard-shape problem: the question marketers need to answer and the screen GA4 shows them are not the same shape.

1. The gap nobody talks about

Most "is GA4 popular in your country?" conversations end at installation rate. Which is fine as a vanity number, and useless as a planning number.

Here is what the full staircase looks like in Japan, pulled from three independent surveys:

Stage	Metric	Share
Installation	"GA4 is installed"	71% (2022, Digipro)[1]
Basic setup	Account + tag deployment completed	31–35% (2023, Auriz)[2]
Custom setup	Custom conversions / events configured	23% (2023, Auriz)[2]
Full utilization	Report automation reached	11% (2023, Auriz)[2]
Experience	"I find it hard to figure out how to actually use the data"	50.7% (2024, Fujifilm BI)[3]

The drop from 71% to 11% is the entire story. Installation is the easy step — it's a tag, it's a prop, it's a migration guide.

Everything downstream — custom events, cohort analysis, report automation — requires answering a question the tool does not ask for you: what exactly do you want to know every morning?

Most organizations never answer that question, so the tool sits at 11%.

2. What the data shows

Market context

Before the "how is GA4 being used" part, the scale worth knowing:

Japan's B2C eCommerce market hit ¥26.1 trillion (~US$170B) in 2024, up 5.1% YoY, per METI's 2024 eCommerce Market Survey[4]. The physical-goods slice alone is ¥15.2 trillion. That's the surface area where GA4 setup quality directly translates to revenue decisions.

The Auriz survey (2023, n=248)

Auriz surveyed 248 marketing professionals actively running ad operations in Japan. They asked: "Which GA4 setup steps have you completed?" (multiple choice)[2]

Setup step	Completion rate
Created account	35%
Installed GA4 tag	31%
Configured custom conversions	23%
Set up report automation	11%

Only 25% had actually completed migration from UA. 28% were mid-migration. 29% had not started. 6% had stopped using Google Analytics entirely.

So within this sample, less than a quarter were fully migrated — and within that quarter, less than half had configured report automation. Roughly 1 in 10 of the entire surveyed population had reached the point where GA4 is producing automated output daily.

The Fujifilm BI survey (2024, n=535)

A year later, Fujifilm Business Innovation surveyed 535 marketing professionals on what they felt hard about access-analytics tools (not just GA4, but GA4 is the dominant tool in the sample)[3]:

Pain point	Share citing it
How to optimally use the data	50.7%
Linking data to goals and KPIs	49.7%
Deciding what to focus on	46.0%
Setup for accurate data collection	40.2%
Integration with external tools	30.8%

Two things to notice:

The top three pain points are all about interpretation, not collection. "Setup" only shows up at rank 4.
Asked what support they need, respondents ranked "data analysis and interpretation" (55.9%) and "translating analysis into action plans" (48.2%) at the top[3].

The problem isn't that the tool is broken. The problem is that the tool answers the wrong question.

The Digipro survey (2022, n=1,009)

The Digipro study established the 71% installation baseline back in 2022[1]. The sample was larger and less filtered-for-seniority than the Auriz one, which is why its installation rate is higher than Auriz's "migration complete" rate — the two are measuring different states (installed vs. fully migrated + configured).

3. Why this gap exists

Three reasons I keep seeing, in roughly decreasing order of scale.

Reason 1: GA4 is shaped for sessions, but business is shaped for revenue

GA4's default home screen leads with users, sessions, events, engagement rate. A business owner's default question is: "I spent ¥50,000 on Instagram ads yesterday. How much of that came back as revenue, and which campaigns?"

Answering that in GA4 requires building an exploration, joining event data with transaction data, and configuring channel grouping. It's possible, it just isn't the path of least resistance.

So people install GA4, see that the home screen doesn't answer their actual question, and... never come back to finish the setup. Installation rate 71%, utilization rate 11%.

Reason 2: The "11% who automate" are the ones who had someone to delegate to

Report automation in GA4 is not a one-click feature. It's a multi-step configuration: exploration templates, scheduled email, BigQuery export, Looker Studio wiring, or custom dashboard work.

Every one of those steps requires either (a) a dedicated analytics role, or (b) an external consultant. Organizations without either stop at the "I can load the default Home screen" level.

The 11% figure is less about skill and more about whether the organization has budget headroom for an analytics function at all. In a survey skewed toward SMB eCommerce operators, that headroom is rare.

Reason 3: Training content optimizes for the install stage

If you search "GA4 setup tutorial" in any language, you will find an enormous volume of material about tag deployment, migration, property creation. You will find dramatically less on "what is the weekly dashboard a store owner should build and look at every Monday."

The content market is shaped the same way installation is: rewards for the easy step, silence at the hard step. So marketers graduate from tutorials feeling confident about setup and no more confident about use.

4. What to actually do

Three things. Ordered by effort.

1. Pick one question, before you open GA4

Write down the single question your team needs answered every Monday morning. Make it concrete: "Which channel drove the most revenue last week at what AOV?" beats "How is our marketing doing?"

Now: can you answer that question in GA4 in under 60 seconds, starting from a cold login? If no, the gap isn't skill — it's configuration. Configure toward that question. Ignore the other 40 reports.

2. Instrument revenue-side events before you perfect pageview events

Most GA4 implementations spend 80% of setup budget on pageview, scroll depth, and engagement events. They spend 20% on purchase, add_to_cart, begin_checkout.

This is backwards for eCommerce. The revenue-side events are the ones that answer the question you actually asked in step 1. If purchase events are not firing cleanly with value, transaction_id, and items, no amount of downstream setup will produce a useful Monday dashboard.

3. Decide if GA4 is your reporting surface, or your raw data layer

This is the hard one.

If GA4 is your reporting surface — where decision-makers read numbers — you are signing up for the "build 3-5 custom explorations + a Looker Studio dashboard" project. That's real work. Budget for it.

If GA4 is your raw data layer — where events are collected and then read by something else — then accept that, and point that something else (BigQuery, a reverse-ETL tool, a specialized analytics product, or an internal dashboard) at GA4 output. Stop trying to read GA4 directly.

Most of the "11% gap" organizations I've talked to are stuck because they're trying to do both with the same tool and the same setup budget. Picking one lane unsticks the configuration.

So what?

The gap between "71% installed" and "11% automated" is not going to close by writing better GA4 tutorials. Every additional tutorial optimizes for the step that isn't the bottleneck.

It closes by one of two things:

Organizations decide GA4 is worth a dedicated analytics role and invest accordingly (slow, expensive, uncommon outside larger companies)
Something else takes the specific "read revenue by channel on Monday morning" job off GA4's plate, so GA4 can be the raw data layer it's actually good at being (faster, cheaper, increasingly common)

If you're shipping analytics tooling in 2026: the question isn't "how do we replace GA4." The question is "which slice of 'use GA4 data' can we make so trivial that the 11% figure becomes 50% for our specific use case."

That's the gap worth working on.

I'd love to hear from folks outside Japan: does the 71% / 11% pattern match what you see in your market? Or is there a country / vertical where the utilization curve actually bends upward? Drop it in the comments.

I'm building RevenueScope, a revenue-first analytics layer that sits next to GA4 and answers the "which channel drove revenue last week at what AOV" question from one dashboard — for the 89% of organizations not going to build that surface themselves.

This post originally appeared in Japanese on the RevenueScope blog. Canonical source is set accordingly.

References

Hagakure (Digipro) — "GA4 Adoption Survey," July 2022 (n=1,009)
Auriz — "Google Analytics 4 Utilization Survey," October 2023 (n=248)
Fujifilm Business Innovation — "Access Analytics Tool Usage Survey," December 2024 (n=535)
METI Japan — "FY2024 Electronic Commerce Market Survey," August 2025

The utm_source you should NOT use for Meta Ads (and why GA4 makes it disappear)

toshihiro shishido — Wed, 22 Apr 2026 22:14:17 +0000

A lot of marketers — myself included, at first — tag their Meta (Facebook / Instagram) ad URLs with utm_source=meta. It feels natural: the company is called Meta now, right?

But if you open Google's officially distributed GA4 Default Channel Group Source Categories spreadsheet and search through all 819 entries, you'll find something strange:

facebook is there
fb is there
facebook.com is there
instagram is there
meta is not

That one missing line isn't a trivia item. It's the difference between Meta ad revenue showing up in your Paid Social channel versus quietly falling into Referral or (other).

This post is a practical, receipts-first walkthrough of what GA4 actually checks, why meta breaks classification, and the URL format I'd recommend fixing on going forward. No opinion — just the file Google itself publishes.

TL;DR

Set utm_source=facebook (lowercase, fixed). Not meta, not Facebook, not fb.
Set utm_medium=cpc. GA4's Paid Social regex matches on .*cp.*|ppc|retargeting|paid.*. cpc is the safest pick.
The 80% of bad-data incidents I see are casing and variant drift: facebook / Facebook / fb / meta splitting one campaign across four rows.

1. What GA4 actually checks when deciding "Paid Social"

Per Google's public documentation on default channel groups[1], the Paid Social classification requires both of these to be true (for manual UTM tagging):

Source matches a regex list of social sites
Medium matches the regex ^(.*cp.*|ppc|retargeting|paid.*)$

That "regex list of social sites" isn't a mystery. Google actually publishes it as a downloadable spreadsheet[2]. It's an 819-row file mapping source strings to categories like SOURCE_CATEGORY_SOCIAL, SOURCE_CATEGORY_SEARCH, and so on.

Here's what it contains for the major Meta-related entries:

utm_source value	Official classification	Counts as Paid Social?
`facebook`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`facebook.com`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`fb`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`m.facebook.com`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`instagram`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`instagram.com`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`l.instagram.com`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`twitter`	`SOURCE_CATEGORY_SOCIAL`	✅ Yes
`meta`	Not in the file	❌ No
`Meta`	Not in the file	❌ No

meta as a string does not appear anywhere in Google's classification file. Traffic tagged utm_source=meta is evaluated against the social list, misses every entry, and falls through to Referral or (other).

"But the company rebranded to Meta" — true, and completely irrelevant to the classification engine. Google Analytics did not update its source file when the corporate rebrand happened. The file still references the long-standing industry-standard string facebook.

Brand names and classification tokens are independent layers. Confusing them costs money.

2. Four failure modes I keep seeing

Failure 1: `utm_source=meta` silently erases Paid Social

Since meta doesn't match the social list, these sessions land in Referral with source/medium meta / cpc. From the monthly report you'll see "Paid Social revenue dropped." Nothing dropped. The classification box moved.

Failure 2: Case sensitivity splits one campaign into two rows

GA4 stores utm_source values case-sensitively. facebook and Facebook are two distinct dimension values and two distinct rows in your report. One campaign, two boxes, each showing half the revenue.

Failure 3: `utm_medium=social` promotes paid traffic to Organic Social

GA4's Organic Social rule[1] is: Source matches social list OR Medium is one of social | social-network | social-media | sm. That's an OR. If you use utm_source=facebook with utm_medium=social, the medium matches Organic Social before the logic ever reaches "but wait, this is paid." Your paid budget gets counted as organic, and ROAS looks worse than reality.

Failure 4: Dynamic parameter macros confirmed late

Meta's own [URL Dynamic Parameter feature][3] lets you embed macros like {{campaign.name}} / {{adset.name}} / {{ad.name}} in destination URLs, resolved at delivery time. Useful, but: at insertion time the preview still shows the raw macros, so skipping the post-launch GA4 check means you only discover empty utm_campaign values or unexpected characters (spaces, Japanese text, uppercase) once real money has shipped.

3. The URL format I'd fix on

Given the constraints above, this is what I tag Meta ads with:

utm_source=facebook
utm_medium=cpc
utm_campaign={{campaign.name}}
utm_content={{ad.name}}
utm_term={{adset.name}}
utm_id={{campaign.id}}

Why each value

utm_source=facebook — matches SOURCE_CATEGORY_SOCIAL in GA4's file, lowercase for casing stability, the industry-canonical value. fb works too (same category), but pick one and stop the drift
utm_medium=cpc — matches Paid Social's regex, does not collide with Organic Social's social* list. Safest minimum overlap
utm_campaign={{campaign.name}} — delivered-time substitution; verify values populate correctly once campaigns are live
utm_content={{ad.name}} / utm_term={{adset.name}} — gives you ad-level and ad-set-level drill-down inside GA4's campaign dimension, without needing custom dimensions

"What about Instagram-only?"

If you want Instagram campaigns to appear as their own row, switch utm_source from facebook to instagram. This is a reporting trade-off: you gain Instagram visibility, you lose the "all Meta ad revenue in one row" view. The cleaner pattern: keep utm_source=facebook (platform-level) and put placement detail in a separate placement={{placement}} custom-dimension — your Meta vs Instagram split survives even when campaign naming changes.

4. Verifying after you ship

Two checks that catch 90% of breakage:

Pre-launch URL preview — in Meta Ads Manager, check the URL preview panel on the ad edit screen. Confirm macros resolve to expected values and no unexpected whitespace / CJK / uppercase slipped in
Post-launch GA4 realtime — within 30 minutes of first impression, check Realtime → Traffic source (or classic Acquisition). You should see facebook / cpc. If you see meta / cpc or (direct) / (none), the URL didn't deliver what you expected

Skipping these two is the single biggest reason "our attribution looks weird this month" reports exist.

5. One-time cleanup check (10 minutes)

If you inherited a GA4 property and don't know what's been tagged, this is a fast audit:

GA4 → Reports → Acquisition → Traffic acquisition
Switch dimension to Session source / medium
Search for facebook
If you see multiple rows among facebook / Facebook / fb / meta — your campaigns are fragmented
Standardize going forward, and (if your stack allows) normalize historical data downstream

If meta / cpc exists as an independent row with meaningful volume, your Paid Social number is currently understated by exactly that amount.

Closing

The "correct" utm_source for Meta ads isn't a matter of opinion, agency convention, or vendor recommendation. It's whatever Google's classification file says it is — and Google publishes that file.

Opening an 819-row spreadsheet and searching for meta is maybe three minutes of work. It's strange how often the answer to a recurring "which is right?" argument is sitting in a publicly downloadable CSV.

I'm building RevenueScope, a revenue-first analytics layer that sits next to GA4 and normalizes UTM drift (e.g. auto-merges facebook / Facebook / fb / meta into one Paid Social row) so you can read channel-level revenue, AOV, and RPS from a single dashboard.

This post originally appeared in Japanese on the RevenueScope blog. Canonical source link is set accordingly.

References

Google Analytics Help — Default channel group
Google — GA4 Default Channel Group Source Categories (official downloadable spreadsheet, linked from [1])
Meta Business Help Center — URL Dynamic Parameters specification

Forem: toshihiro shishido

GA4's 'Direct / (none)' is mostly measurement loss, not user behavior

How GA4 actually decides "Direct / (none)"

The 20% / 40% threshold

The 5 causes (and 8 of 10 are fixable in-house)

A 10-minute health check

So what?

References

71% of stores have GA4 installed. Only 11% actually use it. Here's what's broken.

TL;DR

1. The gap nobody talks about

2. What the data shows

Market context

The Auriz survey (2023, n=248)

The Fujifilm BI survey (2024, n=535)

The Digipro survey (2022, n=1,009)

3. Why this gap exists

Reason 1: GA4 is shaped for sessions, but business is shaped for revenue

Reason 2: The "11% who automate" are the ones who had someone to delegate to

Reason 3: Training content optimizes for the install stage

4. What to actually do

1. Pick one question, before you open GA4

2. Instrument revenue-side events before you perfect pageview events

3. Decide if GA4 is your reporting surface, or your raw data layer

So what?

References

The utm_source you should NOT use for Meta Ads (and why GA4 makes it disappear)

TL;DR

1. What GA4 actually checks when deciding "Paid Social"

2. Four failure modes I keep seeing

Failure 1: utm_source=meta silently erases Paid Social

Failure 2: Case sensitivity splits one campaign into two rows

Failure 3: utm_medium=social promotes paid traffic to Organic Social

Failure 4: Dynamic parameter macros confirmed late

3. The URL format I'd fix on

Why each value

"What about Instagram-only?"

4. Verifying after you ship

5. One-time cleanup check (10 minutes)

Closing

References

Failure 1: `utm_source=meta` silently erases Paid Social

Failure 3: `utm_medium=social` promotes paid traffic to Organic Social