In order for Noibu to detect ROI impacting errors, our script needs to capture 3 types of data.
1. User information
All user clicks and keyboard input are captured and anonymized by our script. We do so to be able to calculate the most common reproduction steps, to understand the funnel progression of the user and to create a textual representation of the user’s journey through your website. The collection of this data adds no or minimal latency to your website.
2. Error Information data
In order for Noibu to catch as many errors as possible, our script instruments existing code to catch hidden errors. What this means in a technical sense is that the Noibu script wraps existing code to try to find errors that were previously not being reported to the console.
Since we wrap code in order to catch hidden errors, our script usually shows up as the main contributor to CPU usage in the Google Lighthouse performance test. This is to be expected since our script becomes the first visible code to the Google Lighthouse test.
3. Session Recording information
The last piece of data that our script is concerned about is the session of the user, in order to capture the session replay of the user we monitor live mutations on the website and store those mutations. A website mutation could be:
- User clicking on a button
- Carousel image changing
- Css animation
- Adding a product to cart
Anything that changes the website’s content is stored and then during replay time we replay those mutations to the viewer on our dashboard. This information collection is the most expensive and was subject to heavy engineering investment in order to become as efficient as possible.
In order for our system to calculate the ROI on errors, offer session replay, etc we need all of the above information to be sent to our backend services. This is done in two ways:
1. Post requests
We send page and error information via POST requests. We only communicate with this endpoint when we detect that users might be leaving the page:
- When user change tabs
- When users close the browser
- When users change pages
Those requests are typically very short (1-100ms) and do not add any latency to your website. We took the necessary steps to reduce the amount of information we were sending per POST request by splitting the information into smaller pieces and sending those pieces individually.
We send session recording activity via a web-socket in order to not hinder site performance. A web-socket is a stream of information and once opened it has to be explicitly closed, unlike traditional requests that close themselves as soon as a response is received from the server. We keep our socket alive for the entire user journey in order to transmit all the session recording information. For that reason you will see that this request is Pending for the entirety of the user session.
Noibu’s commitment to performance
As a monitoring solution that is deployed on all of your user’s websites, our software needs to add minimal latency to your website. Which means that all of our operations need to be very carefully implemented with performance in mind. Noibu is committed to minimizing the impact of performance on your website.
In order to ensure performance and script compatibility with our customer’s website we established multiple processes to monitor the performance and availability of our script.
1. Manual testing before any script changes are pushed to production
Before any change is allowed to be pushed to the production script, engineers need to manually test their changes on various ecommerce platforms. We do so by using an extension run on google chrome, safari and mozilla firefox that allows us to inject our script into our browsers. Once our script is injected into our browsers we execute dummy purchases on a significant subset of our customers websites and monitor the performance impact, error creation and responsiveness of the websites. Once we conclude that our changes are safe, we push our changes to production.
2. Error logging system for our script
In order to constantly monitor our script’s performance and availability, we have setup a mechanism to capture our own script failures as well as suspicious activity. Our script is also fully capable of disabling itself once it starts congesting the network. Our whole team gets alerted when new errors occur on any of our customer websites and it becomes a top of mind priority when such an alert comes in.
3. Constant engineering effort in performance improvements
We have a dedicated engineering team working constantly on data input and performance quality. We call this team our “collect side” engineering team. One of their objectives is to ensure minimal performance impact on our customers.