Add Google Analytics

[barbeau]

As discussed in https://github.com/OneBusAway/onebusaway-iphone/issues/263#issuecomment-35123537, 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.

[bbodenmiller]

On a different note - we probably shouldn't report exact custom server URLs for privacy reasons, because they could be IP addresses. Maybe we just have a CUSTOM_URL generic name.

I disagree with this. If the user is using a custom server I believe we should collect the URL so we can see how widely used select custom servers are. We do this currently on iOS. Additionally I just looked through our privacy policy and I don't see anything that collecting those details violates, we mention that IP addresses may be occasionally collected.

[barbeau]

Additionally I just looked through our privacy policy and I don't see anything that collecting those details violates, we mention that IP addresses may be occasionally collected.

This potentially violates the personally identifiable information clause:

Our goal for information of this kind is to only store aggregate, non-personally-identifiable information. However, to gather this aggregate information accurately, we do need to store a small amount of personally identifying information for a limited time (less than 24 hours), so that for example we can count the number of unique users of the system.

If you're running your own OBA server and point the app at it, we're going to see the server name or IP address, if IP is entered, and permanently store this.

@bbodenmiller where is the reference to IP addresses? I don't see that in the Tampa or Puget Sound privacy policy pages.

At any rate, an easy solution to this is to SHA1 hash the custom URL. If all we really care about is how many unique OBA servers are out there, and that would do the trick without revealing the exact server name or IP.

Alternately, we may want to throw away analytics related to custom URLs. Given that we have "experimental regions" now, I imagine that most use directed at custom URLs will be during development, and I'd prefer not to mix this junk data in with actual user data. Or, we can prefix the label with something like CUSTOM_URL=<SHA_1_HASH>, so we can easily filter out the custom server URLs if desired.

[bbodenmiller]

I was reading the privacy policy from the iOS app:

However, instances of OneBusAway that serve a particular region may save log and other information, some of which is personally identifiable

Which I basically took to mean some IP addresses may be logged. Having now looked at each Privacy Policy further you are right it may violate them. I find it hard to believe that all access logs are being deleted every 24 hours.

Collecting user IPs also violates the Google Analytics Terms of Service:

You will not (and will not allow any third party to) use the Service to track, collect or upload any data that personally identifies an individual (such as a name, email address or billing information), or other data which can be reasonably linked to such information by Google.

So the iOS app needs to be updated to not collect the users IP or emails if they enter it in the custom API. For the most part people seem to be using the custom API field for free text like: seattle wa. If we hadn't collected peoples inputs we wouldn't know that the custom API field really should have a validator.

[cagryInside]

If so, maybe swapping the two would be better, to still allow sorting by initial distance: 00000-00050m - User Distance

Here is the GA report test result for latest configuration:

[bbodenmiller]

I don't think it makes sense to put User Distance: behind the numbers when all the other GA labels have it in the front & sorting works fine both ways.

[barbeau]

I don't think it makes sense to put User Distance: behind the numbers when all the other GA labels have it in the front & sorting works fine both ways.

Yeah, good point :). Not sure what I was thinking.

@cagryInside Can you confirm that the sorting still works with the label first, as originally presented?

[cagryInside]

Can you confirm that the sorting still works with the label first, as originally presented?

@barbeau Yes it should work with original configuration as shown in https://github.com/OneBusAway/onebusaway-android/issues/105#issuecomment-71071731

[barbeau]

@cagryInside Ok, great, let's go with that then.

[barbeau]

@bbodenmiller Also - where is the privacy policy for the iOS app? Is this linked to from within OBA iOS?

[barbeau]

Looks like Google has changed their best practices, and now recommends using different properties for tracking different platforms of the same app:

Track different platforms of an app in different properties. If you’ve developed the same app for different platforms (i.e., MyApp for Android and MyApp for iOS), track them in different properties. If you want to see the data together, creating an account with AdMob allows you to get a view of all of your data in one place with a rollup property. You can then set up new views to organize and compare the performances in your Google Analytics reports.

[bbodenmiller]

Hmm. If we do sepetate properties per app it looks like Google Analytics Premium is required for roll up reporting. What about using multiple tracking id's with one being a roll up and the other per app? Based on http://stackoverflow.com/questions/13681345/should-i-use-two-profiles-in-ga-for-tracking-android-and-ios-apps the recommendation definitely changed at some point.

[barbeau]

@bbodenmiller Hmm, good catch on requiring Premium account for rollup reporting. Recommendation definitely changed, if you look at the first comment on this ticket from me from Feb 2014 the quote says the exact opposite of what the current recommendation is.

Here's the link for multiple trackers for Android: https://developers.google.com/analytics/devguides/collection/android/v2/advanced#multiple-trackers

@cagryInside Can you please look more at multiple trackers option, and see if there are any downsides? As long as data is batched and sent at once I wouldn't think there is any huge performance hit.

[barbeau]

Interestingly, if you go to create a new property in GA console, you get this message:

Already tracking an app with Google Analytics? You might not need this step! An existing tracking ID can be reused in multiple app versions, app editions, and across platforms. In some cases, one tracking ID can also be used in multiple apps. Using an existing or new tracking ID affects how data appears in your reports.

Review the Best Practices for Mobile App Analytics set up to find out if you should get a new tracking ID or use an existing tracking ID.

This in turn links to the best practices guide that tells you to use different properties for different platforms.

[cagryInside]

Can you please look more at multiple trackers option, and see if there are any downsides? As long as data is batched and sent at once I wouldn't think there is any huge performance hit.

I agree that there won't be significant performance hit (network usage will slightly increase). On the other hand, we also need to change IOS app.

Since we want to keep the properties clean, we shouldn't touch current IOS property and we should create new property for rolled up reporting version.

IOS	Android
tracker1 (existing property for IOS)	tracker2 (new property for Android)
tracker3 (rolled up version)	tracker3 (rolled up version)

[barbeau]

@cagryInside I was thinking of the following, using multiple trackers on both iOS and Android:

IOS	Android
tracker1 (existing property - actually "OBA SmartPhone" with iOS view)	tracker1 (existing property - actually "OBA SmartPhone" with Android view)
tracker2 (rolled up version)	tracker3 (rolled up version)

We currently have the data segmented by views (iOS and Android) in GA on tracker 1 (although no data from any Android devices have been reported). The iOS View is defined as "all iOS platforms" (i.e., "Include OS Platform = ^(iOS|iPad|iPhone|iPod)$"), and the Android View is defined as "all non-iOS platforms (i.e., "exclude OS Platform = ^(iOS|iPad|iPhone|iPod)$"). I think the main downside of sharing the tracker is having events from both iOS and Android in the same GA console view, but it seems to me that there are ways to break out and organize all the data using the default GA tools where this isn't a problem.

I don't want to depend on GA Premium for being able to combine the data, since we currently, and in the immediate future, don't have a dedicated funding account for this. So, we would continue using the current tracker1 for the immediate future, but it would give us more flexibility and future-proof-ness if we decide to move to Google Analytics Premium in the future. In this case, going forward we would have both iOS and Android on separate trackers for the rolled up reporting.

[bbodenmiller]

I agree with @barbeau. I think we should use the existing tracker for the combined tracking (since it has the most complete data) and the two new trackers for platform specific tracking. For the foreseeable future the combined tracker could be used for reporting with the secondary tracker id's preparing for potential Google changes or if the per tracker limits are hit on the combined tracker.

[cagryInside]

@barbeau and @bbodenmiller My only concern is, when we start using existing tracker for the combined tracking, we won't get healthy results for couple weeks (since the IOS is reporting for long time, it will take some time to see good combined results from the android perspective).

[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 https://github.com/OneBusAway/onebusaway-iphone/issues/352#issue-56050282 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 https://github.com/OneBusAway/onebusaway-android/pull/209.

[barbeau]

Merged https://github.com/OneBusAway/onebusaway-android/pull/209 to implement GA in the develop branch.