Monetization with an ad management partner

Feature
1

Dear community,

I’m Uwe, and this is my first post in this community. I work as a developer for ad technology at an ad network based in Germany. Recently, when we wanted to collaborate with a publisher who uses Discourse, we encountered the following problem.

With the Ad Plugin, you can deliver advertising via the following networks/AdServers:

Google AdSense 565

DoubleClick for Publishers (DFP) (aka Google Ad Manager 145), including custom targeting

Google Double Click for Publishers 89

Amazon Affiliates 137 - Banner and Product Link Ads

Carbon Ads 140

The problem: The selection by far does not cover the full potential of monetization. This is not intended to be criticism of the plugin; I would like to initiate a discussion about website monetization using Discourse and explain why it makes sense to use 3rd party scripts from ad networks such as Mediavine (US market) or Symplr (DE market).

Why is this important?:

Ad networks are connected to a variety of SSPs (Supply Side Platforms). They are requested for an auction alongside Google and can submit bids. This increases competition and advertising pressure on Google, ultimately leading to a higher TKP (Thousand-Contact-Price) and more revenue than with just Google AdSense or Google AdManager.

Advantage for the publisher:

More revenue due to increased competition and advertising pressure on Google.

Technical hurdles:

Monetizing single-page applications requires additional technical effort.

The Ad Plugin cannot easily implement custom logic for every marketer/ad-technologie-partner.

Possible solution:

One possible solution could be to create a way within Discourse or the ad plugin to reload 3rd party scripts on every page load or route changes. This would give all advertising networks the opportunity for monetization and would be more advantageous for Discourse users, with a focus on monetization.

Question: Is such a feature available already?

Why do advertising networks need to execute their custom scripts?:

They all work fundamentally on the same technology (also known as header bidding) but they are implementing additional logic such as targeting audiences, ad refreshes, lazy loading of ads, implementing special formats, and integrating user ID solutions. That is why it is really difficult to deliver a one-fits-all solution.

Advantage for the Discourse user through the use of an ad-technology partner:

The publisher can focus on creating their content while the AdTech partners handle the technical implementation for optimized ad delivery.

I look forward to your opinions and suggestions on this topic!

2 Likes
2

That’s all quite possible by either forking the ad plugin, and potentially submitting a pr, or using it as a model to create one just for your ad network (which would give you more control, but would limit your audience to self hosted and other sites that can install arbitrary plugins).

You’re welcome to post on marketplace or check out the various plugin topics like this first one I found Developing Discourse Plugins - Part 2 - Connect to a plugin outlet.

1 Like
3

Might be worth noting it seems like the ad plugin is being actively worked on

4

Someone in whose interest it is to make revenue needs to place an ad in marketplace to get a developer to help them support their specific provider.

I’ve been maintaining an ad plugin extension for a client for a while now.

5

@pfaffman
Thank you for the quick response. I would like to highlight some points regarding this:

Developer resources, time, and money: Converting our logic into a plugin for Discourse undoubtedly requires developer resources, time, and financial investment. This process involves understanding the Discourse platform, adapting our logic to its structure, and implementation, all of which entail significant effort.

Maintenance and Updates: Having our own plugin means that we are responsible for long-term maintenance and regular updates. This requires additional resources and attention to ensure that the plugin functions smoothly, remains compatible with future Discourse versions, and addresses any potential security vulnerabilities. It binds resources as well.

Considering these factors, it seems to me that in the initial step, it would be more sensible to look for a simpler solution. Are there perhaps existing plugins that reload 3rd party scripts on every page change/route change?

@merefield
Do I understand you correctly that the publisher who wants to integrate an adnetwork opens a post in the marketplace threat and asks for support with the integration?

1 Like
6

In my case the end user site admin sponsored the work without the direct support of the ad publisher.

However, all things considered, it would be fabulous if the ad publisher were to engage in the developer community and sponsor work to ensure their ads were supported directly.

My work was open source btw (in agreement with the client), so it is possible for others to benefit from that work (though I cannot unfortunately provide any free support).

If you are interested in that repo, I can DM you the basic details.

2 Likes
7

Thank you for sharing your perspective. It does indeed make sense for the publisher/admin of the site to potentially cover any associated costs, especially considering the nature of programmatic advertising where different advertisers deliver ads, often unknown until the ad is displayed. I agree that it would be beneficial for the publisher to engage with the developer community and sponsor work to ensure direct support but it’s the final decision of the publisher/admin of the site.
I appreciate that your work was open source, which allows others to benefit from it. If you could DM me the basic details of the repo, I would be interested in learning more.

So just for safety’s sake. There is no other way to integrate an ad network without the help/work of the developer community via the marketplace request?

8

Generally if the publisher requires the firing of bespoke scripts, usually it requires the intervention of a developer to link it all up.

The basic issue is that usually the code can only be “fired” once the element in question has been rendered in the DOM, which requires some scheduling in the code. This can be exacerbated by special requirements like sequence ids.

The reason for this is that Discourse is built as a web app and uses a javascript framework, so it’s slightly more involved.

1 Like
9

That is understandable. I had already referred to the web application issue in the opening post.

Thanks for your help, we’ll have a chat with the publisher. If 3rd party scripts require individual support from developers, this feature request can probably be closed.

1 Like