Live data from Hacker News

Heap for iOS: the capture-everything approach to mobile analytics

blog.heapanalytics.com

31–40 of 68 posts

Re: Heap for iOS: the capture-everything approach to mobile analytics

#31
post #17

Earlier quoted context omitted.

This makes total sense! Manually syncing is a good idea. We need to make sure we have reasonable defaults in place, though, and so far, we've had no issues from our beta testers.

Steady small but spaced updates is just about worst case for battery if you're on 3G. You want relatively large batch sizes so the system can turn the radios off and keep them off. Obviously doesn't matter if the main app is using the radios...

There is an excellent guide on the Android site covering this: http://developer.android.com/training/efficient-downloads/ef... (and it really applies to iPhones also)

Re: Heap for iOS: the capture-everything approach to mobile analytics

#32

Earlier quoted context omitted.

Sorry to bust your bubble, but most every major app (and every single game app) is already doing this by sending activity data to one company or another.

Doesn't make it right. It's also astonishingly user-hostile; wasting the user's resources (bandwidth, battery life, cpu) on things they don't care about, without their permission. On top of that, doing anything economical with the analytics is very rare. It's very difficult to isolate meaningful variables, and you're almost always better off spending that money paying a designer to tackle issues and features that rea…

> On top of that, doing anything economical with the analytics is very rare.

If this was true, then A/B testing would be useless, while it's quite the opposite.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#33
post #26
post #22

What is there on the analysis part? Restoring user behavior from touch events is a bit like restoring a steak from ground beef. Do you guys offer any help with that? Something to string individual events into a path?

You can try out the analysis part with some sample (web-only) data at: https://heapanalytics.com/dashboard/demo We let you define events after-the-fact based on the gesture type and the corresponding target variable. Once that event is defined, you can include it in funnels, view it in user-specific activity streams, slice n' dice it, etc.

Thanks for the demo link, that clears things up a bit.

FYI, I don't think you're using the work "cohort" correctly in the video. Cohorts are stable groups, composed of the same people over time. "Users who send 5 links" is not a cohort, as the group's composition changes over time.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#34
post #8

We need more mobile metrics innovation so I welcome this. Coincidentally just today I released an open source library on iDevRecipes to do smarter metrics. My approach is to use base classes. To achieve the no extra code part, is the SDK using swizzling‎?

You can easily intercept all UI events via UIWindow or UIApplication subclass, no swizzling required. I do this routinely to detect when a user is idle: no events - no activity.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#35
post #25

Fucking hell. This is exceptionally disturbing. This sort of service needs to be legally regulated now . The app devs must be required to warn in large block letters that evryhting you do in the app, even while offline, is streamed to some random company. You can argue all you want that "everyone's doing it", but it doesn't make this any less unacceptable and going against basic expectations of privacy.

Aside from using some user resource (like battery or network) how is this different from what website have been doing for a long time? There are tools to even track the mouse movement of the user.

Which is not the "everyone is doing it argument", but more "why does this need legal regulation now?". Why not before on web apps? The privacy implications look the same to me, but the point does not seem to be raised in the latter case.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#36
post #25

Fucking hell. This is exceptionally disturbing. This sort of service needs to be legally regulated now . The app devs must be required to warn in large block letters that evryhting you do in the app, even while offline, is streamed to some random company. You can argue all you want that "everyone's doing it", but it doesn't make this any less unacceptable and going against basic expectations of privacy.

I think you're overreacting. Privacy policy disclosure is obviously in order, but that's about all there is to it.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#37

Earlier quoted context omitted.

Doesn't make it right. It's also astonishingly user-hostile; wasting the user's resources (bandwidth, battery life, cpu) on things they don't care about, without their permission. On top of that, doing anything economical with the analytics is very rare. It's very difficult to isolate meaningful variables, and you're almost always better off spending that money paying a designer to tackle issues and features that rea…

> On top of that, doing anything economical with the analytics is very rare. If this was true, then A/B testing would be useless, while it's quite the opposite.

For most people, A/B testing a complex app (non-app websites are a completely different beast) is not economical compared to tackling larger (and hopefully obvious) design problems.

If your product is so well designed and developed that there's literally nothing obvious that you can improve without either 1) isolating changes down to colors or placement, and/or 2) throwing different options at the wall to see what sticks, then I say:

Congratulations.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#38
post #26
post #22

What is there on the analysis part? Restoring user behavior from touch events is a bit like restoring a steak from ground beef. Do you guys offer any help with that? Something to string individual events into a path?

You can try out the analysis part with some sample (web-only) data at: https://heapanalytics.com/dashboard/demo We let you define events after-the-fact based on the gesture type and the corresponding target variable. Once that event is defined, you can include it in funnels, view it in user-specific activity streams, slice n' dice it, etc.

How do you define user's "join date"? Is it the first time you saw the user?

For that matter, how do you identify the user? If the user logged in from two different machines, does it count as one user or two?

Re: Heap for iOS: the capture-everything approach to mobile analytics

#39
post #25

Fucking hell. This is exceptionally disturbing. This sort of service needs to be legally regulated now . The app devs must be required to warn in large block letters that evryhting you do in the app, even while offline, is streamed to some random company. You can argue all you want that "everyone's doing it", but it doesn't make this any less unacceptable and going against basic expectations of privacy.

Aside from using some user resource (like battery or network) how is this different from what website have been doing for a long time? There are tools to even track the mouse movement of the user. Which is not the "everyone is doing it argument", but more "why does this need legal regulation now?". Why not before on web apps? The privacy implications look the same to me, but the point does not seem to be raised in th…

> Aside from using some user resource (like battery or network) how is this different from what website have been doing for a long time?

1) Network requests (and thus communication with a remote machine that can log those requests) is an innate facet of the web. You can't load a site without explicitly choosing to make a network request. An app, however, might have no innate reason to make a network request at all.

I think #1 is the most important, but also:

2) JavaScript can be disabled.

3) HTML/JavaScript and browser network requests can be reviewed. Mobile applications are almost completely opaque to users.

4) Cookies can be blocked to reduce tracking surface.

5) Web analytics and cross-web tracking is already something people are concerned about, resulting in the introduction of do-not-track and similar.

Desktop apps have almost always explicitly asked permission before tracking users, whereas the web community seems to have brought to mobile a blasé approach to privacy and user respect.

Re: Heap for iOS: the capture-everything approach to mobile analytics

#40
So here's my quick feedback to the team.

Pros:

- Pricing is fine with me - I'm doing a paid SaaS app with relatively high per-user revenue. You will likely price out most of other devs, however.

- I like the retroactive analysis. The idea of grab everything and let god sort it out speaks to me.

- I like doing both device and web analytics in one place. I don't think doing one or the other makes sense anymore.

Cons:

- I don't see a way to make sure a user from different devices is counted as one user, not two. I want to track the user across all touch points. From experience I know solving this problem is very-very hard - sometimes you want to see what the user did before he identified himself, which is where your idea of "one user per session" falls apart - a session might have different users in it signin in and out, and then there is a period between signins which can be attributed to either of the authenticated users before or after in the same session. Not to mention apps with support for multiple-account apps, (e.g. iOS gmail app where identity depends on which part of the app you're in).

With all that said, I don't think I will be trying it out. There are tons of analytics services out there, and I don't feel like I can make an educated decision about which one to try first, or at all. Where you can help me is by providing a survey of the problem space, talking about the problems, potential solution methods, and then addressing which products implement which methods.

Good luck.

Post reply on HN