Tracking errors and 404 pages
There are lots of things to focus on when you're trying to improve the user flow and experience in your website or app but one of the easiest things you can do is fix the parts where it's breaking or throwing errors when your customers use it.
That makes sense, nobody wants a broken website or app but tracking these errors isn't something that occurs out of the box with most analytics tools, including Segment's analytics libraries.
Luckily, they are flexible enough that tracking these sorts of errors is pretty simple and I'll discuss how to do this for various situations and platforms below.
404 errors are such low hanging fruit, it's pretty trivial to get meaningful insights into where customers are getting 404's with Segment's .page() method. When called from one of our client-side libraries, you get the current url and the referrer for free so you'll know where broken links are coming from. Whether internal or external links, this is super helpful for cleaning up a site that has gone through a couple iterations. Simply put a .page() call on your 404 pages like so and you'll be able to identify and fix what's causing your 404's.
This can then be viewed in any analytics tool that Segment integrates with or in the raw logs.
It's also good practice to customize your 404 errors a little bit, check out our 404 page for an idea of what you can do rather than the default error page you see everywhere.
Here's an example function you could insert into your code with a try/catch statement.
We'd recommend being smarter about the properties you're passing through on this error event, i.e. breaking them out and only sending what you need.
Tracking errors on your servers is super helpful, if only because it sometimes helps diagnose site-wide errors that can seem unrelated without the server-side context. We find it helpful to put custom .track() events with one of our server-side libraries in your error handlers with context about where the error is occurring. Using the same type of tracker as the try/catch on the server side is even more performant as the events are queued and are batched in the background.