AKA Why This Will Be Your New Favourite Tool
You don’t have a lot of time, so let’s just cut right to the chase… Why does Noibu have the potential to be your favourite tool? Or at the very least, how can Noibu ease some of your major development woes?
Put very simply, Noibu is the automated eCommerce error detection and revenue recovery tool that saves you from doing hours of bug reproductions and helps you operate in a leaner fashion.
Can you imagine how much more time you would have on your hands if you didn’t have to do your own digging to find the root cause of an error? Can you imagine how much more efficient your sprints would be if the beautified stack traces for errors were served to you on a silver platter?
With Noibu, you don’t have to imagine.
But, let’s actually break down how these functionalities help you.
Prioritizing bug fixes
What metrics are you currently looking at to determine what errors should be prioritized? How do you decide which errors are having a bigger impact on the business and thus should be addressed before working on a new feature that the product team has been pushing for?
Speaking with some industry professionals who have previously used other error monitoring software in their developer role, the tools“were capturing our site errors… But they were just a regurgitation of information. Our team would arbitrarily round up what we believed to be the top 10 errors and get to work…”
Unfortunately, the tools they were using never really gave an indication as to how important any one error was.
The result of this? Without data on conversion drops, revenue loss, or the nature of the error, the teams would spend a day (or even 2, evidently) of development time trying to figure out what was actually going on with the “top 10” errors and confirm their severity.
TLDR; Stop spending hours investigating the legitimacy and urgency of a bug. Noibu lets developers view error types along with conversion and revenue impact to properly determine, in a matter of seconds, what should be worked on and when.
Providing Context for Fix Requests
How often does your development team get forwarded a fix request from the support team spurred on by a customer ticket? And how often does the request look something like, “Developers! A customer just called in to complain that the website is broken. Fix it.”
To be fair, it’s not your support team’s fault that they can’t provide you with enough contextual data around a fix request.
Unless the customer is technical and incredibly kind enough to write out everything they did to encounter that error, both your support team and your fellow developers are going to be stuck investigating.
Noibu allows developers to perform individual session searches, though, so you can work backwards to tie the error to the support request without hours of digging. This way, you can quickly pinpoint what went wrong with a minified stack trace or last reproduction step (that is automatically captured and displayed), watch the customer effects, and deploy a solution without the frustration of being given a request with no direction.
*a recording of the error captured in real time
TLDR; Eliminate the frustration associated with customer tickets and support’s fix requests by having all necessary contextual data ready to go and easily findable.
Understanding, Handling, and Resolving Errors
How these errors manifest and how they get resolved are ultimately very different from each other, but the process of finding, understanding, and handling them have a fair amount of overlap.
To use a weird analogy… We can liken the typical bug remediation workflow to being a detective tasked with solving a crime. You’re told there’s been a crime, and that the crime happened somewhere in a mansion.
You have a bit of data there; you know something went wrong and you know the general vicinity where it took place (think: an error occurred, it happened on your website). It’s definitely a starting point, but you don’t really know where to start investigating.
The task of having to go through the mansion floor by floor, room by room, unsure of what exactly it is you’re looking for… that’s pretty daunting, right?
Worse, it’s time consuming. And yes, even worse than that, while you’re spending time looking in the wrong places, the culprit is still on the loose and able to do more damage.
Noibu – the reliable Watson to your Sherlock – can get you off to a much better start. Rather than being prompted with, “a crime in a mansion,” you get, “The groundskeeper was murdered in the study with a knife.”
As one of our own developers said, “We’re serving you the body. We can’t tell you why they were killed, but here are the tools you need to find that answer and get justice, a lot quicker than you would have been able to before.”
But what does this Noibu workflow look like when actually applied in your team?
After using the prioritization feature and selecting an error to begin working on, developers can navigate over to the Developer Tab. Here, you will see the error signature, the error message displayed, and the stack trace associated with the bug.
Essentially, it’s all the data you would get from rounds of reproducing the error manually.
If there is a stack trace available, developers can open the trace and see that Noibu has already highlighted the line of code that is responsible for the bug, so you can immediately focus your efforts there.
Comparing the error signature to the line that is highlighted can give a good developer a solid idea as to what caused the bug, without needing to do much other detective work.
The stack trace associated with the error? Captured.
The line of code that is causing the error to be thrown? Highlighted.
The devices, operating systems, pages, browsers the error is occurring on? Gathered.
All the data that the hours-long replication workflow would typically surface? Ready and waiting.
The New Way of Handling HTTP Errors
If you’d like to see how the console handles specific HTTP error codes, send us a quick message at email@example.com and we’d be happy to show you.
After determining the priority of an HTTP error fix by using conversion and revenue impact metrics, developers can dive into the error report and head to the Developer Tab.
To identify what action spurred the HTTP error, developers can go into Session playback and get an itemized, timestamped list of every action that took place during that session with the specific root cause highlighted. Using the timestamp and the HTTP error details, you can go into your service logs and look for calls and failures that also occurred during that exact timestamp.
TLDR; Quickly identify what actions are causing an HTTP error to be thrown, the resulting symptoms of the error, and snag the exact timestamp to investigate in your service or cloud logs.
Clearing The Department’s Name
Everyone is quick to point fingers at the developers when an error is detected. And sure, code mistakes happen from time to time (as they do in every other department), but we’re of a mindset that developers aren’t the culprit of site errors, they are the ones that fix them.
We actually have a piece on why we adamantly believe that developers can and should be seen as the heroes when it comes to site errors, rather than the villains.
That all being said…
In the eyes of the support and product teams, one can understand why they would be frustrated: developers are supposed to build and maintain the site, why are the support staff the ones alerting them when something is broken. It can be frustrating to constantly have to ask the development team to fix site errors.
What if, instead of waiting to get requests (with limited contextual data, too!), your developers could reduce inter-team friction by proactively gathering lists of live errors and solving them before anyone has a chance to complain. When the end of the sprint comes around, the development team can instead boast about all the things they fixed for the website without being prompted.
With Noibu, developers only need to log into the console to immediately see all live site errors currently plaguing the website. From there, they can easily pinpoint the errors with the largest business impact, figure out what the customer experience of any error looks like, and begin resolving them… Again, all without needing to interact with the support team.
TDLR; By proactively resolving errors, you can transition your development team from being viewed as the source of the problem, to the centre of excellence.
Our own engineers are always hard at work developing new features to help eCommerce teams do their job more efficiently.
Some things already launched or getting ready for production:
– The Noibu SDK
– Source Maps (in BETA)
– Issue Tables
What are Other Developers Thinking?
A brand talking about how amazing their product is won’t carry as much weight as hearing directly from customers. So don’t just take our word for it!
Here’s how a few of our current customers’ development teams are liking the software.
Noibu has exceeded Joe Browns’ expectations in terms of implementation with both their internal and external developers. […]
“The developers are happier because ultimately they are doing what they like doing, which is the development side of things and not necessarily the replication of bugs.” – Joe Browns Case Study
He measured his success with the product based on how much he now interacts with the customer service team. Previously, he would receive 5 to 6 complaints a day and now he receives 1 every couple of weeks. […]
The reduced man-power was also critical for Scrubs and Beyond. “We could have easily hired someone full time to do what I was doing before because it was so time consuming. Now I am able to put my time elsewhere because Noibu will do the job for me.” – Scrubs and Beyond Case Study
With Noibu in place and integrated into the development and QA processes, Princess Auto can accurately quantify the cost of bug fixes using a metrics-based approach. They are no longer using a subjective approach where their prioritization is driven by the opinions of multiple team members. […]
“Now when someone opens the hood and takes a look at our system, they see all the issues right there,” said David Matthes, Imagination Leader at Princess Auto. “We now have the ability to collect the analytics around why a repeatable problem is going on and how to fix it.” – Princess Auto Case Study
Dan explained that “We were just kind of relying on customers contacting customer service and we had to try to replicate it ourselves. But we really had no real way of seeing what they were seeing.” […]
When asking Dan what he has gained from the Noibu tool, he indicated that “In terms of a development experience, I would go as far as to say the tool is invaluable. It’s just an awesome tool to pinpoint what’s going on.” – Ruroc Case Study
Besides the great financial benefits Ego has seen, Hussain explained that Noibu’s largest benefit was that Noibu, “Saved both my hours and the developer’s hours.” – Ego Case Study
Matthew Lawson, Chief Digital Officer at Ribble Cycles, saw that Noibu would allow his developers to work smarter with the time they had. Noibu’s platform would not only give the developers the ability to self-prioritize, but the team would also have all of the information available to them to resolve an issue. – Ribble Cycles Case Study
TLDR; Customers think Noibu rocks. It saves developers time, allows teams to be more data-driven, and provides all the data developers could need when addressing site bugs.
Interested in learning more about how Noibu can help your teams? Send us a message at firstname.lastname@example.org and we’ll get in touch.