I am having problems sending details to Yahoo of users on my site.
Here is the code I am using -
$xmlDoc .= "?mkt=us&keywordCharEnc=latin1&outputCharEnc=latin1&adultFilter=any&maxCount=9&Partner=moneyquest_xml_us_searchbox_mqsearch&type=$data&Keywords=$data&affilData=ip=$REMOTE_ADDR&ua=$[HTTP_USER_AGENT]&xfip=255.255.255.255";
I need to change - ip= / ua= / xfip=
Hope someone can help! Please let me know if you need any more details. Many Thanks
Here is the "how to" doc Yahoo sent me -
Overture User Data HOWTO
Version: Overture-UserData-HOWTO.html v. 2003/4/10
Introduction
"Search Spam"
Overture tracks user information on each click to detect fraudulent or
false user clicks ("Click Spam"), and to provide protection for
advertisers, ensuring a more efficient keywords marketplace.
Similarly, to protect search statistics, Overture tracks user
information on each search. Please read these details to learn how to
send proper user information to Overture for search spam detection.
Using affilData with Overture's XML Interface
Background:
Once you have received your custom XML interface from Overture, you
should already be familiar with the Query Arguments which can be sent,
including &Partner=affiliate_xml_code, and &mkt=uk, and others.
The basic idea behind Overture user search data is to send the user's
IP address and User Agent to Overture with each search query. These
data are usually available as environment variables on your HTTP
server with any user request. Refer to the HTTP protocol
specifications at W3C for HTTP_USER_AGENT and REMOTE_ADDR for details.
How Overture uses this data is somewhat proprietary and beyond the
scope of this document.
Your XML query to the Overture Interface should include the affilData
query argument. The final format for this is like the following:
&affilData=ip%3D218.216.99.194%26ua%3DIE%7CWin%7C5
or, before encoding:
&affilData=ip=218.216.99.194&ua=IE|Win|5
Please observe the following main points about this format:
elements :: The affilData argument is comprised of the "ip" address
and the "ua" string.
encoding :: The entire argument following &affilData= is a single
URL-encoded string.
abbreviation :: To the extent possible, please shorten the User Agent element.
Specifics:
For Overture's search fraud protection system to work, it is important
to send Overture the right data, and also to send it in a consistent
format.
The URL specification should be followed for properly encoding this
and any other arguments which are sent to your Overture XML interface.
The URL specification is located at RFC 1738.
The Overture processing system has its own data size limits. Sending
Overture the User Agent string as an abbreviation improves the
performance of Overture's processing. The User Agent string is often
much longer than needed by Overture. There is no single correct way to
abbreviate the User Agent string. Feel free to create your own system.
Our suggestion and preference, however, is to identify your top 10
User Agents based on traffic, and shorten them each to a sequence like
this: Name|Platform|Version where "Name", "Platform", and "Version"
themselves are each abbreviations of a longer description.
The remaining User Agents, after the top 10 have been identified and
abbreviated, can be included as-is. There may be a large number of
different User Agents sending you traffic, but after the top 10, all
others will combine for a very small fraction of the total hits.
Please see the examples section below. At the time of this writing,
some of the most popular User Agents are web browsers, with the final
encoded abbreviations of IE%7CWin%7C5, IE%7CWin%7C6, and IE%7CWin%7C4
(abbreviations for Internet Explorer versions on Windows). The "%7C"
is the URL-encoded form of a vertical bar " | ".
The order of the query string parameter/argument pairs does not
matter. affilData, when properly URL-encoded, can be the first
parameter, or the last, or somewhere in between.
Alternatives:
For some affiliate partners, the User information, particularly IP
address, is sensitive. Two alternatives for sending Overture the raw
IP address are to send the encrypted IP address, and to send a
server-specific userID, or cookie ID. Since consistency is important,
choose an encryption algorithm which will reproduce the same hash
value every time.
The best example of an encryption algorithm is MD5. Though MD5 alone
is sufficiently tight security that an IP address could not be
decrypted from it, an additional level of security can be obtained by
combining a constant secret term with every IP address prior to
encryption. For example,
IP address >> IP address + constant secret term >> encrypted string
218.216.99.194 >> 218.216.99.194pFORp >> d8d6674e3eab8131
In this example, "pFORp" is known only to the affiliate, but is
appended to every IP address before encryption. The resulting hash,
d8d6674e3eab8131 would be unique and consistent for IP address
218.216.99.194 but this IP address cannot be decrypted from the hash,
especially when the secret constant is appended.
Usage Examples of UserData
Example 1. A basic Windows user with Internet Explorer 6:
&affilData=ip%3D218.216.99.194%26ua%3DIE%7CWin%7C6
Example 2. A Windows user with Netscape 7 where Netscape 7 was not one
of the top 10 User Agents (not abbreviated):
&affilData=ip%3D218.216.99.194%26ua%3DMozilla/5.0+(Windows%3b+U%3b+WinNT4.0%3b+ja-JP%3b+rv%3a1.0.2)+Gecko/20030208+Netscape/7.02
Example 3. A wireless device user, affiliate sends encrypted IP:
&affilData=ip%3De98c26446ba2088f%26ua%3Dsharp%20pda%20browser/6.1%5Bja%5D(MI-E1/1.0) |