Heap is building analytics infrastructure for web and iOS. Unlike other tools, which require you to manually instrument code, Heap captures all user actions automatically, and then lets you answer questions retroactively. Instead of writing a bunch of new tracking code every time you want to answer a question, the data is already in Heap waiting to be analyzed.
As an engineer at Heap, you will work on our in-house distributed system that ingests billions of events a week and processes queries over 100s of terabytes of data in seconds. To learn more about our distributed system, see our talks at PGConf[1] or our recent blog post on how we index our data[2].
We have a small eng team made up of 13 engineers, nine in San Francisco, and four scattered around the globe.
Our interview process consists of a one hour technical phone interview, a three hour takehome problem, and a full day onsite in which you'll build a fake-but-plausible Heap feature.
We offer all of our employees unlimited vacation with a three week minimum.
Heap is building analytics infrastructure for web and mobile. Unlike other tools, which require you to manually instrument code, Heap captures all user actions automatically, and then lets you answer questions retroactively. Instead of writing a bunch of new tracking code every time you want to answer a question, the data is already in Heap waiting to be analyzed.
As an engineer at Heap, you will work on our in-house distributed system that ingests billions of events a week and processes queries over 100s of terabytes of data in seconds. To learn more about our distributed system, see our talks at PGConf [1] or our recent blog post on how we index our data [2].
We have a small eng team made up of 13 engineers, nine in San Francisco, and four scattered around the globe.
Our interview process consists of a one hour technical phone interview, a three hour takehome problem, and a full day onsite in which you'll build a fake-but-plausible Heap feature.
Heap is building analytics infrastructure for web and mobile. Unlike other tools, which require you to manually instrument code, Heap captures all user actions automatically, and then lets you answer questions retroactively. Instead of writing a bunch of new tracking code every time you want to answer a question, the data is already in Heap waiting to be analyzed.
As an engineer at Heap, you will work on our in-house distributed system that ingests billions of events a week and processes queries over 100s of terabytes of data in seconds. To learn more about our distributed system, see our talks at PGConf [1] or our recent blog post on how we index our data [2].
We have a small eng team made up of 13 engineers, nine in San Francisco, and four scattered around the globe.
Our interview process consists of a one hour technical phone interview, a three hour takehome problem, and a full day onsite in which you'll build a fake-but-plausible Heap feature.
You alluded to some of this already, but automatically capturing everything isn't just a feature you can tack on to an existing analytics system. You have to rethink everything from the ground-up in order to support it (the client-side SDKs, the infrastructure, the tools to organize the data, the analysis interface, etc).
This becomes obvious when you try both products side-by-side (and I encourage you to do so!). I haven't come across a single customer who sees this as a viable substitute for Heap.
Also, collecting everything doesn't mean you should pay attention to every possible metric all the time. It just makes it 1000x easier to hone in on the right metric at the right time.
That said, this is an awesome GA extension, and philipwalton deserves a lot of credit for building it.
Analytics tracking code is a serious headache. You rarely know upfront what events you'll care about later, it's a pain to setup and maintain, and there's a principal-agent problem where the person implementing tracking (a dev) isn't the one getting value from it (a non-dev).
I think we'll start seeing teams adopt more automated approaches to analytics tracking over time.
Disclaimer: I founded Heap (https://heapanalytics.com/) with the idea that manual instrumentation should be the exception, not the norm.
At the most fundamental level: Heap's products - our SDKs, infrastructure, interface, pricing - were built from the ground up and optimized for this "capture everything" philosophy. Mixpanel tacked it onto an experience that's still built around manual instrumentation.
This becomes obvious when you actually use both products. I encourage you to do so and witness the differences yourself.
A few deficiencies of Mixpanel's approach relative to Heap:
* Performance. If you click around Mixpanel's site, you'll notice a tracking request get sent for each and every interaction. Click 10 times in a row, and Mixpanel's SDK will issue 10 separate requests in succession. Heap's SDK does the right thing: batch events. This is because Heap's SDK is optimized for automatic event tracking, while Mixpanel's was built for legacy manual tracking.
* Data trustworthiness. Form submissions and link clicks can unload the page before an analytics request gets sent, which means Mixpanel will drop a large percentage of events (~30% in our experience). This gets exacerbated on mobile devices with poor internet connections. Heap does the right thing in each of these cases (it's actually a surprisingly tricky technical problem). This sort of data gap is dangerous for any real analysis, because you're basing decisions upon figures that are fundamentally wrong (especially on mobile!). The "best-effort" approach works for manual tracking, but not for automatic tracking.
* Data completeness. Mixpanel fails to capture some key client-side events, including pushstate and hashchange events. If you have a single-page webapp, pushtate/hashchange events are critical in understanding a user's flow through your product. Heap captures these (and other interactions) seamlessly. Mixpanel doesn't.
* Scale. Owler is the only customer cited as using Mixpanel's autotrack feature in production (at least as far as I can tell from their press release). Heap's automatic tracking, on the other hand, is live and battle-tested on some of the largest websites on the internet (heapanalytics.com/customers). It'll be interesting to see how Mixpanel's approach scales to their customer base. It's clearly not fully figured out: you'll note a "X-MP-CE-Backoff" response header to each of their analytics requests, presumably to pause data collection when their backend load is too high.
* Pricing. Mixpanel still applies traditional per-event pricing here. This causes a few issues: 1) costs can balloon unpredictably as you track more events, 2) you're disincentivized from exploring new data, 3) you have to do a cost/benefit analysis for each new event you're thinking to track. This is a major deterrent to ad-hoc, retroactive, exploratory analysis, which is the primary benefit of capturing everything.
It's clear that automatic data collection is the way of the future, and there's still so many more ways to evolve it (stay tuned!). I think we'll see more and more tools adopt this approach over time. But dealing with a surplus of data requires a fundamental rethinking of analytics practices, and it's not as simple as shoehorning features into traditional experiences.
Because it's really hard to build, test and maintain a non-trivial application in a dynamically-typed language like JavaScript.
I think it's telling that a lot of companies with the most mature products (Facebook, Dropbox, Asana) eventually resort to optional static typing in their products, whether that means extending their runtimes (e.g. Hack) or using a transpiler like TypeScript.
Sorry to hear this! I work at Heap, and Heap certainly shouldn't have any effect on your ajax calls. I also can't see how react.js would interfere with Mixpanel.
Maybe something else is happening. Could you shoot us an email ([email protected])? We'd love to fix this for you.
Heap's approach to analytics is a little different. Instead of forcing you to manually instrument code, Heap automatically captures all user actions. You can then define events retroactively, without writing a bunch of brittle tracking code.
Would love to hear your feedback on this. Does Heap's approach get you closer to what you need?
1. Empirically, we've found that our customers rarely fall back on custom attributes. The vast majority of queries run in Heap (>75%) operate on automatically-captured events. To me, this suggests we've either: 1) cut out a significant portion of implementation work, or 2) enabled analysis that was previously blocked by implementation work. If either (or both) are true, it's a win, and suggests that automatic event-tracking produces salient data out-of-the-box.
2. That said, some metrics are important and do require manual instrumentation. Coincidentally enough, we're about to launch a feature that solves the problem you mention and requires no extra implementation work. We're excited about it. Want to try it out on newrelic.com?
We get this question so frequently that we've created a page dedicated to answering it: https://heapanalytics.com/docs/other-tools. It describes how Heap compares to Google Analytics, Flurry, Mixpanel, and KISSMetrics.
At the core, Heap's main differentiator is that it automatically capture everything, such as clicks, taps, form submissions, and pageviews. This lets you analyze data retroactively, without writing any code. Every other analytics tool requires you to define events of interest upfront.
Feel free to ping me directly at [email protected] if you have more questions! Happy to go into more depth.
Heap is taking a new approach to web and iOS analytics: just capture everything. Whereas other analytics tools require you to define events upfront, Heap lets you run instant, retroactive analytics without writing code.
=== The Role ===
Your creativity and intelligence are much more important to us than your experience with our stack. We're eager to meet all types of engineers, regardless of where you live or what tools you use day-to-day.
We’d like to get to know you if:
* You enjoy teaching yourself whatever is necessary to build something.
* You plow through obstacles.
* You’ve written 10,000 lines of code that look really embarrassing in retrospect.
* You’ve written 10,000 lines of good code since then.
* You communicate ideas with clarity and precision.
* You make decisions with a preference for empiricism and measurement.
* You like fruit, sunshine, and bad jokes.
Our stack is Node + Redis + Postgres + Backbone + D3. Some things we're working on:
* Data capture. We’re integrating with more clients and frameworks, including Android, AngularJS, and Backbone.js, all with virtually no performance overhead or integration cost.
* Real-time infrastructure. We support an expressive set of queries that allow our users to slice and dice the data in arbitrary ways. The results need to come back with sub-second latencies and reflect up-to-the-minute data.
* Data visualization. Simple pre-generated graphs just don't cut it. There's an enormous number of ways to organize the data. Existing tools only scratch the surface.
Heap was in Y Combinator’s W13 batch. Soon after, we raised a $2M seed round from Ron Conway, Ram Shriram, Sam Altman, Garry Tan, Alexis Ohanian, Harj Taggar, and others.
We work in SF but are absolutely open to remote engineers. Email us at [email protected] with reasons as to why you'd make a great fit.
Heap is taking a new approach to web and iOS analytics: just capture everything. Whereas other analytics tools require you to define events upfront, Heap lets you run instant, retroactive analytics without writing code.
=== The Role ===
Your creativity and intelligence are much more important to us than your experience with our stack. We're eager to meet all types of engineers, regardless of where you live or what tools you use day-to-day.
We’d like to get to know you if:
* You enjoy teaching yourself whatever is necessary to build something.
* You plow through obstacles.
* You’ve written 10,000 lines of code that look really embarrassing in retrospect.
* You’ve written 10,000 lines of good code since then.
* You communicate ideas with clarity and precision.
* You make decisions with a preference for empiricism and measurement.
* You like fruit, sunshine, and bad jokes.
Our stack is Node + Redis + Postgres + Backbone + D3. Some things we're working on:
* Data capture. We’re integrating with more clients and frameworks, including Android, AngularJS, and Backbone.js, all with virtually no performance overhead or integration cost.
* Real-time infrastructure. We support an expressive set of queries that allow our users to slice and dice the data in arbitrary ways. The results need to come back with sub-second latencies and reflect up-to-the-minute data.
* Data visualization. Simple pre-generated graphs just don't cut it. There's an enormous number of ways to organize the data. Existing tools only scratch the surface.
Heap was in Y Combinator’s W13 batch. Soon after, we raised a $2M seed round from Ron Conway, Ram Shriram, Sam Altman, Garry Tan, Alexis Ohanian, Harj Taggar, and others.
We work in SF but are absolutely open to remote engineers. Email us at [email protected] with reasons as to why you'd make a great fit.
(Disclaimer: I'm a founder at Heap. We build mobile analytics, so I'm far from impartial.)
Amazon's main purpose in building an analytics tool is to drive spend to the Amazon App Store. If you can't measure the ROI of their app store, you can't devote more resources to it.
This applies to just about all the big tech companies and their respective distribution platforms: Google with AdWords, Facebook with mobile ads, and Apple with the iOS app store. Lots of dollars flow through these platforms, and Amazon/Facebook/Apple don't want their developers measuring those dollars with a hostile competitor's analytics offering. (Often, the hostile competitor they have in mind is Google.)
You'll notice this in the screenshots for Amazon's mobile analytics. On the Overview page, note the breakdown of "Lifetime Value Per User". There are separate figures for iOS users, Android users, and...Fire OS users. A line item for "Fire iOS users" would never be so prominent in Google or Apple's analytics (or even present).
Thus, Amazon et al. focus on making their own analytics tools good at measuring acquisition (prioritizing their own channels) and some high-level metrics. Digging into the data is much less of a priority. Even basic questions - "what's the conversion rate for my signup flow?", "what are the email addresses of my active users?", "what percent of my revenue comes from repeat visits?" - require you to use a different tool.
Bigger companies are aware of this feature gap and happy to pay the price premium. But startups are (appropriately) more price-sensitive, even though a solid investment in growth/analytics is arguably more important for startups.
I'd love to hear HN's feedback on how Heap (and other analytics companies) can structure their pricing to better accommodate small companies.
Heap is taking a new approach to web and iOS analytics: just capture everything. Whereas other analytics tools require you to define events upfront, Heap lets you run instant, retroactive analytics without writing code.
=== The Role ===
Your creativity and intelligence are much more important to us than your experience with our stack. We're eager to meet all types of engineers, regardless of where you live or what tools you use day-to-day.
We’d like to get to know you if:
* You enjoy teaching yourself whatever is necessary to build something.
* You plow through obstacles.
* You’ve written 10,000 lines of code that look really embarrassing in retrospect.
* You’ve written 10,000 lines of good code since then.
* You communicate ideas with clarity and precision.
* You make decisions with a preference for empiricism and measurement.
* You like fruit, sunshine, and bad jokes.
Our stack is Node + Redis + Postgres + Backbone + D3. Some things we're working on:
* Data capture. We’re integrating with more clients and frameworks, including Android, AngularJS, and Backbone.js, all with virtually no performance overhead or integration cost.
* Real-time infrastructure. We support an expressive set of queries that allow our users to slice and dice the data in arbitrary ways. The results need to come back with sub-second latencies and reflect up-to-the-minute data.
* Data visualization. Simple pre-generated graphs just don't cut it. There's an enormous number of ways to organize the data. Existing tools only scratch the surface.
Heap was in Y Combinator’s W13 batch. Soon after, we raised a $2M seed round from Ron Conway, Ram Shriram, Sam Altman, Garry Tan, Alexis Ohanian, Harj Taggar, and others.
We work in SF but are absolutely open to remote engineers. Email us at [email protected] with reasons as to why you'd make a great fit.
Heap is building analytics infrastructure for web and iOS. Unlike other tools, which require you to manually instrument code, Heap captures all user actions automatically, and then lets you answer questions retroactively. Instead of writing a bunch of new tracking code every time you want to answer a question, the data is already in Heap waiting to be analyzed.
As an engineer at Heap, you will work on our in-house distributed system that ingests billions of events a week and processes queries over 100s of terabytes of data in seconds. To learn more about our distributed system, see our talks at PGConf[1] or our recent blog post on how we index our data[2].
We have a small eng team made up of 13 engineers, nine in San Francisco, and four scattered around the globe.
Our interview process consists of a one hour technical phone interview, a three hour takehome problem, and a full day onsite in which you'll build a fake-but-plausible Heap feature.
We offer all of our employees unlimited vacation with a three week minimum.
We enjoy talking to everyone who interviews, so please apply: https://heapanalytics.com/jobs.
[1] https://www.youtube.com/watch?v=iJLq3GV1Dyk
[2] https://blog.heapanalytics.com/running-10-million-postgresql...