The AdWords, DFP, and DFA APIs can take a user agent string in the SOAP headers, and the client libraries all allow you to set this string in their configuration files. This post explains why it’s in your own best interests to set this value to something unique and useful for each of your applications. We will be enforcing this soon in the Client Libraries - you won't be able to leave it as the default setting, or set an empty string. So, come up with a fitting string for your application and start using it in your headers now, if you’re not doing so already!
Here at Google we have the means to check our logs to see the SOAP requests you make, the responses we send you, and any internal error messages that might have been generated if something went wrong. If something appears wrong from your side, you can contact us, and tell us what happened and when, and we can search these logs for your developer token, network code, or specific features of the request that went wrong. In many cases that can be enough for us to be able to help you diagnose and solve that problem.
But many of you are developing more than one product. And sometimes the problem you’re trying to diagnose doesn't come down to a particular single event. Sometimes there’s a behavior over time we’re trying to pin down. And there are a lot of requests and responses in our logs.
If you can tell us the UserAgent or ApplicationName string you set for a particular version of a particular product that appears to be misbehaving, we can much more quickly and easily tell you how many of each request type it made, and when, and what the success rate for those requests were.
Likewise, if you’re trying to migrate from one version of the API to another, we can tell you if you are still making requests using the old API release, and also exactly which version of which application.
Supplying a useful UserAgent or ApplicationName string also enables us to proactively reach out to you when we see something going wrong or notify you of upcoming API changes that may affect you. We could then tell you exactly which behavior of what product and release will be impacted.
We suggest you use the format <CompanyURL>:<AppName>:<Version> so for example:
example.com:ReportDownloader:V3.2
Here’s where to look and what to set for each Client Library:
And if you’re generating your own SOAP and not using a Client Library, please set the string directly in the headers yourself.
So why not make this simple change, if you aren't making use of it already, and set the UserAgent or ApplicationName string for each of your application releases? You never know when it will mean the difference between hours of digging or a quick fix.
Feel free to ask questions or give us feedback via the G+ page.
Here at Google we have the means to check our logs to see the SOAP requests you make, the responses we send you, and any internal error messages that might have been generated if something went wrong. If something appears wrong from your side, you can contact us, and tell us what happened and when, and we can search these logs for your developer token, network code, or specific features of the request that went wrong. In many cases that can be enough for us to be able to help you diagnose and solve that problem.
But many of you are developing more than one product. And sometimes the problem you’re trying to diagnose doesn't come down to a particular single event. Sometimes there’s a behavior over time we’re trying to pin down. And there are a lot of requests and responses in our logs.
If you can tell us the UserAgent or ApplicationName string you set for a particular version of a particular product that appears to be misbehaving, we can much more quickly and easily tell you how many of each request type it made, and when, and what the success rate for those requests were.
Likewise, if you’re trying to migrate from one version of the API to another, we can tell you if you are still making requests using the old API release, and also exactly which version of which application.
Supplying a useful UserAgent or ApplicationName string also enables us to proactively reach out to you when we see something going wrong or notify you of upcoming API changes that may affect you. We could then tell you exactly which behavior of what product and release will be impacted.
We suggest you use the format <CompanyURL>:<AppName>:<Version> so for example:
example.com:ReportDownloader:V3.2
Here’s where to look and what to set for each Client Library:
Client Library
|
Product
|
Props File / setup method
|
Setting Name
|
Java
|
AdWords
|
ads.properties
|
api.adwords.userAgent
|
Java
|
DFA
|
ads.properties
|
api.dfa.applicationName
|
Java
|
DFP
|
ads.properties
|
api.dfp.applicationName
|
PHP
|
AdWords
|
auth.ini
|
userAgent
|
PHP
|
DFP
|
auth.ini
|
applicationName
|
Perl
|
AdWords
|
adwords.properties
|
userAgent
|
.Net
|
AdWords
|
App.config
|
UserAgent
|
.Net
|
DFA
|
App.config
|
ApplicationName
|
.Net
|
DFP
|
App.config
|
ApplicationName
|
Ruby
|
AdWords
|
adwords_api.yml
|
user_agent
|
Ruby
|
DFP
|
dfp_api.yml
|
application_name
|
Python
|
AdWords
|
run the "config.py" script
|
userAgent
|
Python
|
DFP
|
run the "config.py" script
|
applicationName
|
And if you’re generating your own SOAP and not using a Client Library, please set the string directly in the headers yourself.
So why not make this simple change, if you aren't making use of it already, and set the UserAgent or ApplicationName string for each of your application releases? You never know when it will mean the difference between hours of digging or a quick fix.
Feel free to ask questions or give us feedback via the G+ page.