Revenue Sharing using Google's new Managed Ads script

It happens when someone who needs it and knows how to code writes the actual code and contribute it. Or when someone needs it and can't write code funds the effort of writing it.

Because the new Google code is very different from the old one, there are some design issues. For the old code we only had to replace the publisher ID and all was well. For the new code this is not sufficient, we have a unique slot ID for each ad. We cannot assume that the slot ID will be the same for each publisher.

So, what I propose as a design is this:

- We restrict revenue sharing to using blocks (managed ads) for the sake of simplicity. This will become clear in later points.
- We maintain two new database tables for revenue sharing:
* One table has the columns : uid, publisher ID (we no longer store the data in the profile module)
* The other table has an row for each enabled ad block on the site. The columns are: block id, uid, slot id.
- Provide a user interface so each user who is allowed to do revenue sharing can enter their publisher ID in the first table, and their slot IDs for each ad.
- When an ad is displayed, we lookup this tables, fetch the pub ID, and slot IDs, and emit the appropriate ad code.

Note that we now force the users to create an Ad slot in their Google Adsense account, and then enter that in the Drupal site. I don't see a way around that because of Google's new code.

If others have ideas to share, please do so. Once we reach agreement, we can see how this can be sponsored, and then provide a date for its availability.

Google is not guaranteed to keep the old code at all. In fact, I bet they will phase it out, just like they are doing with referrals.

At one point they can just pull the plug and inform everyone of the death of the old code.

Therefore, I don't think we should spend time on something that may not live for long.

So, there are no plans to port the existing old code revenue sharing to Drupal 6.x. Drupal 6.x will only have new ad code support using the design I outlined above.

If you want to contact Google and get from them a statement of direction on the old code, we may revisit the issue.

Hi,

I expect Google will reply to you with a machine-issued reply telling you to see the documentation, support groups, etc. I would be very surprised if you actually got a human to answer you.

Simply put, the way Google AdSense is now working, they really don't want you to do revenue sharing. If you're a major site, you can ask them for access to the AdSense API, and they will allow you to do revenue sharing quite easily..

As written above, the authors of the module are fine with the current module as it is. Building a revenue sharing module that WORKS using the new slot and publisher ID is a major pain in the neck (for everyone: us (the devs, the site admins, the site users, etc.).

As kbahey stated above: "It happens when someone who needs it and knows how to code writes the actual code and contribute it. Or when someone needs it and can't write code funds the effort of writing it."

He already helped with 50% of the work by outlining the architecture of the solution..

Very short answer: it won't by itself anytime soon.

João

Hello,

Sorry, but no, you didn't get the point.

We may actually be quite close to upgrading our Drupals to 6 (I personally plan to do it sometime in September/October), but that doesn't make us need revenue sharing.. The module works without revenue sharing quite well, generating ads (and unshared revenue). :)

We will be quite happy to integrate a new revenue sharing module if someone writes it.

João

Subscribing. And hoping :)

@jcnventura
>> If you're a major site, you can ask them for access to the AdSense API, and they will allow you to do revenue sharing quite easily..

Can you expand on this a little more (link to AdSense API)? Even after access to the AdSense API, you would still need to develop a module, right? If so, do you mean it would be a lot easier?

I agree with the post that said giving users the ability to create there own ads (slot ids) is a moderation nightmare for any well established site. So, i was thinking if slot id is important and does it really have to be there? Here is what I'm going after:

User creates an adsense account and only provides account ID on the revenue sharing site (just like old days). The site admin however will have all needed ads created for the site (thus all needed slot ids) and only switch account ids (just like the D5 module worked). My understanding is that slot id only controls the dimension and assigns a title for the ad (example: 200x200 ad below post). So, would it be ok to use the admin's slot ids and just change the account id according to the post author on the page being loaded?!!!

The Google AdSense API is only avaliable for sites with more than 10.000 pageviews/day. I am not even close to it, so no I wouldn't be able to get near it.. If you google for AdSense API it will give you all the info you want.

The reason kbahey and I are saying that it's a nightmare is that there is no easy way around it.. Once you use slot IDs, those are ONLY VALID with the publisher ID of the user who created that slot. To display ads that are credited to another user you need to have the slot ID for that ad (at least that ad dimension) for that user. It's a nuisance for everyone because, assuming you have 20 ad dimensions in your site, your users will have to create those 20 ad dimensions and insert them somewhere (probably profile fields).

Feel free to use revenue sharing with old format code however.. It's perfectly usable for as long as Google supports the old format.

Joao

>> Feel free to use revenue sharing with old format code however.. It's perfectly usable for as long as Google supports the old format.

New users wont be able to get old code anymore though, correct?

>> The Google AdSense API is only avaliable for sites with more than 10.000 pageviews/day

Not 10,000 but 100,000 pageviews/day!! Here we go again, small fish will never have a chance in this world. How in the heck would a start up site get that many hits/day. Well, unless you have lots of cash for marketing you might as well forget about it.

Any ideas on developing a module that doesn't depend on Ad sense, say something based off of (post views, and post ratings?!) - sorry i'm just thinking out loud.

Thanks to the developers of this module. Its functionality under D6 is useful.

I too would like revenue sharing in D6 (new Google code), and I am sure a few people must have ideas of how it can be implemented (in terms of slot IDs) (oops just noticed the first post on this page.... thats a likely start).

I would contribute financially to getting revenue sharing functionality, even if it meant some manual work afterwards for admin and/or user to get a new users sharing set up each time.

P.S. I have just built a site, Google came to my new domain after six hours, and now my new posts hit Googles main index in about 15 minutes. I get 1000 page views a day (after six days live), and I have not done ANYTHING to promote my site yet.

Go Drupal!

Or when someone needs it and can't write code funds the effort of writing it.

How much fund has to be raised to make this feature available?

hi guys just came accross this and thought you might want to know what I've been working on for my drupal 6.4 website, I am still in the progress of building it but so far the features of my module are this:

- Users can choose as many providers as they want from a list of ad providers such as google adsense, adbrite, etc.
- Users then input their Client ID for each ad provider (there is one per account)
- from a list of "ad zones" (currently left sidebar, right sidebar, header block and footer block) users can activate an ad on each zone, specify which provider they want to use, and input the advertisement ID for that provider and that zone.

- the ads will then be shown on every page created by the author. currently I have it said up to also show on any forum topic the user creates (as I wanted to encourage forum participation), but since its not possible to moderate ad content (other than through the available list of advertisers) I may turn this off (or leave it as an admin option) later.

The module core works perfectly and I have enabled it for a user of mine called "Jason". You can view Jason's blog at http://www.bottleweb.org/jason, google ads are run on the left, top and right blocks. Also if you go to the forum, any topic started by jason will have the ads, and any container where Jason was the last poster will also contain his ads.

I am still working on the interface but I have a draft up and running, here is a screenshot: http://www.bottleweb.org/bottleads_config.jpg

Note that currently the only setup ad provider is adsense. Adding new providers is simple, I have developed a php script that simply takes input such as "client ID", "ad ID", "size" and spits out a javascript, it's just a matter of writing the rules for each ad provider. As an example here are the rules i have used for adsense:

<?php

// This file will build all the required ad javascripts from clien_id, ad_id and position inputs

function build_google_ad($client_id, $ad_id, $block_location)
	{
		//first build the parts that aren't subject to variation by position

		//here is a complete code sample
		
		// <script type="text/javascript"><!--
		// google_ad_client = "pub-3265410399671521";
		// /* 200x200, created 9/14/08 */
		// google_ad_slot = "9810729274";
		// google_ad_width = 200;
		// google_ad_height = 200;
		// //-->
		// </script>
		// <script type="text/javascript"
		// src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
		// </script>
		
		//build up to the client code
		$section_a = "<center>\n<script type=\"text/javascript\"><!-- \ngoogle_ad_client = \"";
		
		//build up to the ad_id (can ignore the comment)
		$section_b = "\"; \ngoogle_ad_slot = \"";
		
		//build up to the ad_width
		$section_c = "\"; \ngoogle_ad_width = ";
		
		//build up to the ad_height
		$section_d = "; \ngoogle_ad_height = ";
		
		//build the rest of the script
		$section_e = "; \n//--> \n</script> \n<script type=\"text/javascript\" \nsrc=\"http://pagead2.googlesyndication.com/pagead/show_ads.js\">\n</script>\n</center>";
	
	if ( ($block_location == 'header') || ($block_location == 'footer') )
		{
			//if the ad is a header or footer, then we want a 728x90 setup
			$ad_width = 728;
			$ad_height = 90;
		}
		
	elseif ($block_location == 'left')
		{
			//if the ad is on the left sidebar we want a 200x200 setup
			$ad_width = 200;
			$ad_height = 200;
		}
	else
		{
			//if the ad is on the right sidebar we want a 120x600 setup
			$ad_width = 120;
			$ad_height = 600;
		}

	$ad_script = $section_a . $client_id . $section_b . $ad_id . $section_c . $ad_width . $section_d . $ad_height . $section_e;
		
	return $ad_script;
	}
?>

adding more ad providers is simply a matter of building one of those functions for each new provider.

I have also included a "special" user in the code who basically gets the space of every page that doesn't have a user on it, so its possible to display your own ads when the users haven't utilised the feature. It wouldn't be difficult to simply display your own ad a certain percentage of the time as well, this would be simple. Currently when a page is loaded the get_ad_data function is called, which looks in the database to see if that user has set up ads. If the user has not set up ads AND the page is a blog, then no ads are displayed (ie. house ads are not displayed on other peoples blogs), but if it's a forum ads are always displayed, so if the user hasn't set them up the house ads are displayed (I have disabled all house ads on http://www.bottleweb.org so you won't see them). Here is the code for the function that retrieves the information from the database about whether or not to display an ad:

<?php

function get_ad_data()
	{
		#This is a draft for the Block content
		
		#Table Structures: 
		#
		
		#ad_registrations Table:
		#-----------------------------------------------------------------------------------
		
		#uid (int(10)) - This is the ID of the user
		
		#header_ad (int(1)) - Does the user want his ad in the header (1 or 0)
		#left_ad (int(1)) - Does the user want his ad in the left sidebar (1 or 0)
		#right_ad (int(1)) - Does the user want his ad in the right sidebar (1 or 0)
		#footer_ad (int(1)) - Does the user want his ad in the footer (1 or 0)
		
		#header_ad_id (TINYTEXT) - advertisement ID for top ad
		#left_ad_id (TINYTEXT) - advertisement ID for left ad
		#right_ad_id (TINYTEXT) - advertisement ID for right ad
		#footer_ad_id (TINYTEXT) - advertisement ID for footer ad
		
		#header_ad_provider (TINYINT) - advertiser ID for top ad
		#left_ad_provider (TINYINT) - advertiser ID for left ad
		#right_ad_provider (TINYINT) - advertiser ID for right ad
		#footer_ad_provider (TINYINT) - advertiser ID for footer ad
		
		#google_id (TINYTEXT)- the user ID for google for that user
		
		#-----------------------------------------------------------------------------------
		
		#Identify whether the current page is an article created by a user in the ad registrations page
		$nid = arg(1); //locate the node ID
			
		//Query the database to obtain the corresponding user ID
		$result = db_query_range('SELECT n.uid FROM {node} n WHERE n.nid = %d', $nid, 0, 10);
		
		while ($node = db_fetch_array($result)) 
			{
				$value = $node;
			}
		$uid = $value['uid'];
		
		//If a user ID can be attributed to the page run the following block
		if ($uid)
			{
				unset($value);
				#Identify whether this user has an advertiser account registered with Bottleweb
				
				//Query the adsense registrations database (ad_registrations) to check if the user has an account
				$result = db_query_range('SELECT a.uid, a.left_ad, a.right_ad, a.header_ad, a.footer_ad, a.left_ad_id, a.right_ad_id, a.header_ad_id, a.footer_ad_id, a.left_ad_provider, a.right_ad_provider, a.header_ad_provider, a.footer_ad_provider, a.google_id FROM ad_registrations a WHERE a.uid = %d', $uid, 0, 10);
				
				while ($node = db_fetch_array($result)) 
					{
						$value = $node;
					}
					
				if ($value)
					{
						//if a user account was found store the data in a new variable
						$ad_data = $value;
						unset($value);
					}
					
				//if a user account was not found	
				else
					{
						
							
						//identify if this page is a forum topic
				
						$result = db_query_range('SELECT f.nid FROM {forum} f WHERE f.nid = %d', $nid, 0, 10);
							
						while ($node = db_fetch_array($result)) 
							{
								$value = $node;
							}
								
						if ($value)
							{
								//It's a forum topic from an unregistered user. Set user id to -1 for standard ads
								$uid = -1;
								unset($value);
								
							}
						else
							{
								//It's not a forum topic and it's not from a registered user.
								unset($uid);
							}
					}
			}
		else
			{
				//if a user ID cannot be attributed to the page, check if it's a forum.
				if (menu_get_active_title() == "Forums")
					{
						//the current page is a forum container, so display standard house ads
						$uid = -1;
					}
			}
		
		//finally, if a user id of -1 was selected, retrieve the data for that user.
		if ($uid == -1)
			{
				$result = db_query_range('SELECT a.uid, a.left_ad, a.right_ad, a.header_ad, a.footer_ad, a.left_ad_id, a.right_ad_id, a.header_ad_id, a.footer_ad_id, a.left_ad_provider, a.right_ad_provider, a.header_ad_provider, a.footer_ad_provider, a.google_id FROM ad_registrations a WHERE a.uid = %d', $uid, 0, 10);
				
				while ($node = db_fetch_array($result)) 
					{
						$value = $node;
					}
									
				$ad_data = $value;
				unset($value);
			}
		else
			{
				//do nothing
			}

	return $ad_data;
	}
?>

I have also built the code for a menu where users can customise their options (http://www.bottleweb.org/bottleads_config.jpg) and ofcourse the rest of the stuff to get the module working. Currently its still a draft and the config options aren't customisable by users yet.

I am perfectly happy to continue producing this module for myself (I'll drop by when it's finished and let you know) but if anyone likes what they have seen and want to help me (financially or with coding help) make this into a proper publishable module let me know.

I don't know much about the module being discussed here so if this isn't as relevant as I think it is then I do apologise for wasting your time.

Sorry for the messy code, I hadn't really intended it to be read by others, if you want help getting your head around it feel free to ask.

This is close to what I outlined in #1, but since this is the adsense module, we don't need to bother with other ad providers.

Also, since we are restricting this to blocks, they already have the dimensions, and all the user needs to do is to enter their own slot ID for each block. The dimensions are already known, and the block description can say where it is too.

The problem is that with a lot of blocks, the users need to enter a lot of info, which is tedious. Also, when the site admin ads new blocks, they have to inform the users to enter their slots, ...etc.

There is no way to escape that because of Google's new ad code.

yeah google's new system sucks for the little guy, not really much we can do about it. I personally think that limiting the user option to google isn't a good idea because it's difficult to get an adsense account, and the people who can get one are unlikely to start a blog on a third-party site anyway. This is why I decided to build the module with the capacity to move beyond google. Just a thought.

Well, to some extent, you are duplicating what the ad module is doing. Better join forces with the author on it then. http://drupal.org/project/ad

Chiming in for interest in Drupal 6 revenue sharing. I can't build my new site with Drupal 6 without it.

While I can't fund it presently, I'm looking into creating my crowdsourcing/revenue sharing website using Drupal 5 modules, then streaming funding from it towards this. Hopefully, before Google phases out its old system.

It's kind of absurd to be writing an AdSense module and lacking funding to do it, neh? A clickable Admin option to donate a percentage or two of pageviews to the module's author to fund development would make it easy and automatic for users of your module to donate to you. Of course, that /would/ involve implementing revenue sharing in order to do it. -sly gryn-

How much fund has to be raised to make this feature available?

+1

As you said "blocks", did you mean the Ads will only be available in blocks and not embedded into site content, like with Google AdSense Injector or via Token?

And from what I understand (which may be very little of course) http://drupal.org/project/ad and Bottleads are two completely different pairs of shoes. Advertisement is an Adserver, Bottleads would do pretty the same like Adsense Module, but for more than just Adsense (Adbrite etc.). I think you guys (kbahey and armsch6) should really consider to join forces! That would be so great!

A clickable Admin option to donate a percentage or two of pageviews to the module's author to fund development would make it easy and automatic for users of your module to donate to you.

+10 for that. This is how it's done in WP and other systems.

Revenue Sharing is very important to me. It's such a pity that it's not supported by the new version of the module. Although the "old" Adsense code works perfectly. It's even used on their own sites (blogger.com etc.) and it will possibly take years until Google will completely kick it...

Just my 2 cents.

Subs

I would be interested in helping to finance this initiative. Budget is tight, but here's what I'd be looking for in terms of features:

1) In the Adsense Module you could define via check boxes the type of User Profiles that can participate (e.g. Anonymous, Authenticated, Writers, etc.).

2) In the Adsense Module you could define via checkbox what type of nodes/content types that revenue sharing applies to and what the percentage revenue sharing would be via a dropdown menu in 5% increments (e.g. Page 50%, Blog 20%, etc.).

It would then be nice if the blocks that were generated via adsense would somehow correspond to the selections you made. For example, a block would be created for every check box that was ticked....I'm not exactly sure what would be the best on this, but some programmers might have a clearer idea.

I'm relatively new to this and can only describe the functionality.

If anyone wants to get involved I would be willing to put forth some or all of the development costs. However, I don't know how much this is going to cost, so it is hard to say.

Cheers,

The Carbon Pig

Personally I think Adsense Revenue share is a good option, and allows a web site to create content which it would otherwise not get.

I started recently another site which is using a fully functional Adsense Revenue share module http://www.tipnews.net where the system used is Pligg
http://www.pligg.com/

see http://www.pligg.com/modules.php

I promote the idea via http://www.tipnews.net/webmasters.htm

The way it works is the poster can (optionally) add their ADSENSE code pub-xxxetc in their profile, then if any posting they made creates a click to a GOOGLE AD the system generates a random number between 1-100 and if that number is <50 then the user gets 100% of that ads revenue.

If the random number is 50-100 then the site gets 100% of the revenue

Google is not involved in the system, since the revenue if shared either/or rather than being split 50/50 per ad.

I understand that the 50/50 can be varied but see no reason to change that.

The concept of ADSENSE REVENUE SHARE is being discussed within the webmaster community via

http://www.webmasterforumsonline.com/forum_posts.asp?TID=8276&PN=1&TPN=1

which may help some Drupal webmasters understand the ups and downs of the idea. Clearly not all sites will benefit, but for me CONTENT is key, and the more pages of relevant information I can get the better.

50% of a little is better than 100% of nothing!!!!

@websi7: the revenue sharing functionality currently supported by the module (that means AT THIS MOMENT), is already capable of doing what the pligg module you described is doing and possibly more (i.e. you can choose whether it's 50-50 or 80-20 or whatever).

What we're discussing here is something that would:
a) Require more effort from the users than just providing their Publisher ID (read the thread to understand why)
b) Continue working if and when Google decides to disable the old format code.

I invite you to use the adsense module and to try it.

João

bump

Happy to pitch in some funds on this also if there is an idea of what it will cost?

I think setting it so that the module maintainers take 1-2% of all revenues is brilliant if possible although not sure if that is an 'approved' Drupal practice. Heck - you can have some of mine!

Subscribing.

Hi,

The 1-2% idea is indeed interesting in that it could easily pay for the development of the module.

The problem with the 1-2% is that it relies on the honesty of the end-users. Don't forget that this is open-source.. A simple search in the code search would turn up the lines that create those 1-2% ads and it would be so simple to just delete them.

I could try running the whole part of the 'get the publisher ID' through a PHP obfuscator to prevent that, but I am not sure if I would still be allowed to publish the module and distribute it here in Drupal.org after that.

I would appreciate your further input on this matter.

João

My 2 Cents: Implement this on a voluntary base. There will be enough of us who are willing to give 1,2,3 or 5%. Everything else would be commercial, not "open" :)

I had meant my suggestion to be open, and opt-in, certainly.

A clickable Admin option to donate a percentage or two of pageviews to the module's author to fund development would make it easy and automatic for users of your module to donate to you.

I would be more willing to have it as an opt-out until the contributions pay for the development, and then switch to opt-out later..

And indeed, the user should not be forced to 'donate' if he doesn't want to.. But I would like to force him to at least, read the instructions. :)

João

Is anyone currently working on this?

I'm considering putting up a reverse bounty and chip-in widget and tackling this.

I'm going to be seeing if I can organize some funding for building a new Adsense Sharing module for Managed Ads, and I wanted to know what the maintainers think as far as where the module should be located on drupal.org. Is it something you wanted bundled with the main Adsense module, like the old Adsense sharing module, or would you prefer it to be a separate module (so there's less to maintain in the Adsense module, or whatever other reason you might have)? I'll be posting my plans for developing the module soon, probably in the 'Projects Needing Financing' group on groups.drupal.org, with links to it from the Adsense issue queue and the 'Paid Drupal services' forum. What are your thoughts on this?

I've scribbled some ideas out on paper, and I'll be posting my initial plans for this soon.

I think this should be part of the standard adsense module. I mean a separate module, but within the adsense project.

As for the design, I outlined my thoughts in #1. The site admin need to advertise "slots" with specific dimensions. Each user who participates in revenue sharing need to enter their publisher ID (like they do with the old code).

Moreover, for each slot that the admin defines, the user needs to either their own slot ID from their account. If the admin adds a new slot, or deletes an existing one, the users need to enter their own corresponding slot.

Tedious, but that is the only way so far.

Yes, I agree.

Do you know if you can have ads from multiple publishers displayed on the same page simultaneously. For example, if the site's admin create's a new slot, but the user hasn't entered a slot ID for that slot, yet, could we display the ad for that slot with the site's publisher and slot id, while displaying the other ads with the content author's publisher and slot id's? Or would google's javascript interfere with all of this? Or does no one know, yet?

I'm also thinking about adding functionality for the site admin to add additional publisher/slot id's for people/organizations that aren't content producing users of the site, kind of as a charity (based on the idea talked about in previous comments for givings adsense developers a percentage or two of the site's page views).

Do you know if you can have ads from multiple publishers displayed on the same page simultaneously. For example, if the site's admin create's a new slot, but the user hasn't entered a slot ID for that slot, yet, could we display the ad for that slot with the site's publisher and slot id, while displaying the other ads with the content author's publisher and slot id's? Or would google's javascript interfere with all of this? Or does no one know, yet?

I think you can have different ads with different publisher/slot IDs on the same page. I have not seen anything against it. And if this is just a fallback, then so be it.

I'm also thinking about adding functionality for the site admin to add additional publisher/slot id's for people/organizations that aren't content producing users of the site, kind of as a charity (based on the idea talked about in previous comments for givings adsense developers a percentage or two of the site's page views).

That would be good too. Has to be documented. Perhaps a separate module.

Hi,

Some things seem obvious:
a) this functionality would be part of basic Adsense support, so it should be part of the module
b) you're totally free to take the existing code and do whatever you want with it, but I would rather that you help us improve the module than duplicating efforts.

If you were proposing to do it for free (or waiting for someone really interested to sponsor it 100%), I would have no problems, but what you're proposing is to ask for money upfront and that changes things. I am not against it (and I can't) but I have to know a bit more before I can say I am for it.

Basically it comes down to a couple of things:

1. Are you willing to maintain it in the future? I mean actively maintain it, port it to Drupal 7 (and maybe Drupal 5, if you feel generous). I have looked at your track record in Drupal.org, and of the four modules you maintained, you've abandoned two, passed ownership of the other and are only actively maintaining one. It is good, but your level of commitment is not that impressive.
2. If you're going to profit from it (and users are going to pay for it), they should at least have some assurance that the value is fair, so I would like to know how much you're going to ask for it before I can say whether I would approve it (and that would mean including the chip-in widget in the module's page, if kbahey also approves it).

At the end of the day, I am willing to keep maintaining the module, however I wouldn't feel happy to be improving/maintaining someone else's code that just developed it, got paid by the users and then moved on leaving the code in someone else's hands.

João Ventura

Are you willing to maintain it in the future? I mean actively maintain it, port it to Drupal 7 (and maybe Drupal 5, if you feel generous).

I'd been about to write in about the importance of backporting to D5, since that's what I'm using right now. Then I realized that the only reason I am using D5 right now is because the current AdSense with Revenue Sharing module doesn't have the revenue sharing for D6. All the other modules I use have been updated to D6, and it's only this one module that's preventing me from upgrading my site to D6. So, I guess I'm posting this to illustrate the collossal non-importance of a D5 backport for the planned module.

jcnventura

It is unrealistic to expect someone will maintain a piece of software forever.

We can ask him to continue to maintain it, and it would be nice to have that, but realistically people get distracted, lose interest, ...

Someone else from the community will need it and will pick it up (like you did) because they need it. Or will ask someone to port it and pay them. If it falls into being unmaintained it gets dropped.

What I focus on before accepting is that it has good design, is simple and clean. Therefore it will be understandable to others and maintainable. If it is overly complex, convoluted or has bad design, it will not be accepted.

As for Drupal 6 or 5, it should be for 6 for sure. Drupal 5 if he or his customer needs it, but it is not at all necessary.

Actually, there IS a port of the revenue sharing module in D5 for D6. It's included in the module.

João

@kbahey: regarding #40, of course, I am not expecting someone to maintain it forever.. I am just asking for some kind of 'warranty' period.. gcopenhaver wants to get paid upfront to do this, so I would expect the normal conditions of a contract (even if the code is GPL) i.e. to know what he wants to do, when he will deliver it, how much is he going to charge for it, and something (6 months or whatever) in which he will maintain it. Specifically, in 6 months, Drupal 7 will be coming out and the module will have to be ported. He has the knowledge for that (his User Permissions module has been ported to D5 and D7).

On the other hand, I would really like to remind everyone what we're discussing here, because Satori42's comment in #39 made me realize that some basic facts of this discussion may not be general knowledge.

Google has two methods of creating AdSense ads:

1. Old code method. The AdSense interface no longer creates ads with this method. BUT IT STILL WORKS. Some Google (and partner) sites still create ads using this code (e.g. Blogger). Using revenue sharing with this method is trivial and the only thing that the user needs to do is to create an AdSense account and provide the publisher ID. You can use this method NOW with Drupal 5 AND Drupal 6, just enable the revenue sharing module that you have installed in the system.

2. Managed ads method. All ads generated in the AdSense interface currently use this method. The main change is that a lot of the settings that used to be in the old code are no longer provided in the ad's HTML. Instead, they are stored in Google and accessed via a combination of the user's publisher ID and the ad identifier. To enable revenue sharing using this method the module will have to provide a form where the users can submit not only their publisher ID (as they do now), but also ALL the slot IDs which are usable in your site. Your users will have to create the ads in Google AdSense, then come back to your site and provide these slot IDs. Of course, you'll have to provide them guidelines on the best color schemes to be used, but in the end, you won't be able to control their look. There's no escaping this bureaucracy, independent of gcopenhaver's design for the module. Revenue sharing with this method is not yet supported for any version of Drupal, and is the subject of this (long) thread.

If anyone asks me, until Google stops supporting option 1, I wouldn't bother with setting up option 2 for revenue sharing sites. Why? Because it's actually a PAIN IN THE A** to ask each of your users to create 4 or 5 (or 10+) ad units in AdSense and then come back to your site to insert the slot IDs in the appropriate form. And if they don't then the revenue sharing won't really be working because without a publisher+slot ID pair, the system will fallback on the backup setting (which if done right would actually be revenue sharing using option 1).

João

This is GPL software: NO WARRANTY! :-)

Let us not raise the barriers to contribution.

gcopenhaver can get paid, contribute the code and that is the extent of his commitment if he choses to. I would thank him for this, and include the code, if it is good quality and easy to maintain. Everyone benefits from the contribution since there are new features they can use. For maintenance, the community then takes over, not just kbahey and jcnventura. ANYONE can submit patches. EVERYONE is encouraged to do so.

Of course, gcopenhaver can be a better open source citizen and continue to get involved. He then gets karma points for that, and can even become a maintainer with CVS access if he shows commitment, and continued involvement.

Whether he gets paid upfront or not paid at all should not be a factor in all this.

I didn't mean that type of WARRANTY. I specifically said some kind of 'warranty' period, meaning a commitment as part of the 'contract' to maintain the code (and by contract here I don't mean a REAL contract, just a statement of intentions to be included next to the chip-in widget).

Of course he can just say: absolutely no maintenance, what you get on the first release is it, and just fix it if it doesn't work. I just think that whoever will chip-in to whatever he will ask for it should know what they're paying for. If that's 0 days of maintenance, fine by me, but I think that should be known in advance.

I am still thinking that letting the module pay for itself as discussed in #21-#32 makes a lot more sense.

João

Supported Drupal versions

• Drupal 6.x
• Back-port to 5.x
• Port to 7.x

I will finish the module for Drupal 6.x before back-porting to 5.x, and then working on 7.x. I will port to 5.x because there are more likely going to be more people interested in a 5.x version now (and possibly some that will be stuck with 5.x for a while, due to various reasons), than there are a 7.x version since Drupal 7.0 will not be released for some time. I do not expect the port to 5.x to require much time. I will then proceed to port to Drupal 7.x, which will take a little more time, and when the port is "finished", I will still need to occasionally update it for any new changes to the 7.x api as it is developed. An official 7.x release of this module should be available within days (or just hours) of the release of Drupal 7.0, assuming the AdSense module has a release for 7.0 (and I'm willing to help with that).

Features

• Admins will use the existing AdSense and Managed Ads modules for setting the default site-wide Publisher ID and Slot ID's. These will be used by default on non-node page views, and as a fallback if the author of a node has not filled in their Publisher and/or Slot ID's
• Users can enter their Publisher ID on a 'Google Ads' tab on their user page.
• Users can (aren't forced to) enter at least one Slot ID for each ad format, with currently used ad formats marked so the user knows they should at least add Slot ID's for them.
• Shared page view percentages for a node's author can be increased or decreased based on role and/or content type.
• If an admin changes which ad formats are being used, they can notify any affected users (users without a Slot ID entered for that ad format) with a message displayed on the top of the page (this assumes users will login relatively regularly...I'm also considering notification by email).
• Admins will be able to post recommended color scheme's for users to consider when creating their ads.
• Admins will be able to enter any other Publisher ID (and it's associated Slot ID's) to share page views over the entire site (except when a node author's ad is displayed).
• Admins will be able to choose users individual, or by role, to share page views with over the entire site (except when a node author's ad is displayed).

This list is not necessarily complete. I may add more features as I come up with them, or are requested by others, as development continues. Feature requests are welcome at any time, before or after completion of the module. I intend on making the module very flexible, but will strive to make it as simple to use as possible for both admins and users.

Testing

• Make sure all forms are validated properly, to reduce or eliminate any possible xss or sql injection threats
• Verify that page views are shared at the intended percentages
• Ensure that normal page view performance is not slowed down significantly

Documentation

• Drupal Handbooks for detailed documentation
• README.txt
• Display help information for both administrators and site users in the actual site using the module
• Thorough code comments/documentation

Maintenance

• Provide support for this module
• Fix any bugs found in this module
• Add features
• I am willing to become an AdSense module co-maintainer, to commit code for this module, and possibly other AdSense sub-modules.

This isn't necessarily a complete list of everything I plan on doing, and I am open to considering features not mentioned here. If the maintainers of the AdSense module are willing to give me CVS access to the AdSense module, I will commit the new AdSense Sharing code to Drupal's CVS servers periodically, allowing anyone to track my progress.

I estimate that I can complete everything within a two month time-frame. I am setting the ChipIn to $6500.

ChipIn page: http://gregcopenhaver.chipin.com/drupal-adsense-sharing

Please post any comments, questions, or suggestions here or through my contact form. This is posted in the Projects Needing Financing group as well.

After some reconsideration, I'm dropping the price down to $3000. And it seems that some people have gotten the idea that I have a client for this module, but I do not. It's purely out of interest in the module and to earn some [much needed] money.

Since gcopenhaver is indeed promising to maintain the code he does, $3000 doesn't seem that much to me, but bear in mind that there are only 5000 users of the module. I am not sure you'll get to raise that much money by April 28.

What me and kbahey could do to help is to place the chip-in widget in the module's homepage, where it will get a lot more traction that hidden here in this thread.

If he agrees, I can edit the page (and in the process I will move most of the information currently there to a handbook page).

João

We already ported this revenue sharing module to d6 with features to enable sharing per role, let me find it and I will post our version here, could jmpstart your project....

Patchak

I agree with posting the chip in on the project page.

If we get the code from patchak, then all the better.

I have modified the home page to move all of the detailed stuff to a documentation page. Some of the features must be added back to the page, but since the previous content is incomplete, I will do that later.

One problem, though.. My documentation team privileges don't allow me to add an object to the page.. So, I have added a simple HTML link to the chipin.com page.

kbahey (or anyone else reading this with higher privileges) if you can use Full HTML filters can you add the following:

<object width="250" height="250"><param name="movie" value="http://widget.chipin.com/widget/id/7671a4adeb75431c"></param><param name="allowScriptAccess" value="always"></param><param name="wmode" value="transparent"></param><param name="event_title" value="New%20Code%20Revenue%20Sharing%20"></param><param name="event_desc" value="%243000%20are%20needed%20to%20develop%20a%20new%20Drupal%20AdSense%20module%20for%20revenue%20sharing%20using%20Google%27s%20new%20Managed%20Ads%20code."></param><param name="color_scheme" value="blue"></param><embed src="http://widget.chipin.com/widget/id/7671a4adeb75431c" flashVars="event_title=New%20Code%20Revenue%20Sharing%20&event_desc=%243000%20are%20needed%20to%20develop%20a%20new%20Drupal%20AdSense%20module%20for%20revenue%20sharing%20using%20Google%27s%20new%20Managed%20Ads%20code.&color_scheme=blue" type="application/x-shockwave-flash" allowScriptAccess="always" wmode="transparent" width="250" height="250"></embed></object>

Here is the file with some instructions :

To use, enable this module, as well as Adsense Core, Adsense Managed
Adds and Revenue sharing basic (old). The only reason for the latter
is expediency - we reuse some of it's settings.

At admin/settings/adsense/publisher - configure the site client ID and
set the module to "Adsense Role Revenue Sharing"

At admin/settings/adsense/publisher/revenue_sharing_basic select the
user profile field (create it first if required)

At admin/settings/adsense/publisher/adsenserolerevenue configure the %
for each role (the highest will be used)

Place block/code/etc as normal

Would be nice if a little mention could be made on the project page that geekomatik.com sponsored this feature!

Thanks,
Patchak

Anyone interested in the advertisement system I built for my website? http://www.bottleweb.org

Let me know.

@armsch6: I take it you're using revenue sharing using Google's old AdSense code. If so, did you use the existing revenue sharing module? If not, why not?

João

No it's not the old code, and I made my own because I wanted a module that allowed users to advertise with other providers as well.

Please, everyone interested in this test the code I posted in no. 52...

Patchak

@armsch6: it seems you've already implemented in part the system which gcopenhaver is asking $3000 to create.. I used the test account, and indeed you're using the new code. However, I notice you haven't used the core AdSense module to create the ads for you, so the applicability here would be limited.

However, if you're willing to share the code GPL-licensed, maybe something useful could be made out of it..

I notice that in 5 days no one contributed a single $ to gcopenhaver's chip-in, so I am highly doubtful that the goal will be reached in the 14 days remaining. I think that the deadline may need to be extended a bit.

João

Ok I can do that. The way it is now users can't modify the size of their google ads (only adbrite ads), and can't pick the colors of their adbrite ads. I have built a system for doing this but it's a little buggy so I ditched it. I start work and uni again tomorrow so this is really a bad time, I can't really work on this right now but when I make some progress or get this stuff on CVS as a beta I'll let you know.

By the way what's with the chip-in stuff? Does that actually work? I mean I'd love to get $3000 for my work but I can't really imagine anyone willing to give money for a drupal module... But then I am a student...

@armsch6: I'd actually be more interested in the code you have now as it seems to work and might give ideas to others on how to do it.. Since you're not using the core module, obviously we're not able to use your code as-is. However, if you don't want to let others see your code at the moment, I understand.
As to the chip-in.. It seems to work well for core Drupal. When a chip-in widget is placed in the front page it gets LOADS of money. Apparently for the issue being discussed here, I guess people just aren't interested in having to pay for it.

@patchak, thanks for the code.

@armsch6, we are not implementing a standalone ad system here. This project is for adsense only. there are other multi provider ad modules, for example http://drupal.org/project/ad. As jcnventura said, we are interested in providing the revenue sharing for the existing adsense module which works quite well.

@patchak and #armsch6, If you are willing to contribute it under the GPL, then please submit patches, and discuss with gcopenhaver (offline?) if you can split the work and/or bounty among you.

Mental note: This issue has been open for many months. I wonder if it was the bounty that caused the code to suddenly show up. Why didn't it show up earlier? I am not expecting an answer to this, just wondering ...

I also posted the reverse bounty on the project page. the style needs some adjusting though. Can someone revise that?

@kbahey: Now that the content is under a filter which I no longer have access, you're the only one who can edit it (or another documentation admin user).

João

@kbahey, well in that case my project won't be of much help to you. adding the actual code for the ad was quite trivial, for adsense it looked like this:

/**
 * @file
 * Compiles javascript for the Google Adsense Provider
 */

//This file has access to the following variables:
//$ad_data, $block_location

//$ad_data contains all the variables for placing the ad, $block location contains 
//an integer describing the location of the block that will display the ad

//Here is an example of a google adsense javascript:

// <script type="text/javascript"><!--
// google_ad_client = "pub-3265410399671521";
// /* 200x200, created 9/14/08 */
// google_ad_slot = "9810729274";
// google_ad_width = 200;
// google_ad_height = 200;
// //-->
// </script>
// <script type="text/javascript"
// src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
// </script>

//This function customises the following parts:
//google_ad_client = "$client_id"
//google_ad_slot = "$ad_id"
//google_ad_width = $ad_width;
//google_ad_height = $ad_height;

//first build the parts that aren't subject to variation by position

//build up to the client code
$section_a = "<center>\n<script type=\"text/javascript\"><!-- \ngoogle_ad_client = \"";

//build up to the ad_id (can ignore the comment)
$section_b = "\"; \ngoogle_ad_slot = \"";

//build up to the ad_width
$section_c = "\"; \ngoogle_ad_width = ";

//build up to the ad_height
$section_d = "; \ngoogle_ad_height = ";

//build the rest of the script
$section_e = "; \n//--> \n</script> \n<script type=\"text/javascript\" \nsrc=\"http://pagead2.googlesyndication.com/pagead/show_ads.js\">\n</script>\n</center>";

//default sizes for different ad zones
$menu_extra_defaults = array(
  0 => array(200,200),
  1 => array(768,90),
  2 => array(120,600)
);

//customizable sizes listed here
$menu_extra_values = array(
  0  => array(728,90),
  1  => array(468,60),
  2  => array(234,60),
  3  => array(120,600),
  4  => array(160,600),
  5  => array(120,240),
  6  => array(336,280),
  7  => array(300,250),
  8  => array(250,250),
  9  => array(200,200),
  10 => array(180,150),
  11 => array(125,125)
);

//the block locations are created below in the zone_array() function
if ( ($block_location == 2) || ($block_location == 3) ) {
  //if the current ad block is in zone 2 or 3
  if ($ad_data['extra_options'][$block_location][0] != FALSE) {
    //if the user has modified the default size settings, extract them here
    $ad_width  = $menu_extra_values[($ad_data['extra_options'][$block_location][0])][0];
    $ad_height = $menu_extra_values[($ad_data['extra_options'][$block_location][0])][1];
    
  }
  else {
    //if the user has not modified the default size settings, use defaults
    $ad_width  = $menu_extra_defaults[1][0];
    $ad_height = $menu_extra_defaults[1][1];
  }
}

//now for the other zones

elseif ($block_location == 0) {
  if ($ad_data['extra_options'][$block_location][0] != FALSE) {
    $ad_width  = $menu_extra_values[($ad_data['extra_options'][$block_location][0])][0];
    $ad_height = $menu_extra_values[($ad_data['extra_options'][$block_location][1])][1];
  }
  else {
    $ad_width  = $menu_extra_defaults[0][0];
    $ad_height  = $menu_extra_defaults[0][1];
  }
}

elseif ($block_location == 1) {
  if ($ad_data['extra_options'][$block_location][0] != FALSE) {
    $ad_width  = $menu_extra_values[($ad_data['extra_options'][$block_location][0])][0];
    $ad_height = $menu_extra_values[($ad_data['extra_options'][$block_location][0])][1];
  }
  else {
    $ad_width  = $menu_extra_defaults[2][0];
    $ad_height  = $menu_extra_defaults[2][1];
  }
}

$ad_script = $section_a . $ad_data['client_id'] . $section_b . $ad_data['ad_ids'][$block_location] . $section_c . $ad_width . $section_d . $ad_height . $section_e;

Although I suspect this won't be of much help... If you guys can tell me a specific aspect of the project you are having troubles with, maybe I can help by showing you how I did it.

@armsch6: thanks for sharing the code.. It's pretty basic, but having seen your site interface, I see that it does the work that it was designed to do..

The code here is not handling any of the publisher ID rotation, but we have those routines already.. The only thing here that might be useful would be code to relate the slot IDs (your Advertisement ID) to the publisher, but in your case that's easy as you have the codes fixed to certain blocks/areas.

There may be a HUGE bug in your code (which will also show up in ours when that gets done): what happens when a user declares an ad in AdSense that's a different size than the one declared in your Drupal site?

João

jcnventura: Basically what happens is the ad is forced to fit into a frame that is either too big or too small. It doesn't affect the margins of the site, the ad just looks strange. I'm working on a fix to let users change the size of the frame to fit the ad if the sizes are not the defaults, this isn't too much of a big deal to do. To stop this being a concern I wrote some tutorials that clearly outline what users need to do, and what the limitations are.

You might be interested to know that this isn't a problem with adbrite ads, because the size data is not stored in the javascript. This was part of my reasoning for including adbrite as the second provider. Haven't bothered to add more, but I wanted at least two.

To be honest I think the biggest limitation of the adsense idea is that users need a website to even get an adsense account, and who with a website is going to want to blog on a website they don't own?? It makes no sense.

What do you mean by relating the slot IDs to the publisher? The database tables look like this:

      CREATE TABLE {ads_registrations} (
        uid int(10),
        ad_provider int(10),
        client_id VARCHAR(255),
        active_zones VARCHAR(255),
        ad_ids VARCHAR(1000),
        extra_options VARCHAR(10000),
        PRIMARY KEY (uid)
      )

the "ad_ids" entry is an array of what google calls "Slot IDs". The "ad_provider" entry contains an integer representing the type of advertiser (whether adsense or adbrite for example), "active_zones" is an array of block zones which are active (this corresponds to the array entries of "ad_ids") and "client_id" is the ID for the account with the advertiser, which - in the case of google - is the publisher ID.

kbahey I don't care about the money or whatever, this did not cost me anything close to 3000$ If I put it here it's to share it...

I did not see this issue until a couple of days ago, when i saw I could maybe some people some money I posted it, weird how these simple things can be misinterpreted...

Patchak

Oh and this is a new module, I don't see why it would need a patch? What should it patch?

I read across this Thread and just want to point on not dropping the old code in future releases. The old Adsense Code still works. And revenue sharing with old code works well too. Even if you can not generate the old adsense code in the google adsense backend, I am shure google will not drop support of old adsense code. Google has thousands of publishers, many have inserted their code manually without a script. If google would block the old ad codes they would lose scope. Think back to amazon affiliates. They switched their direct link design few years ago, surely they still support the old link structure. And I am for shure, google will handle this the same.

For revenue sharing the new code is quite unusable. Like mentioned before, it is not possible to theme size and color by ad code. It is very complicated for users to use the new ad codes and can only be done by workarounds. Ad size in page must be the same as in adsense account etc. In the end it is unsuitable forcing users to setup the same settings in adsense account which you use in your site. Giving users the ability to use ad size they like would screw up most templates...

As long as Google supports old ad code , there is no need for a (unsuitable ) revenue sharing with new ad code. And I hope focus for adsense revenue sharing Modul will remain on the old ad code.

Cheers

@armsch6: regarding #64, Google already confirmed that users using some sort of revenue sharing scheme can provide the revenue sharing site when registering to AdSense (I don't have time now to search for it). Also, as explained so well by 911 in #68, it is possible to use old format AdSense code to do revenue sharing where the admin has full control of the colour and size of the ad, and where you don't need to bother the users with providing the slot IDs. You could use this module to build the ads for you, if you don't want to bother with that hassle.
regarding #65: I would have to see a dump of your ads_registrations table, but it seems for each ad you're storing the publisher ID and the slot ID.. The code works, but you won't get any style points for that. There's a reason why MySQL (and the others) is called a relational database: you don't duplicate information like that.. I guess you'll have time to learn it in the future (see http://en.wikipedia.org/wiki/Relational_database).

@patchak: at one point there was a revenue sharing by role module in the old Drupal 5 branch of the module. The current code doesn't feature that, but I really don't think that there needs to be two modules for that.. A simple variation on the settings form and in the client ID selection function is all that is needed here. That's what kbahey meant by a patch: someone (you or someone else) should take a look at how your code works, and create a usable patch for the existing revenue sharing module (the old code one).

Now that I am thinking of it, a revenue sharing module for the new code should try to build on the existing module, by improving it and providing extension points that could be used by the new code revenue sharing..

@911: it's nice to see that after 68 comments on this thread someone finally understands the point that I have trying to make (since at least comment #11).

@jcnventura : yeah the new code uses the old code for some settings, etc... It could be patched to the old code, I'm not sure I have the time to do this in the next days but anyone is welcome to take this code and make a patch out of it.

I think a adsense revenue shaing module should only allow users to enter their adsense ID and that's it, site admin should keep control of everything else.

Patchak

@jcnventura: Wow some brutal feedback there... I'll look into the old adsense stuff, that would be a good idea and I wasn't aware that the old code worked like that. For my module though, the thing is that I don't want to limit myself to adsense, so allowing users to define their own structure for adsense within my module would require a significant rewrite in order to make it still work with the other providers. The simple Provider/user ID system works well for most ad providers, and allows me to simply add additional ad providers without changing the code.

In regards to the database stuff, there is no redundancy in my structure. The only inefficient aspect is the use of arrays within the database, and this was to give the code scalability (ie. the ability to add extra zones without having to touch the mysql structure), it basically means that instead of having 4 columns each consuming x bytes, I now have one column consuming 4x + 3 bytes (3 extra bytes for the array delimiters).

Here is an example of the database, if you're interested:

uid: 4
ad_provider: 0
client_id: pub-3265410399671521
active_zones: 0|1|2|3
ad_ids: 3078392837|0905541564|5250633057|7132352359

@armsch6: sorry, hadn't meant to be brutal :)

Now that you've shown the data, I can see it's not as bad as I thought it was.. You're not creating 4 records, one for each ad, but instead you create a single record for each user with the different ads using an exploded array.. That does indeed give you some style points, but not the maximum score.. Then again, maybe I have spent too much time with databases created by DB gurus.. Usually, you'd create another table with a record for each ad ID and then JOIN them later for use. However, since you're limiting your code to 4 ads, it's probably safe to do as you did, as long as the exploded array doesn't exceed the field size (100 chars is indeed more than enough for that).

As to the use of the AdSense module in your module.. It would take some time to explain, but basically you'd use the module as back-end to create the ads for you, leaving your current front-end intact.. The only interface would be at the time of writing the ads, where you'd call the adsense_display() funciton with the necessary parameters, followed by a str_replace of the publisher ID when your module determines that it's going to use a user-owned ID instead of the site ID. That would take care of generating the adsense code for you and you'd be able to use the AdSense module options to set the ad colours (groups).

João

To all the fence-sitters, out there.. If you're really interested in having new code revenue sharing, please chip-in.. The module won't happen without your support.

$0 in 2 weeks is really, really discouraging. At this rate, we won't make it to $30 in the next 3 weeks, let alone $3000.

João

what I don't understand is why anyone would not even post a review of the code I posted. There is a module right there doing a lot of what is needed here...
Would be cool to collaborate!!

Patchak

@patchak: well, I didn't do a full review of your code, but my comment on #69 applies fully as a review.. Your code only extends the basic revenue sharing to provide a role-based percentage sharing. As I said before, there was a contributed module to do this in the 5.x-2.x branch of the module, but I don't think that the role-based percentage is so important that it deserves a separate module. This can be trivially merged (i.e. a patch) in the current revenue sharing module.

The code for the old role-based sharing is here: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/adsense/con...

Besides the role-based percentage your module adds nothing new, and this thread is all about the ability to use revenue sharing with the new AdSense ad code.

We gladly accept your collaboration offer, but really, the module is already composed of 7 sub-modules. Adding a new one for a simple additional option to one of the existing modules is not the way to go. Since you already know the code and you (probably) have the capability to test it, just add the role-based percentage control to the existing module admin file and add a couple of lines when determining the percentage to include the author's roles (in addition to the author-based percentage) and select the max value of these.. Your code is doing most of this already..

João

Who needs the new code?
I'm using the old code and doing adsense revenue sharing, there's no reason yet to not continue using the old code, it is so much simpler and it will always be time to update to the new code in case they really stop supporting the old code, which is not happening yet :-)
And $3000 to develop the adsense sharing is really joke, who will be developping for this amount, bill gates himself?
It's so easy to do adsense sharing without even the adsense module, you simply add a profile field in the user account, and show it at registration time, then in node.tpl.php you call the author's data and if he has filled the adsense id field, you check it for validity (pub-XXX) and if it's fine you insert it in your old adsense code, depending on a percentage, like 60% of the time for the author, the rest for you.

And $3000 to develop the adsense sharing is really joke, who will be developping for this amount, bill gates himself?

If you think $3000 is too much, then offer to do it for a better price...otherwise please don't waste our time with ridiculing the only offer to build this module, or restating how the old adsense sharing still works (the issue here is that some people want adsense sharing to work with the new managed ads, rather than the old ads). If people don't want to pay that much, then that's fine. My resources can be better used elsewhere than to get less than $3000 for this module (which is already a relatively cheap price considering what a lot of Drupal developers get paid, and the features and maintenance I offered). If people don't contribute enough money by whatever date I end the offer, I won't build the module, and I'll just refund whatever money people have contributed up to that point, and everyone that wants this module will have to continue to wait for another (hopefully cheaper) offer to build it.

Yes, please excuse me, you're right. I understand people want to use the adsense module with adsense revenue sharing and can't code.

@alliax: really, you should try to think before you type these comments. You depend on software written by people who provide it to you for free, but they still need to eat (and maybe provide for their families). Offending these same people may just get them angry and move somewhere else (Joomla would be happy..). So next time try to use something called empathy and think whether you'd like to be on the receiving side of those comments. Anyway, you've already somewhat apologized, so I thank you for being so fast in doing it.

João

@Patchak: Hi. If i use your module i can use managed ads for adsense sharing? i get it right?

@Marco: No, patchak's code has nothing to do with the main point of this thread.. It's simply a variation of the current revenue sharing, with the ability to assign different sharing percentages according to the user role.

@jcnventura
Thanks for explanation.

gcopenhaven:

3 days to go and only $25 was raised.. It seems clear that there's not enough interest to make this pay what you need in advance.. I don't know if there are any fees associated with returning the money to those who contributed, but I would ask you to consider whether it's helpful to keep the chip-in alive.
I feel that the code you're proposing to do will be needed in the future, but maybe it's time hasn't come yet. I know I have been playing both sides of the question here, as I know that the current code works and is a lot simpler to use than what would be possible with a revenue sharing solution for the new code, but I also know that it takes time to develop something right and what you're asking seems appropriate.

To those who contributed (yes, the two of you), my sincere thanks.. To those who would profit from the use of this code, but who prefer not to contribute, well, thanks also.

João

The chip-in dealine has gone. Setting this back to postponed (for a long time).

João

PS: kbahey can you return the module page to a simpler input filter, please?

Joao,

I removed the bounty. Filter reverted. Added you as a maintainer.

At least we tried. Others willing to contribute code can give this another try by submitting working and tested patches for review.

This probably will not get a lot of traction until the old code stops working. Then you will have a ton of users asking why everything is broken. That is when you will see someone forking over a lot of money to upgrade this module to the new adsense code.

The thing is that there's no reason for the old code to stop working. The new code has been created only to make it easier on the adsense publishers who are not at ease with HTML, such as lots of bloggers who don't host or manage their blog themselves.
The new code hasn't been done for adsense but for its users, so there's no reason to stop supporting the old code.

I just gave refunds to the two people that chipped in money for this module, as promised. Sorry it was so late...I just started moving less than two weeks ago, on the very day that the chipin ended...still have a few things left to move and lots to unpack. I just got internet here at the new place a few days ago, and finally found some time now to look at doing the refunds.

I wanted to implement revenue sharing and discovered my site was utilizing the new google ad code. I figured let's try reverting my new code to the old code. Well, I was able to track down some old ad code here: http://www.hooverwebdesign.com/articles/old-google-adsense-codes.html and they work fine on my site. Hope this helps someone.

Also, fwiw, I read somewhere on the google site that it's not ok to have new & old ad units on the same page. But it's ok to have them on different pages.

To use old ad code, you only need to enable and use the old code ads sub-module that you can find in the adsense module. The module will create the old code format for you.

João

Subscribing.

Subscribing.

Subscribing.

@jcnventura Hi,
I am new to this and really dont understand how to user the old code with revenue shearing can you or maybe some else plz explain how to implement the this option?
Thanks, Avi.

You have to enable the revenue sharing module and follow the instructions provided in the help section in admin/settings/adsense/publisher/revenue_sharing_basic

this needs to be moved to 7.x branch.

Is this possible with the new code yet?

No. Even though with the responsive ad feature, the implementation became a lot more user-friendly: it went from impossibly-annoying to irritating.

Instead of each user having to create their own ads in each different size (about 30 different ads) and inputing the resulting ad codes correctly, now they simply have to create one single responsive ad, and provide the code for that one ad in addition to their publisher ID. Of course, if they don't follow the rules correctly, and instead code a 728x90 ad, instead of a responsive one, and that gets inserted in a 125x125 ad slot, the ad will overlap your site's content - or Google will ban your site.

I believe the old-style ads still work. Use them in the revenue-sharing ad slots. It won't break your site, and the right ads will show, so Google will have no reason to ban you.

I'd like to show image ads on my site, and hope someone can find a solution to show the new google ads and not old text only ads.

I am willing to put money towards this if anyone is interested.

I'm planning to add this soon to the module. The twist will be introducing at the same time, an opt-out donation to support the development of the module and of Drupal core (more details).

You can always disable the 1% revenue sharing at anytime, but I believe there will be more people being generous if I do it opt-out instead of opt-in. The module will also be very public everywhere that the 1% donation is the default setting.

Subscribing