Official Google DFP plugin feedback


(Bcguy) #1

Can I use this plugin just with Google DFP? I don’t want to use Adsense - I have my own advertisers I work with directly.

Also - Amifrid - you mentioned that you did some customized JS code to insert other ad slots between the topics - can you share that code by any chance (or have you already?)

Thanks.


Core Advertisements
Google AdSense plugin
(Jeff Atwood) #2

The one we are building will be DFP only, as that is the preferred way from Google’s perspective and it works better with JS only sites.


(Bcguy) #3

Any estimate on when this might be released (or what version it will be released with?).


(Jeff Atwood) #4

I know we had a goal of getting that out by the end of the week, @neil has been working hard on it.


(Neil Lalonde) #5

The code is available already, but I haven’t had time to document how to use it at all. Even the readme has nothing… :blush:

https://github.com/discourse/discourse-google-dfp

Give it a try in a testing environment, if you’re brave.


(Jeff Widman) #6

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.


(Bcguy) #7

Jeff - definitely a good idea that I agree with. Here is what I originally asked for in a spec. Not sure what they’ve implemented either.


(Neil Lalonde) #8

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.

@BCHK I’ll be looking at your list for features.

From looking into DFP but not using it myself, it seems like it’s a superset of AdSense. Is there a point in having a separate AdSense plugin?


(Jens) #9

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.


(Neil Lalonde) #10

Also, DFP has an API to refresh the ads asynchronously, which is perfect for Discourse. AdSense doesn’t. I want to be able to say that DFP is what to use if you want to render AdSense ads.


(Jeff Widman) #11

A couple of quick clarifications:

  • A basic ads plugin is really just a javascript container(s). Normally there’s some JS in the header + some JS in the specific ad locations.
  • 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.
  • The confusion probably stems from some plugins for other CMS’s that try to make things easy with point-and-click connections. Particularly in the Wordpress world, there are plugins that let you auth with the adsense API, select the ad you want to serve and the location, and they’ll serve it. But really, all they’re doing behind the scenes is generating the javascript and copying it over. In my opinion, this isn’t something @neil should be building. Just create the ad slots and the UI and let us copy/paste the tags. That lets us decide whether we want to use async vs sync tags, generate special variables to pass into DFP, etc.
  • 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.

  1. 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.

  2. 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.

  3. 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.

Hope this is helpful.


(Neil Lalonde) #12

That would be a plugin that allows people to inject arbitrary html and javascript into plugin-outlets in Discourse’s templates, and wouldn’t have much to do with DFP/AdSense anymore. If you really need to use totally custom googletag api code and html markup, then you can make a plugin to inject that into the plugin-outlets fairly easily.

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.


(Mittineague) #13

In addition to the universal Admin Customize locations, the 4 existing Topic plugin-outlet locations look good.

* the edit title outlet is not shown in the screen shot


(Jeff Widman) #14

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:

  1. The power users who like DFP but are frustrated that this plugin doesn’t give them the tweaking ability that they want
  2. 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:

  1. 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.
  2. 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.

(Kane York) #15

Isn’t the point of this to pick the options that work right for Discourse and let you just plug in your access keys and go?

It’s using DFP because there’s no other choice. And there’ll be a guide to put in the right values in the console, if that’s what’s needed.


(Andy R) #16

API for AdSense makes sense but for DFP it does not. It’s very common to customize your DFP header code to use custom targeting criteria.


(Jeff Widman) #17

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.

Examples:

  • 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.


(Neil Lalonde) #18

Ok, I think you’re right that this plugin is more suited to AdSense, and the one customer who uses DFP in a simple way. They use it because they are selling ad space directly instead of letting AdSense choose which ads to show, and are also targeting geographically. Those features don’t affect the javascript code that needs to be pasted into the head and body, so this plugin is working for them. But it sounds like it will work for almost no one else.


(Bcguy) #19

No - it works fine for me too. Most of my advertisers are using pretty simple definitions. The requirements will depend upon the type of advertisers that the site caters too.

We’re healthcare focused and we’re good with this definition, it would work for all the advertisers we’ve had so far.


(Ladydanger) #20

Hey @neil
Great plugin - I’ve just tried this in a development environment with a dummy code and it works a treat!