My name is Bojan, the maintainer of Ubercart Affiliate 2, currently working with Ryan Szrama on a new generation Affiliate module for Drupal 7, with integration for Drupal Commerce.
This is a Google Summer of Code project.
Ryan and me talked about the basic design details, and decided to put it up here for discussion.
The project has two large phases:
1) Building the basic affiliate functionality, in the affiliate_ng module.
2) Building the commerce_affiliate module which will integrate with affiliate_ng and offer Drupal Commerce integration (commissions, payments, etc).
I will be committing the first code to CVS in the next 24h.
The planned layout is similar to the one drupal commerce uses, and the module is split into affiliate_ng.module and affiliate_ng_ui.module. We use views for all listing pages.
The module provides two main permissions, "act as an affiliate" and "use custom affiliate codes".
The first role gives each user access to his affiliate center, where he can generate links, view reports (about people he brought to the site), etc. His uid is his default affiliate code (so mysite.com/affiliate/4 registers a click for affiliate who has the uid: 4). The "affiliate/" part of the url needs to be customizable at a basic level (uc_affiliate2 has a drupal variable that specifies it, for advanced usage scenarios...)
However, the user can have more than one affiliate code. If he has the "use custom affiliate codes" permission, he is able to access a page in his Affiliate Center where he can specify different affiliate codes which can be used to bring users to the site. That way he can track different campaigns and see the effectiveness of his referrals through the statistics in the Affiliate Center.
These custom codes need to be alphanumeric so that we don't mix them up with uids.
The affiliate code is an entity (affiliate_code), containing a serial id, the uid, the code itself, and the created timestamp.
Since we have the uid -> code mapping, we can check if the user still has the "act as an affiliate" permission, and if not, deny the click. That way the admin can disable certain users/groups of users. This requires a user_load each time an affiliate link is invoked, but that is unavoidable.
The clicks db table has a row for each click, with the affiliate uid, the code used, the timestamp, referrer and destination.
This provides us the desired granularity. This is not an entity since we don't need fields/revisions in this case. This data will be integrated into views through a custom handler.
The basic affiliate code (the uid) is inserted into affiliate_code the first time the user visits his Affiliate Center. This is because we have no way to react to a permission change (no API hook in Drupal...)
This is the first part of the story. After this is done, I will post more details up for discussion.
So, tell me, what do you think? If you disagree with anything I've written above, now's the right time to say it.
Also, What are you looking for in a affiliate solution?
I'm interested to hear your thoughts.