it outputs the JavaScript code for a YPN wide skyscraper. When invoked as

affad.pl gsw

it outputs the JavaScript code for an Adsense wide skyscraper. Add additional cases (for other YPN and Adsense ad types) as necessary.

(Actually, my version of affad.pl is a very elaborate script that outputs code for YPN, Adsense, commercial affiliates, and other things besides.)

STEP 5:

Enable SSI on your web server, if you haven't already done so. (Sorry, you'll have to figure that one out by yourself.)

STEP 6:

In your HTML code, add a directive like:

<!--#exec cmd="/var/www/cgi-bin/ypn.pl ysw gsw" -->

STEP 7:

To test the code, visit the page where you added the "exec cmd" directive. Hopefully, you will see a YPN wide skyscraper (or whatever ad you specified as the first argument to the ypn.pl program). This assumes you are in the U.S., and the first two numbers of your network address fall within the us.dat database. Then, temporarily delete your network address from the us.dat file, and do a page refresh. You should now see an Adsense wide skyscraper (or whatever). Remember to undo your previous edit, restoring your network address to the us.dat database.

STEP 8:

Start adding the SSI directive to other pages on your website(s).

STEP 9:

Start earning YPN revenue (hopefully).

NOTES:

--The findus.pl program, and the resulting us.dat file, includes class B networks assigned entirely to the U.S. (according to MaxMind). It excludes class B networks assigned partly to the U.S. and partly to foreign countries. Yes, you will lose a considerable number of U.S. visitors this way. But it plays safe, follows the KISS principle, and speeds up execution (see below). Modify the code as necessary to deal with mixed-location class B networks, but this complicates things, increases the likelihood of false negatives, increases the size of your us.dat file, and slows down ad serving. (Using the isus.pl function, I wrote a separate script to analyze my webserver logs from the past two months. It shows that one of my sites has ~30+% U.S. visitors, and the other ~35+% U.S. visitors. The actual U.S. visitor counts/percentages are greater than this, for reasons stated above, but not by much. Given the nature of my sites, it seems entirely plausible that most of my visitor traffic is "foreign".

--I have verified the correctness of the us.dat file by manually inspecting a hundred or more randomly selected cases, comparing the us.dat entries (or omissions) against the source GeoLight Country Database. Sort the us.dat file if you wish, but that has no bearing on its operation.

--I have verified operation of the ypn.pl and isus.pl tandem many, many times, by removing (then restoring) my network address(es) as described above.

--I was surprised by how fast this all executes, even on my underppowered web server (1.8 GHz Intel Celeron, 512 MB RAM, Apache, SUSE Linux 9.3). I expected to see a noticeable delay for ads appearing, but instead they show in a split second. Fearing that my web server was not up to the task of doing real-time, on-the-fly processing in this way--this is the biggest reason I had refrained from attempting foreign visitor filtering before now.

This all works for me. Your Mileage May Vary. I make no claims, offer no warranties in your case. Make of this as you wish. And, please, I will not respond to any "stickies" asking for technical support. I will only clarify issues in this WW forum as needed.

With my approach, I get a false negative (is this a U.S. visitor?) ~6% (or less) of the time. (Given how I do it, there should be no false positives.) That is to say, my quick-and-dirty solution gets it right (at least) ~94% of the time. Importantly, the chance is near zero that I will incorrectly identify a foreign visitor as a U.S. visitor (then serve him/her YPN ads).