Issue with Adsense and pageviews

To clarify, I didnt mean the difference between Discourse PageViews and GA4 page views.

I mean GA4 running on Discourse seems to overinflate the number of page views compared to GA4 running on a more traditional Forum setup with the same number of users.

I think GA4 on Discourse is seeing lots of phantom pageviews. Having just changed over, I think I’m now getting a much closer number to the levels discourse was counting as page views, but actually minus the crawler total, on my GA4 now.

I think this might be more Google trouble.

Switched on November the 7th

Page views have taken an immediate dive, but user_enguagement has gone up

But still roughly the same number of users

I know switching system etc could casue a wobble and the season is winding down so i expect the site to get a little less busy but seems a huge dive in PageViews, we had maintained the URL structure as much as possible to minimise distuption.

Actually looking back at my Google analytics from the year before, using Universal Analytics on Discourse they’re much more in keeping with my traffic since Tuesday, so I actually think there’s an issue with GA4 and the pageview data it is seeing on Discourse.

… and confusingly, Google AdSense is seeing only a fraction of them as well.

I feel this is kind of going in lots of directions Shane, so let me summarize some stuff:

  1. Pageview numbers from adsense should be ignored. According to Google, adsense does not play nicely with SPAs, it only counts 1 page view per visit.
  2. We have a reproducible bug with adsense, where it just 100% stops working after a certain amount of scrolling, we are working with Google to try to find a workaround.
  3. We attempt to align pageviews in GA4 with page views in Discourse. You get a page view when
    1. You first visit the site
    2. Within the SPA you change routes … meaning you go from one topic to another topic.
    3. Ad blockers etc… will undo all our alignment work, given GA4 is managed via the browser calling google and our counting is done server side.

Traditional non SPA forums, will count multiple page views per topic, one for each page… we only count 1 per topic, no matter how much scrolling you do. Maybe we should re-think this… I am not sure…

5 Likes

Is there a mechanism that will emulate “next page” for the purposes of pageviews when the n+15 topic displays on screen and when n+10 post displays?

Nothing out of the box, but I think there is a possibility to do so in a theme component. You would unalign Discourse page views to a degree if you did so.

1 Like

A post was split to a new topic: GA4 page views are inflated compared to Discourse page views

Hello, for me, the problem is not completely over, it still continues. Especially from 2024, adsense is coming to a completely different ad earning system. Adsense will now pay for impressions. In this case, it will negatively affect the sites using discourse. I will be glad if you can look at this situation in the coming days

The word from Google is:

  1. Adsense does not work 100% right on SPAs, it is simply not designed for it
  2. There is not alternative from Google
  3. Page views are not to be trusted on SPA with adsense

Sorry I don’t have better news, but there is simply nothing we can do here.

5 Likes

Or with Google Analytics judging from my experience.

I disagree with this, our implementation is google analytics friendly.

clearly … google analytics does not count a giant pile of page view

  • Crawlers / API calls count for nothing unless they run JS
  • Our implementation is very conservative, we only ever count 1 page view per topic regardless of how long it is
  • Browsers such as brave may block this traffic, various plugin browsers can as well

Caveats aside, this does work as advertised


If you really really need exact counts, the NGINX logs is what will give you much more accurate number.

I came here with an issue related precisely about ads and pageviews, but from a different angle and I wonder if I might have just stumbled on the actual cause for this.

Some context: I’m using Google’s Ad Manager to show a mix of our own directly sold ads with AdSense as fallback. I’m using the official Ad Plugin.

We rarely have directly sold ads in our forum, but we currently have one. Over the last days I noticed something very odd with the ads the forum: Ad Manager was reporting the banners were having clicks, but reporting to have nearly zero impressions, causing Ad Manager to report a CTR in the thousands percent because it was seeing more clicks than actual impressions. :sweat_smile:

While using Ad Manager feature to preview one of the banners directly on Discourse I noticed that these errors were being displayed on the console:

Expanding on one the errors, they seem related to the advertising.

Screenshot 2024-01-23 at 14.48.06

Note that, as recommended by the Ad Plugin, we are using ‘https’ and ‘unsafe-inline’ for the CSP. I don’t know if the policy of ignoring ‘unsafe-inline’ is new, or if the hash was introduced recently by Discourse.

In any case, if I temporarily disable CSP, as expected, the errors go away and, importantly, Ad Manager started to properly report impressions.

So, it seems that in practice the ads (mostly) work, but the Google Ad Manager internal tracking to report back to thepage seems to be failing (when CSP is not disabled).

Could this issue with CSP’s ‘unsafe-line’ be the cause of the unreported ad pageviews reported on this topic?

1 Like

It seems like it’s ignoring the unsafe-inline, because of a hash in your CSP policy:

Can you remove that hash somehow and see if it goes away?

I’m not adding the hash myself as my CSP configuration is the default plus the recommended changes to run the Ad Plugin.

I don’t know what’s adding that hash, but I suspect Discourse does as the CSP in meta also has one in it.

1 Like

Well okay but when i moved to GA4 on Discourse my pageviews rocketed to 3 x times what they were on UA and after moving to a different platform they’re back to 30% of what I was getting on Discourse with GA4 and much more in line with my Discourse traffic on UA. No one seems to be able to explain why, so there’s potentially something miss there. :man_shrugging:

Not sure if relevant here, but the hash is being added right after https://discourse-host/svg-sprite.

Apologies if this CSP issue is out of context here, although to me it seems related — feel free to move my posts to the Ad Plugin topic if this is off-topic here.

This is an interesting theory. I did a bit of digging to track down where the hash that cancels unsafe-inline is coming from and it looks like it is being added by the splash screen site setting. Can you try to disable that setting on your instance temporarily and see if there are any changes in the Ad Manager reports?

3 Likes

Can already confirm that disabling the splash screen did remove the hash and no longer have errors on the console regarding the ads.

Tomorrow I’ll report if impressions are being counted normally on Ad Manager side of things.

3 Likes

I can now confirm that after disabling the splash screen (and re-enabling CSP), Ad Manager is now acting normal, with impressions being reported back for the ad campaign we have been running (previously showing ~0 impressions, although dozens of clicks).

So, at least for our case, we seem to have found a culprit and a hack of it. I don’t think this affects just us though as we have a pretty standard use of the Ad Plugin with Ad Manager, and the splash screen is enabled by default. I’m not sure if the instructions of the Ad Plugin need a tweak, or if the use of hashes on CSP can be addressed. Either way, I think it needs attention as it currently breaks running Ad Manager campaigns in Discourse when using the Ad Plugin.

Happy to provide more info or test something if it’s helpful as I know it can be tricky to debug these things without already having a Ad Manager account and running an actual campaign.

Having said that, given that I posted about this on this particular topic, I should also note that the number of impressions reported by AdSense (which is our fallback for our own campaigns and takes the majority of the traffic) has not changed substantially after these workarounds (e.g. disabling CSP or the splash screen). So it seems to affect only Ad Manager with directly sold campaigns, and not necessarily if its AdSense showing an ad — perhaps AdSense uses a different way to report the impression back to Google, if it does it at all. Hence, this CSP issue may not necessarily explain the big discrepancy reported on this topic — at least I can’t see it with our particular setup, although the same CSP issue may be breaking other google code when the Ad Plugin is used.

4 Likes

A quick follow-up here, @mentalstring. @david has a PR in the works with a completely differect approach here, that is looking very promising:

We should be able to merge this in core shortly and test it out very soon. It promises to solve all sorts of CSP issues with ad management software (and script management tools like GTM). It might not affect AdSense impressions though, that seems to be a different issue.

6 Likes

Hi @mentalstring - here are some details on that new approach:

With that, you should be able to re-enable the splash screen, and all kinds of advertising / tag-management should ‘just work’ without any additional configuration. Please let us know how you get on!

3 Likes