I have a basic non-U.S. visitor redirect system in place.

First, you need to get GeoIP set up on your server, which I detail in my post MaxMind GeoLite Country and GeoLite City Made Easy

Once that is set up and running properly, follow these 2 steps:

1) Download my GeoIPFunctions.php file and put it in your GeoIP folder on your server.

Be sure to change the parameter on line 6 to match your server setup.

2) At the top of your PHP landing page, put this code:

Again, make sure the path in the require_once matches the path to your GeoIP files.

Now when non U.S. based visitors come to your landing page, you can send them to another offer that accepts non U.S. traffic.

This system is very simplistic, and a setup that forwards any individual country's visitors on to a specific URL would be a better solution, but I'll leave that for later.

Yesterday, I came across the TechCrunch article about people on Wickedfire being up in arms about large amounts of invalid clicks, and was relieved to find out that others saw the issue, and Facebook was on to solving it.

Today, in my Facebook Ads Manager account, I got the following message:

"Recently, we have detected an increase in invalid clicks on Facebook. Your account was impacted and as a result, we are crediting your account. Your credit has been automatically deposited into your Facebook account and will apply toward future advertising campaigns. Your credits expire December 15, 2009."

The amount they credited me was about 75% of what I felt were "missing" clicks, so I'm pretty happy that they were close to the same number on their side. I'm sure as they fine-tune their invalid click detectors, that number will be closer to true.

Update: The #83 Alexa rated site has a search box that is vulnerable to link injection.

Update 2: I used a social bookmarking service to bookmark the vulnerable pages, pointing to one of our affiliate sites. I'll collect ranking data now, and 6-8 weeks from now to see if there is any measurable lift from having links to the page that "links" to our site.

Even before these splogs popped up, I had been interested in GeoIP lookup techniques for Google Maps mashup purposes, but the splog trick finally made me figure out how it was done.

DISCLAIMER: I don't condone the use of these techniques for deceptive advertising techniques. At best, they are disingenuous, and at worst, may be illegal, according to the FTC. Like The Force, this technique can be used for good or evil. Which path you choose is up to you.

MaxMind has a paid GeoIP City database service that costs $370 up front and $90 a month for database updates, which they advertise as 99.8% accurate in determining location from IP address. However, they also make a free database available, that is 99.5% accurate. We'll cover the free version since the accuracy difference is negligible for our purposes.

The crucial information is spread out over four pages on the MaxMind site:

APIs for GeoIP products
GeoLite Country information
GeoLite City information
and our API of choice, the GeoIP PHP API

It should be noted that the GeoIP PHP API has three methods of being implemented, each being more efficient with webserver resources than the previous: a pure PHP module, a PECL module that allows you to embed the GeoIP C Library inside PHP, and mod_geoip, an Apache module that you can access via PHP. Since our needs are fairly minimal, we'll go with the easiest to implement, the pure PHP module, which requires no PHP or Apache changes.

1) Download the following PHP files from MaxMind: geoipcity.inc, geoip.inc, and geoipregionvars.php .

2) Download the latest GeoLite City Binary Format file, which is updated on the 1st of each month, and gunzip it.

3) Put all of those files in their own directory somewhere on your webserver, and for this example, we'll name the directory GeoIP.

4) Put the following code in a web-accessible PHP page, changing the PATH/TO parts to match your setup, and view the page in a web browser:

The database says I'm in Los Angeles when in fact we're in Mission Viejo (Orange County), which isn't a huge deal, but shows the possible slight inaccuracy in IP->location lookup.

One thing this could benefit from is a quick state abbreviation to full state name conversion function, so the text would be "Los Angeles, California" instead of "Los Angeles, CA". I think the full spelling looks more natural in some instances. I've uploaded a PHP state abbreviation to state name conversion function for your use.

Update: Danger Brown steals the show for GeoIP made REALLY easy. He's got a two line javascript snippet that does the same thing, but is reliant on the MaxMind servers each time the script is called. My experience with using javascript that is resident on outside servers is that it works great until it doesn't. One day your site will be slow or completely down because the outside javascript is failing to load. Some well crafted code can mitigate the risk, but I prefer to have all executing code on my server. Except for Google Analytics, because I tend to be no match for their servers.

Update 2: I've uploaded my modified geoipcity.inc that includes the abbreviation to state/province function, with ON->Ontario included, and the call to that function in GeoIP_record_by_addr. Note that I could have also put the $record->region_name = Abbreviation_GetStateName($record->region); code within the _get_record function, but I chose to put it in the higher-level GeoIP_record_by_addr function.

Update 3: SEOcracy.com has a post about a very simple way to use the Google javascript API to do geolocation

Thinking I was a clever chap, I thought I'd try some hyper-targeted ads to dating services, with headlines like "29 and single in L.A.?" and target 29 year old people in the Los Angeles area. Facebook quickly came back with a Disapproved for the ad, and encouraged me to abide by their targeting rules for dating ads, in Section 10.

As an aside, the headline of the ad they let me create initially was "29 and Single in LA?", which to the observant reader is not Los Angeles, but rather Louisiana, because they have a rule against not allowing two punctuation marks in a row, specifically the .? I wanted to end the ad with. Bummer.

After following all the targeting requirements, my ads were still getting disapproved. I sent an email to the Ads support address, and about a day later, they responded that the landing page was not targeted, meaning, the page was not specifically for 29 year old people in Los Angeles. Bored with all their requirements, I wandered off to find trouble in other places.

Fast forward a week, and I'm presented with this ad on Facebook:

Yes, the lovely Mullet Family, in all their glory, calling to me, a Class of 1991 high school graduate. From previous Internet experience, I guessed this to be a Classmates.com ad, but thought "Wait a minute, how can they do that, Classmates.com is not all about the Class of 1991, is Facebook giving them preferential treatment?", until I clicked on the ad:

The landing page IS targeted to the Class of 1991, URL and all. Clever. It seems that all it takes to make Facebook happy is a few bucks for a targeted domain name, and a terrible looking, but highly targeted landing page. So what I need is 29AndSingleInLosAngeles.com, and a picture of a 29'ish looking person on my landing page. I'll give that a try and report back on my level of success.

Update 1: FAIL, my first shot at creating an ad for the landing page was Disapproved, because Facebook Ads policy states "The ad text may not mention any user attribute such as age, gender or location unless it is directly relevant to the offer." I'll create a more generic ad that goes to the highly targeted landing page and see how that goes.

Update 2: A few weeks ago, I noticed Facebook ads with my age and location in both the headline and the ad text. I have also had ads approved with the user's age in the headline, and the user's age, location (U.S. state) and gender in the ad body. Once I get some CTR data on how this type of targeting performs, I'll post again here.

One issue that has popped up is that I have been seeing the keyword AJmain show up in searches from MyWebSearch.com for one of my campaigns, and couldn't figure out what it was. I put a negative campaign keyword in for it, but after seeing it again in my tracking data, I dug into it a little bit more.

The incoming link looks something like this:

http://search.mywebsearch.com/mywebsearch/AJmain.jhtml?qid=0fba4305452cb2a61dc1c57dbc92633e&pg=AJmain&ord=20&action=click&p=AJmain&tpr=jrel4&ptnrS=ZUxdm523YYUS&searchfor=KEY+WORD+HERE&si=&ct=RR&st=kwd&ss=sub&cb=ZU

Notice that there is a 'p' parameter, which it turns out Tracking202 is using to get the keyword, as some search engines pass the keyword in that parameter. Not so for MyWebSearch.com; they use the 'searchfor' parameter to carry the keyword that was searched by the user.

The URL-parsing code is in three different files, and I've posted a bug report/possible fix in the Tracking202 forum. Take a look there for more specifics. I'll update if and when the developers get back on the report.

Update: Keyword GGmain from MyWebSearch.com shows up too, with the same issue. The link looks like:

http://search.mywebsearch.com/mywebsearch/GGmain.jhtml?qid=aee506c433e0ba6ae18155ac1557a2c6&pg=GGmain&ord=20&action=click&p=GGmain&tpr=sugrs&ptnrS=ZKxbn045TQUS&searchfor=KEY+WORD+HERE&si=&ct=RR&st=hp&ss=sub&cb=ZK