WooCommerce Reporting with New Relic

WooCommerce reporting has traditionally been focused on prescriptive business metrics. It can also be challenging to customize.

In this session, learn how you can use New Relic Application Performance Monitoring (APM) to gain greater visibility into the performance of your online store—tracking site performance and key business metrics all in the same dashboard.

Speakers: 

• Joshua Dailey, Product Marketing Manager at WP Engine
• Damien DeHart, MSP Partner Engineer, Team Lead at New Relic

Session Slides:

Transcript: 

JOSH DAILEY: Hello, everyone. Josh Dailey here, product marketing manager for the WP Engine e-commerce solution and I’ve spent the last decade both creating commerce stores and developing and launching extensions for WooCommerce. My job here is to continually improve our e-commerce solution.

Currently, we offer e-commerce packages which have a few unique benefits to drive conversions and to simplify ongoing store management. This includes EverCache for WooCommerce that uses smart caching to deliver 90% more of your store pages cache, Live Cart that lets you sell more to more concurrent shoppers without dropping connections or sacrificing performance for functionality, Instant Store Search powered by ElasticPress for faster, more accurate search, Smart Plugin Manager with a 17-point WooCommerce visual regression test, as well as Builder Tools for WooCommerce for easily building and growing a store.

Plus, we also have add-ons like application performance monitoring for extending your toolset. For years, we’ve partnered with New Relic to offer this to all of our premium customers, but we found that it has unique benefits for WooCommerce stores, and we wanted to make sure you can get the most out of it.

According to Built With, WooCommerce is the most used commerce solution in the world, with more than 7 million installs. Merchants and developers choose it for its seamless integration with WordPress and its ability to create and customize shopping experiences quickly. Streamlining development with WooCommerce gives you a foundation for getting started and allows us to get to production faster, ultimately allowing us to make more on our projects.

But once your store is up and running and receiving traffic, one of the most common questions we hear is how do I optimize my store for conversions and where can we get better reporting? This is because WooCommerce comes packaged with basic functionality and foundational tools. They work out of the box for a starter store, and these include four configurable reports: orders, customers, stock or inventory, and taxes.

Now, this is fine if you’re a beginner. But if you’re a developer and your job is to ensure your site scales for specific campaigns, the generic WooCommerce reports aren’t nearly enough because reports are limited to outcomes. But the healthy– but for healthy analysis, you need to be able to drill down to answer how your site performance connects to your site’s outcomes. Without that information in one place, you’re looking for a needle in a haystack. Client stores depend on healthy reporting to make decisions around customer acquisition and retention, performance bottlenecks, marketing campaigns, how performance corresponds with conversions, and ultimately reducing expenses and increasing your bottom line.

Rather than look for a needle in a haystack, our dashboard is like a magnet that pulls the needle out for you. We see it as a fantastic addition to our e-commerce offering, allowing you to get smarter about building and optimizing WooCommerce. For example, you can view exactly how database response time tracks alongside numbers of orders for a specific time period. Is your site scaling? Where can performance be optimized to increase conversions?

So in this session, we want to get really practical with tools you can standardize on for building a dashboard that can save you time and give you flexible, expandable store reporting. That’s why I’m pleased to have Damien here from New Relic to give you an insider look into how you can enhance your Woo reporting with a real world dashboard created for one of our largest WP Engine WooCommerce customers. Damien, thank you for joining us. I’m really excited to follow along.

DAMIEN DEHART: Josh, thank you for having me. Happy to be here to assist with this presentation. So before we get started and talk about the actual solution that we built with one of WPE’s largest WooCommerce consumers, I would like to take a second to talk about the New Relic platform as a whole.

So the new New Relic platform, we’ll be focusing a lot today on the dashboarding capabilities and APM and how these sort of meld together to create a more robust reporting functionality for WooCommerce customers. But it makes sense to give a brief introduction on the entire platform and how we came to this decision and how we leverage the different capabilities to make this happen.

So if you look at the bottom of this graphic, you’ll see New Relic One. New Relic One is the New Relic platform. It’s built on a massive time series database, which actually sees more hits daily than Google does for search results.

On top of that platform are all of the different capabilities you see: browser, Synthetics, mobile, New Relic APM, and infrastructure. All of these emit telemetry data into New Relic, which we consume and provide to our end customers, WPE, as well as all of their customers, to consume to build things like dashboards, customized alerts, and different– and generate different business insights for any of the use cases that they may have on the New Relic platform.

So we built a dashboard with one of WPE’s largest consumers of WooCommerce. And you see the screenshot here on the right, which shows a snapshot of that dashboard that we– that we built. And I want to take a second to talk about the primary benefits of leveraging the New Relic dashboard and capabilities.

As we talked about in the previous slide, New Relic is a massive time series database which sees more hits daily than Google does searches. And as such, we have built this database for scale and performance. So when you start to think about dashboarding and maybe the differences that WooCommerce may have with reporting, this is a purpose-built solution for searching data at scale. And what that means is we give you the ability to keep your eye on the most critical performance metrics to your business in real time.

We also give you the ability to build a dashboard with any data you want that’s being captured inside of New Relic. You don’t need to code for it. I will retract that just a little bit by saying you need to understand our SQL– our anti-SQL language. But basically, if you know SQL, you know New Relic. It also allows you to diagnose problems faster across the entire stack.

So again, any data that you’re ingesting into the New Relic platform, whether it be from your application running in WooCommerce to even the front-end interactions of your customers in your application itself, such as a JavaScript error, you can track all of that in a single place with New Relic. And then finally, our main goal is to drive data-driven decisions to optimize business outcomes.

So how do we do this? When we look at that dashboard, we see a lot of really nice metrics around cart totals, order totals, Google session IDs, so on and so forth. And we give you the ability to drill into every single session to be able to see what customer did what, what their performance was like, how much money was in the cart, even things like cart abandonment rates.

But the real question everybody wants to know on this call is, “”hat did we do?” What’s the technical stuff that happened behind the scenes? So in order to do that, we need to understand, again, how New Relic APM works.

New Relic APM injects itself into the code level of your PHP WordPress application and gives you visibility into every single call that was made to and from that application. And so that puts New Relic in a unique place to be able to collect data about the users of your application in real time. And so what you’re seeing here is a screenshot from VS Code where we actually inject some custom data into the application. We don’t actually inject custom data. We put a little bit of script in there which actually pulls out attributes, as we call them, or different metadata about the user inside your application, which is already being collected by the WooCommerce add-on in PHP.

So you can see the highlighted section here in the bottom. We’re actually doing what we call add custom parameters to New Relic, and we’re adding order email.

We’re adding a New Relic transaction for successful checkout to be able to track when customers actually purchase things in the website. We’re adding total items in the cart. We’re also adding all of the products that were in the cart, and we’re actually looping through these together every single product along with the line item totals. And then we’re actually summing that into an order total. And all of this data is actually pumped into New Relic, and it’s in line with all of the data we’re already collecting.

So if you think about it from a performance and optimization standpoint, this gives you the ability to drill into every single customer and see, hey, how much money did this customer spend with me? How is their performance on the website? Did they experience any errors? Was our database taking too long? And this allows you to adequately service your large and small customers or maybe even group them into bands so you can do a cohort analysis on how much performance impacts the day-to-day of your business and effectively your bottom line and how much money you generate.

So I did want to mention that this is not limited to the parameters shown. These are just things that we’re collecting. But as everyone on this call knows, WooCommerce generates a lot more data than what we’re collecting today and so this leverages what we call custom attributes. And you’re also able to collect any other data you want. So for example, if your application is collecting username or user email or customer name or support tier and the list goes on and on, you can also inject those additional parameters into New Relic, which gives you those levels of visibility which I was just speaking of.

This extends to your use of APM and Application Performance Monitoring to add that business context into New Relic, into the UI, into the data layer, and ultimately into the practice of your business, which allows you to make a better informed decision and get buy-in from everybody from all the way from a developer to your CTO and even your CEO on the business side. So we wanted to talk a little bit as well about using New Relic Synthetics, which is included with your subscription to WordPress to manage WordPress solution and how you can use this for e-commerce.

So New Relic synthetics is a very robust Selenium-based testing tool and so we don’t like to advertise ourselves as a stress testing or load testing solution, but what we do advertise ourselves as is a way to programmatically send traffic to your website in order to test very specific scenarios. So there is a number of different checks that you get with your subscription, again, to the monitoring package on WP Engine. The first one we’re going to cover is availability testing.

So this is basically a ping to the DNS server that tells you whether the website exists at this point in time. So it has its uses. We consider this as a basic type of synthetic test. There are some other versions available, though. So we have the SSL certificate expiration test.

So this is exactly what it sounds like. You configure it to say, when your cert is expiring, and we give you a notification when you’re approaching that date. You also have Page Link Crawler, which will show you any links on the website, and we’ll actually tell you if you have broken links on your website.

We found this to be especially useful for e-commerce customers as they oftentimes have a lot of different product links on their websites which are changing. And sometimes, it’s hard to keep up with that. So having a test to tell you what’s broken and what your customers can’t access is paramount to ensuring you’re achieving maximum revenue through your e-commerce site. We also have a Page Load Performance Monitor, which does a full page load with all the assets, and it actually tells you what all the different assets on the page are doing– so if you have an image that’s too large, if you have JavaScript errors that are associated with the website, and the list goes on and on.

And then we’re actually going to do a demo next about a step execution or user flow functionality test, and this is going to walk through a checkout page inside one of our demo environments. And it’s going to show any failures that occur throughout the process. So we’re going to be walking through a customer signing in, going through a checkout flow, placing items in the cart, and then attempting to checkout. And we’ll see what happens there. So without further ado, it is demo time.

All right, so here we are inside of New Relic. What you’re looking at right here is the homepage of New Relic. For those who are not familiar with this page, this shows all of the different entities that exist in New Relic. And basically, an entity is a thing that emits data that you want to monitor.

So we’re going to talk about synthetics today. And how you get to synthetics is you navigate to the left side over here, and you see synthetic monitoring on the left. You can also get there by clicking synthetic monitors here. But for sake of completeness, we’re going to click on that today.

And you can see I’ve got a ton of monitors inside of my demo account here. I want to just show you my scripted browser, which verifies the checkout flow is working. So I know that this is named verify, has verify the name. Once I type that in, you can see this is my monitor itself.

Going into the monitor, you see a number of things. So we actually have this running against three different locations. So you see them here: Singapore, London, and Portland. And these three are what New Relic calls public locations.

So we have a number of hosted locations across the world in AWS, which allows you to– you’re actually able to run checks against all of these. So if you have some like a global website or something like that and you want to test performance across the globe, this is how you would do it.

This also helps with maybe requests for CDNs. So let’s say you’re running a check and in Singapore it’s super slow, but your head– your data center and all of your hosting is maybe in US West. You might want to stand up a CDN over here so that you get a persistent performance across the globe.

So on this chart, you’re seeing the number of failures against the number of checks over the time frame that we’re looking at in the last 30 minutes. If I was to expand this out to like a day, you can see some of the metrics here change, but this is going– this here is showing actually over the last 2 and 1/2 hours. Any failures would show up in red.

So we’re actually not seeing any failures in the last 2 and 1/2 hours and you’re seeing some basic timing information across the locations. Going down a little bit, you see some of the performance metrics as well.

So this is showing you user-centric performance metrics. So first byte, basically, when anything on the page was visible. First paint is sort of like if a picture or text or anything was loaded. Page load is the entire page load– so when a page was fully loaded.

And then First Contentful Paint is basically the largest image that was loaded on the page. And so we’re giving you timing information for all of that for this check. We’re showing you request by domain.

So as you’re calling things in the application itself, how long is it taking for those to– how many of those requests are occurring over time? And then duration by domain. So how long are each of these taking? We have our newrelicdemo.com, which takes the longest, and then average size by resource type.

So we can already see here images are the largest on here. So if there were any optimization opportunities, I would probably start to look at the images on this site.

And then finally, error response codes. So these are all the things you can expect to see. When you create a synthetic check, you’ll also see we’ve got a bunch of tags here. These are customizable inside the platform. So if you have a team or a product surface or a specific website or maybe a product that you’re testing, you can actually tag it that way. And then you can search those tags in the platform.

Furthermore, you’re seeing the URL. So if I was to click out to this, this would actually take me to my web page, which I’m monitoring with this check. In your case, it would be your live e-commerce site. In this case, it’s my demo app.

OK, so this is all good and well, but how do we get to the part where we talk about what went wrong, or what could go wrong inside the application? So on this, we have a bunch of different options here on the left sidebar. We’re not going to focus on any of these more views, but we will talk about what each of these do.

Starting from the bottom up, the Settings tab actually shows you what script you’re running inside of here. It shows you basically the configuration settings for your monitor, the locations that you’ve had selected. I don’t actually have the rights here to edit this, so it’s going to show you, here’s a list of all of our public locations, as we discussed before. We’ve selected 3.

And then we’ve got a script in here. So this is our script. It’s built in Node, and we’re actually crawling these web pages, loading specific web pages, and then we’re printing those results out in the console.

You have reporting in here as well. So by default, any monitor that you create get some SLA reporting, and you have the ability to alert on those as well.

And then we were just on our summary page. So I’ll click back to that for a second here. And then in the monitor section, you have all of your results. So this will show you all the results for the checks themselves, what resources were being consumed, as well as any failures that occurred.

So once I click into this, over the last 24 hours, we see a 100% success rate. We see zero checks have failed. Everything is OK. We see duration by location.

So again, we talked about those CDN requirements. You can see Portland is significantly low, or not significantly, but a good bit lower than everything else. So maybe that tells me, hey my data center or my infrastructure is in US West.

I want a consistent performance across the globe. So maybe I put a CDN in some of these other locations. Maybe I don’t because it’s not that big of a deal. Up to the business to decide that.

And then you’ll see all of the different occurrences of these checks. You’ll see them by location. You’ll see them by duration. You see them by response size.

And then if there’s a failure message, you’ll see that as well. You can also filter two failures only. We had none over this time frame. Let me see if we’ll get anything interesting.

I guess we don’t have any failures on this monitor itself. But if I was to click into one of these, I’ll show you what the results look like. So again, this is a synthetic test, which goes across multiple pages. So we’re mimicking what a real user would do inside the website.

So the flow is we land on this main page. This is what happens inside that page. So you have your user-centric timings.

You can see all of the different types of things that were loaded on the page. So we got right here a large image, extremely large image here this is– and this is actually we did this on purpose to display this.

But you’ve got this massive image here, this telco.bids image, which is taking up a lot of time. So if I was to say, hey, look, there’s some optimization opportunities that could be done. Personally, this would be the first thing I focus on is that huge image.

Back to the flow, right, so we start on the main page. We go into the login page. You can see everything that occurs on here as well, any errors JavaScript or otherwise that occur, any AJAX that’s happening, all of the above.

And then once they’re logged in, they get redirected. So we’re seeing the timeline on that as well, nice waterfall view. We’re going through all of the pages.

So they go to the phone page, and they’re browsing for phones. It takes a long time to find the phone they want. That’s fine.

They find the actual phone. This is an actual page in our demo website of a product, so a specific product page. And here’s where it starts to get interesting. You can look into this, and you can see, OK, I just want to look at their performance of this page.

How long does it take this page to load, and is it up to snuff with the SLAs that I’ve given back to my customers? They go into their plans page looking for plans. They decide a plan.

Now, they’re looking for phones. So we’re going through the entire process of a customer finding the phones that they want, finding the plans that they want, putting them all into the shopping cart. They end up in the shopping cart.

We’ve got an error here. So if you wanted to see any requests to have an error, we have this one with this HTML request here, getting to this page. This is valid request, as an error. So I’m not going to go through the full troubleshooting path here.

But basically, we have a scenario which is set to occur in our demo environment where the coupon itself is not valid, and it throws an error every time. And this traces back to a back-end script or back-end piece of code which wasn’t optimized, and we forgot to update the coupons in the database. So from here, you’re actually able to see in a controlled environment what errors are being thrown and how it traces back to performance in your app.

And then you go through the checkout process. You see how long everything takes in here. And then finally, this is the last page they land on. So checkout is complete.

And you can see how you see timing for everything here. You also have a script log, which shows you everything that occurred in here. So they visited the login page, logged in, added phone plan, added six phones. They added all this stuff to cart, and then they purchased the cart contents, and the cart was empty after that.

You also see a browser log which shows you any errors that occurred. We’ve got a bunch of syntax errors in here. This is a demo environment.

So see now you have here failed to load a resource server, responded with a status of 500. So this is that coupon is valid call that we were talking about.

So if I was a developer, I would take note of this. The first thing I would see is, hey, we’ve got a 500 in here, and it seems to be on a coupon page. So they’re trying to load something important. So this is where we start to talk about website optimization opportunities.

And finally, I don’t have it here. But if the check itself failed, you would see a failure screenshot section here, and it actually shows you a screenshot of the page where it failed, what was expected, and what the result was. So we do have a demo environment somewhere out there which actually purposely files a failure, and the checkout– the actual checkout button that’s supposed to be there is missing. And so that’s where you actually see the result of any failures that occur, any errors that occur. And basically, any critical error or any component that you’ve directed the test to find, if it’s not detected, that throws a failure for the entire check.

And that’s when you’ll see the screenshot. That’s when you’ll also see the failure on that summary page. Again, you’ll see it lit up as red. And you’ll be able to see where it failed, what location it failed on, and what the timestamp for that was as well. So that concludes the demo for the synthetics checkout workflow test that we were going to test today.

JOSH DAILEY: Thanks so much, Damien. This has been super insightful. And I hope you as developers who are watching or if you’re a merchant store owner yourself and you’re watching right now that you see the incredible value that something like New Relic can add to your workflow in saving you a big headache if something goes down, if there’s outages and other things that are going on, but also just helping to improve with growth.

If you’re interested in APM and you’re not using it, which is our Application Performance Monitoring feature, talk to your account manager or ask any member of our team and learn how you can start taking advantage of New Relic right here on WP Engine.

Once again, thank you, Damien. Thank you all. And I hope you enjoy the rest of your time here in DE{CODE}.