Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.heapanalytics.com

Post reply on HN
Print view View original

11–20 of 68 posts

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

#11

Post by anonyfuss »

matm wrote: post #9
nwhitehead wrote: post #7

Do you have any case studies showing what the actual overhead is? I love the idea but would worry about negatively impacting the customer experience.

CPU-wise, our SDK adds up to 2% overhead to normal UIEvent-handling. This is with frantic and constant user input - in practice the overhead is much less. Network-wise, we batch user activity and by default make a network request every 5-10 seconds. We'll expose a config variable so devs can tune this frequency on a per-app basis.

You're keeping the WWAN/WiFi interfaces awake, which burns a significant amount of battery, just because you want to gather data from the user.

On top of that, burning 2% overhead on UIEvent handling (which also impacts battery).

What a waste for something that users don't actually want you to be doing in the first place.

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

#12

Post by anonyfuss »

boctor wrote: 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‎?

> To achieve the no extra code part, is the SDK using swizzling‎?

They must be, which is a serious reliability/stability/correctness issue in its own right.

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

#13

Post by DenisM »

matm wrote: post #9
nwhitehead wrote: post #7

Do you have any case studies showing what the actual overhead is? I love the idea but would worry about negatively impacting the customer experience.

CPU-wise, our SDK adds up to 2% overhead to normal UIEvent-handling. This is with frantic and constant user input - in practice the overhead is much less. Network-wise, we batch user activity and by default make a network request every 5-10 seconds. We'll expose a config variable so devs can tune this frequency on a per-app basis.

Keeping network alive like this is not cool - the radio will drain the battery. It would be much better to not only allow a configuration for how often the sync happens, but also allow the app to manually trigger sync, normally at the same time as other network activity is going on so that no extra power is spent bringing the radio up and down.

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

#14

Post by drewvolpe »

matm wrote: post #9
nwhitehead wrote: post #7

Do you have any case studies showing what the actual overhead is? I love the idea but would worry about negatively impacting the customer experience.

CPU-wise, our SDK adds up to 2% overhead to normal UIEvent-handling. This is with frantic and constant user input - in practice the overhead is much less. Network-wise, we batch user activity and by default make a network request every 5-10 seconds. We'll expose a config variable so devs can tune this frequency on a per-app basis.

How much does it affect battery life ?

I would imagine 2% extra CPU plus frequent network connections would add up to a lot of extra battery drain.

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

#17

Post by matm »

DenisM wrote: post #13
matm wrote: post #9

Earlier quoted context omitted.

CPU-wise, our SDK adds up to 2% overhead to normal UIEvent-handling. This is with frantic and constant user input - in practice the overhead is much less. Network-wise, we batch user activity and by default make a network request every 5-10 seconds. We'll expose a config variable so devs can tune this frequency on a per-app basis.

Keeping network alive like this is not cool - the radio will drain the battery. It would be much better to not only allow a configuration for how often the sync happens, but also allow the app to manually trigger sync, normally at the same time as other network activity is going on so that no extra power is spent bringing the radio up and down.

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.

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

#18

Post by idunno246 »

boctor wrote: 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‎?

more likely they are installing a custom responder. At least, I think it might be viable with that

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

#19

Post by jazzychad »

So, I'm curious how this will compete with free offerings like Flurry which do similar-ish mobile analytics tracking and can handle millions of users per app for free. I got very excited about this Heap announcement but looked at the pricing. Multiple thousands/month for sub-million unique users may be considered steep (but then again I'm a cheap developer). I've been looking for a Flurry alternative (since I just want analytics and none of their ad junk).

Mobile apps are kind of a different beast from websites. Apps can have huge number of unique users, whereas SaaS websites tend to have many fewer users by comparison.

Post reply on HN