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 [email protected]? 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.