Introducing the Google Analytics Core Reporting API

Jeetendra

Nick

By Jeetendra Soneja and Nick Mihailovski, Google Analytics API Team

Today we are announcing the new Google Analytics Core Reporting API as a replacement for the Data Export API. This is the second phase in a larger project we started a couple months back to upgrade our APIs to new infrastructure.

The Core Reporting API has two versions.

Version 3.0 is a brand new API, with a 10x reduction in output size and support for many new client libraries, like PHP, Ruby, Python, JavaScript and Java. All new features will only be added to this version.

Version 2.4 is backward compatible with the legacy Data Export Version 2.3.

If you are building a new application or maintaining an existing one, we highly recommend migrating to version 3.0.

One of the biggest changes in switching to the Core Reporting API is that you now need to register your applications via the Google APIs Console and use a project ID to access the API.

With this change, we are also announcing the deprecation of the Data Export API version 2.3. This API will continue to work for 6 months, after which all v2.3 XML requests will return a v2.4 response. Also, we plan to terminate the Data Export API Account Feed. All configuration data should be retrieved through the Google Analytics Management API.

See our Data Export API changelog for all the details of the change and read our developer documentation for more details about each API.

If you have any questions feel free to reach out in our Data Export API Google group.


Jeetendra Soneja is the technical engineering lead on the Google Analytics API team. He's a big fan of cricket – the game, that is. :)

Nick Mihailovski is a Senior Developer Programs Engineer working on the Google Analytics API. In his spare time he likes to travel around the world.

Posted by Scott Knaster, Editor

OAuth 2.0 Playground: open to developers

By Nicolas Garnier, Developer Relations Team

Cross-posted on the Google Apps Developer Blog

In March, we announced that all of the Google Web APIs adopted support for OAuth 2.0. It is the recommended authorization mechanism when using Google Web APIs.

Today, we are announcing the OAuth 2.0 Playground, which simplifies experimentation with the OAuth 2.0 protocol and APIs that use the protocol. Trying out some requests in the OAuth 2.0 playground can help you understand how the protocol functions and make life easier when the time comes to use OAuth in your own code.

Selecting the APIs to authorize

With the OAuth 2.0 Playground, you can walk through each step of the OAuth 2.0 flow for server-side web applications: authorizing API scopes (screen shot above), exchanging authorization tokens (screen shot below), refreshing access tokens, and sending authorized requests to API endpoints. At each step, the Playground displays the full HTTP requests and responses.

Exchanging the authorization code for a refresh token and an access token

The OAuth Playground can also use custom OAuth endpoints in order to test non-Google APIs that support OAuth 2.0 draft 10.

OAuth configuration screen

You can click the link button to generate a link to a specific Playground state. This allows quick access to replay specific requests at a later time.

Generating a deep link to the playground’s current state

Please feel free to try the OAuth 2.0 Playground. We are happy to receive any feedback, bugs, or questions in the OAuth Playground forum.

Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate focusing on Google Apps and Web APIs. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

Posted by Scott Knaster, Editor

Introducing the Google+ Hangouts API

By Richard Dunn, Technical Lead, Google+ platform for Hangouts

Cross-posted from the Google+ Platform Blog

In the three months since we launched face-to-face-to-face communication in Google+ Hangouts, I’ve been impressed by the many ways people use them. We’ve seen Hangouts for game shows, fantasy football drafts, guitar lessons and even hangouts for writers to break their solitary confinement. That’s just the beginning. Real-time applications are more engaging, fun, and interactive, but were hard for developers to deliver. Until now.

Today we’re launching the Developer Preview of the Hangouts API, another small piece of the Google+ platform. It enables you to add your own experiences to Hangouts and instantly build real-time applications, just like our first application, the built-in YouTube player.

The integration model is simple -- you build a web app, register it with us, and specify who on your team can load it into their Hangout. Your app behaves like a normal web app, plus it can take part in the real-time conversation with new APIs like synchronization. Now you can create a "shared state" among all instances of your app so that all of your users can be instantly notified of changes made by anyone else. (This is how the YouTube player keeps videos in sync.) And we’ve added our first few multimedia APIs so you can, for example, mute the audio and video feeds of Hangout participants.

When you’re ready to start hacking, we’re ready for you -- read the documentation, sign up, and start coding. We’re anxious to get your feedback, since this is a very early version of the API. We’ll be making improvements and moving towards full production based on what we learn together. And we’ll be releasing new updates on a regular basis, so stay tuned!

Follow the conversation on Google+.

Richard Dunn is Technical Lead, Google+ platform for Hangouts


Posted by Scott Knaster, Editor

Paid version of Google Translate API now open for business

By Jeff Chin, Product Manager

Back in May, we announced the deprecation of the free Translate API v1. Today, we’re introducing a paid version of the Google Translate API for businesses and commercial software developers. The Google Translate API provides a programmatic interface to access Google’s latest machine translation technology. This API supports translations between 50+ languages (more than 2500 language pairs) and is made possible by Google’s cloud infrastructure and large scale machine learning algorithms.

The paid version of Translate API removes many of the usage restrictions of previous versions and can now be used in commercial products. Translation costs $20 per million (M) characters of text translated (or approximately $0.05/page, assuming 500 words/page). You can sign up online via the APIs console for usage up to 50 M chars/month.

Developers who created projects in the API Console and started using the Translate API V2 prior to today will continue to receive a courtesy limit of 100K chars/day until December 1, 2011 or until they enable billing for their projects.

For academic users, we will continue to offer free access to the Google Translate Research API through our University Research Program for Google Translate. For website translations, we encourage you to use the Google Website Translator gadget which will continue to be free for use on all web sites. In addition, Google Translate, Translator Toolkit, the mobile translate apps for iPhone and Android, and translation features within Chrome, Gmail, etc. will continue to be available to all users at no charge.

Jeff Chin is the Product Manager for Google Translate. Whenever he travels, Jeff enjoys learning and trying to speak the local language, and finding good local restaurants and food to eat.

Posted by Scott Knaster, Editor

Prediction API: Tunable predictive models

By Travis Green, Product Manager

Over the last year, the Prediction API has given you more and more tools to make your apps smarter and teach them to adapt and learn. Today we're adding a frequently requested feature: the ability to adjust models to get better performance.

Historically, getting the right predictive model has required detailed knowledge of algorithmic behavior and experience with similar datasets, and a lot of guess-and-check. With the Prediction API, we ask you what behavior you want to see, and search across many algorithms to find the best-matching one.

How it works:

1. Upload data to Google Storage for Developers.
2. Ask the Prediction API to find a great predictive model.
3. [new] Examine more detailed statistics about your model’s performance, including more training metadata and better accuracy statistics through a confusion matrix.
4. Improve performance.
1. Give your model more samples to learn from.
2. Add in more information (see these samples).
3. [new] Show the API what data is most important (categorical data only).

For those of you ready to get started, feel free to jump in through our newly updated code samples.

Travis Green's favorite part about his job is designing smart applications. In his spare time, he is in the great outdoors (looking for trouble).

Posted by Scott Knaster, Editor

Page Speed Service: Web performance, delivered.

By Ram Ramani, Engineering Manager

Update 7/29/11: We were notified of a bug in the measurement tool that sometimes causes incorrect measurements. If your results indicated a slowdown on your pages, please run the tests again, and make sure you specify a fully qualified domain such as www.example.com. We apologize for any inconvenience and confusion this may have caused.

Details:
Measurement tests run for bare domains (such as example.com, without the prefix www) previously indicated that pages were loading more slowly, rather than speeding up, when using Page Speed Service. The test results page now prominently notifies you of this when you visit this page, if this error applies to you. Please check your old measurement results page if this bug applies to you. Running the tests again with the fully qualified domain such as www.example.com usually fixes the issue and gives you the correct measurement.

Two years ago we released the Page Speed browser extension and earlier this year the Page Speed Online API to provide developers with specific suggestions to make their web pages faster. Last year we released mod_pagespeed, an Apache module, to automatically rewrite web pages. To further simplify the life of webmasters and to avoid the hassles of installation, today we are releasing the latest addition to the Page Speed family: Page Speed Service.

Page Speed Service is an online service that automatically speeds up loading of your web pages. To use the service, you need to sign up and point your site’s DNS entry to Google. Page Speed Service fetches content from your servers, rewrites your pages by applying web performance best practices, and serves them to end users via Google's servers across the globe. Your users will continue to access your site just as they did before, only with faster load times. Now you don’t have to worry about concatenating CSS, compressing images, caching, gzipping resources or other web performance best practices.

In our testing we have seen speed improvements of 25% to 60% on several sites. But we know you care most about the numbers for your site, so check out how much Page Speed Service can speed up your site. If you’re encouraged by the results, please sign up. If not, be sure to check back later. We are diligently working on adding more improvements to the service.

At this time, Page Speed Service is being offered to a limited set of webmasters free of charge. Pricing will be competitive and details will be made available later. You can request access to the service by filling out this web form.

Ram Ramani is an Engineering Manager on the Make the Web Faster Team in Bangalore, India. He is a believer in "Faster is better".

Posted by Scott Knaster, Editor

Get picky with the Google Picker API

By Chris Thrasher, Software Engineer, Google Picker API

Users have content across many Google properties: YouTube, Picasa Web Albums, Google Docs, and more. Now we have a common interface for your users to select Google content. The Google Picker API provides a familiar-looking dialog box that’s easy for you to integrate into your apps. Your users can quickly browse their own content without ever leaving your page or app.

Perhaps you’re developing a blogging platform and you want your users to be able to embed their Picasa Web Albums photos. You can even let your users pick from public content, as found from image and video search.

Once the Picker is invoked by your user, a modal dialog appears on the page. If the user is already signed in to their Google account, they’ll see their content in just a second or two. If not, the user will be asked to sign in.

Integrating with the Google Picker API is straightforward. First, you specify which Google services should show up as options in the Picker navigation. For example, if you’re a photo site, you may choose to show Picasa and Google Image Search, but hide Google Docs and other services. Then, you simply specify a callback function that will be called as soon as the user’s data is returned to your application.

var picker = new google.picker.PickerBuilder().
    addView(google.picker.ViewId.IMAGE_SEARCH).
    setCallback(pickerCallback).
    build();
picker.setVisible(true);

You can find more integration details and examples in the documentation. We hope you enjoy this new API!

Chris Thrasher is a Software Engineer at Google Kirkland and is part of the Google+ team. When he's not writing code, Chris is usually watching old movies. Or quoting from them.

Posted by Scott Knaster, Editor

Make money with In-App Payments for the Web

By Amit Fulay, Product Manager

Cross-posted from the Google Commerce Blog.

At the Google I/O conference back in May, Vikas Gupta introduced a preview of the Google In-App Payments API during the Chrome keynote speech. Google In-App Payments purchases were demonstrated as a simple click right within a web app, so buyers could enjoy a developer’s content, without interruption.

Today, we’re making Google In-App Payments available for all web application developers to integrate with their web apps wherever they’re hosted, including the Chrome Web Store. Integration is simple with just a few lines of code. And pricing is set at just 5-percent.



In-App Payments is initially available for developers with a United States bank account and for buyers in more than 140 countries. We look forward to expanding to additional developer locations as quickly as possible.

Posted by Scott Knaster, Editor

Taking command of issue triage

By Jason Robbins, Google Project Hosting Team

Faster is better, especially for tedious tasks. Even though software development can be creative and exciting, it certainly has its share of tedious tasks. For example, that open source application library you developed that got users so excited? Well, now it is generating dozens of defect reports and enhancement requests for you and your teammates to sift through. Is your team growing? Are you planning a major release? Is it time to finally clean up obsolete issues? It’s awesome to be organized, but keeping up with all your issues can become tedious: click, click, click, click, click.

Today we’re launching a new issue tracking feature that allows quick edits in the issue preview window. It’s a happy medium between viewing one issue in detail and doing a bulk edit. Unlike the familiar forms-based UX that we normally use, quick edits are more command-like, keyboard-oriented, and emphasize the ability to repeat recent commands.

Previewing issues works about 40% faster than our normal issue detail page, so you can skim fast enough to achieve oneness with your backlog, then punch in some quick edits to show it who’s boss. When you’re in the zone, that click, click, click is replaced with something more like h, e, j, j, e, j, j, 2, e, j, e, j, j, j, 1, e, done! Here’s your cheat sheet:

Keystroke	Action
h	Toggle the issue preview window.
j or k	Select the next or previous issue.
f, n, p, l	Scroll to the first, next, previous, or last comment in an issue.
1, 2, 3, 4, 5	Select a recent command. If you modify the command or comment, it will be stored in that numbered slot for later reuse.
m	Focus on the command text field.
e	Execute the command and show the issue comment that it generated.

Not ready to go all-keyboard? Just turn on the user preference for issue preview when mousing. Then, you can do your most common and repetitive issue edits by just hovering over an ID number and clicking the Execute button.

Jason Robbins founded the ArgoUML and ReadySET open source projects as a result of his research into the cognitive challenges of software engineering tool UIs. He’s worked on Google Project Hosting since 2005. Over the years he’s been a contestant, coach, and judge for the ACM International Collegiate Programming Contest.

Posted by Scott Knaster, Editor

Measure page load time with Google Analytics

Zhiheng

Phil

By Zhiheng Wang, Make the Web Faster Team, and Phil Mui, Google Analytics Team

At Google, we’re passionate about speed and making the web faster, and we’re glad to see that many website owners share the same idea. A faster web is better for both users and businesses. A slow-loading landing page not only impacts your conversion rate, but can also impact AdWords Landing Page Quality and ranking in Google search.

To improve the performance of your pages, you first need to measure and diagnose the speed of a page, which can be a difficult task. Furthermore, even with page speed measurements, it’s critical to look at page speed in the context of other web analytics data.

Therefore, we are thrilled to announce the availability of the Site Speed report in Google Analytics. With the Site Speed report you can measure the page load time across your site right within your Google Analytics account.

Uses for the Site Speed report

With the Site Speed report, not only will you be able to monitor the speed of your pages, you can also analyze it along with other analytics data, such as:

• Content: Which landing pages are slowest?
• Traffic sources: Which campaigns correspond to faster page loads overall?
• Visitor: How does page load time vary across geographies?
• Technology: Does your site load faster or slower for different browsers?

Setting up the Site Speed report

For now, page speed measurement is turned off by default, so you’ll only see 0s in the Site Speed report until you’ve enabled it. To start measuring site speed, you need to make a small change to your Analytics tracking code. We have detailed instructions in the Site Speed article in the Analytics Help Center. Once you’ve updated your tracking code, a small sample of pageviews will be used to calculate the page load time.

Bringing the Site Speed report into Google Analytics is an important step of the Make the Web Faster effort, and we look forward to your feedback on Site Speed.


Zhiheng Wang spends most of his time at work building stuff so others can serve the web better. He spends the rest of his time at home fixing stuff so his family can surf the web better.

Phil Mui is the Group Product Manager of Google Analytics and has been leading its development since its early days. He has a Ph.D. from MIT and a M.Phil. from Oxford where he was a Marshall Scholar.

Posted by Scott Knaster, Editor

Visualizing geographic data with the WebGL Globe

By Doug Fritz of the Google Data Arts Team

Today we're sharing a new Chrome Experiment called the WebGL Globe. It’s a simple, open visualization platform for geographic data that runs in WebGL-enabled browsers like Google Chrome. The globe below shows world population, and we’ve created another globe showing Google search traffic.

The primary challenge of this project was figuring out how to draw several thousand 3D data spikes as quickly and smoothly as possible. To do this, we turned to Three.js, a JavaScript library for building lightweight 3D graphics. For each data point, we generate a cube with five faces – the bottom face, which touches the globe, is removed to improve performance. We then stretch the cube relative to the data value and position it based on latitude and longitude. Finally, we merge all of the cubes into a single geometry to make it more efficient to draw.

The second challenge of the project was animating the globe – we wanted it to be fun for the user to manipulate. Thanks to WebGL, we’re able to display thousands of moving points at high frame rates by using the user’s graphics processing unit (GPU) for 3D computations. Each state of the globe has its own geometry and we morph between them with a vertex shader, saving precious CPU resources. Additionally, to make the globe look nice, we took advantage of the possibilities of GLSL and created two fragment shaders, one to simulate the atmosphere and another to simulate frontal illumination of the planet.

Now that we’ve released the globe, we’re hoping that developers like you will create your own. What data will you show on it? If you’re feeling inclined, you can learn more about the data format (represented in JSON) and get the code here. If you create your own globe, please also consider sharing a link with us -- at some point in the future, we hope to post a list of interesting globes that have been submitted.

UPDATE 6:16 PM: Fixed link to the code in last paragraph.


Doug Fritz is a creative programmer in Google's San Francisco office. Doug says he likes "simplifying the complex and complexifing the simple, because in reality it's all somewhere in the middle".

Posted by Scott Knaster, Editor

Prediction API: Every app a smart app

By Travis Green of the Google Prediction API Team.

If you’re looking to make your app smarter and you think machine learning is more complicated than making three API calls, then you’re reading the right blog post.

Today, we are releasing v1.2 of the Google Prediction API, which makes it even easier for preview users to build smarter apps by accessing Google’s advanced machine learning algorithms through a RESTful web service.

Some technical details of the Prediction API:

• Chooses best technique from several available machine learning algorithms.
• Supported inputs: numeric data and unstructured text.
• Outputs hundreds of discrete categories, or continuous values.
• Integrates with many platforms: Google App Engine, web and desktop apps, and command line.
• v1.2 improvements:
• Simpler interface: automatic data type detection, and score normalization.
• Paid usage tier.
• Improved usage monitoring and faster signup through the APIs Console.

Ideas to make the most of the Prediction API:

• Recommendation: What products might a user be interested in? (example)
• Filter RSS feeds, user comments, or feedback: Which posts are most relevant? Should a user comment be featured? Which feedback should we look at first? (example)
• Customize homepages: Predict what content a user would like to see and populate the page with the user’s anticipated interests.
• Sentiment analysis: Is this comment positive or negative? Does a commenter support Group A or Group B?
• Message routing: Route emails to the appropriate person based on analysis of the email contents.
• See the Prediction API website for many more!

To join the preview group, go to the APIs Console and click the Prediction API slider to “ON,” and then sign up for a Google Storage account.

We would also like to continue to thank our supportive preview users for their help making the API the service it is today. We look forward to seeing many more of you join us in making the web just a little bit smarter, and hearing your thoughts and feedback through our discussion group.

Travis Green's favorite part about his job is designing smart applications. In his spare time, he is in the great outdoors (looking for trouble).

Posted by Scott Knaster, Editor

A new test suite for rich text editing

This post is by Roland Steiner of the Chrome Team. Roland works mainly on layout and rendering for Chrome and WebKit. An Austrian native, Roland has ventured far and made Tokyo his second home. -scottk

Many web applications allow users not just to edit plain text, but also to embellish it – making it bold or underlined, adding bulleted lists or images. For example, think of online document or blog editors, or rich e-mail apps. JavaScript provides various APIs you can use to implement these apps.

Unfortunately, while these APIs are largely defined the same in modern browsers, the results often differ. To document the current state of all this, we have set up a new rich text editing test suite as part of the larger browserscope framework.

Let’s look at how a region of text, such as a <div>, can be marked as editable by adding the contenteditable attribute:

<div contenteditable="true"> ...some content... </div>


You can then manipulate the content with simple calls:

document.execCommand("formatting command", showUI, parameter)

For example, you can set the color of the selected text to red with this call:

document.execCommand("forecolor", false, "red")

Although this command works well on most browsers, different browsers implement different subsets of formatting commands, and even common commands often produce varying HTML structures.

There are other APIs that affect selection and cursor movement, or allow querying of the current state, and those, too, are often implemented differently.

Our new test suite tries to capture all currently implemented commands and APIs, and runs them on varying initial HTML content and within various containers. The suite already contains well over 1,000 tests.

We don’t want to stop there. We intend to grow the suite and incorporate external feedback and suggestions so we can arrive at a common set of editing functions. We hope this can then serve as a common reference, not only for browser implementers, but also for web developers.

To achieve this goal, we would like input from anyone interested in this topic, including those with past complaints about bugs and incompatibilities in this area.

For suggestions, criticism, and general discussion on the suite and tests, please send feedback to the browserscope mailing list at [email protected].

Introducing Page Speed Online, with mobile support

By Andrew Oates and Richard Rabbat, Page Speed Team

At Google, we’re striving to make the whole web fast. As part of that effort, we’re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.



In addition, we’ve added a new feature: the ability to get Page Speed suggestions customized for the mobile version of a page, specifically smartphones. Due to the relatively limited CPU capabilities of mobile devices, the high round-trip times of mobile networks, and rapid growth of mobile usage, understanding and optimizing for mobile performance is even more critical than for the desktop, so Page Speed Online now allows you to easily analyze and optimize your site for mobile performance. The mobile recommendations are tuned for the unique characteristics of mobile devices, and contain several best practices that go beyond the recommendations for desktop browsers, in order to create a faster mobile experience. New mobile-targeted best practices include eliminating uncacheable landing page redirects and reducing the amount of JavaScript parsed during the page load, two common issues that slow down mobile pages today.

Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and webpagetest.org.

Please give Page Speed Online a try. We’re eager to hear your feedback on our mailing list and find out how you’re using it to optimize your site.

Page Speed for Chrome, and in 40 languages!

(Cross-posted from the Google Webmaster Central Blog.)

Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.

Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.

Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.

If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via webpagetest.org, which integrates the Page Speed SDK.

We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.

By Matthew Steele and Richard Rabbat, Page Speed Team

Your Web, Half a Second Sooner

At Google we’re constantly trying to make the web faster — not just our corner of it, but the whole thing. Over the past few days we’ve been rolling out a new and improved version of show_ads.js, the piece of JavaScript used by more than two million publishers to put AdSense advertisements on their web pages. The new show_ads is small and fast, built so that your browser can turn its attention back to its main task — working on the rest of the web page — as soon as possible. This change is now making billions of web pages every day load faster by half a second or more.

The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.

How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.

The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.

And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.

By Michael Kleber, Ads Latency Team

Making auth easier: OAuth 2.0 for Google APIs

One of the most exciting things about the architecture of the web is how easily it supports mashups—URLs, IFRAMEs, XHR, and more make it easy to build great new services on top of building blocks from others. As more and more people use the web for non-public data, we need new techniques to secure those building blocks. That’s where OAuth comes in—an open, standard way for users to grant permission for an application to access part of their account.

Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.

In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:


Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.

By Andrew Wansley, Google Developer Team

Introducing the Google APIs Explorer

Google is always looking for new ways to make it easier for developers to get started with our APIs. When you come across a new Google API, you often want to try it out without investing too much time. With that in mind, we are happy to announce the Google APIs Explorer, an interactive tool that lets you easily try out Google APIs right from your browser. Today, the Explorer supports over a half dozen APIs – and we expect that number to grow rapidly over the coming weeks and months.

By selecting an API you want to explore, you can see all the available methods and parameters along with inline documentation. Just fill out the parameters for the method you want to try and click “Execute”. The Explorer composes the request, executes it, and displays the response in real time. For some APIs that access private data you will need to “Switch to Private Access” and authorize the Explorer to do so.

To get you started, here are some sample requests; follow the links and press “Execute”:

• Expand a goo.gl URL using the URL Shortener API
• Translate a phrase to French using the Translate API
• List your personal Buzz posts using the Buzz API (requires private access)

The Explorer makes it easier for developers to discover what APIs we offer and get started using them within minutes. If you have any questions or comments, visit the help page or the support forum. We’d love to hear your feedback.

Happy exploring!

By Anton Lopyrev and Jason Hall, Google Developer Team

Native Client: Getting ready for takeoff

(Cross-posted from the Chromium Blog)

Over the last few months we have been hard at work getting Native Client ready to support the new Pepper plug-in interface. Native Client is an open source technology that allows you to build web applications that seamlessly and safely execute native compiled code inside the browser. Today, we’ve reached an important milestone in our efforts to make Native Client modules as portable and secure as JavaScript, by making available a first release of the revamped Native Client SDK.

The SDK now includes support for a comprehensive set of Pepper interfaces for compute, audio, and 2D Native Client modules. These interfaces are close to being stable, with some important exceptions that are listed in the release notes.

In addition, we’ve focused on improving security. We have enabled auto-update and an outer sandbox. This allowed us to remove the expiration date and localhost security restrictions we had adopted in previous research-focused releases. Beyond security, we’ve also improved the mechanism for fetching Native Client modules based on the instruction set architecture of the target machine, so developers don’t need to worry about this any more.

We are excited to see Native Client progressively evolve into a developer-ready technology. In the coming months we will be adding APIs for 3D graphics, local file storage, WebSockets, peer-to-peer networking, and more. We’ll also be working on Dynamic Shared Objects (DSOs), a feature that will eventually allow us to provide Application Binary Interface (ABI) stability.

Until the ABI becomes stable, Native Client will remain off by default. However, given the progress we’ve made, you can now sticky-enable Native Client in Chrome 10+ through the about:flags dialog. Otherwise, you can continue using a command line flag to enable Native Client when you want to.

A big goal of this release is to enable developers to start building Native Client modules for Chrome applications. Please watch this blog for updates and use our discussion group for questions, feedback, and to engage with the Native Client community.

By Christian Stefansen, Native Client Team

Visualize your own data in the Google Public Data Explorer

(Cross-posted from the Official Google Blog)

Over the past two years, we’ve made public data easier to find, explore and understand in several ways, providing unemployment figures, population statistics and world development indicators in search results, and introducing the Public Data Explorer tool. Together with our data provider partners, we’ve curated 27 datasets including more than 300 data metrics. You can now use the Public Data Explorer to visualize everything from labor productivity (OECD) to Internet speed (Ookla) to gender balance in parliaments (UNECE) to government debt levels (IMF) to population density by municipality (Statistics Catalonia), with more data being added every week.

Today, we’re opening the Public Data Explorer to your data. We’re making a new data format, the Dataset Publishing Language (DSPL), openly available, and providing an interface for anyone to upload their datasets. DSPL is an XML-based format designed from the ground up to support rich, interactive visualizations like those in the Public Data Explorer. The DSPL language and upload interface are available in Google Labs.

To upload a dataset, click on the “My Datasets” link on the left-hand side of the Public Data Explorer. Once imported, a dataset can be visualized, embedded in external websites, shared with others and published. If you’re an official provider, you can request that your datasets appear in the Public Data Explorer directory; please contact us to discuss this process.

With this new capability, we hope more datasets can come to life through Public Data Explorer visualisations and enable people to better understand the world around them and make more informed, data-driven decisions. Stay tuned for more datasets, visualization features and DSPL extensions in the future.

By Omar Benjelloun, Google Public Data Team