Why Site Errors Aren’t Always Your Engineering Team’s Fault

Site errors can be caused by poorly written developer code or user error. But it’s not the only way bugs can infiltrate your site. Understand how third party updates introduce errors to your site, and why it’s not your developers’ fault.
Why site errors aren't always your engineering team's fault - blog banner

Let’s get right down to it. Site errors, regardless of whether or not you’re in the eCommerce space, happen for a number of reasons.

You know the classics: user error and poorly written developer code.

But there’s actually another massive avenue for errors to be introduced into your flow, and it’s one that could end up being quite costly.

Ending scene from Seven - Morgan Freeman opens the cardboard box

These errors are also not your developer’s fault…

To figure out how these “other errors” come to be, we have to take a look at how organizations run and release updates.

It’s all in the updates

I know updates happen. You know updates happen.

Your marketers know updates happen. Your engineers know updates happen.

When your company is releasing or updating something new to the site, your team is going to be looking for code regressions and error rates to identify any code or functionality issues. They’ll be keeping an eye on the APM traces to detect any major disruption in their eCommerce service.

Question is, though… Is your team going to be doing that every time a software in their stack updates?

The answer is almost always going to be, “No.

At best, the answer would be, “Not proactively.

Both are totally fair answers; no development team has the time (or the ability) to know what is going on behind the scenes of all of the software entities the entire company is using. It would be absolutely ludicrous to expect that.

But that’s certainly not stopping those service and software companies from releasing their own updates, whenever they so choose.

What happens when a third party updates their software?

As I mentioned above, you’re not the only one doing releases or updates… Your entire tech stack is also constantly working to bring new features to light.

And do you think the team at PayPal is going to individually QA the update’s functionality on all of their customers’ unique sites?

No.

What about WooCommerce? Are they going to dedicate hours to test out every single user flow on every single eCommerce site that uses their software?

Also no.

* There’s an estimated 12-24 million eCommerce retailers currently on the web, and each one has unique products, individual offers, specific campaigns, different automations that make their sites their own… So checking compatibility with all these aspects, and with all the other third party softwares that are involved in powering any portion of a site’s functionality or any individual users’ technology, is an impossible feat.

So the onus falls on your team to hear about new updates, learn what’s changed, see how those changes are interacting with your site infrastructure and users, and figure out the root cause for anything breaking. That’s assuming you have someone on hand to do this 24/7.

And to call a spade a spade, your executives probably want your developers to be focusing on new innovations for the company, rather than sitting and waiting around for new innovations from other companies to come and mess something up.

What are the root causes for these unknown update errors?

There is quite a wide range of possible root causes for these errors…

Incompatible code and incongruent API calls, cross browser or device UX issues pushing critical content outside of the viewable window, infinite loads with no answer or direction at the end, the list goes on.

* Here is a pretty simple, and widely applicable, example of how a third party update may cause errors to occur, specifically, how something as small as adding an additional number to a version name could unknowingly break your site: Google Chrome 100 update may break your website.

Either way, there is a large chance that something small may break – independent of work that your engineers and developers are doing – that ultimately goes unreported for days, weeks, months because it only occurs to a select few individuals who are using an untested or niche method to navigate to and around your eCommerce site.

And unfortunately, these errors can add up if left unchecked. We see this happen time and time again due to the focus on ongoing code health taking a back seat post-site release.

Additionally, with only 10% of consumers creating support tickets when they encounter a bug online, it’s easy to see how those net-new third party errors come in under the radar and stay there.

So what?

Errors are going to come in no matter what.

When you know about them, how you know about them, and what you do about them is what is in your control.

You have a few options available to you that technically monitor for site errors and will let you know when an egregious issue starts to occur to a large portion of leads… But if you’re serious about being data-driven and efficient in any of your approaches, there’s some critical data that is missing from those tools. And it has everything to do with revenue prioritization.

To learn more about why some monitoring tools simply aren’t enough, check out this piece on eliminating tech debt and going beyond the classic APM softwares.

Share Post:

Stay Connected

More Updates

Deliver better eCommerce experiences.
Prevent revenue loss.

Get a Free Site Audit!

Contact Sales Specialist
First

Get Your Free Checkout Audit!

Contact Sales Specialist
First

Get a Demo