Not sure what on-screen positions you’re working on, but would it be possible to insert an ad every Nth post? And conditional on whether a user is a guest or not?
I run Digital Point Ad Positioning | XenForo community on one of my Xenforo forums to insert an ad randomly within the post content for guests only. That ad placement pays over double of any other ad slot. Similarly, I know of other forums owners who make 1/2 their revenue off that particular ad position. None of us show it to registered users, as it’s too intrusive, but if a guest is swinging by without choosing to become involved with the community, then we don’t mind monetizing them a bit more aggressively.
Especially since the ad world is moving (slowly) to viewability as a key performance metric, inserting ads between posts will maximize visibility of those posts since Discourse only loads those ad calls when the page is actually loaded.
Actually, ideally the ad is called several posts before it comes on screen, so that there’s time for the back and forth with all the ad servers (RTB auctions) to happen so the ad is ready to go when the user scrolls down.
I really, really appreciate the work on this. No worries if other things are a priority and these feature requests don’t happen, just wanted to add feedback from the POV of someone who spends a lot of time using DFP to traffic ads on forums.
Good ideas! Yes, we should add placements between posts in a topic. Right now, we only have ad units above topic lists, above the first post of a topic, and above suggested topics at the bottom of a topic.
The adsense plugin has a setting to hide ads based on whether they’re logged in and based on trust level. The default is to hide ads for logged in users at trust level 3 and higher. I think that’s the best way to do it.
You could keep it separate, if you distinguish between ad types and know exactly which positions are for classic or programmatic (display) ads, and which are adsense/performance ads.
In most cases though you’d want a 2nd call or backfill with adsense on your large banner positions.
That’s why we’re thinking about exactly the same thing: merging DFP and Adsense plugins is the way to go.
The header JS is normally designed to fetch all the ads in one call, so you aren’t making roundtrips for each ad location. And then the specific ad slot JS just says ‘put ad 1 here’, ‘put ad2 here’ etc. It’s very useful for the power user, but a lot of errors happen with this header JS + location slots style setup because people who don’t understand what’s happening write their head JS to call all ad IDs that are served on any pages of their site, even though any one page will only serve a subset of those ads. It creates all kinds of discrepancy issues in reporting.
Alternatively, admins can use standalone tags in each ad location that both fetch the ad and locate it. This adds round trips since you’re not doing all the ad calls at once, but it’s simpler. It’s also probably the best way to handle ads in a single-page app like Discourse, because if there’s an ad every 10th post, and there’s 500 posts in the thread, you don’t want to fetch 50 ads on initial page load. I’m not sure how to code it, but you only want to fetch the ad when it’s about to be shown. Otherwise networks will pay you lower CPMs since most of those 50 ads are never considered to be viewable (50% visible to the user for at least 1 second).
DFP, Adsense, and many other ad networks emit JS tags–all of them will emit standalone tags for each ad slot, most of them also support building ad tags of the header + location js style. So in some ways, the discussion of Adsense vs DFP is mute. Just go into the Adsense or DFP dashboard, select an ad and generate the tags and put them in the correct slots.
So at the end of the day, I don’t want something that lets me auto-auth with DFP or with Adsense. If you build something that auths with the DFP or Adsense API, then you’re hurting my flexibility to switch adservers, pass in custom variables to DFP that I might use for targeting, etc. The added convenience gets in the way of a power user, reduces flexibility if I want to use a different ad server, takes a lot more time to code, and is more brittle if DFP or Adsense changes their JS. All I want is something that says ‘header js’, ‘ad slot above topics’, ‘ad slot above first topic’ etc and ‘if guest’ etc.
Sounds like there’s a bit of confusion here.
Adsense doesn’t allow ads to be refreshed on a page. So yes, you can serve auto-refreshing ads via DFP, and I do so using some other ad networks, but for ad slots where I serve Adsense, I can’t enable that feature. Sucks for Discourse because that means on a 500 post thread you can only serve 4 adsense ads. I wouldn’t be surprised to see this change in 3-5 years, but Google is leery of people trying to game the system.
DFP does let you setup Adsense to compete dynamically against other ad networks using the Dynamic Allocation feaure, so it is a great way to serve Adsense if you also have a daisy chain that includes other ad networks like OpenX, Casale, etc.
However, most people who just run a little bit of ads use straight Adsense, without using DFP. And I wouldn’t in the least recommend they add on DFP–it’s powerful, feature-packed, and complicated, so most of these folks are better off sticking with straight Adsense and focus on generating more pageviews. Only after they have significant traffic is it worth the time to learn how to use DFP to traffic multiple ad networks.
If you go with what I described above of just creating slots for people to insert ad tags, then it’s really simple to generate ad tags within Adsense and copy/paste them in without needing to use DFP.
I would hate to give up on trying to parameterize it into a plugin. Before quitting, we should break down exactly what parameters the plugin is missing. I think a lot of the options in DFP are not applicable to ads that would be shown in Discourse.
I know it’s easy for you, but most people who traffic ads can’t write that type of plugin at all… they know how to copy/paste ad code just fine if they’re given slots in a UI, and they frequently edit ad tags by inserting custom variables, timestamps, etc but that’s very different than writing rails/ember code.
I get that you’re trying to make things simple, and build a nice experience, but I think you might end up building a tool that frustrates both power users and non-power users:
DFP has a lot of options. Making ads responsive, async vs sync tags, auto-refresh vs not, passing custom variables, single request vs not. Making responsive ads for example is kind of tricky because it depends on which ad sizes the user is trafficking.
Anyone who uses DFP is, by definition, a power user. Non-power users generally get frustrated and quit using DFP. I know a number of forum owners who just choose to run adsense or hard code sponsor ads because they get confused every time they open DFP.
You can decide to build a plugin that offers a subset of the available DFP options, but then you’ve just built something that connects to a tool that only power users use, and they’ll get frustrated because your plugin actually gets in their way for the one oddball setting they want.
Remember, these type of plugins that are basically just ways to inject ad code are popular in the Wordpress/Drupal/Xenforo world because it hits that sweet spot of not requiring writing actual code, but still allowing a user to paste in the pre-generated ad code and then tweak it slightly. Think of the product manager who is comfortable looking at existing code and changing a variable value from 60 to 30 or tweaking the HTML, but can’t actually write/edit complete functions… that’s about the technical sophistication level you’re targeting in DFP users.
To me, it makes no sense to try to build an API connector/GUI when you can build something that caters to their power user whims by just giving them slots to paste in ad tags–and save your engineering time as well, both upfront and in ongoing maintenance. Plus decent GUI’s already exist for them to build their ad tags: http://dfpgpt.appspot.com/ Many folks who use DFP build their tags with this, and then edit it slightly to do what they want. No sense in reinventing the wheel there.
If you want to build a API-based experience, then you should stick with Adsense. That way you’re building a WYSIWYG tool for the folks who want it and who don’t have the ability/interest in tweaking some random setting.
I just think if you go down the road of trying to connect to the DFP API, you’ll have two sets of frustrated users:
The power users who like DFP but are frustrated that this plugin doesn’t give them the tweaking ability that they want
The non-power users who like the ease of this plugin but are frustrated that you’re forcing them to use DFP which is a confusing morass if you’re not a power user type.
If you want something that works for both users, go with the blank ad spots:
The non-power users won’t mind because they are accustomed to the flow of ‘go into adsense > generate ad code > blindly copy/paste into my CMS ads plugin’. Or ‘sponsor sends me an image > I create html tag > paste into ad slot’ and they skip dealing with DFP.
The power users will be happy because they can still edit the ad tags, and the ad insertion is now handled for them, since they can’t code the plugin to actually insert the ads.
That’d be great if it was possible. However, there’s no one-size fits all because the options are based not just on Discourse, but also on policies of the advertisers that are being trafficked.
Adsense pays reasonably well if the ad unit has a high CTR, by policy only allows 4 slots per page and doesn’t allow auto-refreshing ads. OpenX allows auto-refresh every 60 seconds, max of 6 slots per page. In general, I make more money if I show more ads, unless it’s a really high-performing Adsense slot. So I want to specifically designate 2-4 units to be adsense-compatible and the rest auto-refreshing. Does the GUI allow me to specify which ad units are auto-refreshing?
An advertiser wants to target ads against threads in certain categories. So I add a custom variable in DFP tags that says ‘category = $cat’ and then within DFP I target the line items only at that variable. Similarly, Adsense by policy will ban you for running adsense on certain pages like login/logout/contact us, etc. Other networks don’t care. So I add a custom variable that says ‘if [url or template] = login/logout/contact us, then custom var adsense = no’ and adjust the targeting within DFP. How does the GUI allow me to add custom variables?
Responsive ads are a royal pain. In a 300 width ad unit served to a mobile device, some admins are willing to run 300x250 because it pays better, some only want 300x100 because they think the 250 height is too intrusive. If the ad unit is locked by this plugin to supporting 300x250, there’s no simple way within DFP for me to say ‘only run 300x100 at mobile’. There’s some hacky ways to pull it off by creating duplicate line items within DFP and careful targeting, but that’s forcing an ads trafficker to do the equivalent of ‘if IE 6, then use this entirely separate set of CSS…’
Again, I think the goal of ‘connect your keys and go’ is great.
I just think that you need to realize that a GUI-based plugin won’t be able to support all the scenarios, and power users will get frustrated having their options constrained.
So only non-power-users will be happy with a GUI-based plugin. Which is great–there’s a lot of folks like that who would love a ‘connect-and-go’ plugin… except you’re forcing them to use DFP, which non-power-users generally find befuddling and frustrating compared to just using straight Adsense. Seriously, trying to learn DFP for a non-power-user is more frustrating than learning how to copy/paste Adsense ad tags.
Pick your users, figure out their expected behavior, and play to that.