Order Source Analytics for WooCommerce

How well this listing is tuned to rank in WordPress.org search, on the factors an owner controls. Not popularity, optimization.

Directory searches this plugin turns up in, and which way each one is moving. WordPress.org publishes no history of search positions, so this starts the day we first tracked a keyword and never backfills.

Not enough tracked days yet to call a direction. Momentum needs at least three keywords measured a week or more apart.

wp.org is where the directory puts the plugin for that search. On merit is where it would sit if results were ranked on rating, support and updates, without the install boost. The last column is how far the wp.org position moved, from our first reading in the last 90 days to the latest.

1 search this plugin appeared in over the last 90 days, 0 listed. 1 left out as unrelated or noise (years, numbers, stray words). 5 of its tags aren't in the top 24 for their own search.

Directory rank

Ranked about #30,100 to #45,000, alongside the other plugins at 10+ installs. Plugins with the same install count swap places between wp.org requests, so this is where most of them sit. Checked monthly, last on 21 Oct 2026.

How often this plugin actually ships. A steady rhythm is the maintenance signal a single "last updated" date can't show.

Modeled within the band wp.org reports; tightens as we track daily.

1. ★★★★★ servicestsim

   4mo ago

   Version 1.0.1 has serious reporting bugs 1. It probably excludes completed orders The code converts statuses using: 'wc-' . ltrim($s, 'wc-') The second argument to ltrim() is a set of characters, not a literal prefix. Consequently: processing -> wc-processing completed -> wc-ompleted cancelled -> wc-ancelled The default statuses are processing and completed, so completed orders will likely be silently excluded from both the source report and daily-revenue trend. The correct form is approximately: $s = sanitize_key((string) $s); return str_starts_with($s, 'wc-') ? $s : 'wc-' . $s; This bug appears in multiple paths and must be fixed everywhere, including the legacy-order queries. 2. Its PHP 7.4 compatibility declaration is wrong The plugin says it supports PHP 7.4, but repeatedly calls: str_contains() str_starts_with() str_ends_with() Those functions require PHP 8.0 or later. On PHP 7.4, report execution will fatal-error. The developer should either declare PHP 8.0+ or replace those calls with PHP 7.4-compatible implementations. 3. Large date ranges can consume excessive resources The date parameters are sanitized but not strictly validated or limited. The plugin: Builds one PHP array entry for every day in the selected period. Retrieves one database row per order and aggregates the results in PHP. Describes the queries as “aggregated,” even though the main source query is not aggregated in SQL. A shop manager selecting an extremely large range could cause a heavy database query, high PHP memory use, or a timeout. 4. Its HPOS support is brittle It does query wc_orders and wc_orders_meta, so it understands HPOS storage. But it: Directly couples itself to WooCommerce table structures. Does not declare HPOS compatibility through WooCommerce’s FeaturesUtil mechanism. Executes a second legacy-table query even when HPOS is active, attempting to find orders not present in HPOS. That is less robust than using supported WooCommerce order/query APIs. 5. The advertised meta-key settings do not exist The plugin initializes a list of possible attribution meta keys and tells the administrator to configure the correct meta key in “Settings.” However: There is no settings screen or save handler. The private option-update function is never called. The reporting function ignores the supplied $metaKeys. It always uses three hard-coded WooCommerce attribution keys. Therefore, the advertised support for custom attribution metadata is effectively unimplemented.6. It can misclassify attribution The normalization code tends to label a source value of google as Google Ads, without examining UTM medium. It also collapses most referring domains into a generic Referral category. That can give misleading marketing results even after fixing the completed-order bug.7. “Revenue” means order total, not net sales It sums total_amount. It does not subtract refunds or reproduce WooCommerce Analytics’ net-sales calculation. Its revenue result may include shipping and tax and may differ materially from WooCommerce’s standard reports. I would not rely on version 1.0.1 in production until at least the following are fixed: Replace all faulty ltrim($s, 'wc-') status handling. Require PHP 8.0+, or implement PHP 7.4-compatible string helpers. Validate dates and impose a sensible maximum report range. Compare its counts and totals against known completed and processing orders. Clarify whether “revenue” means gross order total or net sales. Add a proper HPOS compatibility declaration.

   Read on wp.org ↗

Whether ChatGPT and Claude name this plugin when asked the category question, and whether the readme gives them something to quote.

Not measured yet for this plugin’s topics. Its tracked searches are not among the measured topics. See the topics measured so far.

Growth timeline

Install-tier crossings we have observed, and how long each tier took to outgrow

No tier crossings observed yet.

Competes with

The plugins that solve the same job, ranked by shared tags then reach, closest match first. The letter on the right is each plugin's health grade (A best, F worst).

Embed this report card

Drop a live Pulse card for Order Source Analytics for WooCommerce into a readme, a review or a deck. It updates itself.

Order Source Analytics for WooCommerce: 10+ active installs, 5.0★ (1 reviews). Plugin Pulse (WP Mayor), as of 2026-10-31. https://plugins.wpmayor.com/plugin/order-source-analytics-for-woocommerce