matm

Heap | Software Engineer | San Francisco | REMOTE https://heapanalytics.com/jobs

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...

Heap | Software Engineer | San Francisco | REMOTE https://heapanalytics.com/jobs

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.

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...

Heap | Software Engineer | San Francisco | REMOTE https://heapanalytics.com/jobs

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.

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...

Happy to hear that!

Could you email me at matin@heapanalytics.com? We're cooking up some features you might find useful.

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.

(Founder of Heap here.)

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.

No, Mixpanel does not auto-capture user interactions. Heap does. (Disclaimer: I build Heap.)

The Heap approach (i.e. auto-capturing events) lets you run retroactive/on-the-fly analytics. Without it, this feature is closer to a mobile equivalent of Google Tag Manager's click listener tag (https://support.google.com/tagmanager/answer/3415369?hl=en#C...) or KISSMetrics' click tracker (http://support.kissmetrics.com/tutorial/event-library-tutori...).

Happy that Mixpanel is making their event-tracking easier, though. It's a major pain-point, especially for mobile apps.

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 (support@heapanalytics.com)? We'd love to fix this for you.

Agreed. I built Heap (https://heapanalytics.com) to eliminate the clumsiness you mention.

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?

Heap (where I work) built a feature that addresses this exact use-case: https://heapanalytics.com/features/users. Is that what you had in mind?

(I'm a founder at Heap.)

This is an excellent point. Two things:

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?

Really sorry about this. We try to follow-up with every candidate, and you must have slipped through the cracks during the Thanksgiving holidays.

I'll make sure we get back to you ASAP.

(I'm a founder at Heap.)

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 matin@heapanalytics.com if you have more questions! Happy to go into more depth.

Heap (YC W13) - Software Engineer - San Francisco or Remote

https://heapanalytics.com/jobs

=== What's Heap? ===

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 jobs@heapanalytics.com with reasons as to why you'd make a great fit.

Heap (YC W13) - Software Engineer - San Francisco or Remote

https://heapanalytics.com/jobs

=== What's Heap? ===

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 jobs@heapanalytics.com with reasons as to why you'd make a great fit.

Relevant: Heap automatically takes this "capture every event" approach for you. Would be curious to get your thoughts: https://heapanalytics.com.

(I'm a founder at Heap.)

(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 (YC W13) - Software Engineer - San Francisco or Remote

https://heapanalytics.com/jobs

=== What's Heap? ===

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 jobs@heapanalytics.com with reasons as to why you'd make a great fit.

Heap's list view was built for this exact use case: https://heapanalytics.com/features/users. We use it all the time for developing a better intuition for our product.

(I'm a founder of Heap.)

This post was primarily written for a iOS dev-centric audience. I wanted to focus more on the underlying technical pieces than on selling Heap itself.

Noted, though, that we lost you with the piece's verbosity.

That would require modifying existing code.

Which is fine if you're adding automatic event-tracking directly to your own app. But for a third-party library (like our own), it exacerbates the integration process. Method swizzling allows for a purely drop-in solution.

Agreed. Will keep in mind next time we display performance stats.

At the very least, it should be trivial to confirm that CPU usage is low by checking out this code (or installing Heap) and running Time Profiler yourself.

That's true. The reason we showed the Energy Usage graph is because that's our most common perf-related question ("How does this affect battery life?").

It's certainly worth displaying the time spent in the replacement method call using the Time Profiler.

There are two components to method swizzling: 1) the initial method implementation exchange, 2) the overhead of calling the swizzled method before the original method.

The actual method exchange (#1) is little more than a pointer swap and happens at load time. You can safely assume it introduces no performance overhead.

The overhead of swizzled code (#2) is also minimal. Specifically, in Instruments you'll see that ~1ms of time gets spent in an empty replacement method before the original method is called. But this replacement method is blocking, so it's imperative you keep it as lean as possible (e.g. by pushing tasks onto a background queue).

Thanks for the heads-up. As mentioned over email: if the Event Visualizer isn't providing quite the right precision, keep in mind that you can manually specify hierarchical CSS selectors within the dashboard itself. It'll work as expected.

This is referring to the integration code itself. It was something like:

  var DOMEvents = ['click', 'submit', 'change'];
  for (var i = 0; i < DOMEvents.length; i++) {
    window.addEventListener(DOMEvents[i], function(e){
      $.post('/collector', {type: e.type, target_id: e.target.id, target_class: e.target.className});
    });
  }

We automatically annotate each event with referrer, search keyword, and all UTM properties. Full list of properties here: https://heapanalytics.com/docs#events

Would love to know if there's other important context we're missing.

For our use case, it just wasn't the right fit. In particular: 1) we needed more features/performance than Mongo's aggregation framework provided, 2) the mongod global lock was prohibitive for our write throughout (turning off fsync wasn't suitable), 3) schema migrations were difficult/impossible without transactional guarantees.

It seems like Mongo's addressed some of these concerns since we started building Heap.