What's your store's health?
- An audit generally takes 2-3 weeks (perhaps longer if the website is more complex).
- Audits must be completed by highly-skilled individuals.
- Audits must be comprehensive—this article details the SwiftOtter audit process.
Your ecommerce experience represents first impressions that lead to the follow-through of the purchase. Customers are flaky in that they want a quick and painless purchase journey. As a customer runs into problems finding what they wish or flat-out errors in the purchase process, they are likely to abandon and look elsewhere.
This article discusses how the audit process works at SwiftOtter and what you can expect. Alternatively, if you are technical, this is our plan that you can also follow.
We unlock your blackbox (website).
Eliminate surprises and become completely informed.
Critical audit pieces
What is an audit?
The goal of the audit is to identify the current state of a website: a thorough review. A certified architect-level developer completes the technical pieces of an audit. A business analyst should explore customer-experience-related areas.
Our audits take many hours to complete—sometimes over 100. There are a few shortcuts to make an audit faster.
What value does an audit bring?
An audit is your “State of the Union”. Your website can appear as a black box if you are not a developer. You know these powers transactions, but you are also aware of bugs and other problems. You are an expert at running an ecommerce business but not at debugging Adobe Commerce. This makes you worried that there are other problems in the platform you are unaware of.
An audit shines a light into the unknown. You have an understandable and thorough document that goes through every aspect of the system. You know the quality of your developer’s decisions. You know the weaknesses and strengths of your system. You know how well Adobe Commerce is configured. You see the speed bumps that inhibit customers from purchasing. You understand the security vulnerabilities that could land you in a PCI-compliance or GDPR nightmare.
Even if you have a stable relationship with an agency, a periodic audit will turn up aspects that are easy to overlook. This gives a game plan for the next steps on improving security and the conversion rate.
What is needed from the merchant for an audit?
This depends on the level of audit. The more that is reviewed, the more access is needed.
- Server access via SSH. We need to review database records and configuration. We will also investigate the structure of the deployment and web server. This is a critical step for verifying the security of your website.
- Code access. We request access to your version control system (GitHub or GitLab). If this is not possible, we can look at the code on the server. Version control gives insight as to who changed what and when.
- The admin area. We can get this for ourselves once we have SSH access. However, this is included in the list for full disclosure.
- Google Analytics. This helps determine revenue trends. When paired with a conversion rate audit, we use this to identify points in time. We also use this to diagnose technical issues that affect specific browsers.
- New Relic. If you are using New Relic (as we do with all of our customers), we will have visibility into performance problems with a glance. This provides insight into slowness on the website—poor performance leads to customer frustration which hurts the conversion rate.
- Other tools like Full Story, Algolia, etc. These tools provide additional clarity to how the website is operating.
We usually bring plenty of our findings regarding your website—but it is pretty helpful to hear specific complaints. We research these issues and formulate a game plan for their resolution.
What is the deliverable from this audit?
You get a document of 5-15 pages (or longer). This is highly detailed but still understandable by a “lay” person. When we deliver the audit, we walk you through our findings so you will have plenty of opportunity to ask questions.
What options are available?
We split our audits into three categories:
- Core: a review of the 3rd-party modules, customizations, security posture, and hosting environment.
- Performance: a review of the bottlenecks that affect system stability and conversion rate.
- Customer experience: a review of how customers approach and interact with the checkout process. This entails conversion rate optimization, purchase journey details, and more.
Each of these categories are split further. From here, we get more technical. Note that while we describe the audit process in as much detail as possible, this does not substitute for having an architect perform the review.
Core: Module review
This is a hands-on/manual review of every 3rd-party module in your project. These are found in app/code/ and the vendor/ directories.
The first thing is to compare the currently-installed version with the latest version. We often find significant disparities that can account for bugs or security issues.
We focus on all modules in app/code/ to identify whether or not these can be moved into Composer version management. What’s the problem with leaving them in app/code/? They are harder to update. In other words, updates don’t happen. It’s even worse in that the Composer-managed modules are updated: having some outdated modules can cause bugs when interacting with updated modules (that’s a lot of the word “update” in a paragraph!).
Our following review is to understand what each module does. We can achieve immediate performance boosts by removing modules that no longer provide value. We take an initial stab at determining a module's value by reviewing the database and log files.
Every module is evaluated for significant security issues. We don’t review every line of code, but it’s pretty close. A good developer has first places they review that often are markers for the quality of the rest of the module. These issues are called out for further review or diagnosis.
Core: Custom code review
3rd-party modules can have poor-quality code, but custom modules are often worse.
These must be reviewed with a fine-toothed comb. Every line must be checked. Depending on the size of the website, this is very time-consuming.
Our developers often apply well-learned heuristics to identify the overall quality of the architecture. As the code passes or fails basic checks, the developer knows what further to review.
If a problem, like a SQL injection vulnerability, is found in one module, it’ll be found in others. It is up to the architect to find every case of these violations and notate to ensure they are promptly fixed.
We use tools such as phpcs to assist in the more automatable processes. For example, if the developer uses tabs instead of spaces, this will likely point to further issues. If there is a significant amount of commented code, we see they were not relying on version control.
One of my personal favorites is ObjectManager in the code. This should never be present in almost any circumstance.
Problems that affect upgradeability
If one problem was king over all difficulties, it’s the strong preference. The preference is powerful and capable. It can change any functionality and fix any bug. In the short term, preferences are fantastic.
In the long run, they are upgrade killers.
So what is a preference? A preference is pointing to Magento to use a different class instead of a core class. This almost always entails copying significant amounts of code. When Magento is upgraded, there is a reasonable chance the original class has been changed. Thus, a preference uses old code instead of new code. You can imagine how this creates significance for strange bugs.
We, at SwiftOtter, have used preferences for this situation, but they are our last resort. Instead, we use Composer patches. When we use a preference, they are small and well-documented.
Preferences are incredibly time-consuming to clean up in preparation for an upgrade. We have to pay special attention to this to ensure you get as accurate of an estimate as possible.
Core: Server and Application Configuration
This is the most “checklist-able” step of the audit. Up to and after this point, most of the work is completed by hand.
Here are some of the points we review.
- Varnish configuration
- PHP configuration
- MySQL configuration
- Cache configuration
- Session configuration
- Effective use of RabbitMQ
- CloudFlare (or other good CDN) in use
- Cron jobs are running
- Attribute sets are adequately used
- Scoping is configured
- Categories are correctly structured
- Admin users are not shared
- Proper use of role scopes and resources (does the custom code work with these resources?)
All database tables are reviewed to identify runaway tables representing massive data storage.
Core: Security posture
Magento is what version?! This is our starting point. We identify this as the most critical problem if Magento is not within a patch version or two.
If Magento is out of date by more than one month, you are no longer PCI compliant. Check this out:
6.2: Ensure all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.
(Almost) every Adobe Commerce release fixes critical issues. While you don’t have to upgrade from Adobe Commerce 2.3 to 2.4 the day it’s released, it’s essential to follow the lifecycle policy (Adobe Commerce 2.3 is no longer supported on September 8, 2022).
Security goes beyond the version of Magento. The modules and customizations must also be secure. This is another reason why manual code review is so important. We have found plenty of vulnerabilities in these reviews.
The front end of a website is what is seen in your browser. This could be the Product Display Page or the Admin area. The front end is when you click on something, and the page doesn’t refresh, but something happens. For example, when you change from one email to another in Gmail, this is the front end.
What we see is initially identified through the Google Page Speed (or Lighthouse) audit. The resolution is the challenging part.
We focus on:
- Content Layout Shift (CLS): this is the metric of how much the page changes after loading it. We’ve all had those instances where just as we click on something, the page changes, and we click on the wrong “thing.” This is annoying at best and can be problematic at worst if an order is submitted or a form is cleared. Google penalizes websites with a high CLS. Adobe Commerce sites have a poor track record in this category.
- Largest Contentful Paint (LCP) or Render-blocking Assets: this is the point in time after the request is triggered that the page is considered loaded. This takes into account the server processing time as well as the time to download assets. Again, Magento loads many files, and these scores are often less-than-ideal.
- Image optimization: Content managers typically upload images. Unfortunately, many have not been trained to optimize these images, negatively affecting page load.
- Script Execution: it’s easy for you merchants to sign up for a new service that promises better conversion rate opportunities. Unfortunately, many of these services negatively affect your website. One or two is fine, but they add up significantly. We recommend paring these back, deferring their load, or loading only on specific pages (like the PDP and checkout pages).
- LESS / CSS: these don’t affect performance as long-term upgradeability. We review the stylesheets to understand how the theme was constructed and provide recommendations on how to improve these.
Related to upgradeability:
Outside of preferences, one of the most significant headaches of upgrades is theme-related issues. This is one reason why using other themes (like Porto) can be of concern. We must review every step of the customer journey to identify theme-related issues. The more out of date a theme is or if it is poorly-implemented, the more the cost to upgrade.
Conversely, the Backend is what provides data to the front. If a page takes a long time to load, there is a good chance that the backend has poorly-performing processes.
We have seen even simple mistakes cause a catastrophic loss of speed. We use tools like New Relic to understand where the problems are.
There is no “one size fits all” solution for these problems. We provide an essential roadmap and an estimate for the fix.
If we don’t have access to New Relic, our starting point is anecdotal observations through the customer journey.
Customer experience: Purchase Journey
The purpose of an audit thus far has been to identify problems with the codebase. These things, like performance problems or bugs, indirectly affect the conversion rate. Fixing these issues often represents a boost in sales.
However, the best part of the process is when we can review aspects that directly affect sales. Our quality assurance team reviews the site with a fine-toothed comb. Our business analyst walks through each step to identify missed opportunities.
This part of the audit is the least concrete. We give our team complete latitude to apply the best-practice heuristics they have learned and see how your website matches up.
Customer experience: Conversion Rate Optimization
The conversion rate is the ratio of visitors to orders. The higher the ratio, the better. There is no “set” conversion rate, but 5-7% is outstanding. We have seen it closer to 0.5% for some content-heavy websites.
This phase is started in Google Analytics. We spend significant time piecing together segments to get unique vantage points on the website. We review year over year and different date ranges to identify seasonality.
We look for trends in customer acquisition and how the conversion rate is affected. We find drop-off locations.
Then, we take this data to the website and identify the conversion rate killers.
Customer experience: Post-order delight
The customer experience continues past clicking the “Submit Order” button.
At this level of the audit, we always place an order so we can open the box. What is this experience like? Are there review requests? Is there an opportunity to take advantage of a customer’s delight when seeing this new acquisition for the first time?
You won’t see an immediate return on investment for changes implemented here. You will see it in the form of long-term loyal customers. You will see it as customers share the good word about your brand. You will be glad that you put some dollars into this category.
Customer experience: Technical SEO
We are not a search engine optimization company. We have partners to which we can refer you.
Technical SEO represents the technology-powered aspects of getting your domain name to rank highly on search engines. Are your header tags properly schemed? Do you use rich snippets? Do you have a sitemap? A robots.txt? Any crawl errors? Do you have penalties due to poor performance?
We are duly impressed with Hyva. Increased PageSpeed scores (specifically Largest Contentful Paint and Cumulative Layout Shift) are associated with better search rankings.
SwiftOtter takes a serious approach to every audit we perform. We leave no stone unturned.
The result is a highly insightful report that removes the black box covers. You now have a gameplan for pushing forward to the new features you wish to deliver.