Fake Traffic in GA4: A Referral Spam Investigation and What Helped

A young publishing website bought an inexpensive promotion subscription and soon saw hundreds of new referral sessions in Google Analytics 4. The growth looked promising until the analytics events were compared with actual website requests. This anonymized case explains how the discrepancy was investigated, what Google support recommended, and why contacting a provider can be part of the response without proving that the provider caused the problem.

Practical takeaway: before blocking countries, changing tags, or buying more promotion, establish whether the questionable activity reaches your website at all. Cleaning a report, stopping website bots, and preventing fabricated analytics events are three different jobs.

Contents

Executive summary

The investigation found a repeated pattern: suspicious page_view events appeared in GA4 without nearby requests for the same pages in the website's access logs. Verified manual visits did appear in those logs. Browser captures and the published Google Tag Manager configuration provided further checks.

Google support described the evidence as Direct Hit Injection: analytics requests submitted without the ordinary website visit they appear to represent. That was a conclusion in this support case, not identification of the sender or disclosure of Google's raw collection logs.

The suspicious stream later stopped after the publisher contacted the distribution platform. No substantive response explained the stop. At the latest case update, the publisher reported no recurrence and no reply seven days after a follow-up. The sequence matters, but it does not prove that the platform sent the events or that the correspondence stopped them.

About this case: the website and distribution platform are anonymized. The account comes from a publishing project investigated by metricfixer. Names, identifiers, exact dates, and article URLs are withheld; the selected log-comparison results are preserved.

Growth that looked like success

The publisher wanted more people to discover its technical articles. A blogging platform offered a low-cost monthly subscription and public previews linking to the original content. Shortly after activation, GA4 began showing roughly 200-250 suspicious referral sessions a day.

Some of those sessions also appeared engaged. That made the increase easier to trust: visitors seemed to come from many countries, use different devices, and spend time with the content.

But engagement is calculated from the events Analytics receives. Under Google's definition of an engaged session, two page or screen views can qualify a session even without a purchase or enquiry. A second reported view is therefore not independent evidence that a person read an article.

The marketing question changed from "How much traffic did the subscription generate?" to "How much of this reported activity can we connect to credible visits?" Neither a surprising country nor a weak conversion rate could answer that on its own.

Signals that justified investigation

No single finding proved fabrication. The concern came from several features appearing together in the same traffic group.

Why the traffic deserved investigation, not an immediate blanket ban

Observed pattern	Why it mattered	What it did not prove
A nearly steady stream across many hours	It resembled a repeated process more than a short promotional burst.	Scheduled promotion can also produce regular traffic.
The same unusual language code, en-en, across varied devices and countries	It gave the investigation a consistent technical signature.	A language value is not proof of a bot or its location.
A full listing URL in page_referrer	It differed from the origin-only referrer in verified manual visits.	Other browser policies or tag settings can legitimately produce different referrers.
Repeated additional page views and reported engagement	The apparent engagement needed validation beyond GA4's own counters.	A two-view session is not inherently suspicious.
Page titles changed from missing to populated at a clear point	Something in this traffic group's reporting behavior had changed.	The change did not identify a program, operator, or motive.
Few of the site's usual custom events accompanied the reported views	Normal test visits produced a richer event sequence.	Consent, implementation errors, or blocked scripts can also alter that sequence.

The referrer difference required particular care. With the default strict-origin-when-cross-origin policy, a cross-origin HTTPS navigation normally sends only the referring origin, not the complete article path. However, this is not a universal rule for every request. The useful evidence was the comparison with a captured visit through the same listing, not a claim that full referrers are always fake.

Also, GA4's session source and an HTTP request's Referer header are not interchangeable. The first is an attribution result; the second describes one request. The campaign and traffic-source rules explain why a simple daily comparison between referral sessions and referrer-bearing requests is not enough.

Checking alternative explanations

Could the website's tags be responsible?

The review examined the analytics code and GTM configuration for duplicate views, overridden referrers, forced language values, and unexpected event generators. An early export turned out to be a workspace draft, so the published version was checked separately.

No mechanism explaining the distinctive referral pattern was found in the reviewed published configuration. That narrowed the investigation; it did not certify every possible integration as faultless. The general lesson is to examine what actually ran during the incident, not just what is currently in a workspace.

Could a cache explain the missing website requests?

A HAR file is a browser's network recording. Controlled HAR captures showed the directory serving its own resources and the browser then requesting the original article from the publisher's server. The captured visit did not show the platform serving a cached copy of the publisher's HTML in place of that request.

That finding applied to the recorded path. Cache-bypassing requests in a test cannot exclude browser caches, service workers, or different delivery paths for every other visitor. Likewise, missing CSS or image requests are weak evidence when assets may be cached or logged elsewhere.

Were the logs complete enough to use?

The investigation checked the monitoring filter, domain coverage, rotated archives, and control visits before relying on missing log entries. A tiny current log was not treated as the entire history: previous days were stored in hosting-panel archives.

This matters because Nginx can log conditionally and in the location where request processing ends. A log can omit a request without the website having rejected or never received it. On a CDN-backed site, edge logs may also be needed.

Time zones and processing delays needed attention too. The comparison used a documented time-zone assumption and control visits consistent with it. Google notes that reported data can change during processing. A minute in a report is not a unique request identifier, and a delivery timestamp is not always the event time.

What the log comparison showed

Twelve suspicious page-view observations were selected for comparison with historical access logs. For each one, the check looked for a GET request to the corresponding article around the reported minute. Two manually verified page views were included as controls.

Selected observations compared with archived website access logs

Group	Observations checked	With a candidate request within ±2 minutes	With a candidate request within ±10 minutes
Suspicious page views	12	1	3
Verified control page views	2	2	2

Eleven of the twelve suspicious observations had no nearby request in the narrower window. Both control page views did. Repeating the comparison against the main archived access log supported the earlier monitoring-log result.

The three wider-window candidates were not three verified visits from the platform. One request identified itself as a search crawler. Two other candidates used browser-like user-agent strings without a referrer. A nearby URL match alone could not connect any of them to the GA4 event.

These are results from a small, selected diagnostic sample, not a random estimate of the percentage of all visits that were false. The logs also came from the same website infrastructure, not two independent observers. There was no shared event identifier joining an individual GA4 event to a server request.

Even with those limits, the combined evidence supported a stronger explanation than an ordinary referral spike: many reported views were probably being submitted without the normal page-loading path. Legitimate server-generated events and alternative delivery paths still need consideration in any other case.

What Google support said

The initial support response suggested general measures, including unwanted-referral settings, IP filtering, and form protection. The publisher explained why these did not address the central finding: suspect page views with no corresponding website requests.

In a later response, Google support accepted the supplied log comparison and described the case as Direct Hit Injection. Support distinguished ordinary web collection from Measurement Protocol, recommended isolating the affected traffic in reporting, and suggested a new web data stream if the activity continued.

This was case-specific support advice. The response did not include raw Google collection telemetry, identify the sender, or establish that the named referral platform operated the generator. The classification supported the diagnosis; it did not prove attribution.

A Measurement Protocol secret is not a lock on all web collection

A Measurement ID identifies a destination for website measurement. It is not proof that a reported event came from that website. In this case, support explained that standard web-collection requests did not require the secret used by Measurement Protocol.

Google's Measurement Protocol documentation requires an api_secret for that separate sending method and says to keep it out of client-side code. Creating such a secret does not turn the normal Google tag route into an authenticated private service. There was no evidence in the supplied case record that a leaked Measurement Protocol secret caused the anomaly.

Known-bot filtering has limits

Google documents automatic exclusion of known bots and spiders. That does not mean every event remaining in a report is verified human activity. "Known" is an important qualification.

Historical data needs a more precise explanation

One support statement suggested that processed data could not be deleted. That is too broad to repeat as general guidance. GA4 has data-deletion requests, but the documented parameter-deletion process removes text values while events remain counted in overall metrics. Other deletion routes have their own scope. This is not a simple "remove these fake sessions and rebuild every report" function.

For this type of incident, preserve the original evidence and maintain clearly labeled analytical exclusions. Do not promise that a support classification will automatically repair historical totals.

Choosing the right response

The first decision is not which tool to buy. It is which problem needs fixing. A report can become more useful while unwanted events continue arriving. A website can block a bot while an unrelated sender continues submitting analytics events.

Match the measure to the problem it can actually address

Measure	Useful for	Important limitation
A combined historical signature	Separating the investigated group in available reporting data.	A case-specific signature is not a universal bot definition.
A custom event-origin marker	Identifying sessions with events carrying your implementation's label.	The label is visible and copyable; old events are not backfilled.
Website firewall rules or form protection	Abuse that reaches your website or forms.	They do not inspect requests sent directly to Google's infrastructure.
Measurement Protocol secret rotation	Containing suspected misuse of that secret.	It does not secure ordinary browser collection.
Unwanted-referral settings	Correcting referral attribution in appropriate situations.	Changing attribution is not rejecting fabricated events.
A new web stream and Measurement ID	Testing whether a sender continues targeting only an old identifier.	A new public identifier can also be discovered; migration adds dependencies.
Server-side validation	Applying acceptance rules to events passing through your own collector.	Direct submissions to a public destination may bypass that collector.

For example, unwanted referrals use ignore_referrer to change how a referrer is used for attribution. They are not a spam-rejection list. Suppressing a source can make an investigation harder without removing the questionable events.

GA4's documented data filters cover developer, internal, and web-hostname traffic. They apply prospectively and can permanently discard data. They are not arbitrary rules for accepting only events with any custom parameter you choose. A permitted hostname also does not authenticate a sender that claims that hostname.

A new stream deserves a controlled migration, not an impulsive deletion. Record dependencies, verify event delivery and consent behavior, avoid duplicate collection, and distinguish old-stream from new-stream reporting. Keeping a spammed stream in the same property can still pollute property-wide totals. Google warns that stream deletion cannot be undone and affects dependent integrations. The case did not establish an ID change as the reason the traffic stopped.

For stronger control, a first-party collector could validate short-lived server-issued tokens and reject replays before forwarding events. That is a possible design, not a measure proven in this case. A token can indicate passage through an approved route; it cannot prove a human visit.

Google describes server-side tagging as a route for receiving and processing events. Our architectural conclusion is narrower than a security guarantee: routing your own tags through a server does not force every external sender through it. A controlled first-party event record may be the better reference dataset. See our review of what server-side GTM can and cannot improve.

Using an origin marker without calling it proof

The site's own analytics layer already labeled its dataLayer events with source: "ui". The implementation was updated to forward that value to GA4 as the custom event parameter Origin. This is an implementation label, not the HTTP Origin header.

The aim was modest but useful: compare sessions containing a site-labeled page view with sessions lacking one. It was not to reject requests at Google or certify every labeled session as human.

Send the marker and check the request

Read the dataLayer value in GTM and pass it through the Google tag and relevant GA4 Event tags. Google's shared event settings can reuse a parameter across those tags. Check the actual outgoing page_view request and relevant custom events. A value visible in dataLayer is not evidence that GA4 received it.

Do not add an extra page_view just to carry the marker if your existing Google tag already sends one. Test normal navigation and consent states without weakening consent requirements.

Register it for reporting

In GA4, use Admin → Data display → Custom definitions to create an event-scoped custom dimension for the exact parameter name. The display name can be something readable such as "Collection origin." In the case implementation, the parameter was Origin, including the capital letter. Google describes this setup in its custom-dimension instructions and notes that reporting availability can take 24-48 hours.

Select whole sessions, not just marked events

In an Exploration, create a session segment with both conditions evaluated within the same event:

Include sessions containing an event where:
Event name exactly matches page_view
AND
Collection origin exactly matches ui

Condition scope: Within the same event

The display name must match the custom dimension you created. Google's segment builder distinguishes session segments from event segments: the former retains activity in qualifying sessions, not only the qualifying event. A property-saved segment remains an Exploration tool, not a global collection filter.

Keep an unfiltered comparison alongside it. Do not exclude an entire session merely because one automatic event lacks the marker. Also check legitimate backend events, offline activity, and visits affected by incomplete tagging before calling an unmarked session fake.

A static marker is not authentication. Browser automation can execute the normal tags, and a deliberate sender can copy the parameter. It is a useful reporting safeguard against a pattern that does not carry it, not permanent protection. For historical periods, use the documented source-and-language signature rather than retroactively requiring a marker that did not exist.

Contacting Google and the provider

The strongest support request was not "your traffic is fake." It was a small, reproducible evidence package: what GA4 reported, which page requests were sought, how timestamps were compared, what the logs covered, and whether control visits were visible.

For Google, the question was about collection: could events be reaching Analytics without website visits, and which supported mitigations applied? A response about invalid advertising clicks or form spam did not answer that question. The follow-up brought the discussion back to the supplied evidence.

For the distribution platform, the question was about the service: what promotion had been activated, whether third parties were involved, and whether any process had changed around the time the stream stopped. The publisher did not need to accuse the platform to request an explanation.

The following is adaptable wording, not a quotation from the private correspondence:

After activating the subscription, we observed a referral pattern that does not match ordinary visits in our server logs. We are not assigning responsibility. Please explain which promotional processes or partners were activated, investigate any associated automated activity, and confirm whether anything was changed after our report. Please distinguish any proposed suspension of promotion from cancellation of the listing or subscription.

Provide a summary first. Keep original logs and HAR files in restricted storage; share them only through an agreed secure channel after reviewing their contents. They can contain identifiers, sensitive URLs, and credentials. Support correspondence and publication illustrations must not expose API secrets or unredacted account information.

A request is also more useful when it distinguishes a billing or service question from a technical one. A low subscription price does not answer whether the traffic has value; a good search ranking for a directory preview does not establish that the reported sessions are real.

What stopped and what remained open

The distinctive referral stream stopped after the initial contact. Later checks in the case record found normal website measurement continuing while the suspect language-and-referrer pattern was absent. The publisher subsequently reported that the stream had not returned and the platform had not substantively answered the later follow-up after seven days.

Outcome without assigning an unverified cause

Stage	Observed result	What remains unknown
Subscription activation	The unusual referral increase followed soon afterwards.	Which system or party initiated it.
Technical checks and correspondence	Evidence was assembled and sent to support teams.	Whether the distribution platform acted internally.
Traffic stop	The distinctive pattern ceased while other measurement continued.	Whether contact, automated detection, an expired job, or another cause stopped it.
Follow-up observation	No recurrence was reported at the case cutoff.	Long-term recurrence risk and the subscription's genuine commercial value.

This was cessation after correspondence, not a negotiated admission or a proven technical cure. Silence does not establish responsibility. Nor does support's classification identify the referral platform as the sender.

The practical next step was to judge the subscription using credible visits and business outcomes, separately from the suspect group. That assessment was still pending at the latest update. A platform's preview might bring useful discovery, or it might attract attention without sending meaningful visitors. This case does not settle that marketing question.

The incident could be treated as inactive and monitored, while reporting exclusions, evidence preservation, and the commercial decision remained separate tasks. There was no basis to promise that it could never recur.

A checklist for the next traffic spike

• Save the baseline. Record the affected dates, property time zone, dimensions, event names, and deployment changes before editing tracking.
• Build a specific comparison group. Combine relevant signals; do not treat one country, language, referrer, or engagement metric as a verdict.
• Verify ordinary visits. Capture a controlled journey and confirm that your chosen logs and analytics reports show it.
• Check the evidence boundary. Include relevant CDN or backend paths, log filters, rotation, caches, and timing limitations.
• Separate reporting from prevention. Test reversible analytical exclusions before destructive changes, and match any protection to the route it can actually control.
• Escalate with examples and monitor the outcome. Keep a timeline, ask providers concrete questions, and distinguish an observed stop from an identified cause.

How metricfixer can help

The hard part is often deciding which system to investigate next. A traffic anomaly can involve website delivery, GTM, consent, GA4 processing, server integrations, or a promotional service. A generic bot filter does not answer all of those questions.

The Google Analytics Traffic Anomaly Investigation service is the relevant place to request help assessing this type of discrepancy. A focused investigation should connect analytics observations with the published implementation and available request evidence, explain the confidence limits, and identify proportionate next actions.

For an initial assessment, provide the affected period, suspicious dimensions, examples, recent changes, and the logs or browser captures you can safely supply. Use limited access for tracking diagnostics, not shared passwords or API secrets.

The work can be scoped around diagnosing the collection route, validating reporting safeguards, checking an approved implementation change, or organizing evidence for a platform escalation. It should not promise to identify an anonymous sender, erase all historical contamination, obtain a vendor admission, or guarantee permanent immunity from fabricated events.

The aim is usable measurement and a defensible decision, not simply a lower traffic number.

Methodology and sources

This retrospective uses the investigation record supplied for the case: GA4 report extracts and API results, recorded Nginx log comparisons, archived-log inventories, controlled browser HAR captures, published GTM exports, and correspondence with Google support. These private materials are not reproduced as downloadable raw evidence because they contain identifying and potentially sensitive data.

The 12 suspicious observations were a selected diagnostic sample. The two controls were verified page views, not two independent populations. The matching procedure compared page paths and reported minutes using two time windows; it did not join events by a shared unique identifier. Near-time matches were treated as candidates, not authenticated visits. Monitoring and archived access logs were two views of the same website infrastructure.

The source site's identity and the distribution platform are withheld. Exact calendar dates, fees, account IDs, IP addresses, listing URLs, and support-ticket identifiers are omitted. Broad traffic volumes are rounded; the sample sizes and matching counts are unchanged. At the case cutoff, subscription value remained under evaluation, and the most recent non-recurrence statement came from the publisher.

Public technical guidance was checked on 30 October 2026. Official Google Analytics and Google Tag Manager documentation, Nginx documentation, and MDN are linked beside the claims they support. The support team's diagnosis is attributed to that private case; architectural recommendations and causal limits are metricfixer's analysis. No claim is made that a public documentation page independently confirms the private incident.

This article provides technical and operational information, not a guarantee of security, traffic quality, or a particular support outcome. metricfixer is independent of Google and the anonymized distribution platform. The evidence does not identify the sender of the suspicious events or establish wrongdoing by the platform. Product settings and documentation can change; validate any filtering or collection change against legitimate traffic and applicable consent requirements.