Add Google Analytics

[barbeau]

As discussed in OneBusAway/onebusaway-iphone#263 (comment), we'd like to add Google Analytics to both the OBA iOS and Android apps to have better information about how they are being used. As recommended in GA Best Practices, we plan to use the same property for both apps:

Track different platforms of an app in the same property.
If you’ve developed the same app for different platforms (i.e., MyApp for Android and MyApp for iOS), track them in the same property. You can then set up new views to organize and compare the performances in your Google Analytics reports. If your iOS and Android apps differ greatly in performance or usage, you might want to track each platform in separate properties.

Tracking data is needed for research projects such as StopInfo.

[barbeau]

We should also include an opt-out setting for GA.

[bbodenmiller]

As per my comment at OneBusAway/onebusaway-iphone#263 (comment) I disagree that allowing an opt-out would be a good idea at this point.

[barbeau]

Here's what OBA iOS is tracking, and what we should use as a template for tracking in OBA Android.

[barbeau]

Apparently Google Analytics is now integrated in Google Play Services with the latest update, so a separate SDK for analytics is no longer required.

[jrharshath]

I'm new to GA - does anyone know if we can report custom statistics via GA?

I'm thinking of how to report the number of favourite stops that users have, or the number of reminders people use etc.

[bbodenmiller]

@jrharshath I believe one option to track those type of statistics might be custom metrics.

[bbodenmiller]

I've started working on this and hope to have a PR for initial feedback this coming weekend.

[barbeau]

@bbodenmiller Thanks for the heads up! I was actually planning to start work on this late this week or early next week as part of a project I'm working on. I assume you saw that I created an Android view in GA? Please keep me posted on how this is going, and I'd be glad to help speed up development.

Also, things we're interested in (beyond what OBA iOS is tracking), include tracking stopIDs information for requests (ideally that could be categorized by region), and rough locations and/or distance to stop for which info is being accessed (for example, to help answer the question if users are accessing OBA while they are standing at the stop, or from anther location such as home, work, etc.). Location info is tricky, since we need to protect privacy as well. So, we'll need to obfuscate location to some level - I plan to read more about existing techniques for this. Simple schemes include reducing accuracy of lat/longs through simple randomization of an offset or simply recording distance to stop or some general categorization of proximity to stop (e.g., near, medium, far). If we record raw distance to stop, we should obfuscate location before this too, since in some cases you could reverse engineer the probable source location. Likely something for discussion on the OBA dev list too, once I put together a plan for this.

[bbodenmiller]

Don't think I saw your GA view, could you point me to it?

bbodenmiller@f4feed5 has the progress I've made so far.

Any idea how we can get around Play Services with GA only working with SDK 9+ or do you think it is okay for us to up the minimum SDK to 9?

The type of information you are looking to log beyond what iOS has right now certainly sounds interesting but might require some creative solutions. That might be a good place to start looking in to beyond what I've started to get this on par with iOS tracking.

[paulcwatts]

We're down to about 4% usage on Android 2.2. I could be convinced to make 10+ the minimum.

[barbeau]

@bbodenmiller If you go to your GA account, Android view should be listed under "OneBusAway->OneBusAway Smartphone->OneBusAway Android." I think I've got the filtering correctly set up now so iOS data should only be visible under "OneBusAway iOS", and Android is visible under "OneBusAway Android". There doesn't seem to be a way to limit an initial spike in OBA Android numbers that occurs in history before you can set up the filter to exclude all iOS devices, so we'll just have to ignore the Day 0 numbers when running reports.

tl;dr:

IMO, since we're looking at implementing a few Play Services-based features, it will be simpler to start with Android 2.3 as a baseline and drop 2.2 (API 8) support.

Full explanation:

If we use newest version of the GA SDK (v4), that means using Google Play Services 4.3 or higher, which is only compatible with Android 2.3 (API Level 9) or higher. Note that according to the docs that this doesn't require Google Play Services to be installed on the device for GA to work at runtime:

Note: The SDK can be used and will work on devices that do not have Google Play Services. In this case the SDK will will automatically fall back to local dispatching.

Only option I see to keep support for Android 2.2 is to go with a legacy version of the GA SDK.

@paulcwatts just beat me to it, but since I have it typed up - from the Google Play Developer console, it looks like we still have ~8,400 OBA users (4.03%) on Android 2.2. Based on the Android dashboard, globally it looks like only 1% of Android devices accessing Google Play are still on Android 2.2.

We could do Maps v2 and Location API v2 while still keeping support for Android 2.2 via Google Play Services for Froyo (which just freezes the version at v3.2.65), but we'll need to drop Android 2.2 eventually if we want to keep pace with the latest Google Play Services version, since updates for Play Services are no longer being released for Android 2.2. And, I've seen misc. issues (e.g., problems with location updates suddenly stopping) that are (supposedly) fixed in later Play Services versions (e.g., >= 4.3.x). If we do an initial release for Android 2.2 with Google Play Services for Froyo, we'll likely be stuck with some problems out of the gate that can't be fixed.

[bbodenmiller]

I'm all for SDK 9 being the minimum just wanted to check with you guys. I also saw the note about GA working without Google Play Services being installed and wondered if that might allow us to still support SDK 8. Unfortunately Android Studio just complains when I put compile 'com.google.android.gms:play-services:4.4.52' in build.gradle and don't up the minimum SDK.

As a side note, what exactly does target SDK mean? Is there a reason behind keeping it at 17?

[paulcwatts]

Target SDK is the SDK we're building against, and what APIs we think we can use. So it allows us to "target" newer versions of Android while maintaining compatibility with older SDKs.

We could move it to the current SDK, if we want to target APIs that are unavailable in <= 17.

[barbeau]

I believe @paulcwatts is confusing targetSdkVersion with compileSdkVersion - compileSdkVersion defines which SDK you're building against, and you can only access APIs/methods in your source code that are <= compileSdkVersion. As @paulcwatts states, I'd only suggest bumping this if we need APIs that are only available in > compileSdkVersion, to avoid accidentally accessing an API that is not backwards compatible to our minSdkVersion (buildToolsVersion, on the other hand, should be kept up to date, to avoid bugs in the tool chain).

targetSdkVersion is one of the more confusing attributes - it should be the latest version of Android that you've actually tested your application against. Its a hint to the platform whether certain backwards compatibility features should be enabled for your app - you can see a list of these compatibility features on the Build.VERSION_CODES page, and a full description of targetSdkVersion on the uses-sdk page.

A good example is when the physical menu key was removed from some Android devices. If you had targetSdkVersion <= 13, on API 14 and higher Android would add a soft menu key to the app, to ensure users could access your legacy menu options. If you bump targetSdkVersion to 14 or higher, Android assumes you've updated your app to make legacy menu options available some other way (e.g., via ActionBar), and removes the soft menu key. If you didn't actually update your app to make your menu functions available via another method, then users on devices without menu keys couldn't access the menu functions (we actually got bit on this one on another app).

So, if we bump targetSdkVersion to > 17, we should definitely do testing on devices with API > 17 to ensure everything behaves as expected (and closely look at the Build.VERSION_CODES page above to see if any changes affect us).

[paulcwatts]

Good explanation @barbeau, I've been out of the game for too long :). For what it's worth, I use a KitKat (SDK=19) device all day, way more than I would use a SDK=17 device.

[bbodenmiller]

Thanks for the explanation. I'm not saying we need to up the targetSdkVersion yet but I did notice on the uses-sdk page it says:

To maintain your application along with each Android release, you should increase the value of this attribute to match the latest API level, then thoroughly test your application on the corresponding platform version.

[barbeau]

@paulcwatts Good to know, I'm on KitKat now too as my personal device (Galaxy S3, formerly stock, now Cyanogen). So, if we bump targetSdkVersion we should be able to get some good testing in.

@bbodenmiller Key word in that sentence is thoroughly :).

[barbeau]

@cagryInside is currently working on this. As mentioned earlier, we’d like to capture a metric for how far the user is in real-time from their bus stop when they check the arrival time. For example, is the user waiting at the bus stop when they check the time, or from a more distant location (e.g., work, coffee shop)? Does this differ depending on the stop?

To do this in a privacy-sensitive manner, we’re proposing that we capture distance ranges for each time the user checks the real-time info, without capturing the exact lat/long.

Here’s our current range definitions that would be captured for each arrival time check:

• NEAR = User is less than 75m (246ft) from the stop
• MEDIUM = User is between 75m (246ft) and 200m (656ft) from the stop
• FAR = User is greater than 200m (656ft) from the stop

Stop ID is captured for each arrival time check as well. So, we’d be able to determine the breakdown of near/middle/far access for each stop in the system, but without capturing precise locations for the access. We’d also make the assumption that locations with an extremely large accuracy uncertainty value (e.g., > 200m) would automatically get tossed into the “FAR” category (or thrown out completely?), no matter the exact location.

Any comments/suggestions? Any different opinions for what the range definitions should be, and the number of ranges? The current choice is somewhat arbitrary, so improvements are welcome.

[barbeau]

Above question also posted to oba-dev and users lists:
https://groups.google.com/forum/#!topic/onebusaway-users/bWe1nWm_gwI
https://groups.google.com/forum/#!topic/onebusaway-developers/bWe1nWm_gwI

[bbodenmiller]

Are you planning on collecting this information using Google Analytics?
Before you go through all the effort of wiring this up using GA I'd be sure
to check that GA allows you to crunch the numbers or export the way you'd
like to.

If you are going through the effort I think creating another bucket for
everything outside the "FAR" category would be good also. This might show
other unusual usage patterns or allow you to detect issues if a large
number of people start appearing in a "VERY FAR" category.

Are you planning on looking at the users reported location accuracy and
taking that in to account somehow? How about elevation vs. stop elevation
(could indicate working in a high rise)?

I think your buckets are either too small or you need more of them. For
example my house is about 2 blocks from the bus stop walking and about 1.5
as the crow flies but I would appear in the "FAR" bucket. The nearest
RapidRide stop is .5 miles or a 10 minute walk and it appears I wouldn't be
counted when viewing from home which I do very often. Perhaps you might do
5 buckets:

• at stop (<440ft or <2 minute walk)
• near stop (441-1100ft or 2-5 minute walk)
• medium (1101-2200ft or 6-10 minute walk)
• far (2201-3300ft or 11-15 minute walk)
• very far (3301+ft or 16+ minute walk)

(Assuming walking speed of 2.5 mph from WolframAlpha).
On Wed, Jan 7, 2015 at 2:28 PM Sean Barbeau notifications@github.com
wrote:

Above question also posted to oba-dev and users lists:
https://groups.google.com/forum/#!topic/onebusaway-users/bWe1nWm_gwI
https://groups.google.com/forum/#!topic/onebusaway-developers/bWe1nWm_gwI

—
Reply to this email directly or view it on GitHub
#105 (comment)
.

[barbeau]

Are you planning on collecting this information using Google Analytics?
Before you go through all the effort of wiring this up using GA I'd be sure
to check that GA allows you to crunch the numbers or export the way you'd
like to.

@bbodenmiller Yes, @cagryInside has been working with a PoC for this with Google Analytics, and it seems to work as expected. The buckets are essentially treated as arbitrary labels and can be sliced/diced as desired.

Thanks for the examples. I agree that we'd probably benefit from a few more buckets, and I like trying to frame it within walk times - perhaps we'd benefit from a "bike" bucket as well, so we could differentiate a reasonable bike distance for an immediate trip from users looking at stops from across the city or across regions. We'll look into this further.

Are you planning on looking at the users reported location accuracy and
taking that in to account somehow?

Yes, we could either throw out locations with a high accuracy uncertainty value, or automatically place them in the "FAR" bins. Picking the threshold here is a bit tricky.

How about elevation vs. stop elevation (could indicate working in a high rise)?

Thanks for bringing this up. Altitude values derived purely from GPS aren't precise enough to determine level within a building. But, over the last year or so phones have been shipping with embedded barometers, and other sensor fusion, that are making altitude more accurate. I'll have to think more about how this might be integrated into analytics - our system above is two dimensional. Today's altitude data probably wouldn't be very useful, but I could see technology progressing to a point in the next year or so where the altitude precision and accuracy would be much better, and usable. The other challenge here is that you'd also need an altitude value for the nearest bus stop or base map layer at a minimum, and potentially building data, to compare against and determine if someone is in a high-rise, and which "floor" someone is on. This would need to be pulled from another dataset.

[barbeau]

One other challenge I should mention related to capturing and using altitude - on Android, the only location accuracy value we have is horizontal accuracy. We do not have a comparable vertical accuracy value. So, given the current Location APIs on Android, determining whether or not an altitude value from a device is usable (i.e., from a newer-gen device with a barometer and sensor fusion) can be difficult - you'd really have to code around specific device make/models that you know support advanced altitude positioning.

IIRC, I believe iOS does have a vertical accuracy value.

[cagryInside]

We have implemented the fallowing segmentation hierarchy for capturing a metric for how far the user is in real-time from their bus stop when they check the arrival time.

• By region
  • By agency+stop
    • By search distance

In GA interface, we could segment these data.

Here is the results from GA:

Segment by search distance:

Search Distance Far:

Region: Tampa

[bbodenmiller]

What did you guys decide on the distances? Do you know if there is a limit on number of reported events? An event for every stop a user views could be a lot of events.

On iOS we report the users region to GA slightly differently. Since iOS and Android will use the same GA account it would be nice if they reported it the same way so the data can be aggregated together. Once the regions been reported once I believe you can just use that in your data view.

[cagryInside]

We also implemented exact same region reporting mechanism with IOS. This is an extra event for reporting distance.

Here is our latest study on distance:

Average walking speed from Wolfram Alpha
Average biking speed from Wikipedia

[bbodenmiller]

I think that should be fine since the combined tracker still allows filtering by platform.

[barbeau]

@cagryInside and I just discussed this, and given that we have views per platform defined in the main OBA account we should be able to segment per platform ok when using tracker1 on both platforms. So we're going to proceed with that plan.

I just grabbed two new tracker IDs for the unrolled versions:

• tracker 2 - iOS (unrolled) - UA-2423527-18
• tracker 3 - Android (unrolled) - UA-2423527-19

@bbodenmiller I'm going to open a new issue on OBA iOS for implementing dual trackers with tracker 2 there.

[bbodenmiller]

@barbeau can I get access to the new trackers?

[bbodenmiller]

Automated measurement features, like automatic screen and uncaught exception measurement, will only use one tracker to send data to Google Analytics. If you are using these features and want to send data using other trackers, you will need to do so manually.

Do we want to use tracker 1 as the default tracker? Or is there an easy way to send this data to multiple trackers?

[barbeau]

@bbodenmiller See OneBusAway/onebusaway-iphone#352 (comment) for a link to iOS multiple tracker implementation details. Probably best to continue iOS conversation on that thread. Just added you to view new trackers, let me know if you can't see them.

@cagryInside is implementing multiple trackers on Android.

[antrim]

I am considering working to implement OneBusAway for a small agency. Google Analytics reports would be useful for assessing usage and success. In addition, it might be useful to spot anomalies in usage patterns that would indicate a OBA configuration problem.

How would we access Google Analytics reports?

• It appears as though there are not instance-specific GA accounts. Would we therefore need access to a global GA account for OBA?
• Is there any way of restricting access to specific categories in GA for specific users?

[barbeau]

@aaronantrim Good questions.

It appears as though there are not instance-specific GA accounts. Would we therefore need access to a global GA account for OBA?

Yes, currently we have a global GA account for the official OBA apps deployed on Google Play and App Store. If you added a new region to OBA and users downloaded these same apps, we'd give you access to read/analyze the global account. You would be able to set up filters to view data only for users of your region.

Is there any way of restricting access to specific categories in GA for specific users?

Not presently, to my knowledge. All data is anonymous and collected at an aggregate level. Off the top of my head, the only potentially sensitive information for private industry may be the number of active users of a specific region. This would be visible to everyone.

If the global account issue is a non-starter but you still want to use the official OBA apps and deploy a new OBA region, we could potentially look into allowing regions to define their own GA account that would be private. I'd prefer to avoid this, though, if possible.

[antrim]

Thank you for these answers. I do not see any need to restrict GA reports for specific instances to specific users at this time. I just wanted to make sure my understanding was clear. I suppose if a sufficiently compelling need arose in the future, we could cross that bridge then.

[barbeau]

@aaronantrim Ok, great! Yes, we could always look at defining region-specific GA accounts in the future.

[bbodenmiller]

I agree with you both here. I see no reason the data needs to be private unless a private company begins using OBA. I actually think we should be posting the usage data more publicly on some sort of public dashboard. It appears we could even automate it using the GA Reporting API.

[barbeau]

I'm open to making the GA data/dashboard for OBA publicly readable - I actually tried to do that for the GA dashboard a while back but didn't see a way to do this given the Settings I saw within GA. Building something based on GA Reporting API is possible, but of course requires someone whip something together - I'm open to other ideas of anyone has them, or knows how to do this within GA dashboard.

[barbeau]

@aaronantrim Also, just to clarify - if you set up a server instance of OBA for a transit agency, that would include a website to access the real-time info. GA for that website would be managed privately by you. The centralized GA instance applies only to the Android/iOS apps.

[barbeau]

I'm re-opening this issue until we get GA merged into the develop branch - this is currently submitted as PR #209.

[barbeau]

Merged #209 to implement GA in the develop branch.