analysis of reviews from the google play store
play

ANALYSIS OF REVIEWS FROM THE GOOGLE PLAY STORE Prof. Rachel - PowerPoint PPT Presentation

ANALYSIS OF REVIEWS FROM THE GOOGLE PLAY STORE Prof. Rachel Harrison Oxford Brookes University rachel.harrison@brookes.ac.uk CONTEXT AND MOTIVATION 18% of all apps downloaders say ratings and reviews are extremely important , 36% say


  1. ANALYSIS OF REVIEWS FROM THE GOOGLE PLAY STORE Prof. Rachel Harrison Oxford Brookes University rachel.harrison@brookes.ac.uk

  2. CONTEXT AND MOTIVATION � 18% of all apps downloaders say ratings and reviews are “ extremely important ”, 36% say they are “ very important ,” and 34% say they are “ somewhat important .” (Nielsen, 2010) � The number of customer reviews an app receives tends to grow exponentially (Especially for very popular apps) � An ever-increasing volume of data to sieve through for useful information � critical reviews � recurring issues � trends reported

  3. STUDY DESIGN – DATA COLLECTION � Google App store* � 6 most popular categories � Personalization � Tools � Books and references � Education � Productivity � Health and fitness * Iacob, Claudia, Varsha Veerappa, and Rachel Harrison. "What are you complaining about?: a study of online reviews of mobile applications.“ Proceedings of the 27th International BCS Human Computer Interaction Conference . British Computer Society, 2013.

  4. STUDY DESIGN – DATA COLLECTION � For each app: � Rating, number of ratings, price, size, number of installs, last update, current version, reviews � For each review: � Date, rating, device, version of the app, title, text � 169 apps & 3279 reviews � 4.27 avg. rating � 326.83 avg. number of ratings/app � £1.92 avg. price

  5. Refined Codes Code Classes CLASSIFICATION SCHEME

  6. CLASSIFICATION SCHEME � Agreed on by 2 reviewers � How it works: “ Works good prefer over swype. Wish it had a smiley face button and issues with typing a single letter, doesn’t automatically space .” Snippet Code Class Refined Code “ Works good ” “Positive Feedback” “Overall” “ prefer over swype ” “Comparative Feedback” “Positive” “ wish it had a smiley face button ” “Requirements” “Missing gui feature” “ issues with typing a single letter ” “Reporting” “Minor bug” “ doesn’t automatically space ” “Requirements” “Missing logic feature”

  7. RESULTS 1 – HOW DO USERS RATE APPS? Distribution of Code Classes � Lower ratings are often by Star Rating accompanied by concerns about 30% customer support with no concern at about versioning 25% � Middle ratings are mostly likely to be linked to bug reports 20% � High ratings occur with 15% requirements requests 10% 5% 0% <2.5 2.5-3 3-3.5 3.5-4 4-4.5 4.5-5 comparative feedback customer support money feedback negative feedback reporting requirements usability versioning

  8. RESULT 2- HOW DO REVIEWS VARY WITH PRICE? Distribution of Class Codes by Price 16% � The main concern for reviews for 14% cheapest apps was mostly about requirements while that more 12% expensive ones was bug reporting. 10% � Price and money feedback was 8% positively correlated 6% � There is a weak negative correlation between price and 4% requirements 2% 0% 0.50-0.99 1.0-1.49 1.50-1.99 >2.00 comparative feedback customer support money feedback negative feedback reporting requirements usability versioning

  9. RESULT 3(A) – DISTRIBUTION OF REVIEWS ACROSS CLASS OF CODES No. of Reviews by Code Class 1200 � Users tend to provide positive feedback. 1000 � Reviews are used for expressing requirements and 800 reporting bugs. 600 � Users are least concerned with issues related to versioning 400 200 0

  10. RESULT 3(B) – DISTRIBUTION OF REVIEWS ACROSS REFINED CODES Distribution of Reviews by Refined Code � Omitted “Overall” which 600 dominates the distribution with 500 2219 reviews. 400 � Users write mostly about the functional aspect of apps. 300 200 100 0

  11. RESULT 4 – COMMONLY OCCURRING PAIRS OF CLASS OF CODE IN REVIEWS � Main Observations � Positive feedback is dominant across the reviews � Users tend to provide more than one type of feedback in a review � Money feedback occurred mostly with Reporting and Negative feedback. � Users tend to group multiple Requirements related issues in a review � The main measure of comparative feedback is usability

  12. RESULT 4 – COMMONLY OCCURRING PAIRS OF CLASS OF CODE IN REVIEWS 900 800 700 600 No. of Reviews 500 400 300 200 100 0 comparative customer money negative requirement reporting usability versioning feedback support feedback feedback s versioning 8 11 10 12 22 21 7 7 usability 40 12 46 16 37 40 23 7 requirements 34 14 58 56 75 100 40 21 reporting 36 35 124 166 64 75 37 22 positive feedback 144 83 283 91 258 473 228 60 negative feedback 15 21 85 56 166 56 16 12 money feedback 34 32 32 85 124 58 46 10 customer support 10 3 32 21 35 14 12 11 comparative feedback 1 10 34 15 36 34 40 8

  13. RESULT 5 – COMMONLY OCCURRING PAIRS OF (CODE CLASS, REFINED CODE) TUPLES IN REVIEWS � Interesting observations: � (Positive feedback, overall) and (Requirements, Missing logic feat) appeared together in 188 reviews (most commonly occurring pair of tuples in dataset) � Users are always looking for improvements in apps � (Positive feedback, overall) and (Positive feedback, GUI) appeared together in 176 reviews (2 nd most commonly occurring pair of tuples in dataset) � A good GUI makes users happy � (Positive feedback, functionality) was paired with (Positive feedback, overall) , (money feedback, worth the money), (positive feedback, gui) and (comparative feedback, positive) in 172, 51, 50 and 49 reviews respectively. � Good functionality made users feel that they are getting value for money

  14. RESULT 5 – COMMONLY OCCURRING PAIRS OF (CODE CLASS, REFINED CODE) TUPLES IN REVIEWS 600 500 (negative feedback,device) 400 (customer support,pf on support) (customer support,pf on 300 support) (usability,recommend it) 200 (usability,easy to use) 100 (customer support,pf on support) (requirements,missing 0 logic feat) (requirements,diff preference for existing gui feat) (reporting,minor bug) (reporting,medium bug) (reporting,major bug)

  15. MORE ABOUT Requirements REQUIREMENTS more user friendly features 2% � Users report what needs to be 4% diff added to the app to make it more preference updates more useful to them for existing 6% logic feat more 9% options 7% missing � How can we use this to extract logic feat 45% feature requests? diff preference for existing gui feat 12% missing gui feat 15%

  16. WHAT DO THESE FEATURE REQUESTS LOOK LIKE? “This "FaceBook" Application is the “simply the best keyboard there ever is! best! Just one major flaw, which thx for this little piece of magic dev! :) needs to be fixed keep up the good work. btw could we pls IMMEDIATELY! This "FaceBook" have mandarin language pack ?” Application NEEDS TO HAVE the Features: Bold, Underline, and Italics ! PLEASE FIX IMMEDIATELY! Is there any way that this "FaceBook" Application can please be upgraded as soon as possible to include the Features: Bold, Underline, and Italics?? ”

  17. MEET MARA* * Iacob, Claudia, and Rachel Harrison. "Retrieving and analyzing mobile apps feature requests from online reviews." Mining Software Repositories (MSR) , 2013 10th IEEE Working Conference on. IEEE, 2013.

  18. DERIVING LINGUISTIC RULES R1 R2 R3 Reviews “an exit “adding more “tips and math Snippets button would icons would be support would be fantastic” great” also be nice” Keywords would Linguistic (adding) <request> would (<ADV>) be <POSITIVE- rules ADJECTIVE>

  19. EVALUATION P = R = 237 TP/(TP+FP) TP/(TP+FN) Linguistic 136,998 Pre- Rules reviews processing TPXTN − FPXFN = MCC ( )( )( )( ) TP + FP TP + FN TN + FP TN + FN Feature Request Feature Requests Mining Algorithm Sample 1, size Sample 2, size 480 3000 Randomly selected Randomly selected 3000 feature requests one app and chose returned and checked its reviews as a whether they were sample for counting TPs. the FNs and TNs. R = 0.87 P = 0.85 MCC = 0.90

  20. LINGUISTIC RULES Linguistic Rule Example Context <request> would make it “support for VTODO would make it much <COMPARATIVE-ADJ> cooler” (<SB>) (<ADV>) wish there was “I just wish there was the smiley editor <request> ability” <request> should be “the long press should be shorter than <COMPARATIVE-ADJ > than 0.25 seconds” <existing-feature> wish < request> instead of <existing “Wish the 2 add-ons were in a bundle feature> pack instead of doing two transactions” “Next update please include a journaling please include <-request> feature with a keyword search” “Could use more icons”; “could use could use (more) < request> zoom and horizontal layouts” “Add the ability to create walls so they add the ability to <request> don’t go off screen and to make cool mazes” “The only thing missing is font (the only thing) missing <request> customizations” “Needs the ability to set custom wall needs the ability to <request> paper”

  21. CONCLUSION AND FUTURE WORK � Similar work on the App Store reviews (currently) � More detailed analysis of reviews stores � More precise definition of classification scheme � Strategies to extract useful information for mobile app developers � THANKS!

Recommend


More recommend