Jump to content
View in the app

A better way to browse. Learn more.

Learn more

Who is facing the same issue: massive attack of our Cloud hosted IPS which breaks our GoogleAd

You are viewing a curated collection of the most significant posts in this topic with an estimated read time of 5 minutes. The full topic contains 28 posts with an estimated read time of 21 minutes.

Featured Replies

We are currently facing a huge attack: a large set a bots (with IP addresses located mainly in the US , Brazil, Columbia, ...) are opening connection to our server without getting the content of the pages.

These geographical origins are not believable for our site, since we are a French Forum with mostly all users located in France.

Many of these connections are counted by IPS as "visitors". Indeed, all our counter are becoming completely wrong and does not represent anymore the real usage of our Forum.

However, this is not really a problem, since we are on the Invision Cloud solution, which has all the needed protections to maintain our Forum 100% up and responsive.

Our problem lies on the GoogleAd side, which gives us a significant part of our revenues (we push Ads to our guest and free user).

The current attack makes the GoogleAd system become crazy: when a bot gets the page, the GoogleAd code is pushed to the bot, but no revenue is generated by Google, since the bot does not behave in the expected way.

As a consequence our Ad revenue have dramatically dropped and we have been tagged by Google as an untrusted site.

Regarding this problem, I have 2 questions:

  • is someone else facing the same problem?

  • as we are hosted on a Cloud instance managed by Invision, we have no access to the incoming network filtering configuration.
    Is there a way to make a configuration at IPS Admin level that would reject all the ill traffic or make the GoogleAd script resistant to this kind of attack?

Edited by bernhara

  • bernhara changed the title to Who is facing the same issue: massive attack of our Cloud hosted IPS which breaks our GoogleAd
  • Community Expert
On 9/4/2026 at 8:39 PM, bernhara said:

We are currently facing a huge attack: a large set a bots (with IP addresses located mainly in the US , Brazil, Columbia, ...) are opening connection to our server without getting the content of the pages.

These geographical origins are not believable for our site, since we are a French Forum with mostly all users located in France.

Many of these connections are counted by IPS as "visitors". Indeed, all our counter are becoming completely wrong and does not represent anymore the real usage of our Forum.

However, this is not really a problem, since we are on the Invision Cloud solution, which has all the needed protections to maintain our Forum 100% up and responsive.

Our problem lies on the GoogleAd side, which gives us a significant part of our revenues (we push Ads to our guest and free user).

The current attack makes the GoogleAd system become crazy: when a bot gets the page, the GoogleAd code is pushed to the bot, but no revenue is generated by Google, since the bot does not behave in the expected way.

As a consequence our Ad revenue have dramatically dropped and we have been tagged by Google as an untrusted site.

Regarding this problem, I have 2 questions:

  • is someone else facing the same problem?

  • as we are hosted on a Cloud instance managed by Invision, we have no access to the incoming network filtering configuration.
    Is there a way to make a configuration at IPS Admin level that would reject all the ill traffic or make the GoogleAd script resistant to this kind of attack?

Do you have further information from google on what has been provided to you to state your Adsense is being penalised because of bots hitting your site? If so, please feel free to open a ticket with that information (or respond to the one you already have set up).

  • Community Expert

Besides screwing up my metrics should I care??

Screenshot_20260907-143528.png

Thank you Marc.

I understand how RPM is calculated, but unfortunately this is not the issue I am trying to report.

The problem is the massive amount of abnormal traffic currently reaching the community. GA4 is showing approximately 16,000 Direct sessions today, with thousands of users coming from countries that normally represent only a very small part of our French community.

For example, today GA4 reports approximately 4,850 users from the United States, 1,670 from Brazil, 1,590 from Colombia and 890 from Ecuador. Most importantly, the average engagement time for several of these countries is 0 seconds, while France is at approximately 1 minute 17 seconds. GA4 itself is flagging this traffic increase as an anomaly.

This happened previously at the beginning of September, then the traffic returned closer to normal and AdSense monetization recovered at the same time. Since last night, the abnormal traffic has returned, and AdSense monetization has immediately collapsed again.

So my concern is not the RPM calculation itself, but whether Invision Cloud can identify and mitigate this automated/abnormal traffic at infrastructure/WAF level before it reaches the community and the advertising system.

I will open a ticket as you suggest and provide the GA4 screenshots. This is now quite urgent for us because advertising revenue finances a significant part of the community's operating costs.

Thank you for your help.

GA4-09-09-2026-abnormal-traffic-country-engagement.png

GA4-09-09-2026-abnormal-bot-traffic-countries-realtime.png

I actually already opened a support ticket about this infrastructure/traffic issue last week, including details about the abnormal traffic and a request to investigate possible bot activity and WAF protection.

Unfortunately, I still have not received a response to that ticket, and the situation has now become urgent. The abnormal traffic returned last night and is once again severely affecting our AdSensemonetization.

Today GA4 is showing thousands of abnormal visitors from the United States, Brazil, Colombia, Ecuador and other countries, mostly through Direct traffic, with 0-second engagement for several of them.

Could you please help escalate my existing ticket to the Cloud/infrastructure team, rather than having me open another one?The financial impact on our community is now significant, so I would really appreciate if someone could investigate this as soon as possible.

Thank you.

I wish you luck working with support if this involves IC infrastructure. Be prepared for zero response, rude response, and them to say they can do anything to help you as you’re only a “consumer” vs enterprise customer.

I know this from recent experience. Didn’t leave me feeling positive about the company after many years.

Hi Marc,

I’m following up as it has now been 7 days since the ticket was escalated to the advanced/Cloud infrastructure team, and I still haven’t received any update.The abnormal traffic is still clearly visible in GA4, with the same unusual geographical patterns and very high numbers of guest requests.

Our AdSense monetization has returned to normal, but this is because we have blocked guests from accessing pages where ads are displayed. This prevents the abnormal traffic from generating ad impressions, but unfortunately it also affects legitimate guest visitors.

This is therefore only a workaround, not a satisfactory long-term solution.Could you please confirm whether the Cloud/infrastructure team has applied any filtering, WAF rules, rate limiting or other mitigation to our community since the ticket was escalated?

If nothing has been applied yet, could you please let me know whether the infrastructure team has identified this traffic pattern and whether server-side mitigation is possible?The abnormal traffic is still reaching the community, so I would really appreciate a technical update on the investigation.

Thank you.

Hello Marc,

I am sorry to post another update so soon, but the situation has deteriorated significantly this morning and is now having a severe impact on our AdSense monetization.

The latest GA4 report shows that the abnormal traffic is no longer targeting only specific sections of the community. It is now crawling a very large number of regular forum topics (/topic/ URLs), including old topics and deep pagination pages.

So far today, GA4 has recorded 21,122 page views, including 6,370 from the United States (30.16%), compared with 4,735 from France (22.42%). This means that today our French-language community is actually receiving more page views from the United States than from France.

The report clearly shows that these US views are distributed across a very large number of ordinary forum topics rather than being concentrated on one particular page. This is consistent with automated crawling of the community.

As shown in my previous report, this abnormal international traffic also has extremely poor engagement, with 0-second average engagement time for the United States and several other countries, whereas legitimate French traffic shows normal engagement.

The most serious consequence is now visible in AdSense. At approximately 12:12 PM today, AdSense had already recorded 13,300 page views, but only 7,400 ad impressions, with the page RPM collapsing to just €0.69 and page CTR to 0.84%. Estimated revenue was only €9.20, despite this exceptionally high number of page views.

In recent days, when traffic quality was much more normal, our page RPM was around €3 or more. The sudden combination of huge volumes of abnormal page views and the collapse in RPM strongly suggests that this traffic is severely degrading the monetization of our advertising inventory.

Unfortunately, because these requests are now reaching normal public forum topics containing advertising, I cannot simply block these pages for guests without also blocking legitimate visitors coming from Google and seriously affecting the normal operation and visibility of the community.

This is therefore becoming extremely concerning for us. Restricting individual sections such as Downloads, profiles or search can reduce the exposed surface, but it cannot solve the problem now that the abnormal traffic is systematically crawling ordinary public topics.

I am attaching the latest GA4 report because I believe it demonstrates particularly clearly why this issue now requires infrastructure-level mitigation rather than additional community permission restrictions.

Could the Cloud/advanced team please urgently investigate whether this traffic can be filtered, challenged or rate-limited before it reaches the community pages and the advertising code?

Thank you again for your help and for forwarding this additional information to the Cloud team.

Kind regards,

Nicolas

GA4-Abnormal-Traffic-Crawling-Public-Topics-2026-09-20.png

  • Community Expert
  • Management

We went ahead and pulled the raw connection logs for your community to compare against what GA4 is reporting, and the two don't line up.

Looking at actual server level connections, the traffic is overwhelmingly from France and from known search engine crawlers, primarily Googlebot, Bingbot, and Facebook's link preview fetcher (facebookexternalhit). For the specific window you referenced, we only see 53 total connections from Colombia, nowhere close to the 680 page views GA4 attributed to that country. The same gap holds for the Brazil, and Ecuador numbers you sent over.

That mismatch tells us much of this traffic isn't even hitting your site. If it were real requests, even automated ones, they would show up in our edge logs regardless of what GA4 does or doesn't capture. Since they're not there, the traffic GA4 is counting never actually reached your server.

What's most likely happening is that your GA4 Measurement ID is being hit directly by scripts sending fake data straight to Google's collection endpoint, without ever loading a page on your site. This is a known issue sometimes called ghost or phantom traffic or GA4 measurement spam, and it's unfortunately common when a Measurement ID is exposed in public page source, which it always is by design. Because it bypasses your site entirely, there's nothing at the server or WAF level for us to filter, rate limit, or block, since no request is being made to your infrastructure in the first place.

A couple of things on your end that should help confirm this and clean up your reporting:

  1. In GA4, check the Traffic acquisition report and add the Hostname dimension. Legitimate hits will show your actual domain. Spoofed hits typically show blank, "not set," or an unrelated domain.

  2. Consider setting up a valid hostname filter in GA4 so only traffic reporting your real domain is counted. This is the standard fix for this exact issue.

  3. If you want to fully cut this off, the Measurement ID can be rotated, though that requires re tagging your GA4 setup.

You should Google "GA4 phantom" or ghost traffic. There is a lot of information and potential solutions. In any event, it's not something we can solve on our end as it's often not real traffic. Even in the event of legitimate automated traffic passing through, we unfortunately just do not live in a world where we can toggle a one-size-fits-all "desirable traffic only" button. I wish it existed. At a retail platform level, we have to make adjustments that capture as much malicious/automated traffic as possible while balancing false positives. It's a never-ending game of cat and mouse.

Recently Browsing 0

  • No registered users viewing this page.

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.