Originally posted on Google Analytics blog
In the digital world, whether you’re writing stories for your loyal readers, creating creative content that your fans love, helping the digital community, or providing items and services for your customer, understanding your audience is at the heart of it all. Key to unlocking that information is access to tools for measuring your audience and understanding their behavior. In addition to making your page load faster, Accelerated Mobile Pages (AMP) provides multiple analytics options without compromising on performance.
You can choose to use a solution like amp-pixel that behaves like a simple tracking pixel. It uses a single URL that allows variable substitutions, so it’s very customizable. See the amp-pixel documentation for more detail.
The amp-analytics component, on the other hand, is a powerful solution that recognizes many types of event triggers to help you collect specific metrics. Since amp-analytics is supported by multiple analytics providers, this means you can use amp-analytics to configure multiple endpoints and data sets. AMP then manages all of the instrumentation to come up with the data specified and shares it with these analytics solution providers.
To use amp-analytics, include the component library in your document's <head>:
<head>
<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
And then include the component as follows (for these examples, make sure to specify your own account number instead of the placeholder):
<amp-analytics type="googleanalytics"> <script type="application/json"> { "vars": { "account": "UA-YYYY-Y" }, "triggers": { "defaultPageview": { "on": "visible", "request": "pageview", "vars": { "title": "Name of the Article" } } } } </script> </amp-analytics>
The JSON format is super flexible for describing several different types of events and it does not include any JavaScript code which could potentially lead to mistakes.
Expanding the above example, we can add another trigger, clickOnHeader:
clickOnHeader
<amp-analytics type="googleanalytics"> <script type="application/json"> { "vars": { "account": "UA-YYYY-Y" }, "triggers": { "defaultPageview": { "on": "visible", "request": "pageview", "vars": { "title": "Name of the Article" } }, "clickOnHeader": { "on": "click", "selector": "#header", "request": "event", "vars": { "eventCategory": "examples", "eventAction": "clicked-header" } } } } </script> </amp-analytics>
For a detailed description of data sets you can request, as well as the complete list of analytics providers supporting amp-analytics, check out the amp-analytics documentation. You can also see more implementation examples in the Amp By Example site.
If you want to conduct a user experience experiment on your AMP pages, such as an A/B test, you can use the amp-experiment element. Any configurations done in this element will also be exposed to amp-analytics and amp-pixel, so you can easily do a statistical analysis of your experiment.
There are still plenty of ongoing developments for AMP analytics to help you gain insights as you AMPlify the user experience on your site. Visit the AMP Project roadmap to see a summary of what the team is cooking up. If you see some features missing, please file a request on GitHub.
Posted by Nathan Martz, Product Manager, Google VR
At Google I/O, we announced Daydream—Google's platform for high quality, mobile virtual reality—and released early developer resources to get the community started with building for Daydream. Since then, the team has been hard at work, listening to feedback and evolving these resources into a suite of powerful developer tools.
Today, we are proud to announce that the Google VR SDK 1.0 with support for Daydream has graduated out of beta, and is now available on the Daydream developer site. Our updated SDK simplifies common VR development tasks so you can focus on building immersive, interactive mobile VR applications for Daydream-ready phones and headsets, and supports integrated asynchronous reprojection, high fidelity spatialized audio, and interactions using the Daydream controller.
To make it even easier to start developing with the Google VR SDK 1.0, we’ve partnered with Unity and Unreal so you can use the game engines and tools you’re already familiar with. We’ve also updated the site with full documentation, reference sample apps, and tutorials.
Native Unity integration
This release marks the debut of native Daydream integration in Unity, which enables Daydream developers to take full advantage of all of Unity’s optimizations in VR rendering. It also adds support for features like head tracking, deep linking, and easy Android manifest configuration. Many Daydream launch apps are already working with the newest integration features, and you can now download the new Unity binary here and the Daydream plugin here.
Native UE4 integration
We’ve made significant improvements to our UE4 native integration that will help developers build better production-quality Daydream apps. The latest version introduces Daydream controller support in the editor, a neck model, new rendering optimizations, and much more. UE4 developers can download the source here.
Get started today
While the first Daydream-ready phones and headset are coming this fall, you can start developing high-quality Daydream apps right now with the Google VR SDK 1.0 and the DIY developer kit.
We’re also opening applications to our Daydream Access Program (DAP) so we can work closely with even more developers building great content for Daydream. Submit your Daydream app proposal to apply to be part of our DAP.
When you create content for the Daydream platform, you know your apps will work seamlessly across every Daydream-ready phone and headset. Daydream is just getting started, and we’re looking forward to working together to help you build new immersive, interactive VR experiences. Stay tuned for more information about Daydream-ready phones and the Daydream headset and controller coming soon.
Posted by Michael Winser, Product Lead, Google Apps and Wesley Chun, Developer Advocate, Google Apps
Last week, we clarified the expectations and responsibilities when accessing Google user data via OAuth 2.0. Today, we’re announcing that in order to better protect users, we are increasing account security for enterprise Gmail users effective October 5, 2016. At this time, a new policy will take effect whereby users in a Google Apps domain, while changing their passwords on or after this date, will result in the revocation of the OAuth 2.0 tokens of apps that access their mailboxes using Gmail-based authorization scopes. Please note that users will not notice any specific changes on this date and their applications will continue to work. It is only when a user changes their password from that point moving forward that their Gmail-related tokens become invalid.
Developers should modify their applications to handle HTTP 400 or 401 error codes resulting from revoked tokens and prompt their users to go through the OAuth flow again to re-authorize those apps, such that they can access the user’s mailbox again (additional details below). Late last year, we announced a similar, planned change to our security policy that impacted a broader set of authorization scopes. We later decided not to move forward with that change for Apps customers and began working on a less impactful update as described above.
What is a revoked token?
A revoked OAuth 2.0 token no longer provides access to a user’s resources. Any attempt to use a revoked token in API calls will result in an error. Any existing token strings will no longer have any value and should be discarded. Applications accessing Google APIs should be modified to handle failed API calls.
Token revocation itself is not a new feature. Users have always been able to revoke access to applications in Security Checkup, and Google Apps admins have the ability to do the same in the Admin console. In addition, tokens that were not used for extended periods of time have always been subject to expiration or revocation. This change in our security policy will likely increase the rate of revoked tokens that applications see, since in some cases the process will now take place automatically.
What APIs and scopes are impacted?
To achieve the security benefits of this policy change with minimal admin confusion and end-user disruption, we’ve decided to limit its application to mail scopes only and to exclude Apps Script tokens. Apps installed via the Google Apps Marketplace are also not subject to the token revocation. Once this change is in effect, third-party mail apps like Apple Mail and Thunderbird―as well as other applications that use multiple scopes that include at least one mail scope―will stop accessing data upon password reset until a new OAuth 2.0 token has been granted. Your application will need to detect this scenario, notify the user that your application has lost access to their account data, and prompt them to go through the OAuth 2.0 flow again.
Mobile mail applications are also included in this policy change. For example, users who use the native mail application on iOS will have to re-authorize with their Google account credentials when their password has been changed. This new behavior for third-party mail apps on mobile aligns with the current behavior of the Gmail apps on iOS and Android, which also require re-authorization upon password reset.
How can I determine if my token was revoked?
Both short-lived access tokens and long-lived refresh tokens will be revoked when a user changes their password. Using a revoked access token to access an API or to generate a new access token will result in either HTTP 400 or 401 errors. If your application uses a library to access the API or handle the OAuth flow, then these errors will likely be thrown as exceptions. Consult the library’s documentation for information on how to catch these exceptions. NOTE: because HTTP 400 errors may be caused by a variety of reasons, expect the payload from a 400 due to a revoked token to be similar to the following:
{ "error_description": "Token has been revoked.", "error": "invalid_grant" }
How should my application handle revoked tokens?
This change emphasizes that token revocation should be considered a normal condition, not an error scenario. Your application should expect and detect the condition, and your UI should be optimized for restoring tokens.
To ensure that your application works correctly, we recommend doing the following:
If your application uses incremental authorization to accrue multiple scopes in the same token, you should track which features and scopes a given user has enabled. The end result is that if your app requested and obtained authorization for multiple scopes, and at least one of them is a mail scope, that token will be revoked, meaning you will need to prompt your user to re-authorize for all scopes originally granted.
Many applications use tokens to perform background or server-to-server API calls. Users expect this background activity to continue reliably. Since this policy change also affects those apps, this makes prompt notification requesting re-authorization even more important.
What is the timeline for this change?
To summarize, properly configured applications should be expected to handle invalid tokens in general, whether they be from expiration, non-existence, and revocation as normal conditions. We encourage developers to make any necessary changes to give their users the best experience possible. The policy change is planned to take effect on October 5, 2016.
Please see this Help Center article and FAQ for more details and the full list of mail scopes. Moving forward, any additional scopes to be added to the policy will be communicated in advance. We will provide those details as they become available.
Back in May at Google I/O, we announced the expansion Firebase, a mobile platform that enables you to quickly develop high-quality applications, grow your user base and earn more money. To help developers better understand the range of features in Firebase, our Developer Relations team in Sub-Saharan Africa will be hosting the Launchpad Build Event Series in Sub-Saharan Africa The first leg will be held in Lagos (22nd Sep), followed by Nairobi (26th Sep) and finally Cape Town (29th Sep).
Launchpad Build is an event series aimed at raising awareness, amongst intermediate and expert developers with an existing Web or Android application, around important tools available today.
At this event, engage in talks and hands-on codelabs focused on Firebase Analytics, Firebase Cloud Messaging, Firebase Crash Reporting, Firebase Test Lab, Pirate Metrics, Serverless with Firebase, Tensor Flow and much more. Through the Launchpad Build event, developers will get skills and resources necessary to start using Firebase in their applications.
This is a technical event, with multiple sessions on Firebase, facilitated by Googlers and Google Developer Experts from around the world.
For further information, visit the Launchpad Build Event Series Sub-Saharan Africa Website.
Register now: bit.ly/lpbuildssa2016
Applicants will be contacted with necessary details.
We have been investing in the core machine learning technologies that enable natural language interfaces for years. To continue that investment, we’re excited to welcome API.AI to Google!
API.AI has a proven track record for helping developers design, build and continuously improve their conversational interfaces. Over 60,000 developers are using API.AI to build conversational experiences, for environments such as Slack, Facebook Messenger and Kik, to name just a few. API.AI offers one of the leading conversational user interface platforms and they’ll help Google empower developers to continue building great natural language interfaces.
Stay tuned for more on details on integrations into Google. And if you’re already using API.AI, keep building your conversational interfaces and if you’re not, start today!
Posted by Roy Glasberg, Global Lead, Launchpad Accelerator
We’re delighted to open our call for applications for the third class of the Launchpad Accelerator. If you are a late-stage app startup from Brazil, India, Indonesia, or Mexico, we encourage you to apply here by October 24, 2016. Based outside of these countries? Stay tuned, as we expect to add more countries to the program in the future!
The equity-free program will begin on January 30, 2017 at the new Google Developers Launchpad Space in San Francisco and will include 2 weeks of all-expense-paid training.
What are the benefits?
During the kick-off bootcamp we deliver in-depth technical and business mentoring that enables our startups to tackle their specific challenges and successfully scale. Launchpad mentors hail from around the world and more than 20 teams across Google. In total, startups receive access to Google’s expertise and resources for 6 months.
What do we look for when selecting startups?
Each startup that applies to the Launchpad Accelerator is considered holistically and with great care. Below are general guidelines behind our process to help you understand what we look for in our candidates.
All startups in the program must:
Additionally, we are interested in what kind of startup you are. We also consider:
We look forward to learning more about your startup and working closely with you on building a successful business that has both a local and global impact.
Posted by Ale Borba and Adriana Cerundolo, Developer Relations Program Managers
Today kicks off the annual DevFest season, a series of developer community-run events which will be happening over the next 3 months. Google Developer Group (GDG) chapters from around the world will host #DevFest16 events, bringing together developers to exchange knowledge, share ideas, and express their passion for technology.
At its core, #DevFest16 is powered by a shared belief that when developers come together to exchange ideas, amazing things can happen! Itis an opportunity for GDGs to share speakers and event resources with each other to put on quality events uniquely tailored to the needs of the local developer communities. Attendees can expect technical content around Google developer technologies, including Firebase, Google Cloud Platform, machine learning with TensorFlow, web development and much more.
We anticipate 50k developers from over 70 countries to participate in #DevFest16 this year; from Canada to Australia, throughout South America, Africa, Europe and Asia, GDGs will be joining together to bring you an enriching developer experience. Go find a DevFest near to you!
Happy Festing!
The Closure Compiler was originally released, in Java, back in 2009. Today, we're announcing the very same Closure Compiler is now available in pure JavaScript, for use without Java. It's designed to run under NodeJS with support for some popular build tools.
If you've not heard of the Closure Compiler, it's a JavaScript optimizer, transpiler and type checker, which compiles your code into a high-performance, minified version. Nearly every web frontend at Google uses it to serve the smallest, fastest code possible.
It supports new features in ES2015, such as let, const, arrow functions, and provides polyfills for ES2015 methods not supported everywhere. To help you write better, maintainable and scalable code, the compiler also checks syntax, correct use of types, and provides warnings for many JavaScript gotchas. To find out more about the compiler itself, including tutorials, head to Google Developers.
This isn't a rewrite of Closure in JavaScript. Instead, we compile the Java source to JS to run under Node, or even inside a plain old browser. Every post or resource you see about Closure Compiler will also apply to this version.
To find out more about Closure Compiler's internals, be sure to check out this post by Dimitris (who works on the Closure team at Google), other posts on the Closure Tools blog, or read an exploratory post about Closure and how it can help your project in 2016.
Note that the JS version is experimental. It may not perform in the same way as the native Java version, but we believe it's an interesting new addition to the compiler landscape, and the Closure team will be working to improve and support it over time.
To include the JS version of Closure Compiler in your project, you should add it as a dependency of your project via NPM-
npm install --save-dev google-closure-compiler-js
To then use the compiler with Gulp, you can add a task like this-
const compiler = require('google-closure-compiler-js').gulp(); gulp.task('script', function() { // select your JS code here return gulp.src('./src/**/*.js', {base: './'}) .pipe(compiler({ compilation_level: 'SIMPLE', warning_level: 'VERBOSE', output_wrapper: '(function(){\n%output%\n}).call(this)', js_output_file: 'output.min.js', // outputs single file create_source_map: true })) .pipe(gulp.dest('./dist')); });
If you'd like to migrate from google-closure-compiler (which requires Java), you'll have to use gulp.src() or equivalents to load your JavaScript before it can be compiled. As this compiler runs in pure JavaScript, the compiler cannot load or save files from your filesystem directly.
For more information, check out Usage, supported Flags, or a demo project. Not all flags supported in the Java release are currently available in this experimental version. However, the compiler will let you know via exception if you've hit any missing ones.
Posted by Eitan Marder-Eppstein, Senior Software Engineer for Tango
Technology helps us connect and communicate with others -- from sharing commentary and photos on social media to a posting a video with breaking news, digital tools enable us to craft stories and share them with the world.
Tango can enhance storytelling by bringing augmented reality into our surroundings. Recently, the Tango team hosted a three-day developer workshop around how to use this technology to tell incredible stories through mobile devices. The workshop included a wide range of participants, from independent filmmakers and developers to producers and creatives at major media companies. By the end of the workshop, a number of new app prototypes had been created. Here are some of the workshop highlights:
We even had an independent developer use Tango to create realtime video stabilization tool. We’re looking forward to seeing these apps—and many more—come to life. If you want to start building your own storytelling and visual communication apps for augmented reality, check out our developer page and join our G+ community.
Posted by William Denniss, Product Manager, Identity and Authentication
The Identity team is constantly striving to help Google users sign-in to third-party applications with their Google account in a secure and seamless way, and enable users to share select information from their account such as their calendar or contact information with other apps, when they wish to do so.
Under the hood these interactions happen via OAuth requests, and over the years Google has supported a number of ways for developers to implement OAuth flows with us. With improved security and usability in mind, we will soon be ending the support for one of these ways. In the coming months, we will no longer allow OAuth requests to Google in embedded browsers known as “web-views”, such as the WebView UI element on Android and UIWebView/WKWebView on iOS, and equivalents on Windows and OS X.
In contrast, the outdated method of using embedded browsers for OAuth means a user must sign-in to Google each time, instead of using the existing logged-in session from the device. The device browser also provides improved security as apps are able to inspect and modify content in a web-view, but not content shown in the browser.
To help you migrate, we offer libraries and samples that follow modern best practices which you can use:
You can also read protocol-level documentation for our standards-based support of OAuth for Native Apps, and an IETF best current practice draft on this topic.
Versions of Google Sign-In on iOS prior to version 3.0 don’t support the current industry best practices of the in-app browser tab, and therefore are also deprecated. If you use Google Sign-In, please update to the latest version to get all the recent security and usability improvements. For now, this policy does not remove our support of WebView on iOS 8, however we may start to display notices encouraging users to upgrade their device for better security.
The rollout schedule for the deprecation of web-views for OAuth requests to Google is as follows. Starting October 20, 2016, we will prevent new OAuth clients from using web-views on platforms with a viable alternative, and will phase in user-facing notices for existing OAuth clients. On April 20, 2017, we will start blocking OAuth requests using web-views for all OAuth clients on platforms where viable alternatives exist.
If you have any questions with the migration, please post to Stack Overflow tagged with “google-oauth”.
