AdWords Support for Local Time Zones
AdWordsAPIAdvisor
accounts' time zones
(https://adwords.google.com/support/bin/answer.py?answer=32346). This
means that all metrics returned for a given account will be reported in
that account's time zone (currently all accounts are reported in US
Pacific Standard Time (PST) - the time zone for Google's headquarters
in California). In addition, billing and budgeting cycles will be
based on each account's time zone.
Advertisers and MCC managers will be invited to set their time zones in
May, at which point we will release a new version of the AdWords API
that includes "set" and "get" time zone functionality. We plan to
release more detailed/technical FAQs (via the AdWords API Blog) as we
get closer to the launch date.
In the meantime, we'd like to give you a high-level overview of
time-zone related functionality and implications for developers.
WHAT IS TIME ZONE SUPPORT?
Advertisers can select any time zone in the world for their AdWords
account. All reporting, ad serving, and billing will be based on the
time zone set by the advertiser. Advertisers or MCC managers who
choose not to establish account time zone settings will continue to
have their accounts managed in US PST, as they have been in the past.
It is important to note that each account's time zone may only be set
once, so advertisers should be careful when setting their time zone.
WHAT WILL CHANGE IN THE WEB APPLICATION?
Starting in early May, existing advertisers who login to the AdWords
website will receive an invitation to set their account's local time
zone. New advertisers will be asked to specify their local time zone
during the account setup process.
HOW WILL TIME ZONE SUPPORT IMPACT ADWORDS API DEVELOPERS?
The interfaces for submitting and returning date/time values already
support local time zones (even though all data is currently
submitted/reported in US Pacific Standard Time). Therefore, the impact
should be minimal.
-- You will be able to get and set your local time zone through new
methods in AccountService, as well as get the effective date of
the most recent time zone change.
-- Statistics will be collected at standardized times within each
account's local time zone boundaries. For example, if a customer
in Tokyo sets her account for Japan Standard Time (JST), that
account's stats will be collected from midnight to midnight, JST.
Likewise, accounts set to PST will have their stats collected from
midnight to midnight, PST.
-- The start and end time specified in report jobs sent to
ReportService will be interpreted in the account's local time zone.
-- Where appropriate, date parameters will be used instead of
date-time (xsd:date instead of xsd:dateTime). This includes
the start and end day of a campaign, the start and end period
for stat methods, and the start and end day of report jobs. The
day will automatically be interpreted in the account's local time.
If a time zone is specified along with the day, it must match
the account's local time zone.
-- If you schedule a single report to aggregate data across multiple
accounts (and those accounts are in different time zones), the
report will aggregate each account's local daily data.
-- If you schedule a single report to aggregate data across multiple
accounts (and those accounts are in different time zones), the
report will aggregate each account's local daily data.
WILL THIS CHANGE BE BACKWARD-COMPATIBLE WITH V3?
Once you begin setting time zones for your accounts, you will still be
able to use the current version (V3) of the API. However, there will
be one difference. In V3, all API calls will still return account
statistics in PST (regardless of each account's specified time zone)
except for reports, whose day boundaries will be calculated in each
account's local time zone.
TABLE: http://www.google.com/apis/adwords/images/api_ltz_matrix.gif
Once you migrate to the new version (V4), all API calls will return
statistics and reports calculated in each account's local time zone.
However, we understand that some developers may want to return all
account statistics in one time zone. Therefore, you will be able to
access all account statistics in PST by passing in a flag to the stat
methods. The coming release notes will have more information on this.
We hope you find this information helpful, and we promise to release
further technical details as soon as possible.
-- Rohit Dhawan, Product Manager
Richard Jones
Just a couple of tiny questions about this:
* Our sales manager told us that you'd only be able to set the
timezone once for each account, after which it'd be unchangable. Is
this true?
* Will timezones be simple offsets from UTC, or will they incorporate
daylight savings times? (Actually, I think we'd prefer them to be
simple offsets from UTC, because we plan to set everything to UTC for
compatibility with our database).
Rich.
--
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com