What is Direct Traffic in Google Analytics 4 and How to Fix it

Updated: March 28th, 2025

Direct traffic in Google Analytics is often misunderstood. If you think direct traffic only captures when visitors have typed your website in the address bar or accessed it through a saved bookmark, I’ve got some bad news. The truth is, this is just a fraction of what makes up direct traffic.

The confusion starts with the name itself – “direct.” What does this really mean? In reality, the definition of direct traffic should be, “I don’t actually know where this traffic came from *shrug*.”

It could be directly from the address bar and bookmarks, or it could be from chat/messenger, or an email with errors in the UTM parameters, or any other number of reasons.

That said, labeling this traffic as “unknown” would make more sense, but that’s a discussion for another day.

Given the many reasons that direct traffic can appear in your data, this article will address how to reduce direct traffic in Google Analytics 4. Also, I will touch on some things you have no control over and will just have to accept.

Table of Contents

Here’s what you will learn in this article

• A quick overview of Direct traffic
• “But direct traffic shows that our branding efforts are solid.”
• Where can I find direct traffic in GA4?
  • Method 1: Built-in reports
  • Method 2: Customized report
  • Method 3: Build an exploration
• How to reduce direct traffic in Google Analytics 4
  • #1. Redirects between HTTP and HTTPS
  • #2. Your cookie consent solution is losing the traffic source
  • #3. UTMs with errors
  • #4. Affiliate links with no referrer info or UTMs
  • #5. URL shorteners can lose the referrer
  • #6. Links in non-web documents are missing UTMs
  • #7. UTMs are not properly adopted company-wide
  • #8. Fake traffic from bots
  • #9. Not all pages of the website have Google Analytics 4 code (or GTM)
  • #10. Cookie Restrictions
  • #11. Did you rebrand recently and change the domain?
  • #12. Incorrectly configured cross-domain tracking
  • #13. Check the Landing Pages report in GA for one more time
  • #14. Android apps
  • #15. If possible, ask not to include the noreferrer in backlinks
  • #16. Server-redirects or meta refresh redirect
  • #17. JavaScript redirects
  • #18. User ID set in the middle of the session
  • #19. Processing errors in GA4
  • #20. ignore_referrer
• Things you need to accept
  • #1. Some websites don’t send the referrer data
  • #2. Chats and messengers usually do not send the referrer
  • #3. Visitors might use browser plugins that affect the referrer
  • #4. People can actually enter the address in the address bar
• Final Words

A quick overview of Direct traffic

Several things help Google Analytics determine where a visitor was before coming to your site:

• UTM parameters in the URL, like utm_source, utm_medium, utm_campaign, etc.
• The referrer, a.k.a. The URL of the previous page (privacy-related limitations reduce the reliability of the referrer)
• gclid and other similar parameters that indicate that a visitor has come from paid advertising campaigns
• The traffic source is overwritten on the code/tag level

If none of the above information returns meaningful values, Google Analytics 4 will attribute the traffic to (direct). It’s like the miscellaneous drawer everyone has in their home to store things that don’t have a place elsewhere.

Can you see how the name direct is confusing here? Realistically, it just means that a traffic source is unknown.

“But direct traffic shows that our branding efforts are solid.”

If 40% of your traffic appears as direct and you have attributed this to strong branding, here’s a reality check: Unless you’re a widely recognized brand, it’s likely that this direct traffic is influenced more by the limitation of web tracking (or poor configuration) rather than people looking directly for your brand.

Unfortunately, I cannot prove that. Actually, I don’t think anyone can prove what kind of direct traffic comes to your website. Maybe your branding IS strong, and you get a lot of direct visitors. Maybe it isn’t. And from what I have seen, I always bet on the latter.

Why? Because eventually, GTM/GA audits uncover a lot of technical problems.

Direct traffic is a black box. Nobody can prove what goes on inside of it. If someone can, I’d like to meet them and learn.

Instead of ranting about all of this, I would like to go to the more practical part of this guide: the reasons why you get Direct traffic in Google Analytics 4 and how to deal with that (if possible).

You can check and implement all of these list items in your setup. Hopefully, that will reduce some of your direct traffic and attribute those sessions to other traffic sources.

Also, I will mention several reasons that you have no control over. Consider them as “gotchas”.

I am pretty sure that more items could be added to the list. If you believe something is missing, let me know in the comments, and I’ll update the list.

Where can I find direct traffic in GA4?

If you haven’t thought too much about your traffic sources, you may be curious about how much of your traffic comes from this elusive “direct” value. There are a few methods for how to get direct traffic data in Google Analytics 4.

Method 1: Built-in reports

The quickest way is to head to the Acquisition reports in Google Analytics 4, specifically the Traffic Acquisition report. Since GA4 is customizable, your property may not look the same as mine, so the location of this report may be elsewhere.

You can also add this report collection to your reports tab if you don’t have it by going to the Library and publishing the “Life cycle” collection.

In the report, click “Add filter” at the top. Set the Session default channel group to exactly match “Direct” to filter out all other traffic sources.

Now, you will only see the direct traffic source in the report!

Method 2: Customized report

If this is data that you often check and want to be able to reference easily, then you can customize the built-in report. This option will require you to have editor or admin access to the GA4 property.

Essentially, you will create a copy of the Traffic Acquisition report with some modifications.

Begin by clicking the pencil icon in the top right corner of the report.

Under the Report Filter section, click “Add filter.” Here, you can use the “Session default channel group” dimension and filter by the “Direct” value.

You can customize the report by adding or removing dimensions and metrics and setting a different default dimension.

Once you’re satisfied with your customized report, you can save it. I would suggest saving it as a new report so you don’t overwrite the existing report (which you might use for other purposes).

To add this new report to your Acquisition folder, go to the Library in the Reports tab.

Under the Life cycle collection (or wherever you have your Acquisition reports stored), click “Edit collection.”

Search for your created report and then drag it into the Acquisition topic.

Don’t forget to save the changes. Now, you can access your customized report alongside the other built-in Google Analytics 4 reports!

Method 3: Build an exploration

Lastly, if you want more freedom over how you present the direct traffic data, you can build a free-form exploration. Start by creating a new blank report in the Explore section of GA4.

Here, you can add whichever dimensions and metrics will provide the most insightful analytics.

For example, you can start by adding either the Session default channel group or the Session source for the dimensions and Sessions and (Active or Total) users for the metrics.

You will need to filter the report to ensure that only direct traffic data is included, which you can do the same way as the two methods above by filtering on the session default channel group that exactly matches “Direct.”

Add the dimensions and metrics to the report to explore the direct traffic data.

How to reduce direct traffic in Google Analytics

Let’s start by addressing some factors contributing to direct traffic that you can do something about. Near the end of the guide, I will also touch on some things you just have to accept as a given.

So, first up – let’s dive into how you can reduce direct traffic in Google Analytics 4. Just a heads up, this may involve a lot of digging and auditing from your side.

#1. Your website is on HTTP, and there are redirects from websites with HTTPS

As I have mentioned in one of the previous chapters of this guide, the referrer is one of the parameters that Google Analytics uses to determine the traffic source.

If another website contains a backlink to your site AND that site has HTTPS in the URL (while your site is on HTTP), the browser will not pass the referrer because of security protocols.

So, your direct traffic numbers are affected if your website is still not using SSL (meaning that your site’s address still contains http:// instead of https://).

If you don’t know how to add SSL, find a developer to do it for you. Really, I mean it. Please do it. It’s 2024.

However, keep one more thing in mind. Imagine a 3rd party website that contains a link to your site (https://www.3rdpartysite.com). That website is using https:// in the URL. Their backlink to your site contains http://, but you have just migrated to the https version (the link is outdated).

If a visitor clicks your link on https://www.3rdpartysite.com, is redirected to http://www.yoursite.com and is then redirected to https://www.yoursite.com, the browser will not collect the referrer. That is because the redirect in the middle is without https.

This might require more communication from your site to update that backlink from http to https.

If you are still on http, the more you delay the migration, the more significant the consequences of “http” backlinks you will have.

#2. Your cookie consent solution is losing the traffic source

If you have implemented a cookie-consent banner on your website because of GDPR or some other privacy regulation AND a visitor consents on the 2nd (or subsequent) pageview, Google Analytics 4 will treat that session as a (direct).

Why? The traffic source is available only on the landing page (if we are talking about regular websites, not single-page applications) and you haven’t implemented any hacks to circumvent this.

Here’s a situation: A visitor lands on your site (the URL might contain UTM parameters, or the referrer of the previous website is available). Once the visitor goes to the next page, the URL changes, so the UTM parameters vanish, and the referrer will be the URL of the landing page (because that is the previous page). GA4 will treat this as a self-referral, labelling the traffic source as (direct).

So, in which situations might this happen?

• Your cookie consent popup/bar is not eye-catchy, and the visitor just ignores it, thus continues browsing (and then you lose your traffic source)
• I have also seen some poorly implemented solutions where the site redirects a visitor (immediately after providing consent) to another page. Hence, the referrer/other parameters are also lost.

What to do in this case? First, just to protect myself, I will post the usual “I am not a lawyer; you should discuss this with your legal department” disclaimer. Alright, now we can continue.

I would suggest that:

• Your cookie consent popup/bar should not redirect visitors anywhere after providing consent. Just let them browse further and fire your tracking codes accordingly.
• Your cookie consent popup must be visible and get all the attention once the visitor lands on a site (e.g., a popup that blocks the website content). The visitor should make their choice right away – to accept or decline. Your goal is to get that choice on the first pageview.

#3. UTMs with errors

UTM parameters are additional pieces of information that you can add to links to your site. Usually, one would use UTM parameters in email marketing, social media posts, paid advertising, custom channels (like ebooks), etc.

So, where is the problem? Quite often, I see typos or just a poor configuration in GA4 reports.

If the visitor lands on your website and the referrer’s value is empty, but the URL contains UTM parameters, Google Analytics 4 will attribute that session to the traffic source described in those UTMs. But if UTMs are incorrect (I mean, they are formatted incorrectly), GA4 will attribute that session to (direct).

To have your UTMs work correctly, you must properly format them:

• Add UTM parameters in the URL after the question mark (while it is possible to use UTMs after the #, I suggest you don’t). Example: mysite.com?utm_medium=social&utm_source=twitter.com
• Separate the different parameters with an ampersand (&)
• UTM parameter names must be exactly like this:
  • utm_medium
  • utm_source
  • utm_campaign
  • utm_term
  • utm_content
  • Other variations (like utmMedium, etc.) will not work.

You can check if there are incorrectly formatted UTM parameters in your links by creating a free-form exploration.

In the dimensions, add the Session default channel group and the Page location, and for the metrics, add (Active or Total) Users.

This report aims to see which URLs contain UTM parameters but are being captured within direct traffic. In your filter, you should set the Page location to contain “utm”, and the Session default channel group exactly matches “Direct”.

Using the GA4 – Google Merch Shop data, I found an example where a URL’s UTM parameters are incorrect. Where a “?” should denote the start of query parameters, there is an ampersand (&), so GA4 is not capturing the UTMs properly.

What should you do if you find these types of problems? You are going to play detective to determine which people on your team are incorrectly implementing UTM parameters and implement some proper conventions (see #7 below).

Other things to search in that very same report (but not limited to):

• medium
• source
• #

You get the idea!

#4. Affiliate links with no referrer info or UTMs

Is your business running an affiliate program? If yes, chances are that some of your affiliate links are coming in as direct traffic if you’re not using UTM parameters.

To check, go to the Reports tab in GA4 and locate the “Landing Page” report (if you have the Life cycle collection, it is under “Engagement”).

This report uses the “Landing page” dimension (not “Landing page + query string”), so the affiliate ID will not be displayed (since the affiliate ID is tracked as a query parameter).

You can easily customize the report by clicking on the pencil icon in the top right and adding “Landing page + query string” as the default dimension.

Save the report. If having the query parameters is more helpful than not, you might want to save them to the existing report or just have them as a separate report in your repertoire.

In the search bar of the report, enter your affiliate ID parameter (e.g. affiliate_id, aID, addID, etc.). The report will return a list of landing pages that contain the affiliate_id parameter.

At the top of the report, click “Add filter,” and filter by Session source/medium contains “(direct)”.

Add in Session source/medium as a secondary dimension. The result is a list of all your affiliate sessions treated as (direct) in Google Analytics 4.

The best way to avoid this situation is to contact the people or companies with affiliate links and provide them with links containing UTM parameters.

It has already been mentioned (and will be mentioned more), but how you set these parameters up is important to ensure success. One suggestion for UTMs is:

• utm_source=[brand or company]
  • E.g. utm_source=analyticsmania
• utm_medium=affiliate
• utm_campaign=[name of what is being promoted]
  • E.g. utm_campaign=spring_sale

At the end of the day, you will be using this data, so make sure it makes sense to you (and that they are correctly formatted).

#5. URL shorteners can lose the referrer

If you use link shorteners, they might lose the referrer, resulting in no traffic source data. Luckily, there is an easy solution – add UTM parameters.

For example, instead of inserting “https://www.mywebsite.com/some-landing-page, “ you could insert “https://www.mywebsite.com/ some-landing-page?utm_medium=……” (replacing the dots with the actual UTM parameters).

That way, the UTM parameters will properly indicate the traffic source to Google Analytics, even if the referrer is unavailable.

I have no quick ways to audit short links; thus, you must review/update them individually in your link shortener platform/app.

#6. Links in non-web documents are missing UTMs

You may not know that the referrer will not be available if you have links to your site in non-web documents (PDF, Word Doc, etc.) and a person clicks any of those links. Ever! Even if you open the PDF with Chrome, there will be no referrer!

It sucks to think of all the traffic that might have been incorrectly attributed to direct traffic, but there is a solution – our trusty UTM parameters.

If you have many documents, like ebooks, already published, and none contain UTMs in the links, you must update them manually. Unfortunately, this will not change any documents that visitors have already downloaded.

If you need some inspiration for naming conversion (see #7), one idea could be:

• utm_medium=pdf
• utm_source=[type of content]
  • E.g. utm_source=ebook, utm_source=size-guide
• utm_campaign=[name of the document]
  • E.g. utm_source=how-to-guide-for-shoe-care

#7. UTMs are not properly adopted company-wide

This tip is more like an extension of the previous UTM-related tips.

UTM parameters offer valuable insights into user navigation, so why are they listed once again as a potential cause of direct traffic? Inconsistent implementation of UTMs within your team can lead to issues.

When multiple people create links, mistakes and inconsistencies in naming conventions or UTM set-up can easily result in inaccurate data, a.k.a direct traffic.

Google Analytics is case-sensitive, so if someone sets up utm_medium=email and someone else sets up utmmedium=email (which is incorrect), these will result in different traffic sources. Utm_medium=email will be reported as email, while utmmedium=email will most likely reported as direct traffic (or sometimes referral).

It is essential to communicate with your team to ensure they constantly include UTM parameters in links in PDFs, emails, social media campaigns, etc. The more you and your team tag links with UTMs, the less (direct) traffic you will see.

But how can you minimize the risk of mistakes?

You can simply create a spreadsheet with naming conventions. Whenever someone wants to generate a link with UTMs, they need to:

• Enter all the UTM parameters in specific cells, and then the sheet will return the URL
• In doing so, they must view the existing UTMs in the list and (at least try) to follow the naming conventions

Check out Annie Cushing’s (Annielytics) spreadsheet if you need some place to start.

Alternatively, you can use a specialized tool for UTM management, like utm.io.

#8. Fake traffic from bots

It may come as a surprise, but it’s likely you’re already getting fake traffic from bots, and this data is coming through in GA4. GA4 automatically implements a non-optional known bot-traffic exclusion to exclude traffic from bots and spiders.

While not all bots are bad or malicious, they still will skew data, which is frustrating. For example, Cookiebot regularly crawls your website (so this will show up in reports). However, you can exclude Cookiebot from Google Analytics 4 data using their known IP addresses.

If you want a more comprehensive solution, you can use a Content Delivery Network (CDN), like Cloudflare, to help reduce bot traffic. This solution aims to prevent bots from landing on your site in the first place (this allows vendors other than GA4 to also benefit from more accurate data).

For an in-house solution, ask your developers to check the server logs to see if any regular spikes in traffic could be attributed to one or several IP addresses that you think are associated with bots. If so, exclude those IP addresses in GA4 or your server-side tagging setup.

#9. Not all pages of your website have Google Analytics 4 (or Google Tag Manager) code

Here’s a situation: a visitor lands on a page of your website from Google. The referrer is “google.com,” so it should be easy to identify the traffic source.

But, for some reason (maybe a human error), the Google Analytics 4 tracking code is not implemented on that landing page. However, when the visitor navigates to the second page, the GA4 code is present.

So, what GA4 considers the first pageview is actually the 2nd pageview for that visitor. The result? The value of the referrer of that page is your own website. This means that GA4 will treat this as a self-referrer, hence the direct session.

How can you prevent this? Audit your website and check that you have implemented GA4 on all pages.

One of the possible options is to use Screaming Frog.

Screaming Frog is a solution that is especially popular among SEO professionals who want to check what’s happening on their clients’ websites. How is it related to GTM or GA4? You could configure it to crawl the entire website and look for particular information (like scripts).

If you have implemented Google Analytics 4 via GTM, you could configure Screaming Frog to keep looking for https://www.googletagmanager.com/gtm.js in the website’s source code (the Google Tag Manager container uses this URL).

In Screaming Frog’s application, go to Configuration > Custom > Custom Search and enter the following condition: Does not contain https://www.googletagmanager.com/gtm.js

Enter the website URL you wish to check and hit the Start button.

That’s it! As the crawl progresses, you’ll be able to see the complete URLs of the pages where your GTM container code is missing. Your next step is (obviously) to add the tracking code to those pages or ask a developer to do that.

And then, of course, make sure that the trigger of your Google tag in Google Tag Manager is All Pages or another condition that fires on all pages.

If you have implemented Google Analytics directly in the website’s source code, use https://www.googletagmanager.com/gtag/js in your audit.

#10. Cookie Restrictions

Apple’s restrictions for first-party cookies keep getting stronger over recent years with ITP.

There are many things that it affects, but the main thing in the context of direct traffic is:

• Cookies set by Google Analytics 4 (or any other analytics/marketing tool) are set to expire in 1-7 days (unless the visitor returns to your site sooner)
• Cookies set on the page when the visitor directly lands from the ad network (e.g. Google Ads or Facebook Ads) are set to expire in 24 hours (unless the visitor continues to browse your site)

So if you acquire a visitor for the first time from Google Search and later that visitor returns after eight (8) days, Google Analytics 4:

• Will treat it as a new user
• Give the current traffic source priority. If the current traffic source of that repeat session is direct, it will be reported as direct in GA4, too.

These restrictions limit cookies set both via client-side (read: JavaScript) and server-side. Yes, server-side cookies are also affected by ITP if the first two numbers of the IP address (e.g. 123.123.xxx.xxx) don’t match the first two numbers of the website’s server.

What can you do about cookie restrictions?

A solution would be for the developers to use the same load balancer (e.g., from Cloudflare) for both the website and server-side setup so that IP addresses match.

#11. Did you rebrand recently and change the domain?

If yes, the rebranding may lead to direct traffic in your analytics data. Visitors accessing your site through a bookmark of the old domain or typing (or autocomplete filling in) the older domain may result in redirected traffic if the referral data is not transmitted.

In GA4, you can go to Reports > Acquisition > Traffic Acquisition and filter the report by Session default channel group that exactly matches “Direct”.

Choose a date range that contains some time before and after the rebrand. Check to see if there was a significant increase in data on the day of the rebrand or the few days after.

If you notice a sudden increase, this is most likely caused by some redirects (between the old and new domain), resulting in the referrer being lost along the way.

Unfortunately, I don’t have a quick way to identify what exactly is broken (if you know one, please let me know ). But here are several ideas:

• Check some of your client/business backlinks that redirect to the older domain. Click on some of them. When you finally land on the new domain, open the JavaScript console of your browser and enter document.referrer. If you only see quotation marks containing an empty value, the referrer value may be lost somewhere in the redirects between your old and new domains.
  
• Checking which traffic sources have decreased after the rebranding might give some clues about which traffic is turning into direct traffic, specifically looking at the “referral” Session medium. In the screenshot below, I’ve identified that the referral traffic dropped significantly after the official rebranding. The next step I would take is to check whether the direct traffic increased by a similar amount. If yes, I would check the most popular referral backlinks. Click them on their respective websites and see if the referrer is visible in the console (see above). If the referrer is lost, consult with developers.
  

What should you do when you identify the traffic sources/referrals that redirect visitors to your site but do not return the referrer anymore?

First, collect a handful of examples of pages (on other websites) that contain your backlinks. Then, send those links to your website’s developers and explain that when you click a backlink, a redirect occurs between your old and new domain, and the referrer is lost. They need to fix it — your devs need to preserve the referrer.

It is not your job to know or explain to them HOW to do that. Just tell the developers you need them to preserve the referrer when a redirect between the old and new domains occurs. If they don’t know how to fix that, maybe it’s time to look for more experienced devs.

IMPORTANT: There might be other reasons why the referrer is missing, and you/your devs have no control of it (See #1 (LINK) of things you need to accept below). So, before you contact them, finish reading this blog post.

#12. Incorrectly configured cross-domain tracking

If visitors can navigate from one domain to another (I am not talking about subdomains of the same domain), you need to implement Google Analytics 4 cross-domain tracking. However, if you misconfigure something, chances are that part of your traffic will become (direct) in your GA4 reports.

One possible case that comes to mind is that you updated the the list of unwanted referrals in Google Analytics 4 correctly, but the GA4 client ID differs across different domains (normally, it should not, but maybe you are dealing with some edge case).

The result of this? You will get a lot of new users on domain B, and their traffic source will be direct (because you excluded domain A from referrals).

#13. Check the Landing Pages report in GA for one more time

For one last time (for this blog post), let’s look at our Landing Page report (found under Engagement if you have the Life cycle collection). Here, we’re not going in with a specific task at hand but rather as an investigator to see if anything suspicious or unusual exists.

While I don’t have any specific tips (since every website is different), you can follow the steps from “Method 1: Built-in reports” at the beginning of the blog post to filter the report by direct traffic and then search for “?”.

What are we looking for? Landing pages that have URL (a.k.a) query parameters but GA4 has assigned to direct sessions.

Does anything stand out to you? Perhaps there’s a URL that contains ?_hsmi indicating that someone has sent an email via Hubspot, but for some reason, no UTM parameters were added.

How do I know that _hsmi belongs to links from Hubspot emails? A good old Google search (our most powerful, yet far too often underused, tool)! Now, you can investigate why these emails do not include UTM parameters.

This is purely a theoretical example (which may not be possible in reality). Still, it illustrates that some detective work will be needed when uncovering the mysteries of direct traffic.

#14. Android apps

Special thanks go to Marek Lecián, who pointed out this solution on Twitter.

Apparently, when a visitor lands on your website from an Android app (e.g. Slack), the referrer is present on the page, but Google Analytics 4 ignores it. Hence, direct traffic.

If you want to see if links from Android apps are causing direct traffic, follow the steps below (assuming you have implemented GA4 with Google Tag Manager).

Firstly, you must go to the Google Tag in your GTM container and add a new parameter to the Configuration settings. Label the parameter as “cd_referrer” and set the value to be “{{Referrer}}” (which is a built-in value).

If you have set up your GA event setting variable, include this new parameter here as well.

Go to Admin > Data display > Custom definitions in your corresponding GA4 property and register the new parameter as a custom dimension.

Once some time has passed (allowing for data to populate in the parameter), go to the Traffic Acquisition report (see Where can I find direct traffic in GA4?).

Add the Referrer custom dimension as a secondary dimension into the report and search for “android”. You will be able to see which Android app referrers are being captured under direct traffic.

The traffic volume here is usually low, so there is no significant impact, and I suggest just ignoring this. However, if you insist on resolving this, you could check the referrer, and if it contains “android-app:”, then you could overwrite campaign parameters in GA4 tags and some other value you want.

#15. If possible, ask not to include the noreferrer in backlinks (#quiteUnlikely)

I am not a link builder, and (I think) I would be pretty bad at this. I’m not sure if this tip is even helpful, but, hey, it may work in some cases where you have very good relationships.

So here’s the thing: if a link on another website redirects visitors to your site and that link contains “rel=noreferrer”, that traffic will become (direct) in your GA4 reports (unless there are UTMs). That happens because (surprise, surprise!) the referrer is not passed.

If possible (in most cases, probably not), ask a developer to remove the noreferrer from the rel parameter in that link element.

When weighing the costs/benefits of this solution, I’d suggest that you should invest more of your time in the other tips mentioned in this blog post.

If it was already challenging to acquire the backlink, getting someone to remove the noreferrer will be even more challenging. Plus, some webmasters might reject your request due to privacy issues.

Anyway, I just wanted to mention this option if you’re desperate for solutions.

#16. General redirect caused by 301, 302 or meta refresh redirect

There are many reasons developers might implement redirects on your site. A developer may implement a 301 redirect when there is a permanent change from an old domain to a new one (see #11), a 302 redirect when there is a temporary change to a different URL, and a meta refresh redirect to redirect visitors to a different webpage after a certain amount of time.

This article is not about the merits of each of those redirects, but the one (related) thing to note is that these redirects can cause direct traffic in GA4 for various reasons:

• The referrer information can be lost
• UTM parameters can be lost
• Tracking scripts or tags may delay execution, so GA4 may not capture the initial referrer or UTM data.

You can ask your developers if you’re using any of these redirects and test the different pages to see if you notice any issues. If so, ask your developers to implement actions to maintain the referrer and UTM parameters.

#17. JavaScript redirects

Sometimes, developers might implement redirects directly in JavaScript code to automatically send users from one page to another. This may be used if there is a rebrand (see #11) to direct users from pages on the old domain to the new domain or if you are doing some A/B testing to spit traffic to different pages of your site.

Even though it does the job, this type of redirect always loses the referrer. Developers should avoid this. Alternatively, consider telling your developers to implement server-side redirects, as these will maintain the referrer.

#18. User ID set in the middle of the session

Artem has done some experiments in the past with GA4 to understand better how it sets session source/medium. One surprising outcome was that if the user ID is set in the middle of a session, the traffic source of the session changes to direct.

If you have a lot of direct traffic and user ID implemented, you can temporarily change the reporting identity to Device-based. If direct traffic significantly decreases, then it means this issue persists.

You can update the reporting identity by going to Admin > Data Display > Reporting Identity.

I suggest weighing the pros and cons of changing the reporting identity for your business. Is temporarily removing user ID from your data worth determining if it is causing an issue with direct traffic? It’s just something to keep in mind. What I mean by saying this is that if you switch to device-based, the user id collection is not affected. It will continue. However, it will not be taken into account when doing calculations.

Don’t you just love GA4’s little quirks? No? Well, hopefully, Google will fix this soon.

#19. Processing errors in GA4

Unfortunately, we have no control over this, but sometimes processing errors/bugs happen in GA4.

For example, on November 8th, 2023, many GA4 users noticed sudden spikes in direct traffic (and their frustration). In this case, Google fixed the issue several days later, and everything returned to normal. However, Google never reprocessed the misattributed data.

If it so happens that your main issue with direct traffic is during this period, then great, this is why.

Otherwise, this is a scenario where I have no solution other than to hope these issues don’t occur in the future, but that might just be wishful thinking.

#20. Explicit use of ignore_referrer

When cross-domain tracking is implemented and a visitor goes from domain A to domain B, Google Analytics automatically adds the ignore_referrer parameter.

But you have the ignore_referrer parameter set to true in your GA4 tag (inside Google Tag Manager), the referrer will be ignored (at least, it should be).

So, it’s a good practice to check if this parameter is not explicitly set in the tag.

Things you need to accept

Now that we’ve explored the reasons behind the presence of direct traffic that are within your control to some degree (issues that you or developers can fix), let’s get into the harsh truth.

In some situations, you must accept that a significant portion of your direct traffic is related to mediums that don’t have the referrer. Period.

#1. Some websites don’t send the referrer data

This is related to section #16. If a backlink to your website has a rel=”noreferrer” parameter, GA4 reports will display that traffic as direct.

But there are other ways that someone could configure the referrer policy, like:

• In the HTTP headers
• In the website’s meta tags. Suppose you open the website’s source code and see this in the head. This means that no links on a site will pass the referrer, hence direct traffic.
  
• via the referrerpolicy attribute

#2. Chats and messengers usually do not send the referrer

Oddly enough, if someone clicks on a link to your site in Zoom chat(or some other messaging apps), that will likely be counted as a direct session (this article dives into the details). And there is nothing you can do about it, my friend.

Messengers tend not to pass the referrer, but some social media private messaging tools will, like LinkedIn messaging (at least, it used to. I haven’t checked this for a while 🙂).

#3. Visitors might use browser plugins that affect the referrer

For example, a Chrome Extension called Referrer Control lets you forge the referrer OR disable it altogether. If a visitor lands on your website with a disabled referrer, you guessed it – there is nothing we can do about it.

#4. People can actually enter the address in the address bar (or bookmark it)

I admit that it is possible that people have entered your website address in the address bar or bookmarked it, but (as has been the point of this entire article) there is no way to tell if this is the case.

Did the user just land on your site from another medium that doesn’t pass the referrer or doesn’t contain UTM parameters (or any of the other reasons that direct traffic can occur)?

Another interesting thing to keep in mind is that a visitor might have landed on your site from an email (with UTM parameters) and bookmarked it. Then, each time they click that bookmark, the traffic source of the visit will not be (direct); the attribution will be to the UTMs stored in the bookmarked URL.

Direct Traffic in Google Analytics 4: Final Words

There is no single solution to address direct traffic in your data because there are multiple reasons that Google Analytics 4 attributes traffic as direct. Even implementing every solution in this article may only partially resolve the problem.

Unfortunately, it’s just what we (marketers and analysts) have to accept and work with.

Now brace yourself for a bit of a buzzkill: if you think strong branding brings loads of direct traffic, that’s probably not the case.

Hopefully, this article helps you implement some strategies to redirect your direct traffic to other traffic sources, providing a more realistic view of how visitors reach your site.

If you have uncovered any other situations that would result in direct traffic not listed in this article, comment below!