matm

Heap works great with dynamic content - in fact, we use it ourselves all the time on our own single-page app (built on Backbone).

As an added bonus of using Heap with Angular/Backbone, we automatically capture all pushState events, so you'll get accurate pageview tracking for free.

Not sure what you mean by your second point, but it sounds interesting. What sorts of use cases motivate this?

It's mostly the same market. The disconnect thus far has been that many of the people in this market who use analytics (PMs/marketers) are not the same people who integrate analytics (devs).

Looking through MP/KM's docs is pretty telling. You'll notice that they put a lot of emphasis on catering their onboarding flow to non-technical people. For example, KM's onboarding flow lets you choose between "Asking for 5 min of your developer's time" or "Asking for 3+ hours of your developer's time", the former being a quick n' dirty way to get started (presumably because the dropoff for the latter is so high).

Sorry about that - Ghostery seems to wholesale block any JS requests from the heapanalytics.com domain, which will of course break our site.

This issue only applies to our domain (heapanalytics.com). Keep in mind that your own website will not break with Ghostery if it has Heap installed.

For us, I/O isn't as big a cost factor, since our data processing mostly resides in ephemeral storage where I/O charges don't apply. (Our permanent data backups live in S3.)

I/O pricing does apply when using EBS.

Very true. This is basic stuff, and we simply overlooked it. In the future, we might even need to add increased redundancy to our data, which we need to be aware of.

Yes, we do all our querying on Postgres, and shard per customer.

We'll definitely make sure to write a post soon that describes this all in more depth.

Good point. We'll definitely keep an eye on this.

One of Heap's most important value props is retroactive analysis. You forgot to define an event upfront? No problem - it's available for you to analyze across your app's entire history.

A 60-day free trial helps our users make better use of retroactive analysis than, say, a 30-day free trial. The longer you accumulate data via Heap, the more viscerally you understand this need.

Not currently. But we're eager to learn more about your use case to see if we can figure something out! Care to email team@heapanalytics.com?

Interesting. With regards to the unit of pricing, our thinking was quite the opposite. There's a high variance in value across your userbase, but our previous (per-user) model would price them the same. This was an issue.

We tried to match a user's value as closely as possible by pricing per visit (instead of per user). This assumes, of course, that the frequency of a user's visits correlates closely with their overall value, which is certainly imperfect in some cases.

We already have one. It's part of our enterprise tier.

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 team@heapanalytics.com.

Huh, interesting! Will keep that in mind.

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.

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.

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 team@heapanalytics.com.

We'd definitely appreciate more data points on pricing - care to send us an email at team@heapanalytics.com, and we can discuss more there? It'd be great to understand what sort of price point works for people like you.

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.

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.

"Capture everything" need not imply "measure everything." It should imply "measure anything you need to, immediately and retroactively".

It's quite different. Clicktale and Mouseflow capture a similarly large volume of user data, but they do it at the expense of flexibly quantifying that data.

Most of their visualizations - while useful in their own right - are pre-built reports that serve a different role than the flexible reporting capabilities in Heap (and Google Analytics et al).

We initially tried to build this on Mongo, and it was a huge pain. I'll need to elaborate on why at some point, but the very ad-hoc nature of all our querying precludes any non-relational database from being our store (at least any that I'm aware of).

Our thinking is that it's an efficient way to grow responsibly while still gathering user feedback early and often.

We tried to include as much tangible product as is possible with an invite-only product.

Correct.

This is interesting. Our naive thinking was "fewer numbers" implies "easier comprehensibility", but I don't think the pricing was quite as understandable as we would've hoped. I like your suggestion a lot.

With the current model, your charges would spike. Which is bad.

But we plan to offer caps and the option to auto-sample if you exceed your tier.

Feel free to reach us at sales@heapanalytics.com. We'd love to talk about fair pricing, and we certainly need more data points to evaluate what that fair pricing is.

Oh, whoops. Good catch. That should be min, not max.

Very keen observation. There are a number of ways to solve this problem. Machine learning helps (there are a few simple heuristics we currently use to sort the Event Feed).

But the right interface for defining events helps even more.

Sorry for the frustratingly mum response.

Thanks for the heads-up, we'll fix this asap.

We've run into this issue before, and it seems to have something to do with the font's Unicode values being "out of range" on Windows, whatever that means.

Unfortunately, we're not tracking those events now, mostly because they don't fit neatly into the event-based analytics model (i.e. they're not as "graphable").

But that doesn't mean they aren't important. Agreed the data can be very useful.