Showing posts with label analytics. Show all posts
Showing posts with label analytics. Show all posts

Saturday, February 20, 2016

Using Credentials between your Server and Google Services

Posted by Laurence Moroney, Developer Advocate



This is part 4 of a series on Google Sign-In that began with a blog post on the user experience improvements that launched with Google Play services 8.3. We then discussed the API updates that make the programming model much easier. Most recently, we went into how you can use Google Sign-In to authenticate a user with your backend server.



In this post, we’ll discuss how you can have your users sign in via your app to authorize your service for access to Google APIs, such as Google Drive, on their behalf.



When using Google Sign-In, it is easy to extend your integration with Google by requesting additional scopes for API access after sign-in, like storing the user’s pictures of food in Google Drive. Typically, you should request this access incrementally (not at initial sign-in) -- i.e. in the context of a user’s actions (for example, after an app user’s order has been delivered and they’d like to save a copy of their food photos), following best practices in user experience to make it most likely that the user will grant access, and aligning with the runtime permissions model in Android Marshmallow 6.0.



When you do this kind of integration, you probably want to access data from your server, so that you can continue to have access when the user is offline, or to store user-generated data in your own database. This flow would look like Figure 1. This also has the advantage of working across all platforms.





Figure 1. Accessing Google Services with Credentials.



To do this, follow these steps:



Step 1: As with the scenario in server authentication covered in the previous post, this sample provides canonical code for your Android app. In particular see the ServerAuthCodeActivity.




 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
.requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))
// The serverClientId is an OAuth 2.0 web client ID
// Details at: https://developers.google.com/identity/sign-in/android/?utm_campaign=android_discussion_server_021116&utm_source=anddev&utm_medium=blogstart step 4
.requestServerAuthCode(serverClientId)

.requestEmail()
.build();


This requires you to get a web client ID for your server. Details on how to obtain this are available here (see Step 4).



In this case, the scope DRIVE_APPFOLDER is requested, meaning that the user will be asked to give the app permission to access their Google Drive. In addition to this, a server auth code will be requested.



If the sign-in is successful, the auth code can be extracted from the account object like this:




 if (result.isSuccess()) {  
GoogleSignInAccount acct = result.getSignInAccount();
String authCode = acct.getServerAuthCode();
}


(Taken from onActivityResult in the sample here)



This auth code should then be sent to your server using HTTPS POST, and, after it is exchanged, will give your server access to the user’s Google Drive. [Important: you should send the code in an authenticated call to your backend to ensure that it is a legitimate request from the active user].



Step 2: On your server, you will then exchange the auth code for tokens using the GoogleAuthorizationCodeTokenRequest class:




 // Set path to the Web application client_secret_*.json file you downloaded from the  
// Google Developers Console: https://console.developers.google.com/project/_/apiui/credential
// You can also find your Web application client ID and client secret from the
// console and specify them directly when you create the GoogleAuthorizationCodeTokenRequest
// object.
String CLIENT_SECRET_FILE = "/path/to/client_secret.json"; // Be careful not to share this!
String REDIRECT_URI = "/path/to/web_app_redirect" // Can be empty if you don’t use web redirects
// Exchange auth code for access token
GoogleClientSecrets clientSecrets =
GoogleClientSecrets.load(
JacksonFactory.getDefaultInstance(), new FileReader(CLIENT_SECRET_FILE));
GoogleTokenResponse tokenResponse =
new GoogleAuthorizationCodeTokenRequest(
new NetHttpTransport(),
JacksonFactory.getDefaultInstance(),
"https://www.googleapis.com/oauth2/v4/token",
clientSecrets.getDetails().getClientId(),
clientSecrets.getDetails().getClientSecret(),
authCode,
REDIRECT_URI)
.execute();
String accessToken = tokenResponse.getAccessToken();
String refreshToken = tokenResponse.getRefreshToken();
Long expiresInSeconds = tokenResponse.getExpiresInSeconds();
// You can also get an ID token from the exchange result if basic profile scopes are requested
// e.g. starting GoogleSignInOptions.Builder from GoogleSignInOptions.DEFAULT_SIGN_IN like the
// sample code as used here: http://goo.gl/0Unpq8
//
// GoogleIdToken googleIdToken = tokenResponse.parseIdToken();


Then, create a GoogleCredential object using the tokens from GoogleTokenResponse:




 GoogleCredential credential = new GoogleCredential.Builder()  
.setTransport(new NetHttpTransport())
.setJsonFactory(JacksonFactory.getDefaultInstance())
.setClientSecrets(clientSecrets)
.build();
credential.setAccessToken(accessToken);
credential.setExpiresInSeconds(expiresInSeconds);
credential.setRefreshToken(refreshToken);


If a refresh token is available, you can persist the credentials using StoredCredential for later use if you need ongoing access to the API on behalf of the user.



Step 3: The credential can then be used to access Google services. Now, in our food delivery scenario, you might want to store or retrieve photos or receipts of finished deliveries in Google Drive. For example, it would look something like this:




 Drive drive = new Drive.Builder(new NetHttpTransport(),   
JacksonFactory.getDefaultInstance(),
credential)
.setApplicationName("Auth Code Exchange Demo")
.build();
File file = drive.files().get("appfolder").execute();


This demonstrates the use of Google Sign-In credentials where your server can make Google API calls on behalf of your users. To learn more about this, and all Google Sign In technologies, visit the Google Identity Platform website.



Thursday, September 10, 2015

Play Games Loot Drop for Developers

Posted by Ben Frenkel, Product Manager Google Play Games



Launched last March, Player Analytics is already becoming an important tool for many game developers, helping them to manage their games businesses and optimize in-game player behavior. Today we’re expanding Player Analytics with two new analytics reports that give you better visibility into time-based player activity and custom game events. We’re also introducing a new Player Stats API to let you tune your game experience for specific segments of players across the game lifecycle. Along with those, we’re rolling out a new version of our C++/iOS SDKs and Unity plug-in and giving you better tools to manage repeating Quests.



New useful reports for developers



We are launching two new reports later this week in the Play Games developer console: the Player Time Series Explorer and the Events Viewer. We’ve also made improvements to our player retention report.



Player Time Series Explorer



Ever wondered what your players are doing in the first few minutes of gameplay? What happens just before players spend or churn? The time-series explorer lets you understand what happens in these critical moments for your players.



For example, you carefully built out the first set of experiences in your game, but are surprised by how many players never get through even the first set of challenges. With the Player Time Series Explorer, you can now see which challenges are impeding player progress most, and make targeted improvements to decrease the rate of churn. Learn more.



Customize settings to explore player time series





Select from a list of preset questions





Find out what happens before your players spend for the first time



Select “What happens before first spend” to see what happens just before your players spend for the first time. Time series are aligned by first spend event so you can easily explore what happened just before and after first purchase.





Find out what happens before your players churn



Select “What happens before churn” to see what happens before your players stop playing. In the example below, all the churn events are right aligned to make it easier to compare player time series.





Hovering over events shows you additional details

You can see more details for all event types by holding your cursor over the event’s shape. In this example, you can see that “Player 03” spent $4.99 after earning six achievements. Hovering over the achievement shapes will show you which specific achievements were earned.





Events Viewer



Now you can create your own reports based on your custom Play Games’ events. You can select multiple events to display and bookmark the report for easy access. Learn more.



Here’s an example showing how a developer can compare the rates at which Players are entering contests, winning, and almost winning. This report would identify opportunities to improve the balance of its contest modes. You can then bookmark the settings so you can easily track improvements.





28x28 day retention grid



We added a 28-day-by-28-day retention grid to help you compare retention rates across a larger number of new user cohorts.





Tailor player experiences with the Player Stats API



Stats and reports give you insights into your what your players are doing, but wouldn’t it be nice to take action on those insights in your game? That’s what the Player Stats API is all about. The Player Stats API lets you tailor player experiences to specific segments of players across the game lifecycle. Player segments are based on player progression, spend, and engagement.



Here are some examples of what you can do with Player Stats API:



  • For highly engaged players that just aren’t spending, you can show them special bonuses that are aimed at recruiting others to play instead of spending

  • For your most prolific spenders, you can provide occasional free gifts and upgrades

  • For users that haven’t found their stride in your game, you can show them a video that directs them to community features, like clan attacks or alliances, that drive deeper engagement

  • For players that have been away from the game for a while, you can give them a welcome back message that acknowledges impressive accomplishments, and award a badge designed to encourage return play


The Player Stats API is launching in the next few weeks.



C++/iOS SDK and Unity Plug-in updates



iOS support for Play game services just got a lot better. This update includes improved CocoaPods support, which will make it easier to configure Play game services in Xcode. This also means you’ll have a much easier time building for iOS using the Unity plug-in as well.



The latest build of the C++/iOS SDKs is now built on the new Google Sign-In framework, which adds support for authentication via multiple Google apps, including Gmail and YouTube. More importantly, if a player does not have any applicable Google apps installed, the Sign-In framework will bring up a webview within the app for authentication. Opening up a webview inside the app, instead of switching to a separate browser instance, makes for a much better user experience, and addresses a top developer request. For more on the new Google Sign-in library on iOS, check out this video. Learn more.



Improved Quests



Quests are a great way of engaging your players with new goals, and with this update we have made managing Quests easier with the introduction of repeating Quests. You can create Quests that run weekly or monthly by checking the repeating quest box. This will make it easier for you to engage your players with regularly occurring challenges. Repeating Quests will be launching in the next few weeks.



If you have previously integrated Quests, you can easily convert them into repeating quests by following two easy steps.



1. Go to Quests section of developer console, and open up an existing Quest. Click the copy Quest button at the top of the page





2. Scroll down to the Schedule section of the Quest form, check the “Repeating quest” box, select between monthly and weekly quests under “Repeats”, and leave the “Ends:” field set to “Never”. After hitting save, you are done! From then on, the quest will run weekly or monthly until you decide to end it.





Google Play game services (GPGS) docs and SDK downloads