Simplifying eCommerce reporting across international sites with multiple currencies
BCIT increases visitor satisfaction with 4Q Suite and the Google Analytics API
Posted by Pete Frisella, Google Analytics API team
Introducing two new versions of the Management API
Today we are releasing two new versions of our Management API into public beta; a brand new version 3.0 and a backwards compatible version 2.4. While the data the API exposes is the same, both versions migrate the Management API from the existing Google Data Protocol to Google’s new API infrastructure. This impacts the way you request and handle data from the API.
With this change, we are also announcing the deprecation of the legacy version 2.3 of the Management API. It will continue to work for 2 months, after which all v2.3 requests will return a v2.4 response.
The biggest changes in switching to the new versions are that developers need to register their applications via the Google APIs Console and use a developer token. Also the URL endpoints have changed, which influence how you request OAuth authorization tokens.
Here’s a rundown of what’s new:
Version 3.0
Is the latest major version of our API and is not backwards compatible. Features include:
- A faster response over version 2.3
- An improved quota policy
- Integration with the Google APIs console to manage API access and request more quota
- OAuth 2.0 is now the recommended way to Authorize users
- The URL to make requests is now at https://www.googleapis.com/analytics/v3/management/...
- The API response is more compact using JSON
- New Google API client libraries, which support many more languages
- Support for the Google Discovery API
All future development of the API will be done to this version so we also added some exciting new data only in version 3, including:
- Event goals are fully represented
- An internal web property id which can be used to deep link into the GA user interface
- Profile configurations for the default page and site search query parameters
Version 2.4
This is a minor version upgrade and we tried hard to make it backwards compatible with the existing Version 2.3. New changes include:
- A faster response over version 2.3
- An improved quota policy
- Integration with the Google API console to manage API access and request more quota
- Continued support for existing authorization mechanisms; OAuth 2.0 now supported
- The URL to make requests is now at https://www.googleapis.com/analytics/v2.4/management/...
- Supports XML response only
- The Google Data JavaScript client library will not work with this version
The XML output from this version is the same as version 2.3 so the existing Google Data client libraries will continue to work.
If You’re a Developer, What You Need To Do
Take a deep breath and get excited ;)
While we typically don’t share our roadmap, to alleviate any concerns, we wanted to give you some insight on where we’re going and how this release fits into the bigger picture. Today’s release adds two new versions to the Management API, v2.4 and v3.0. We also have a Data Export API that provides access to report data, which is still on version 2.3. In the future, we plan to do a similar upgrade to the Data Export API Data Feed by releasing two new versions for it, and deprecating version 2.3. At that time, we also plan to completely deprecate the Data Export API Account Feed.
The future of our APIs is to access all configuration data through the Management API and all processed report data through the Data Export API.
So for now, if you are already using the Management API, we recommend you migrate to the latest and greatest version 3.0.
If you are still using the Account Feed in the Data Export API, we highly recommend you test out the new Management API and start planning your migration. But, you can probably wait to do a full migration until all our APIs are on version 3.0.
If you have any questions feel free to reach out in our Management API developer group.
Posted by Jeetendra Soneja and Nick Mihailovski, Google Analytics API Team
New Ecommerce Tracking and Validation in the Analytics SDK for iOS
Today we’re happy to announce that Google Analytics SDK for iOS version 1.2 has been released. This new version supports Ecommerce tracking as well as the new debug and dry run modes, just like its Android counterpart.
Ecommerce Tracking
With Ecommerce mobile tracking, you can capture transaction and product information, send the data to Google Analytics, and then analyze which products performed best. Of course, because this is all within Google Analytics, you can also tie transaction data back to app usage behavior. See the Google Analytics SDK for iOS developer docs to learn how to implement this feature.
Debug and Validation
In addition to Ecommerce, we’ve added new debug and dry run modes to make it easier to validate your Google Analytics implementation.
Debug Mode:
[[GANTracker sharedTracker] setDebug:YES];
With debug mode, all data requests to Google Analytics are sent to the debug console.
Dry Run:
[[GANTracker sharedTracker] setDryRun:YES];
The dry run mode sends all tracking data locally so that you don’t corrupt your production data. Just be sure to turn it off before releasing your app, otherwise you won’t collect any usage data.
Posted by Jim Cotugno, Google Analytics Mobile Tracking Team
New Ecommerce tracking and validation in the Analytics SDK for Android
So today we’ve added Ecommerce tracking functionality to the Google Analytics SDK for Android.
Ecommerce Tracking
With Ecommerce mobile tracking, you can capture transaction and product information, send the data to Google Analytics, and then analyze which products performed best. Of course, because this is all within Google Analytics, you can also tie transaction data back to app usage behavior. For example, you can now compare the referral that generated an app download by the revenue it generated. See the Google Analytics SDK for Android developer docs to learn how to implement this feature.
Debug and Validation
In addition to Ecommerce, we’ve added new debug and dry run modes to make it easier to validate your Google Analytics implementation.
Debug Mode:
tracker.setDebug(true);
With debug mode, all data requests to Google Analytics are sent to the Android log, allowing you to validate that your app is sending data properly. You can view the Android log using the adb logcat command.
Dry Run:
tracker.setDryRun(true);
The dry run mode sends all tracking data locally so that you don’t corrupt your production data.
See Us At Google IO
We’ll be demoing all this new functionality this year Google IO, so stop by the Optimizing Android Apps With Google Analytics session on May 11, 12:30PM – 01:30PM / Room 9.
Posted by Jim Cotugno, Google Analytics Tracking Team
Client Side Authorization in the API
Great question Henrik! While you do have to authenticate to the Google Analytics Data Export API in order to access data, your application doesn’t have to re-authenticate every time. In this post we show you an easy way to re-use tokens and give you a Python class to simplify the process.
(Note: we recommend you follow the actual sample code to see how all the pieces described below work together.)
Background
Just like you have to log in to view Google Analytics data, you also have to grant an application access to your Analytics data when you use the the API. This is called authorization and is done through the Google Accounts API.
Different Authorization Protocols
When you log into the Analytics interface, your login credentials are protected from being exposed. In the same way, you use the Google Accounts API to protect credentials by requesting an authorization token in place of actual user names and passwords. That authorization token is used in the header of each Google Analytics API request.
There are a two authorization routines that applications can choose in order to obtain this token:
Client Login - a legacy, Google proprietary, authorization routine. The user of your application must supply their user name and password in your application. Your application communicates to Analytics on the user’s behalf and retrieves an authentication token. This token only lasts for 14 days. The issue with this method is that if the token is stolen, others can use it and the user has no way to revoke it.
OAuth For Installed Apps - is Google-supported open standard. Client apps must send users to a web page where the user logs in and grants account access to the application. The web page presents the user with a verification code which they must input back into the application. The application can exchange this verification code for a long-lived token. The long-lived token lasts forever and can be revoked by the user through the Google Accounts interface. This routine is more secure because a user can revoke the token and prevent an application from accessing their data at any time.
Obviously OAuth For Installed Apps is a better way to generate authorization tokens.
Token Management
Because authorization tokens are valid for multiple requests, applications should reuse them until they become invalid. For a client-side app, this usually means saving the token to disk. Here’s the logic to handle this in python:
def GetAuthToken(self):
if self.auth_token:
return self.auth_token
self.auth_token =
self.auth_routine_util.LoadAuthToken(self.token_obj_name)
if not self.auth_token:
self.auth_token = self.RequestAuthToken()
self.auth_routine_util.SaveAuthToken(self.auth_token)
return self.auth_token
Here the code tries to load a token from disk. If it exists, the token is set in the client object that makes requests to Google Analytics. If the token does not exist, the code tries to obtain it from the Google Accounts API, then save it to disk...all pretty easy.
Retrieving a New OAuth Token
To get a new OAuth token, the code uses helper methods in the Python Client Library. The my_client parameter is a reference to the gdata.analytics.client.AnalyticsClient object provided by the Google Data Python Client Library. It handles all the logic to make requests to the Google Analytics API.
First, the my_client object is used retrieve the URL to the OAuth authorization end point. Next it retrieves a request_token from the Google Accounts API and use that token to generate a URL for the user to go to.
The URL is printed to the screen and the code tries to pop open a browser and take the user directly there. The user will be prompted to login and grant access to the application. Once complete, the web page gives the user a verification code.
The code prompts the user for the verification code, and once inputted, the application uses it to get a long-lived access token. This access token will be valid until the user revokes the token.
Here’s the sample code:
def GetAuthToken(self, my_client):
url = ('%s?xoauth_displayname=%s' %
(gdata.gauth.REQUEST_TOKEN_URL, self.my_client.source))
request_token = self.my_client.GetOAuthToken(
OAuthRoutine.OAUTH_SCOPES,
next='oob',
consumer_key='anonymous',
consumer_secret='anonymous',
url=url)
verify_url = request_token.generate_authorization_url(
google_apps_domain='default')
print 'Please log in and/or grant access at: %s\n' % verify_url
webbrowser.open(str(verify_url))
request_token.verifier =
raw_input('Please enter the verification code '
'on the success page: ')
try:
return self.my_client.GetAccessToken(request_token)
except gdata.client.RequestError, err:
raise AuthError(msg='Error upgrading token: %s' % err)
Once we have the long-lived token, it’s returned and the GetAuthToken method above saves it to disk.
Making Google Analytics API Requests
To use the token retrieved above, we simply set it in the gdata.analytics.client.AnalyticsClient object:
try:
my_client.auth_token = my_auth.GetAuthToken()
except auth.AuthError, error:
print error.msg
sys.exit(1)
At this point an application can use the client object to retrieve data from the Google Analytics API. Because a user can revoke a token from the Google Accounts API and the code loads the token from disk, there can be a case where the token on the disk is invalid. In this case, the Google Analytics API returns a 401 status code and the client library raises a gdata.client.Unauthorized exception. If this happens, we need to catch the exception, delete the saved token and prompt the user to get a new token.
try:
feed = my_client.GetDataFeed(data_query)
except gdata.client.Unauthorized, error:
print '%s\nDeleting token file.' % error
my_auth.DeleteTokenFile()
sys.exit(1)
So there you have it, a quick overview of client side authorization with the Google Analytics API. As we mentioned above, you can view and use the full sample code.
Submit your own questions
We’re thrilled to get feedback from our developers. You guys rock! If you have a question about our API, like Henrik, please leave it in our comments. We’ll go through them and try to highlight the code solutions.
Posted by Nick Mihailovski, Google Analytics API Team
Deep Dive Articles For The Data Export API
As a result of identifying these areas, we’ve written a few in-depth articles. Each article is meant as a “Deep Dive” into a specific topic, and is paired with open-source, sample reference code.
In no particular order, the articles are as follows:
Visualizing Google Analytics Data with Google Chart Tools
This article describes how you can use JavaScript to pull data from the Export API to dynamically create and embed chart images in a web page. To do this, it shows you how to use the Data Export API and Google Chart Tools to create visualizations of your Google Analytics Data.
Outputting Data from the Data Export API to CSV Format
If you use Google Analytics, chances are that your data eventually makes its way into a spreadsheet. This article shows you how to automate all the manual work by printing data from the Data Export API in CSV, the most ubiquitous file format for table data.
Filling in Missing Values In Date Requests
If you want to request data displayed over a time series, you will find that there might be missing dates in your series requests. When requesting multiple dimensions, the Data Export API only returns entries for dates that have collected data. This can lead to missing dates in a time series, but this article describes how to fill in these missing dates.
We think this article format makes for a perfect jumping off point. Download the code, follow along in the article, and when you’re done absorbing the material, treat the code as a starting point and hack away to see what you can come up with!
And if you’ve got some more ideas for areas you’d like us to expound upon, let us know!
Posted by Alexander Lucas, Google Analytics API Team
New Tools to Debug Your Tracking Code
- You just set up your tracking code and you're wondering if it's correct--and you want to know right now.
- You have decided to migrate your tracking to the new asynchronous syntax--but you want to know if your syntax has any errors.
- You finally decided to customize the tracking code for cross-domain tracking--but you're worried that you might break your tracking.
- You want to make sure that your campaign is set up to the correct goal.
The Google Analytics team has launched a debugging version of the Analytics Tracking code called ga_debug.js to verify your tracking code setup. To make it even simpler, we also created a Chrome extension which uses the ga_debug.js script, which allows you to use the new ga_debug.js without re-tagagging any of your content. You can also use this extension to verify what information is sent to Analytics with each page.
How does it work? First, the ga_debug.js script provides a testing version of the tracking code which will print common syntax errors and tracking analysis messages to the browser’s JavaScript console. Secondly, the Chrome extension which automatically enables your page to use the debug version of the JavaScript without any need for you to retag or recode your pages.
How do you use it? The most simple thing to do is to download the Tracking Code Debugger extension for your Chrome browser. Next, turn on the extension by clicking on the icon to the right of the address bar on Chrome.
Finally, visit a page that contains the tracking code you want to test and open up the Chrome JavaScript console to see the messages (detailed instructions). That's it!
If you want to go use ga_debug.js without the Chrome extension, read all about how to do this in our newly revised Troubleshooting Guide on Google Code. You can use the script on your testing environment to verify extensive tracking code changes. Make sure, however, that you don't use this version of the tracking code on your production website--the script is meant for debugging and analysis, not speed, so you should always use this as a testing mechanism only. If you want to learn more about the kinds of errors this script can help you find, see Common Tracking Code Errors/Typos in our Troubleshooting Guide. While the ga_debug.js script doesn’t catch all possible errors yet, we think it’s off to a great start and will get even better over time.
Happy testing!
Brian Kuhn on behalf of the Analytics Team
A Better Developer Doc Experience
Since Nick, Alex, and I were under the hood making docs and sample code for the Management API, it also seemed like a good time to spiff up the site and add some structure to handle this burgeoning developer resource.
New Look and Feel
Nick went to town on our new home page. If you attended his talk at the Google I/O conference this May, you might notice that the Analytics data model diagram has reappeared, but this time as a gateway into the key parts of our documentation on Google Code. We surfaced the most important links to provide deep access to the key parts of each section of the site.
New Landing Pages
Since we now have 3+ major sections on our site, it was time to provide landing pages for all the news and updates relevant to Tracking Code configuration, Management API, and Export API. Here you will always be able to see the latest release news and best practice guides for each API without having to dig down into the site.
We’ve also redesigned our navigation bar to be more visually appealing and consistent across all three APIs.
New Groups Pages
We have three major developer groups to help you out with your Analytics coding--Async tracking, Management API, and Export API. Not only that, but our general Help Forum is great for issues with general tracking topics. Since we have so many different groups, we created a new groups landing page to help you figure out which group will help you best.
Our Management API and Export API groups use the new Google Discussion Forum, which is embedded right in the page--a pretty nifty feature.
We hope that you find the new design makes it clearer and easier for you to find what you need for Analytics development. We’d love to hear your feedback, so please post any comments on one of our developer groups pages and let us know.
Patricia Boswell on behalf of the Analytics API team.
Launched: New Google Analytics Management API!
Many developers have asked for a faster, more powerful way to access Google Analytics account configuration data through the Data Export API. We’ve listened and today we’re releasing a preview of the new Google Analytics Management API.
The Management API provides read-only access to Google Analytics configuration data. It consists of 5 new Google Data Feeds that map directly to the Google Analytics data model.
Previously, the API returned all the configuration data at once, which in many cases was inefficient if you only needed a subset of data. Now with separate feeds, developers can request only the data they need. For example, it’s now easy to get the Profile IDs for a single account or the Goal configuration data for only a single Profile.
To help you learn more we created a new Management API section in our developer documentation. We also created new reference examples in Java and have a live working demo in JavaScript. Check it out, no coding needed!
The Management API is being launched in Labs as an early preview. The API will change, grow, and get better over time. We recommend developers who aren’t committed to making updates to their applications only experiment with the new API and continue to use the Account Feed as their primary source for configuration data. We will strive to give you at least one month advanced notice of changes to this API.
The Management API represents a significant new piece of the Google Analytics developer platform. We encourage you to come try it out and give us feedback in our new Management API Google Group.
Thanks!
Jeetendra M. Soneja, on behalf of the Google Analytics API team
P.S. - Please make sure to sign-up for our notify list to stay up-to-date on all the latest Google Analytics Developer updates.