Ads only to registered users?

Is there a way to only show ads to registered users and not to guests?

Or to use a customize script tag depending on session state?

The logic here is that those who have accepted the Terms/Privacy Policy during signup/SSO have accepted the use of cookies/ads elsewhere, while the guests haven’t.

I reckon the need/scope of this is limited (mostly EEA countries), but I’d already be happy if there was a way to do this regardless of the location of the visitor.

Tips on where to look in the code to do this are welcome too.

3 Likes

You could hide with CSS, but you’ll still be getting cookies and collecting information. Edit: this is bad advice.

Maybe you want this: Discourse Cookie Consent Banner

3 Likes

Indeed, hiding ads with CSS does nothing about the cookies or the data being collected.

That depends on a 3rd party service which is a paid product. And looking at its source, it seems to just display the banner, but does nothing to stop cookies triggered by Discourse’s Advertisement plugin.

In any case, that banner handles the consent for the use of cookies — this is not enough for the more strict GDPR consent to collect private information required for, eg, targeted ads. This consent needs to happen before any ads are loaded.

We already collect the consent for that elsewhere (SSO), so an option to display ads only to logged in users would be one way to handle this, but I reckon this may be specific to our setup.

1 Like

FWIW, on our site we serve ads only to guest users by checking the user id. On our “other than discourse” forum, all guests (not logged in) users have a userid of less than one, so it is easy to check and not serve ads to members (just the opposite of server only to registered users).

I have not yet looked at the official discourse ad plugin to see if this is a configuration option or possible with a simple code mod.

When you say “serve ads” do you mean doubleclick/ public ad network, or house ads?

If a public ad network can’t see the ads being served in the page (because they’re hidden to guests) you risk having you account suspended. Impressions without verification is usually an abuse flag, they assume you’re rendering ads outside the viewport or doing something equally squirrelly.

1 Like

By not serving ads, we mean not serving ads. In our case, we own and run our own ad server and that ad server runs tags as we specific (house, tech networks, special campaigns, google ad tags, so many ad network… it it “up to us” and our ad customers how we serve ads). hi

Not serving ads is not hiding ads. It is not serving ads

We can easily configure “serve house ads to China”… “serve no ads to members”… “server only tech net ads to usa”… " serve green ads to Brazil" … “do not serve ads to UK” “Serve purple ad to FF browsers” … “Serve pink ads to Chrome”… This is all very basic ad serving 101.

We have been managing and serving ads for more than 15 years, and we are not at risk for anything.

We know what we are doing and have been in this business for a very, very long time.

As far as others, all this talk about CSS and “hiding ads” is not how to run a web site or even discuss the topic. You serve ads to users based on any number of criteria (geo, user status, time-of-day, we can target ads down to browser and sex of the user). This is all basic ad server 101 if you run your own ad server.

I think we served around 500 million ads last year (maybe less since traffic has been declining on old forum), from house to custom direct vendor buys.

I have no idea how the discourse ad plugin works; but from an ad serving perspective, there is nothing wrong at all with targeting registered users and not targeting (or serving to) guests. This is how ad serving works. Targeting.

In our case, we run an ad server and we target based on myriad criteria. This is all very basic ad server 101 stuff. On our site, for nearly two decades, we only serve ads to unregistered (guest) users. Our membesr never see ads, per long standing policy.

Example of ad targeting

This is how every ad server I have every managed works.

Moreover, at the “bare metal” level we can target to turn off all ads (all ad serving) to any geo, member (based on many criteria) and more. This is basic ad targeting using all commercial ad servers.

On a forum, it is relatively easy to set a boolean and not serve ads to any group, as the site chooses.

However, with discourse plugins, I have no idea since we have no immediate plans to serve ads; but if we do, I promise we will not serve ads to logged in users, even if I had to modify the plugin myself or write my own :slight_smile:

For those who have never seen legacy forum ad management (modern ad plugins are much prettier, LOL), here are two screenshots from a legacy vB ad management system (only the global settings page) not the detailed pages for ad placements.

This is not the “ad server” this is only a plugin which helps with placements targeting forum ids (categories), usergroups, etc. This is all very legacy stuff and we hardly use it anymore, so FYI.

However, you can see that usergroups can easily be targeted, including serving or not serving ads to any usergroup class (guests, registered users, moderators, leaders), etc.

See also,

Note: On ```bare metal`` (the server) we also target based on geo, cookies, etc. This is all bare bones ad serving 101, to be frank. For example, we can easily do this “use ad server one in Germany” and “user ad server three in Japan”… the sky is really the limit when you combine (1) “bare metal” and (2) a good “ad placement plugin” and (3) “run your own ad server”.

Regarding the Discourse ad plugin…

I just took a peek for the first time into the plugin.

$ pwd
/Users/Tim/desktop/discourse-adplugin/test/javascripts/acceptance
$ vi dfp-test.js.es6

Looks to me like the basic capability to serve ads to certain trust levels and groups is already there (however, I did not test it, but it looks fairly straight forward since it is there in the plugin already…)

Here is the code:

Sorry, not in my radar to work with this plugin this month; but it looks straight forward to target based on trust levels and user groups, after a brief look at the code.

Anyway… just checked the docs… most of this exists in the discourse ad plugin already, see for example (adsense though trust level, in this example setup):

1 Like

Discourse’s ad plugin is not about handling targeting but mostly about placing the ad units code into Discourse’s output. One may use something like DFP (Ad Manager) for the geo/etc targeting. I don’t think this plugin should handle the targeting bits.

It does already have a setting for not showing ads above a certain trust level. Our need (again, specific to our SSO setup) is sort of the reverse: to not display ads at all to guests as they have not given the consent.

I’m new to Ruby and Discourse’s codebase but will take a look at the code and see if I can figure something out. Hints appreciated.

See here (adsense example, each file is different in that directory). You can slightly change the logic in this code to only show ads to users above a certain trust level or user group (instead of below), etc.

FYI (and a hint)

./discourse-adplugin/assets/javascripts/discourse/components

This “may” be easily modified and rebuilt (test on your favorite staging server) to accomplish what you asked for, as I understood your original post (show ads to members only). If you based it on trust level or user group, then of course it is nearly trivial to modify.

Sorry, I have not tested, only looking into the code for you.

3 Likes