I'm in the UK, my server is in USA.

My own searchfeed implementations pass the IP of the browser to searchfeed with the query and they (SF) geotarget the results they send back.

I just realised that it looks like this plugin doesn't do that - I'm getting USA targeted ads, different from those I get from doing one of my own SF searches.

I could easily imagine that the plugin sends the server IP, but the thing that confuses me is that I thought the search and the click had to come from the same IP to be valid, and it does seem that clicks from the plugin are being counted.

But allowing SF to geotarget the ads would be much better.

Hi,

Unfortunatly, I'm not sure this is possible :/ The IP address that is passed along, is simply your servers IP address, and not yours. AFAIK, there is no way to pass that information along to SearchFeed, in an attemp to get more geographical targeted ads. Sorry :(

Cheers
Andy
Programmer/Designer/LinksSQL Freak

---

http://www.ultranerds.com
http://www.imagesql.com

I think you will find that SearchFeed say that is what you must do (pass the user's IP with the search).

In my own implementations, I get the browser IP using:

$ip = "$ENV{REMOTE_ADDR}";

I'm actually quite concerned that your way works at all - because one of the anti-fraud and anti-cache measures PPCs use is to ensure that searches and resulting clicks come from the same IP. I did do a test to confirm (I think) explicitly that a particular search and click were recorded at SearchFeed using the plugin, but I do think there is a very high risk that they might already be disqualifying some clicks from the plugin (they would be the high calue ones of course) and/or that they might pick up in this mismatch at some point in the future and break the plugin.

On a related matter: if you do <%Plugins::SearchFeed_Results::check_results($query)%> at the top of a page and then display results further down the page, does this result in one or two search calls to SearchFeed?

Thanks - I do think this is worth getting "just right" as supplementing a directory with relevant PPC results is very powerful combination.

Regards

Stewart

Hi,

I know what your saying.. but thats not the case =)

When someone clicks the link, it doesn't matter where they come from.. their REMOTE_ADDR is defined, and sent to SearchFeed's system, when its recorded (and fraud checks etc run, before giving the cash to you =)).

Ideally, the need a way to define the "target" area. For example, adding;

&zone=UK

.. but this isn't possible, AFAIK

Cheers
Andy
Programmer/Designer/LinksSQL Freak

---

http://www.ultranerds.com
http://www.imagesql.com

Sure - the IP address of the click is taken care of automatically. Nothing to do there.

But when you retrieve XML search results, you have to pass an IP address - and to quote SearchFeed:
"The value for the parameter is the IP address of the person who performs the search. On most systems this is the REMOTE_ADDR parameter that comes with the HTTP request."

So your code has to get the users IP and pass it to SF in the XML request string. I've been given 3 reasons for that being a requirement:

1) Anti fraud. Tells them that the search and resulting clicks are being done by the same person.
2) Anti cache. Tells them the searches have not been done by one machine, stored, displayed later, then clicked from another. You're not allowed to cache SF results.
3) Geotargetting. Searchfeed do deliver geotargeted ads if they have them.

Now, we can see that 1) and 2) don't seem to be very tightly applied as we know we are getting paid for SF clicks through this plugin, but we can't rule out the possibility that the mismatch of IPs is preventing some clicks from being paid after some fraud filtering. I don't think SF reports on clicks that haven't been paid (unlike RevenuePilot for example who show a very depressing list of all the clicks they haven't paid for).

But 3) is very important and can have a great bearing on clickthrough rates.

I haven't noticed this before when making US-targeted areas because the ads were in keeping with the page content, but as soon as I saw the plugin results on a UK-targeted page it stood out.

It may or may not be important enough for you to do something about it of course - that's your call

Regards

Stewart

Hi,

Should be simple to do then =)

..find all occurences of; (in /admin/Plugins/SearchFeed_Results.pm)

Code

..and replace with;

Code

..and then just before the;

Code

..part, add;

Code

Hope that helps.

Cheers
Andy
Programmer/Designer/LinksSQL Freak

---

http://www.ultranerds.com
http://www.imagesql.com

Thanks Andy - I will give that a try and report back.

A supplementary question above got missed while dealing with the main matter:

If you do <%Plugins::SearchFeed_Results::check_results($query)%> at the top of a page does this retrieve and store results for use later down the page, or just check there are some? In other words, does checking then displaying mean you send one or two search calls to SearchFeed?

Thanks

Stewart

Hi,

No problem. Currently, it does 2 checks (1, to make sure that results are found.. and another to actually get the results).

Unfortunatly, its a case of finding the time to make the changes (its totally possible to do it in one query.. but I didn't know how to previously =))

Cheers
Andy
Programmer/Designer/LinksSQL Freak

---

http://www.ultranerds.com
http://www.imagesql.com

Good - the code changes above work and give geotargeted results.

For completeness, I should add that I realised another "REQUIRED parameter" (Searchfeed definition) is missing from the URL that retrieves te XML from SearchFeed:

"trackID=X9999999999" - the trackID is displayed top left of your SF account pages under User ID. Why they need two IDs in the URL - when they define/supply them both - I really don't know, and - again - the code seesm to work without it although they suggest it won't.

In any case, it's easily hard-coded into the URLs in the .pm file in the same way as is documented above.


Stewart

Hi,

I'm not sure why/what that extra trackID does, so I can't really add it in... as it could well be for unique category pages/unique searches, or something totally different.

However, I have updated the plugin (1.6 now), as well as the Readme that comes with it (looked a bit "outdated", to say the least <G>).

Please find the new version attached.

Cheers
Andy
Programmer/Designer/LinksSQL Freak

---

http://www.ultranerds.com
http://www.imagesql.com

No, I don't know what it does either - one unique ID in the URL should really be enough for them to identify the partner, but there is one and only one trackID for each account (it doesn't vary according to type of search etc), so I would suggest it could (should) be treated the same as the ID you already use - capture it in the plugin setup and use it as a variable in the searchfeed URL.

Reading the SearchFeed page on their XML feed (the one with the table that describes each of the parameters and gives sample URL) this is "REQUIRED" (their emphasis) but the frustrating thing about SF - as has been borne out by this thread - is that they don't seem to back up their strong words with action.

The danger of course is that they might just implement something overnight that enforces their "REQUIRED" items and everything not using trackID breaks.

Stewart