Heap for iOS: the capture-everything approach to mobile analytics(blog.heapanalytics.com)
blog.heapanalytics.com
Heap for iOS: the capture-everything approach to mobile analytics
http://blog.heapanalytics.com/?p=76
14 comments
I don't think this is an invasion of privacy at all. Heap hooks into single apps, it's not like it hooks into the OS to monitor user interaction with everything a user does in every app. I would sympathise with your reaction if this was the case.
I think it's perfectly good enough for a vendor to declare what data they are collecting in their ToS e.g. "we collect information on how you use the app" and why, e.g. "to consider for future versions so that we release the best possible, most useful software for our users". It's absurd to mandate that this be communicated in "large block letters" as this makes it into a bigger deal than it is.
Let's take off the tin foil hats and be pragmatic. I fully expect analytics to collected on everything I use and I understand the motivation behind it too, i.e. it's to improve whatever it is I am using to make it more useful, and therefore valuable to me.
I think it's perfectly good enough for a vendor to declare what data they are collecting in their ToS e.g. "we collect information on how you use the app" and why, e.g. "to consider for future versions so that we release the best possible, most useful software for our users". It's absurd to mandate that this be communicated in "large block letters" as this makes it into a bigger deal than it is.
Let's take off the tin foil hats and be pragmatic. I fully expect analytics to collected on everything I use and I understand the motivation behind it too, i.e. it's to improve whatever it is I am using to make it more useful, and therefore valuable to me.
> I don't think this is an invasion of privacy at all.
I vehemently disagree. Most companies will just hide the fact they are collecting (and often selling) user data within slimy legalese.
Consumer protection includes niceties such as warranties, and protection against false advertising, and clear display of nutritional information and safety warnings.
Privacy also deserves the same treatment so users can make an informed decision, without having to wade through a hefty licence agreement.
Edit: updated reply context
I vehemently disagree. Most companies will just hide the fact they are collecting (and often selling) user data within slimy legalese.
Consumer protection includes niceties such as warranties, and protection against false advertising, and clear display of nutritional information and safety warnings.
Privacy also deserves the same treatment so users can make an informed decision, without having to wade through a hefty licence agreement.
Edit: updated reply context
- "Most companies" sell user data? "Slimy?" Incredible bias here. Wouldn't be so bad if you provided some evidence to support up your position.
- ToS of don't have to be "hefty", they can be written in plain English.
Try using facts instead of loaded, emotional language to support your argument next time.
- ToS of don't have to be "hefty", they can be written in plain English.
Try using facts instead of loaded, emotional language to support your argument next time.
I didn't mean to say most companies sell user data, but rather of the companies that sell user data, most are not straight forward about it.
Example: Onavo, Dolphin Browser, Opera Mini, Ask Toolbar
What I am emphasising is that while they could ask plainly, and state they are collecting your data, and then selling it to 3rd parties (even if in aggregate), they do not.
I would want users to be given a clear choice about what is happening with their data, and some companies have the integrity to do this.
Example: Onavo, Dolphin Browser, Opera Mini, Ask Toolbar
What I am emphasising is that while they could ask plainly, and state they are collecting your data, and then selling it to 3rd parties (even if in aggregate), they do not.
I would want users to be given a clear choice about what is happening with their data, and some companies have the integrity to do this.
Companies I respect (including Apple) ask before gathering usage data; they don't hide it in the ToS that you and I both know nobody will read.
Do you object to asking users? If so, why? My guess is that you know the answer will usually be "no".
See also: opt-out vs. opt-in e-mail spam.
Do you object to asking users? If so, why? My guess is that you know the answer will usually be "no".
See also: opt-out vs. opt-in e-mail spam.
By all means users should be asked for permission. I can't speak for others but I personally don't often read ToS and that is my choice. In the event that there is something there that I object to and I miss it because I didn't read something I was supposed to I'm not going to cry about it.
What do you suppose the best way to ask for permission is? Please provide actual examples, perhaps from the companies you respect.
What do you suppose the best way to ask for permission is? Please provide actual examples, perhaps from the companies you respect.
> What do you suppose the best way to ask for permission is? Please provide actual examples, perhaps from the companies you respect.
Literally ask for permission. That's what Apple does, as does almost every other traditional desktop software developer. On first launch, or when an error occurs, or when some other event that would involve sending personal/usage data to Apple occurs, they:
- Ask if you want to send the data
- Provide details on what kind of information will be sent (including, in some cases, providing access to the data itself)
- ... and usually give you the option to always send that kind of data
Literally ask for permission. That's what Apple does, as does almost every other traditional desktop software developer. On first launch, or when an error occurs, or when some other event that would involve sending personal/usage data to Apple occurs, they:
- Ask if you want to send the data
- Provide details on what kind of information will be sent (including, in some cases, providing access to the data itself)
- ... and usually give you the option to always send that kind of data
I agree this is also a good way to ask for permission. Does Apple do this in iOS? I don't recall ever seeing it outside of OS X. I imagine it's difficult to clearly express why the app wants to send this data within the constraints of a UIAlertView.
iOS asks for permission before exposing location information, or access to contacts/photos and I can see why, the information is highly private. I don't agree that "this user pressed this button at this time" quite fits into the same category of privacy though.
iOS asks for permission before exposing location information, or access to contacts/photos and I can see why, the information is highly private. I don't agree that "this user pressed this button at this time" quite fits into the same category of privacy though.
> I agree this is also a good way to ask for permission. Does Apple do this in iOS?
Yep, just once.
> I don't agree that "this user pressed this button at this time" quite fits into the same category of privacy though.
You're going to consume the user's resources by sending that information, and most users don't really want you to (for obvious reasons), so it seems most ethical to ask first.
Yep, just once.
> I don't agree that "this user pressed this button at this time" quite fits into the same category of privacy though.
You're going to consume the user's resources by sending that information, and most users don't really want you to (for obvious reasons), so it seems most ethical to ask first.
[deleted]
Agree 100%. I am amazed by all the positive remarks around here. I understand the startup-vibe, but I would expect 'hackers' around here to take note of privacy concerns.
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.
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.
> 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.
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.
Disabling Javascript is an easy opt out for websites.
This service is designed to produce user specific data. judging from what they record on websites (see docs, tldr everything) I'd be surprised if the iPhone version doesn't record GPS locations or what other apps you use.
I'm also not sure how commonly websites record data in this detail that also maps to specific users, but if it's common on websites its definitely news to me - and all the more reason to use stuff like Ghostery/Disconnect/Noscript. Do these have iPhone equivalents yet?
This service is designed to produce user specific data. judging from what they record on websites (see docs, tldr everything) I'd be surprised if the iPhone version doesn't record GPS locations or what other apps you use.
I'm also not sure how commonly websites record data in this detail that also maps to specific users, but if it's common on websites its definitely news to me - and all the more reason to use stuff like Ghostery/Disconnect/Noscript. Do these have iPhone equivalents yet?
Not using an app is an easy opt out for people.
That assumes the customers know about it, and I think you're giving companies too much credit to assume they will disclose it.
Not a lot of customers know to disable JS either.
Because website is a service and an installable app is a product.
You expect a coffee shop's camera to track you, but you sure as hell don't expect your moka pot do that. Moreover, if it were doing that, you would've not bought it in the first place.
You expect a coffee shop's camera to track you, but you sure as hell don't expect your moka pot do that. Moreover, if it were doing that, you would've not bought it in the first place.
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 really ought to be obvious to you already ...
... unless you're Zynga, I guess.
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 really ought to be obvious to you already ...
... unless you're Zynga, I guess.
> 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.
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.
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.
>doing anything economical with the analytics is very rare.
That is a very bold claim and I'm interested if you have any sources to back it up. I'm hard pressed to believe that all of Facebook's design decisions hinge on whatever side of the bed Zuckerberg woke up on.
That is a very bold claim and I'm interested if you have any sources to back it up. I'm hard pressed to believe that all of Facebook's design decisions hinge on whatever side of the bed Zuckerberg woke up on.
Belief that numbers can be interpreted usefully without a rigorous statistical approach is an enormous fallacy; I don't really see why the burden of proof lies on me.
Once you do apply rigor, you'll find that what the numbers can tell you provides very little help in guiding application design (unless you're optimizing for extremely simple measurable metrics, eg, Zynga).
Note that Zynga themselves copies a full game design, and then applies metrics to optimizing games for addiction and spendthrift response.
The numbers also can't tell you that what you really need to do is rework your application's entire interaction model to cleanly integrate feature X, Y, and Z -- which will also be far too expensive to even attempt to A/B test.
Most analytics users are simply playing an expensive game of "hot or cold".
Once you do apply rigor, you'll find that what the numbers can tell you provides very little help in guiding application design (unless you're optimizing for extremely simple measurable metrics, eg, Zynga).
Note that Zynga themselves copies a full game design, and then applies metrics to optimizing games for addiction and spendthrift response.
The numbers also can't tell you that what you really need to do is rework your application's entire interaction model to cleanly integrate feature X, Y, and Z -- which will also be far too expensive to even attempt to A/B test.
Most analytics users are simply playing an expensive game of "hot or cold".
I'm interested how this is user hostile? What is the purpose of collecting such data? I think it's to improve whatever is being measured, to make it more useful. I don't call that hostile.
I thought I was the only one. I too think (in general) companies collect data to improve user experience. Although I am sure there are companies that misuse it (selling user data), but I would think most companies genuinely want to collect data to improve their product. Why do I believe this? Because I myself am a founder want this data for exact reason. It makes no sense to me to user that data in any other way. Why else woud I want it?
I am that "crazy" individual that actually answers YES to share usage data (as long as I feel it's reputable company or reputable management team). I do this because I don't want to be a hypocrite. I have yet to suffer any consequences of answering YES to most. Although I realize that my experience alone of opting in to sharing usage data has been fine, it doesn't mean much. I just hate when people cry loudly without any solid data of misuse.
My two cents...
I am that "crazy" individual that actually answers YES to share usage data (as long as I feel it's reputable company or reputable management team). I do this because I don't want to be a hypocrite. I have yet to suffer any consequences of answering YES to most. Although I realize that my experience alone of opting in to sharing usage data has been fine, it doesn't mean much. I just hate when people cry loudly without any solid data of misuse.
My two cents...
Then ask the user first. I'm sure that if you can elucidate the value of tracking their every interaction, they'll be happy to agree.
I'll say no, because don't want my battery wasted, my bandwidth consume, my IP logged, my address book mined, etc, just because a PM can't decode where to spend development and design dollars without fudging almost uselessly ambiguous numbers.
I'll say no, because don't want my battery wasted, my bandwidth consume, my IP logged, my address book mined, etc, just because a PM can't decode where to spend development and design dollars without fudging almost uselessly ambiguous numbers.
You are so incredibly misinformed. An address book cannot simply be mined. Those are extended permissions and access requires explicit opt in from the user at the OS level before the OS exposes any of that information.
Furthermore, do you have any data on how much battery, or bandwidth heap uses? No? Ok, please spare the FUD.
This is clearly about allowing developers to see how their users use their apps so they can improve the experience and make them more useful not about snooping on contacts/photos (which heap clearly does NOT facilitate). It goes without saying that the user has to be made aware that certain data is collected. I wonder, have you ever heard of a privacy policy?
Furthermore, do you have any data on how much battery, or bandwidth heap uses? No? Ok, please spare the FUD.
This is clearly about allowing developers to see how their users use their apps so they can improve the experience and make them more useful not about snooping on contacts/photos (which heap clearly does NOT facilitate). It goes without saying that the user has to be made aware that certain data is collected. I wonder, have you ever heard of a privacy policy?
> You are so incredibly misinformed. An address book cannot simply be mined. Those are extended permissions and access requires explicit opt in from the user at the OS level before the OS exposes any of that information.
It used to be possible without requiring opt-in. What I've seen in some applications has been piggy-backing permissions -- that is, wait until you have a legitimate reason to request access to the user's address book, location, etc, and then also send that information to your analytics service.
> Furthermore, do you have any data on how much battery, or bandwidth heap uses? No? Ok, please spare the FUD.
Sure I do. They're uploading every 15 seconds, which keeps the WWAN and/or WiFi links up all the time. That can shave at least 25% off of battery runtime (exact numbers aren't easy, given that there are a lot of other factors at play. The basic battery device recommendation is simply: let unused hardware be powered down whenever you can).
There are very limited CPU and battery resources on a mobile device, and it's ridiculous to waste them without asking, specially if you're planning on pushing a massive torrent of mostly-useless data.
> It goes without saying that the user has to be made aware that certain data is collected. I wonder, have you ever heard of a privacy policy?
Ah, right. Put it in the huge document that no user ever reads (because it's huge and unreadable), and that excuses everything.
This is the same argument that sleazy people make in favor of opt-out mailing list spam.
It used to be possible without requiring opt-in. What I've seen in some applications has been piggy-backing permissions -- that is, wait until you have a legitimate reason to request access to the user's address book, location, etc, and then also send that information to your analytics service.
> Furthermore, do you have any data on how much battery, or bandwidth heap uses? No? Ok, please spare the FUD.
Sure I do. They're uploading every 15 seconds, which keeps the WWAN and/or WiFi links up all the time. That can shave at least 25% off of battery runtime (exact numbers aren't easy, given that there are a lot of other factors at play. The basic battery device recommendation is simply: let unused hardware be powered down whenever you can).
There are very limited CPU and battery resources on a mobile device, and it's ridiculous to waste them without asking, specially if you're planning on pushing a massive torrent of mostly-useless data.
> It goes without saying that the user has to be made aware that certain data is collected. I wonder, have you ever heard of a privacy policy?
Ah, right. Put it in the huge document that no user ever reads (because it's huge and unreadable), and that excuses everything.
This is the same argument that sleazy people make in favor of opt-out mailing list spam.
Please don't slight me by implicitly putting me in the class of "sleazy people" whom send "spam". It's been nice discussing this with you, but since you're resorting to ad hominem I'll wish you well and bow out of this discussion. Thanks.
We don't do it in our apps or games. And I know quite a few developers who make analytics opt-in via settings (as well those who provide an opt-out). Big brand games probably do it, though.
i think app devs may already be liable if they haven't set up a proper privacy policy for their app that explains what data they collect and how it is used.
i would not automatically enable analytics tools like these without consulting a lawyer.
i would not automatically enable analytics tools like these without consulting a lawyer.
I think you're overreacting. Privacy policy disclosure is obviously in order, but that's about all there is to it.
When is the last time you read a privacy policy disclosure?
A reasonable person would assume that if an application has no functionality that requires sending data over the network, the application won't surreptitiously spy on you and send your data over the network.
A reasonable person would assume that if an application has no functionality that requires sending data over the network, the application won't surreptitiously spy on you and send your data over the network.
this is how analytics should be done. congrats, guys. proud to be an investor!
I've been having an awesome time with Heap for the web. Their response time is fantastic for user feedback too.
Glad they exist.
Glad they exist.
Is the "capture everything" approach to analytics a way to differentiate themselves from more enterprise level mobile analytics solutions such as Localytics?
Been testing Heap on iOS out for the last few days. Awesome product. Congrats guys!
Curious if this means that the Heap SDK will require for the shipped app to be symbolicated or not, given how their example is written.
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.
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.
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)
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.
I would imagine 2% extra CPU plus frequent network connections would add up to a lot of extra battery drain.
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.
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.
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?
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.
more likely they are installing a custom responder. At least, I think it might be viable with that
[deleted]
> 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.
They must be, which is a serious reliability/stability/correctness issue in its own right.
[deleted]
[deleted]
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.
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.
We'd definitely appreciate more data points on pricing - care to send us an email at [email protected], and we can discuss more there? It'd be great to understand what sort of price point works for people like you.
I've wanted to use heap in the past, but the plans aren't very startup friendly..
Similar to my comment above: it'd be great to understand what sort of price point works for people like you. Feel free to send us an email at [email protected].
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?
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.
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.
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.
Huh, interesting! Will keep that in mind.
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?
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?
Yes, first time we saw the user.
It counts as two, since by default we identify users with first-party cookies. We offer a heap.identify() API call that can be made to associate multiple devices with one identity.
It counts as two, since by default we identify users with first-party cookies. We offer a heap.identify() API call that can be made to associate multiple devices with one identity.
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.
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.
Great, thanks for the thorough feedback!
Re: your first con. We offer a heap.identify() API call that associates activity with one canonical identity. For instance, if a user logs in on a new separate device, you can call heap.identify({handle: 'DenisM'}) to associate all activity on that device with the existing user DenisM.
We hope you reconsider and give us a go. We're always down to talk more in person and better understand your use cases. Just ping us at [email protected].
Re: your first con. We offer a heap.identify() API call that associates activity with one canonical identity. For instance, if a user logs in on a new separate device, you can call heap.identify({handle: 'DenisM'}) to associate all activity on that device with the existing user DenisM.
We hope you reconsider and give us a go. We're always down to talk more in person and better understand your use cases. Just ping us at [email protected].
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.