Browser Language settings for the user about openrtb2x

[chompi]

From [email protected] on July 20, 2011 19:00:23
hi. good idea. you are right. we should send the browser's language when available. however, this is already avaiable in user-agent string, so it might be redundant to send it twice.

[chompi]

From [email protected] on July 21, 2011 12:21:06
Correction: Patrik is right, this should be in there, since it needs to be pulled from the Accept-Language headers.

for example (from my firefox browser):

Accept-Language: en-us,en;q=0.7,es;q=0.3

[chompi]

From [email protected] on July 21, 2011 19:52:38
If the language isn't available in the user-agent string there's really no definitive way for an SSP to determine the user's language anyway.

[chompi]

From [email protected] on July 21, 2011 20:07:50
Thought I posted this earlier but looks like it only went to mail list...:

The lang could be in User Agent but it's rarely there.

It is common (but not strict) to see for for Safari, AndroidWB and unusual for the most other browsers.

HTTP does have a special header for this - Accept-Language. It is most likely that a browser will send this header then in UA-string.

Ideally the value can be taken from there and put into the open RTB request field by the SSP server.

[chompi]

From [email protected] on July 22, 2011 12:16:28
We might want to step back on this. There are probably 2 values that are useful, which can be determined in a couple of ways, I'd be leery about constraining supply-sources approaches:

1. language of the page/environment

In CONTEXTWEB's case we do real-time using our RTC service to do analysis of the page to determine language at the same time we classify it into the IAB taxonomy

1. language(s) the user can accept/read

This could be determined by looking at the Accept header, or indexing user behavior, or some other metric