Wandering Thoughts archives

2005-10-29

Affiliate marketing is undead

Dear Internet marketers: affiliate marketing schemes that pay money are dead, killed by spammers. Please get over it and find a marketing technique that doesn't cause spam and attract spammers. (And if you are actually a spammer hiding behind 'affiliates', sorry, no one believes that any more.)

Affiliate marketing pays people for traffic. When people are being paid for traffic, spamming becomes the most cost effective way of generating it. So people spam. Anyone who opens their eyes can see this all over the Internet.

On today's Internet, spam is the inevitable consequence of 'affiliate marketing' schemes. There is a word for people who knowingly do things that cause spam: in many eyes, it is 'spammer'. (Or worse, for people who are trying to profit from spam without catching the blame for it.)

The other inevitable consequence is a bad reputation, because you can't throw a stone at spam without turning up (claimed) affiliate marketing or 'pay per click' programs. Consider that my referrer spammers, my comment spammers, and even the spam blogs I found are all doing it.

Affiliate marketing should be dead. But people prefer not to see this or believe their scheme will be an exception. As a result, affiliate marketing schemes lurch around the Internet, shedding spam everywhere they go, dead but still moving. In short, undead.

Unfortunately, I believe that this means that Google AdSense is probably doomed. And as the spam blogs I found demonstrate, spammers are already exploiting it. (Google can work to stop spammers, but there are lots more would-be spammers than there are Google people working to stop it.)

(If you don't 'pay' affiliates in money but instead use moderate discounts of not very liquid merchandise, you may be able to survive. See Amazon.)

spam/AffiliateMarketingIsUndead written at 21:20:27;

The problem with If-Modified-Since as a timestamp

The If-Modified-Since header in HTTP requests is used as one way of doing 'conditional GET' requests, where the web server can give you a nice bandwidth-saving '304' response if the URL hasn't changed since the version you already have. In theory the header has an arbitrary timestamp and the server will 304 the request unless the page has changed since that time.

In practice, the HTTP RFC strongly recommends that clients treat the value as a magic cookie, just repeating the value the server last told them. Unfortunately, not everyone does this. This is bad, because it is very difficult for the server to use If-Modified-Since as a real timestamp.

To accept If-Modified-Since as a timestamp, your last modified time has to go forward any time a change is made. Or, to put it another way, you have to guarantee that your last modified times will always go forward. This sounds nice in theory but is extraordinarily difficult in practice, even for static web pages.

For example, here's a bunch of things you have to consider for static pages on Apache on Unix:

  • did I rename the old 'page.bak' to 'page.html'?
  • did I rename a higher-level directory to flip to another version of an entire section?
  • did I change rules in a .htaccess file that affects the page?
  • did I modify the web server's configuration files, ditto?

(Even if Apache made all these checks, it still couldn't guarantee that I hadn't just had to flip a backup server with a not yet fully up to date copy of the website into production when my main server exploded.)

Dynamic web pages have it worse, in part for the reasons in Pitfalls in generating Last-Modified; they have more moving pieces and the moving pieces don't always come with change times attached.

Doing this right requires the application generating dynamic pages to find out any time anything affecting those pages changes. There are 'total control' applications like that out there, but not very many, as such total control has significant costs (for a start, everything has to go through the application).

DWiki is honest about not being able to make its own timestamps always run forward, and thus requires strict If-Modified-Since matching as a minimum. To do otherwise would run the risk of erroneous 304s, which in my opinion are much more serious than some extra bandwidth used.

(People with more constrained bandwidth may feel otherwise. But in that case they should fix their clients to use ETag.)

web/IfModSinceTimestampProblem written at 02:07:00;


Page tools: See As Normal.
Search:
Login: Password:

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.