The Ecommerce Numbers Worth Tracking (and the Ones That Waste Your Time)

Most store owners have access to hundreds of metrics and act on roughly none of them. The problem isn’t discipline — it’s that most dashboards are built to display data rather than to prompt decisions.

A simple test

Before adding a number to your dashboard, finish this sentence: “If this goes down by 20%, I will …”

If you can’t finish it, the metric is decoration. Track it if you enjoy it, but don’t hold meetings about it.

Six numbers worth tracking

1. Funnel conversion, step by step. Not “2.1% conversion” but sessions → product view → add to cart → checkout started → purchase. One overall number tells you something is wrong; five tell you where. A store losing people between cart and checkout has a different problem to one losing them at product view, and the fixes have nothing in common.

2. Recovered revenue. Actual money from customers who abandoned and came back, measured against real orders. Not emails sent, not open rate. This is the only number that says whether your recovery setup is worth its cost.

3. Zero-result searches. Every internal search returning nothing is a customer telling you what they expected to find, in their own words. It’s free demand research and the list is usually short enough to act on in an afternoon. Half the entries are typically vocabulary or spelling failures rather than missing stock.

4. Repeat purchase rate. The share of customers buying more than once, over a fixed window. It’s the cheapest growth available, and it moves when your post-purchase experience improves — which most stores never touch.

5. Mobile conversion versus desktop. Track them separately. A large gap is almost always a checkout or speed problem, not a customer preference. Most stores discover their mobile conversion is roughly half of desktop and have never once looked at why.

6. Time to first byte on your checkout. An operational number with direct commercial impact. Checkout can’t be page-cached, so it’s the page most exposed to server slowness, at the exact moment the customer is holding a card.

Four that mostly waste your time

Getting the tracking right first

All of this assumes your numbers are true, which is a bigger assumption than it should be. Before optimising anything:

• Verify events fire once. Duplicate purchase events are common and quietly inflate everything downstream.
• Check attribution isn’t double-counting. If your ad platform and analytics both claim the same order, one is wrong and you’re probably budgeting against it.
• Confirm refunds are subtracted. Revenue that includes returns is a number you’ll eventually have to un-believe.
• Test on mobile, in a private window. Consent banners and blockers change what actually gets recorded.

An hour verifying tracking is worth more than a month optimising against numbers that were never right.

Our Cart & Funnel Infrastructure service includes verifying your tracking properly — events, attribution and recovered revenue measured against real orders. From $850.

Does Elementor Slow Down WordPress? A Straight Answer

Yes. Usually. But the reason matters more than the verdict, because the reason determines whether you need an afternoon of work or a five-figure rebuild.

The short answer

A page built with Elementor, Divi, WPBakery or similar typically ships more CSS and JavaScript than an equivalent hand-built template. On a well-hosted site that might cost you half a second. On cheap shared hosting with twenty other plugins, it compounds into something worse.

What it usually isn’t is a server problem. Builders render to fairly ordinary HTML; the cost lands on the visitor’s device and connection, not on your database. That distinction matters, because it means the fix is frontend work, and frontend work is cheap relative to rebuilding.

What’s actually adding the weight

• Global stylesheets on every page. The builder’s full CSS loads on your contact page even though that page is a heading and a form. Same for its JavaScript.
• Widget assets you’re not using. Carousels, lightboxes, animation libraries, icon fonts — often enqueued site-wide because the builder can’t be certain which page needs them.
• Deep DOM nesting. Builders wrap content in section, container, column and widget divs. More elements means more layout work for the browser, which shows up in interaction delay on cheap phones.
• Add-on plugin packs. This is the one that actually hurts. A builder plus three widget-extension plugins, each loading its own assets everywhere. The builder gets blamed for the stack built on top of it.

What you can recover without rebuilding

In our experience most of the frontend cost comes back through configuration rather than reconstruction:

Run a proper audit first so you’re fixing what’s actually costing you rather than what’s easiest to find.

When a rebuild is genuinely the answer

Not because a testing tool showed red. Rebuild when:

• The builder is blocking a business requirement. You need dynamic templates, structured data or complex conditional logic that fights the builder every time.
• You’ve done the optimisation work and you’re still far off. If dequeueing, deferring, images and caching are all done and mobile LCP is still over four seconds, the structure is the problem.
• Nobody uses the builder any more. This happens surprisingly often. The site was built by an agency two years ago, your team edits content in the block editor, and the builder is loading its full toolkit on every page for the benefit of nobody.

That last one is the most satisfying finding in any audit: a large chunk of weight serving a workflow that no longer exists.

Our Speed & Performance service works across Kadence, Elementor, Bricks and standard themes — we recover what configuration can recover, and tell you honestly if it can’t. From $650.

What Custom WordPress Development Actually Costs — and What Drives the Number

Send the same brief to five WordPress developers and you’ll get quotes that differ by a factor of five. That’s not a market failure — it’s a briefing failure, and it’s fixable.

Why the same brief gets five different numbers

Because five people read five different projects. “A custom booking system” could mean a form that emails you, or something handling availability, deposits, rescheduling, cancellation rules and calendar sync.

The cheap quote isn’t dishonest. It’s usually someone who imagined the small version. You’ll meet the difference later, as change requests, at a worse moment.

What actually drives the cost

Two of these surprise people consistently. Integrations: connecting to a CRM is rarely “just an API call” — it’s mapping fields, handling rate limits, deciding what happens when the other end is down, and reconciling records that exist twice. Admin interfaces: the feature might be a week; making it operable by someone who won’t read documentation is often another week, and skipping it produces software only its author can use.

Where estimates go wrong

• The demo-to-production gap. A working prototype is perhaps 40% of the job. Validation, permissions, error states, logging and testing are the rest, and none of it is visible in a demo.
• Nobody looked at the real data. Estimating a migration without opening the database is guessing. Duplicate records, inconsistent formats and fields used for something other than their name are the norm.
• “While you’re in there”. Small additions during a build cost more than the same work scoped upfront, because each one reopens decisions.
• No maintenance budget. Custom code needs occasional attention as WordPress, PHP and dependencies move. Budget for it or you’ll be surprised in year two.

Writing a brief that gets comparable numbers

You don’t need a technical specification. You need to remove ambiguity:

• Describe the outcome, not the implementation. “Corporate customers assign seats to staff without contacting us” beats “build a seat plugin” — it lets a developer suggest a cheaper route.
• Name the systems involved. Which CRM, which payment gateway, which LMS, which versions.
• Say who operates it. A developer, or someone in accounts on a Tuesday? Changes the interface budget substantially.
• State volumes. Fifty records or five hundred thousand. Different architecture entirely.
• List what you’d accept losing. Marking your own must-haves against nice-to-haves is the single most useful thing in any brief.
• Share access to the current site. Anyone quoting without looking is quoting a fantasy.

Fixed price or day rate?

Fixed price suits well-defined work with clear boundaries. You get certainty; the developer prices the risk. Expect a firm change-request process, which is reasonable — it’s what makes the fixed number possible.

Day rate suits exploratory work where the answer emerges. Cheaper when scope is honestly unclear, and it requires trust plus regular check-ins.

A practical middle path: pay for a short discovery phase first — a few days to examine your data, systems and constraints, ending in a specification. Then get fixed quotes against that. It costs a little upfront and turns a five-way spread into numbers you can actually compare.

If you’re still deciding whether custom is warranted at all, the signals that say you’ve outgrown off-the-shelf are the place to start.

Our Custom WordPress Development service starts with discovery — we look at your data and systems before quoting, so the number means something.

Cart Recovery Without Handing Your Funnel to an Email Platform

The standard advice for WooCommerce cart recovery is to connect your store to a marketing platform and build the flows there. It works. It’s also how a lot of businesses end up with their commercial logic living in a tool they rent.

Worth separating what you’re actually buying.

Three parts, frequently confused

• Detection. Knowing a cart was abandoned — what was in it, who the customer is, how far they got, whether they’ve bought before. This data originates in WooCommerce.
• Decision. The rules. Who gets contacted, after how long, with what message, and who gets left alone. This is your commercial policy.
• Delivery. Actually sending the email or SMS, handling bounces, unsubscribes and deliverability. Genuinely specialist work.

Delivery is worth outsourcing — email deliverability is a discipline and you don’t want to learn it. The question is whether detection and decision should follow it out of the building.

What outsourcing all three actually costs

• Your funnel logic lives elsewhere. Rules are configured in someone else’s interface. Changing platform means rebuilding, and everyone quietly avoids it, which is the point of the design.
• Pricing scales with contacts, not results. These platforms bill on list size. Your recovery cost grows with your audience whether or not it’s recovering anything.
• Sync becomes a thing you maintain. Product data, stock, prices and customer records have to stay aligned across two systems. When they drift, customers get emails about items you no longer sell.
• Reporting splits in two. Store data in WooCommerce, campaign data in the platform, and a recurring argument about which number is right.

The case for keeping the logic in WordPress

Detection and decision sit naturally next to the data they depend on:

Note the last row. This isn’t an argument for sending mail from your web server, which is a reliable way to end up in spam folders.

When an external platform genuinely is the right call

Sometimes it is, and pretending otherwise would be daft:

• You already run serious lifecycle marketing there. If your welcome series, win-back and post-purchase flows are in one platform, cart recovery belongs beside them.
• You need multi-channel. SMS, push and paid audience sync are genuinely hard to replicate.
• A marketing team owns the flows. If non-technical staff need to change sequences weekly, a visual builder earns its cost.

A sensible split

Keep detection and decision in WordPress, where the data lives. Send through whatever provider you like, and change providers without rebuilding anything.

Practically: WooCommerce captures the abandonment with full context, your rules decide who gets what and when, and the send goes out through an SMTP or API provider. Recovered revenue is attributed against actual orders in your own database.

You get deliverability without renting your funnel. And when the platform raises prices — which they do — the decision is about email, not about rebuilding six months of logic.

Our Cart & Funnel Infrastructure service builds exactly this split: tracking and rules inside WordPress, your choice of provider for delivery. From $850, pay after it works.

The Best WordPress Search Plugins in 2026 — and When None of Them Fit

Someone lands on your site, types four words into the search box, and gets a page of results sorted by publication date. The thing they wanted is on page three. They leave.

That’s not a bug. It’s WordPress working exactly as designed — and it’s why the search plugin category exists at all.

Why native WordPress search disappoints

Out of the box, WordPress search does three things that quietly cost you visitors:

• It sorts by date, not relevance. A post that mentions your keyword once in 2019 can outrank the definitive page you published last month.
• It demands exact matches. One transposed letter and the result set is empty. On mobile, where most typos happen, that’s a lot of empty pages.
• It ignores most of your content. Custom fields, taxonomy terms, ACF values, WooCommerce attributes — none of it is searched by default. If your product data lives in custom fields, your product search doesn’t work.

There’s a fourth problem that only shows up later: every search is a LIKE '%term%' query against your posts table. That can’t use an index. At a few hundred posts nobody notices. At fifty thousand, search becomes the slowest thing on the site — and it gets slower precisely when traffic is highest.

The plugins worth knowing about

Four names come up repeatedly, and they solve genuinely different problems.

Which one fits which site

• Blog or brochure site, under ~2,000 posts. Relevanssi free. It fixes ranking, and ranking is the whole problem at this size.
• Content site with custom post types. SearchWP, for the weighting control. Being able to say “a match in the title is worth five times a match in the body” is the difference between useful and nearly useful.
• WooCommerce store with a manageable catalogue. FiboSearch. The live dropdown does most of the work.
• Large catalogue, heavy filtering, or search that’s central to the business. A hosted engine. Property portals, car listings, course libraries and stores with tens of thousands of SKUs all end up here eventually.

If you’re weighing the last option, what “AI search” actually means in a WordPress context is worth reading first — the term covers several different things, and only some of them are what you need.

Where plugins run out of road

A plugin is a good answer to a common problem. It’s a poor answer to a specific one. You’ve usually crossed the line when:

• Your filters depend on business logic, not fields. “Show properties available on the tenant’s move-in date, within budget, that allow pets” isn’t a facet — it’s a rule.
• You’re running three plugins to get one behaviour. One for indexing, one for the dropdown, one for filters. They fight, and every update is a small gamble.
• Search is slowing the site down. If your search queries appear in your slow query log, no amount of relevance tuning fixes that. The query needs to leave the server.
• Results are relevant but the experience isn’t. Correct results delivered after a two-second wait still lose the visitor.

How to decide without over-thinking it

Ask what’s broken. If relevance is wrong, a plugin fixes it — start with the free tier and stop there if it works. If search is slow, or the filtering your customers need doesn’t map onto WordPress fields, more plugins will not help; the workload has to move somewhere built for it.

The honest summary: most sites need Relevanssi and an afternoon. The ones that don’t tend to know already, usually because someone has already tried three plugins.

If you’ve reached the plugin ceiling, our Smart WordPress Search service connects your site to an Algolia-powered index and configures the whole thing for $295 — and you pay after you see it working.

AI Search for WordPress: What It Actually Means

“AI search” has become a category the way “cloud” once was: technically accurate, commercially useful, and almost meaningless without a follow-up question.

Underneath the phrase are several different technologies. They solve different problems and cost wildly different amounts, so it’s worth separating them before anyone quotes you.

Four things currently sold as “AI search”

• Typo tolerance and fuzzy matching. The engine knows “runing” is one edit from “running”. Genuinely useful, entirely deterministic, and about as much AI as your phone’s autocorrect. Standard in every serious search engine.
• Relevance ranking. Results ordered by how well they match, informed by what people clicked last time. Statistics doing honest work. This is what most people are missing.
• Semantic search (vector embeddings). The engine converts your content into mathematical representations of meaning, so “winter coat” can return a down parka even with no shared words. Legitimately clever, and where the real capability jump is.
• Conversational answers. A chatbot trained on your content that answers in sentences rather than returning links. Impressive in a demo. A different product from search.

Which one does your site actually need?

An honest test: go to your own site and search for something the way a customer would — hurriedly, on a phone, using their words rather than yours. Then check where the failure is.

Most sites land in the first three rows. That’s not a disappointing answer — it’s a cheap one.

What it costs to buy the wrong thing

Two failure modes, both common.

Overbuying. A 400-product store commissions a semantic search implementation to solve what was a synonym problem. It works, but they’re paying a monthly platform fee to do something a text file could have done.

Underbuying. A site with 60,000 listings installs a database-backed plugin, gets better relevance, and finds search now takes three seconds because every query still hammers the same server. The relevance improved; the experience didn’t.

The second is the more expensive mistake, because it looks like progress. If search queries are showing up in your performance audit, that’s the tell.

A sensible sequence

• Read your zero-result queries. Free, and it tells you which of the four problems you have.
• Add synonyms by hand. An afternoon. Often fixes the loudest complaints.
• Move the query off your server. Typo tolerance, relevance and instant results usually arrive together at this step, and the site gets faster as a side effect.
• Only then consider semantic search, and only if your content is large enough or specialised enough that vocabulary is genuinely the barrier.

The unglamorous truth is that step three fixes most sites, and it’s the one nobody writes a press release about.

Our Smart WordPress Search service covers steps one to three — Algolia-powered indexing, typo tolerance, relevance and filtering configured around your content for $295. We’ll also tell you if you don’t need it.