Use Conversion Goals to measure conversions across workflows. Learn more →

Hey Product Hunt 👋 Get 30% off your first 3 months if you sign up using this link

Tracking via JavaScript snippets

Offering a JavaScript snippet is a popular way to add tracking to web applications. In this update, Benedikt explains the technical complications with such solution, and why we're not planning to implement it (yet).

Benedikt Deicke
Benedikt Deicke

Both Jane and Claire are taking a few well deserved days off, so it’s Benedikt on the line again. Last week’s update was about tracking user behavior via our Push API. One of the follow-up questions we got was this: “Are you planning to offer a JavaScript snippet I can embed in my app to do the tracking?”

The answer to that is a definite “maybe” ?

Offering a JavaScript snippet is a popular way to add tracking to web applications. Since it works in the user’s browser, it’s basically platform independent — it doesn’t matter if your application is written in Ruby, PHP, Java, or any other language. In-browser JavaScript is the common denominator for all web-based SaaS applications.

However, we see a handful of problems with the JavaScript snippet approach:

  1. It’s hard to reliably identify core actions. JavaScript snippets are great to track page views or button clicks. Tracking these actions results in very fine-grained event streams that are very hard to distill into meaningful information. We’re convinced it’s better to only track core, high-level actions that relate to your product. Just because someone clicks a button on a form, doesn’t necessarily mean that they successfully created a new project.
  2. Tracking information can be lost because of ad blockers. Loading JavaScript snippets from 3rd party servers is usually a red flag for ad blockers. Chances are high that these snippets will get blocked eventually. This would mean that you don’t get any information about a user with ad blockers into Userlist. Effectively this also means that there’s no way to send them messages based on their behavior.
  3. Not everything can be tracked via JavaScript. Even if we’d offer a JavaScript snippet, some actions will still require a server side integration — e.g. events that happen without the user actively doing something in their browser. This includes things like scheduled email deliveries, completion of long-running background jobs, or friend requests being accepted by other users.
  4. JavaScript snippets are hard to get right. Lastly, building JavaScript snippets that are embedded in other websites are hard to build and test. They should work reliably across a lot of browsers and not break any functionality of the embedding website. It’s not impossible, but requires a lot of time and effort, that we’d rather spend on our core product right now.

Ultimately, we decided to not create a JavaScript snippet. Does that mean we’ll never build one at all? Probably not. We’ve got some ideas for future features (such as informational in-app messages) that will require a JavaScript snippet to work. For the time being, our focus is on the core application and the server side integrations to provide a solid base to build upon.

What’s your opinion on the topic? Is a JavaScript snippet a must-have feature for you? Let us know! We’re looking forward to your comments.

– Cheers, Benedikt.

Download your free guide on Atomic Emails

Don't wait for the muse. Apply this step-by-step method to write high-performing email campaigns in hours, not weeks.

About the author
Benedikt Deicke

Benedikt is a software engineer and ex-strategy consultant. Before founding Userlist, he used to help founders plan, build, grow, and maintain their web applications. He's a co-host on the Slow & Steady podcast and co-founder of FemtoConf.