Direct is near the top of your GA4 report, and you're trying to work out which marketing activity brought those visitors in. The row gives you a session count. It gives you very little explanation.
I see this a lot in the accounts I've worked on. Some visitors will have typed your address or used a bookmark. Others will have followed a link that arrived without enough information for GA4 to identify its source. Both can appear as (direct) / (none).
A high percentage is a reason to investigate, especially when it changes suddenly. There's no universal cutoff that tells you the implementation is broken. The useful question is whether the links you control carry the information you expect.
First, get the report straight
Open Traffic acquisition and use Session source / medium, or Session default channel group to compare channels.
Keep the date range and dimension consistent, and compare the number of Direct sessions as well as the percentage. Direct's share can rise because traffic from another channel has fallen, even if the Direct count stays the same.
First user source / medium describes the first acquisition of the user GA4 recognizes, rather than the source assigned to each later session. Google's guide to traffic-source scopes explains the distinction.
GA4 also uses earlier source information when assigning credit. Someone who returns through a bookmark may still have their session attributed to an earlier known source. The report reflects those rules as well as the information arriving with the visit.
Keep key-event attribution separate, too. An earlier recorded non-direct interaction can still receive credit for a key event when someone returns directly. The Direct session total won't tell you how much conversion credit a channel has lost.
Follow a newsletter link
I keep running into this one: a newsletter goes out, people click, and the links have no campaign tags.
An email click may bring little useful referrer information. UTM parameters put the campaign details into the destination URL, giving GA4 another way to identify where the visit came from. A newsletter link could look like this:
https://datamentari.com/insights/why-ga4-direct-traffic-is-high/?utm_source=newsletter&utm_medium=email&utm_campaign=analytics_tips
Here, newsletter identifies the source, email describes the medium, and analytics_tips names the campaign. Agree on a naming convention and use it consistently. GA4 treats Newsletter and newsletter as different values, so a small change in capitalization can split your reporting. Google's campaign URL guide is a useful reference.
Apply that convention to external marketing links in emails, social posts, QR codes and downloadable documents. For Google Ads and other integrated advertising platforms, review the integration and auto-tagging before adding or replacing manual tags.
Keep acquisition UTMs off ordinary links within your own site. If you want to measure a homepage banner or internal promotion, use an event. That lets you record the interaction without introducing a new campaign label halfway through the visit.
See what survives the redirects
A correctly tagged link can still lose its campaign information before the page loads. I've seen a shortener strip the query parameters from a campaign URL. The page loaded normally, so nobody noticed what had gone missing.
Follow the route your reader takes: the email's click-tracking link, any shortener, the redirects and the final page. The parameters need to survive until the analytics tag reads the URL. Looking at the original link alone won't tell you whether they reached it.
The referrer takes a separate route through the browser's rules. Under the common default policy, an HTTPS-to-HTTP downgrade suppresses it. A normal cross-site HTTPS link usually retains the referring website's origin, even when the browser leaves out the full page path.
An old HTTP destination or a redirect that drops the query string gives you a specific fault to fix and retest. Judge the fix on that journey, without guessing which channel owns the rest of Direct.
A shared link may tell only part of the story
Someone reads your article and sends it to a colleague through a messaging app. Their colleague opens it in the app's browser, or switches to another browser. That route may deliver little or no useful referrer information to your site.
Behaviour varies by app, device and browser handoff, so test the actual route your audience uses.
Campaign tags bring another complication. If someone copies a tagged newsletter link into a group chat, the next visitor may arrive with the original newsletter tags. GA4 can identify the tagged link; it has no record of the conversation that passed it along.
Browser privacy can change what you measure
Safari and other browsers can limit how long identifiers remain available. When an identifier is lost, GA4 may struggle to connect a returning visitor with their earlier activity. Our guide to cookies in GA4 explains the storage rules and their conditions.
A new visit can still bring a valid email tag or search referrer. GA4 can use that information even when the connection to the earlier visit has gone.
Other privacy controls block collection altogether. In that case, there may be no observed GA4 session to put in any channel. Consent settings also affect collection: basic consent mode can keep Google tags blocked when consent isn't granted, while advanced mode can send cookieless measurements.
Include both consent choices in your testing and compare the result with how your implementation is meant to behave. Respect the visitor's choice throughout. Reducing Direct isn't a reason to collect data you shouldn't collect.
Where server-side tracking fits
Server-side tagging gives you more control over how collected data is processed and where it goes. It still needs the campaign information to arrive in the first place. Moving an event through a server can't supply the missing campaign name from an untagged link, and browser restrictions can also apply to some server-set cookies.
For a lead-generation site, capturing first-touch and latest-touch campaign fields can add useful context to a CRM record. Those fields describe the touches you captured. Keep that historical context distinct from a new acquisition signal in GA4; sending an old campaign value as though it describes a new campaign interaction can distort reporting.
Start by fixing broken links and collection errors. Then assess server-side work against a specific remaining measurement problem and its cost. Our server-side tracking explainer covers that decision in more detail.
Give the next test a clear result
Choose one active campaign and open its real link from the email or app. Use a clean test browser profile when checking a new campaign session. An existing session can confuse the result, and another tagged click alone won't start a new one.
Follow the redirects, then use Tag Assistant and GA4 DebugView to inspect what your implementation sends where collection is permitted. Look at the first page event's page_location and page_referrer values. They show the page URL and referring URL that help GA4 identify the source.
Then allow 24–48 hours for GA4 processing and check the acquisition report. Confirm both that the event arrived and that the reported source makes sense.
Use what you find to decide where to look next:
- If campaign parameters disappear before collection, fix that part of the link route and repeat the test.
- If no event arrives when collection should be allowed, investigate consent handling, blockers or the tag itself.
- If the event carries the expected information but the processed report surprises you, review the session context, reporting dimension and attribution rules.
A Direct spike after an email send, a concentration on one browser, or traffic landing on a long URL can help you choose the next journey to test. These are clues. People can bookmark any page, and timing alone can't establish where a session came from.
For a wider review, use our quick GA4 setup check. For this investigation, finish with one documented journey: the link clicked, the information that reached GA4, the reported source and any change you made. Repeat it after the fix, then compare equivalent reporting periods. That gives you evidence about what improved and a way to explain the gaps that remain.