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:
- 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.
- 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.
- 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.
- 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.
Don't wait for the muse. Apply this step-by-step method to write high-performing email campaigns in hours, not weeks.