fitbit-final presentation

Click here to load reader

Download Fitbit-Final Presentation

Post on 16-Jan-2017




1 download

Embed Size (px)


PowerPoint Presentation

Fitbit- Activity Monitoring, APIs development, Data Analytics and Network security

Avik Das, University of Connecticut, USA Hongxuwang, Jingyuanchou, University of Connecticut, USAYupengluo, University of Connecticut, USAMohammad Valizadeh, University of Connecticut, USA

Titles and Contents

Project ContentsFitBit Network APIs- Oauth protocol and Data Accuracy Fitbit Data AnalyticsFitbit network security and protocols

ChallengesFuture workReferences

FitBit Network APIs- Oauth protocol and Data Accuracy:

Oauth Protocol Introduction: Accessing Fitbit data from OAuth protocol & Data Accuracy

Authors- Yupeng Luo Jingyuan Chou Hongxu Wang

Oauth Protocol IntroductionOauth is a protocol that allow users to share private tokens, instead of passwords, that grant access to a specific service (e.g.Fitbit) for a specific resource(e.g. just step counts and hours slept) and for a defined duration (e.g. six months).

Fitbit provides a public API that allows us to gather the users data from their sensors . These APIs required permission to access data which was obtained with user permission via Oauth on an account setup website that we created.Now, we proceed to Authorization, which is very important in Oauth.


Obtaining ConsentFitbit supports theAuthorization Code GrantandImplicit Grantflows as defined inRFC 6749.(This is The OAuth 2.0 Authorization Framework)The Authorization Code Grant flow is recommended for applications that have a web service. This flow requires server-to-server communication using an application's client secret.

Authorization Code Grant FlowThe authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owners user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server

1.Application redirects the user to Fitbits authorization page.2.Fitbit redirects the user back to the client apps callback URL with authorization code.3.The client app exchange authorization code for an access token and refresh token.4.application stores the access token and refresh token. It will use the access token to make requests to the Fitbit API. It will use the refresh token to obtain a new access token when the access token expires without having to re-prompt the user.

Implicit Grant Flow

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.the client receives the access token as the result of the authorization request. The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI.

Implicit Grant Flow Example

1.Client App redirects user to the Fitbit Authentication Page.

2.Fitbit redirects the user back to the client apps callback URL with an access token as a URL fragment.

3.The client app stores the access token. It uses the access token to make request to Fitbit API.

Difference Between ACGF and IGFUnlike the Authorization Code Grant flow, the refresh tokens are not issued with the Implicit Grant flow. Refreshing a token requires use of the client secret, which cannot safely be stored in distributed application code. When the access token expires, users will need to re-authorize your app.

Access tokens from the Implicit Grant flow are longer lived than tokens from the Authorization Code Grant flow. Users may specify the lifetime of the access token from the authorization page when an application uses the Implicit Grant flow. The access token lifetime options are 1 day, 1 week, and 30 days. Applications can pre-select a token lifetime option, but the user ultimately decides.

Access tokens from the Implicit Grant flow are longer lived than tokens from the Authorization Code Grant flow. Users may specify the lifetime of the access token from the authorization page when an application uses the Implicit Grant flow. The access token lifetime options are 1 day, 1 week, and 30 days. Applications can pre-select a token lifetime option, but the user ultimately decides.10

ScopeApplications must only request permission for resources they intend to access or modify. OAuth 2.0 refers to these permissions as scopes. All Fitbit API endpoints require one or more scopes, which are listed in each endpoint's documentation.Applications must specify a list of scopes when redirecting the user to the authorization page. The access token issued will only contain the scopes the application requested.Below, we will introduce the scope parameters.


Scope Diameters

Accessing Fitbit data from OAuth protocol based APIStep1: finding a fitbit API that authorize users with access to fitbit dataStep2: add our own functions in javascript at google spreadsheetStep3: coding and testingStep4: visualize the data

How setup function works

Setup function in JavascriptApplication shown in spreadsheet

Get authorization from API & googleChoose the authorize function and hit runWhen you see the content on the right, grant your permission by clicking the allowAfter the account permission close, you successfully connect your google account with fitbit and API

Download data using APIWhy do we get the data using our own script?All the data will be downloaded automatically without any limitGoogle has a lot of gadgets and chart to help you visualize the data We can get another series of data by changing the value of the refreshTimeSeries function, and different category of data in GetActivity function

Data accuracy & comparison with iPhone HealthDateiPhone health data(steps)Fitbit Data(steps)Discrepancy(steps)Oct 64551453813Oct 7201420077Oct 8702370149Oct 9460346096Oct 105473546310Oct 11720572014Oct 124035400629Oct 136298631719Oct 14530052991Oct 158720866159

Data visualization in chart

Observations of comparisonWe did not take our iPhone and Fitbit with us 24/7, which may be one of the reason for discrepancyThe more steps taken, the more discrepancy appearsThe discrepancy is always below 1% from the data, which is trivial and acceptable in analyzing our fitness

ReferencesMobile Health Mashups: Making sense of multiple streams of wellbeing and contextual data for presentation on a mobile device, Konrad Tollmar, Frank Bentley, Cristobal Viedma, Department for Communication Systems, Royal Institute of Technology, Stockholm, Sweden.Acquiring Evaluation Data of Health Habits and Its Application- Xingquan Cai, Qianqian Shi and Lina Duan . Year- Aug 2013. Venue- College of Information Engineering, North China University of Technology, Beijing 100144, China.

FitBit Data Analysis

Predictive analysis (Depressed vs Non-Depressed)

SVM and Bayes algorithm for Predictive Analysis

Logistic Regression Analysis for (Depressed vs Non-Depressed)

FitBit Vs treadmill data collection

Linear Regression for FitBit vs Treadmill data relationship

Author- Avik Das

Predictive analyticsObjective: To develop a predictive algorithm based on the data collected from Fitbit to see if a person is depressed or not

Algorithm used: Supervised Machine learning and Bayes classification

Input Attributes: Date, Calories Burnt, Steps, Distance, Floors, Minutes Sedentary, Minutes Lightly Active, Minutes Fairly Active, Minutes Very Active, Activity Calories.

Output predicted: `Depressed (1) vs Non-Depressed State (1) (# of labels)

Data collection: Using an existing Fitbit API from Fitbit Dashboard

Assumptions: We will have the user data of depressed vs non-depressed for each date.

Input Attributes AttributesDescriptionDateThe date on which data is collected in MM/DD/CCYY (e.g. 11/29/2015)Calories burntThe cumulative calories burnt for a particular day (e.g. 393 cal)Steps The total number or steps taken by a person in a particular day (e.g. 190 steps)DistanceThe total distance covered by a person in a particular day in miles (e.g. 1.78 miles)Minutes AsleepThe duration during which the person was asleep in minutes (e.g. 299 Minutes)Minutes AwakeThe duration during which the person was awake in minutes (e.g. 299 Minutes)Number of AwakeningsThe number of times the person was awake in during the sleep duration (e.g. 11)Activity CaloriesThe number of active calories burnt for a particular day (e.g. 450 cal)

Overview of the prediction process

SVMBayes classification

Supervised Machine learningSVM (Supervise machine learning)- The Aim of SVM is to build a model that makes prediction based on evidence in the presence of uncertainty. As adaptive algorithms identify patterns in data, a computer "learns" from the observations. When exposed to more observations, the computer improves its predictive performance.

Steps taken:Data was collected using Fitbit API for all the dates in a .CSV fileA label (Depressed (1) vs non-Depressed) was assigned to all the records in the dataset. This data was converted into binary format.This data was divided into parts training and testing.The training dataset was used to create a model.The model predicted the labels of the testing dataThe labels