shan

Hi Leslie,

Found it. Your Scheduled Actions screenshot was the smoking gun — that “failed after 300 seconds” entry on June 12 12:12 UTC told the whole story.
Thank you for taking the time to pull it; that one screenshot saved me days of guessing.

Here’s the full picture, including why this whole “deferred events” machinery exists in the first place — because the answer is intertwined with the bug.

Why we have a deferred-events table at all.
The plugin maintains a ~9,500-CIDR datacenter IP list (AWS, GCP, Azure, ColoCrossing, OVH, etc.).
Events arriving from those IPs are usually scrapers, headless browsers, ad-fraud bots — but not always. Apple iCloud Private Relay traffic rides on Apple’s own datacenters.
VPN shoppers often exit through commercial hosting ranges. A logged-in customer using a corporate VPN looks identical to a scraper at the network layer.
We can’t just drop those events — we’d lose real shoppers.

So instead of dropping or sending immediately, ambiguous events get parked in mcapi_deferred_events while the plugin watches that visitor for “real human” signals: paced page views, behavioral keepalive proof, a click-ID cookie, eventually a Purchase.
If any of those land, the plugin “graduates” the visitor to trusted and replays the entire deferred funnel into the queue — so Meta/Pinterest see PageView → ViewContent → AddToCart → InitiateCheckout → Purchase as a complete chain instead of an orphaned Purchase.
If the signals never land, the deferred rows age out without ever being sent. Real shoppers preserved, scrapers excluded.

Where 3.7.1 broke this.
I added a pacing check to the soft-trust graduation logic — 3 events with at least 3-second average gaps instead of just “3 events”. That’s correct anti-bot hardening (a bot firing 3 events in 200ms shouldn’t earn trust).
But the side effect was that more events accumulate in the deferred table before graduation.
And when a visitor finally graduates, the recovery function would dump ALL of their accumulated deferred events into the queue in one shot — no cap.

Combined with the second problem: the plugin’s admin Event Log uses WordPress transients for caching, and 3.7.1 added two new transient keys (mcapi_logs_byip_*) for the new By-IP view. Each log insert fired 5 delete_transient() calls. On a queue tick processing 100 recovered events × 3 platforms × 5 deletes = 1,500 DELETE queries against wp_options in one cron tick. On a site with bloated wp_options (many plugins, lots of options), those DELETEs stack up, combined with HTTP timeouts to Meta/Pinterest, the batch can exceed Action Scheduler’s 300-second wall. Action Scheduler then marks the action “failed” — and it doesn’t auto-reschedule. Silent halt.

Your downgrade-to-3.7.0 fixed it because WordPress runs the activation hook on a fresh install, which re-registered the cron from scratch.

3.7.2 just shipped to ww.wp.xz.cn with two fixes:

1. Per-event invalidation is gone — replaced with a single invalidation call at the end of each queue batch. ~1,500 DELETEs → ~30 DELETEs per batch.
2. Deferred-event recovery now caps at 50 rows per call (filterable via mcapi_deferred_recover_limit). A single trust graduation can’t dump a saturated backlog into one cron tick anymore — anything beyond 50 drains naturally on the next tick.

When you update from 3.7.0 to 3.7.2, the activation hook fires and re-registers the cron (same way your downgrade did), so dispatch resumes on the new code automatically. No manual intervention needed.

You can update whenever you’re comfortable — there’s no urgency because you’re already on 3.7.0 and events are flowing. If you do update and see anything off, please write back and I’ll dig in immediately.

One more thing: your diagnostic work here directly led to the fix. If anyone else hit the same silent failure mode they hadn’t reported it — your screenshots are the reason every user gets this fix today.

Genuinely grateful.

Kind regards,
Suhan

Hi Leslie,

Really sorry to hear about the tracking impact — that’s a painful 3 days, and I want to help you get to the bottom of it.

Quick context up front: we haven’t seen similar reports from other users on 3.7.1 yet, so this might be something specific to your environment, or there could be a regression we haven’t seen elsewhere. Either way I’d like to walk through the diagnostic together rather than guess.

A few things that would help me narrow it down:

1. Walk me through the timeline. When exactly did you first notice the events stopped flowing, and when did you update to 3.7.1? Sometimes the update timing is coincidental with another change on the site (a host migration, a security plugin update, cron service change, SSL renewal) and the diagnostic gets easier once we map the sequence out.
2. What the most recent Event Log rows show. In CAPI Suite → Event Log → Detailed Event Log, the most recent rows should have a status (“success” / “failed”) and a response_data column. If there are rows with failure responses (HTTP 401, 5xx, timeout etc.), those error messages usually point right at the cause. Could you share the last 5–10 row statuses and their response_data values?
3. Queue health. On the WP Dashboard widget (CAPI Suite section), what do these show?

• Queue size
• Oldest pending
• Last successful dispatch
• Background tasks pending If queue size is high but “Last successful dispatch” is days old, the queue processor (Action Scheduler / WP-Cron) likely isn’t firing. You can force a manual run from WP-CLI: wp action-scheduler run –hooks=mcapi_process_event_queue

1. Outbound HTTP reachability. Some hosts silently block outbound HTTPS after security/firewall changes. Quick test from WP-CLI: wp eval ‘var_dump( wp_remote_get( “https://graph.facebook.com/v25.0/”, array( “timeout” => 5 ) ) );’ A network error or timeout here would explain a dispatch stall regardless of plugin version.
2. Pixel ID + Access Token still valid? If the access token expired or was rotated, dispatch would fail silently with 401 responses — and those would show up in the Event Log rows from item 2. A 60-day Meta system-user token rotation, a Business Manager permission change, or an account reorganization can all cause this on a date unrelated to the plugin update.
3. Anything else around the same time. Plugin updates, theme change, server move, security plugin install, .htaccess edit, SSL renewal, cron service change, WP-Cron disable — worth listing anything that changed in the same window.
4. (Optional) Your site URL. A quick look at the front-end lets us spot the theme, caching plugin, and security plugin setup — sometimes a security plugin’s recent rule update silently blocks outbound HTTP to graph.facebook.com, and the setup often tells us where to look without you needing to dig through configs. For context: 3.7.1’s changes were a browser-side fix for the AddToCart dataLayer push, a tightening of the behavioral bot filter for datacenter IPs, and a couple of admin-side cleanups (cache invalidation + an option autoload flag). None of those touch the server-side dispatch loop that POSTs events to Meta or Pinterest — so I’m puzzled by the symptom and want to make sure we’re not chasing the wrong cause. If the diagnostic data above points back at the plugin, we’ll absolutely ship a hotfix and pull the affected version; if it points elsewhere (which is what the changeset suggests), we’ll know exactly where to look together. Whenever you can share the items above — even partial info helps — I’ll dig in.
   
   Thanks for the detailed report.
   Kind regards,
   Suhan

UPDATE:

I took a quick look at https://eurocharms.sk source. Your stack is Elementor Pro + a custom child theme (FinestudioEcommerce1). This is almost certainly the root cause: Elementor Pro’s WooCommerce widgets (Products grid, Loop Grid, custom Add to Cart buttons) implement their own AJAX flow that bypasses both WooCommerce’s standard fragments mechanism and the jQuery added_to_cart event.

What that means specifically:
– The cart updates correctly (Elementor calls woocommerce_add_to_cart PHP hook directly), so server-side CAPI is still firing — please confirm by checking the plugin’s Event Log tab; you should see AddToCart rows with Success (Meta) after testing
– But the browser-side dataLayer push doesn’t happen because our JS listener depends on the standard jQuery added_to_cart event, which Elementor doesn’t trigger

Three options to fix the browser-side / GTM half:

1. Switch the product cards to native WC blocks (or the classic shortcode [products]). This is the simplest fix — WC’s native rendering uses standard AJAX and our plugin works out of the box. Best if you don’t need Elementor-specific layout tricks.

2. Add a custom dataLayer push bound to Elementor’s event. Drop this in your child theme’s functions.php:

add_action( ‘wp_footer’, function() {
if ( ! function_exists( ‘is_woocommerce’ ) || ! ( is_shop() || is_product_category() || is_product_tag() || is_product() ) ) return;
?>
<script>
jQuery(document.body).on(‘elementor/widget/loop_grid/add_to_cart/success added_to_cart’, function(event, fragments, cart_hash, $button) {
// Re-check the mcapi fragment in case Elementor’s response did include it
var $el = jQuery(‘.mcapi-atc-datalayer’);
if ($el.length && $el.attr(‘data-mcapi-payload’)) {
try {
var payload = JSON.parse($el.attr(‘data-mcapi-payload’));
$el.removeAttr(‘data-mcapi-payload’);
window.dataLayer = window.dataLayer || [];
window.dataLayer.push(payload);
} catch(e) {}
}
});
</script>
<?php
});


2. This rebinds the listener to Elementor’s success event in addition to WC’s standard one. If Elementor’s AJAX response doesn’t carry our fragment, this won’t help on its own (option 3 below covers that).

3. Force the dataLayer push server-side without depending on fragments, by directly enqueuing the AddToCart push for the next page load. Add to child theme functions.php:

add_action( ‘woocommerce_add_to_cart’, function( $cart_item_key, $product_id, $quantity ) {
if ( ! function_exists( ‘WC’ ) || ! WC()->session ) return;
$product = wc_get_product( $product_id );
if ( ! $product ) return;
$value = (float) $product->get_price() * (int) $quantity;
$payload = array(
‘event’ => ‘add_to_cart’,
‘event_id’ => ‘addtocart_’ . $cart_item_key . ‘_’ . uniqid(),
‘ecommerce’ => array(
‘currency’ => get_woocommerce_currency(),
‘value’ => $value,
‘items’ => array( array(
‘id’ => (string) $product_id,
‘item_id’ => (string) $product_id,
‘item_name’ => $product->get_name(),
‘price’ => (float) $product->get_price(),
‘quantity’ => (int) $quantity,
) ),
),
);
// Stash for the next page load — gets emitted by Elementor’s redirect or page refresh
WC()->session->set( ‘mcapi_pending_atc_datalayer’, $payload );
}, 5, 3 ); // priority 5 = before plugin’s hook at 10

add_action( ‘wp_footer’, function() {
if ( ! function_exists( ‘WC’ ) || ! WC()->session ) return;
$payload = WC()->session->get( ‘mcapi_pending_atc_datalayer’ );
if ( empty( $payload ) ) return;
WC()->session->set( ‘mcapi_pending_atc_datalayer’, null );
echo ‘<script>window.dataLayer=window.dataLayer||[];window.dataLayer.push(‘ . wp_json_encode( $payload ) . ‘);</script>’;
});

3. This fires once on the next page load (e.g., when Elementor redirects to the cart or refreshes a fragment). Less ideal than real-time but works regardless of which AJAX flow Elementor uses.

My recommendation: start with option 1 if your design allows it — least code, zero ongoing maintenance. If you need Elementor’s layout, try option 2 first (1-min test in browser console will tell you if Elementor includes the fragment); fall back to option 3 if it doesn’t.

Either way, please first verify server-side CAPI is firing via the Event Log — that tells us whether the cart-add itself is reaching to the plug-in, even though the dataLayer push isn’t.

Regards,
Suhan

1. Plugin’de zaten “Datacenter IP filter” var.

Açıksa plugin her gün ~9,500 CIDR (AWS, GCP, Azure, Cloudflare, DigitalOcean, Linode, Vultr, Hetzner, Alibaba…) indirip otomatik filtreliyor. Ad-fraud bot’larının yaklaşık %85-90’ı bu cloud datacenter’larından geliyor.

2. Country-filter, datacenter filter ile büyük ölçüde overlap eder.

TR mağazası için, gelen trafik örnekleri:

 ┌────────────────────────────────────────────────┬───────────────────┬──────────────────────────┐
│                    Senaryo                     │ Datacenter filter │ Country-filter (TR-only) 
├────────────────────────────────────────────────┼───────────────────┼──────────────────────────┤
│ AWS Virginia'dan bot                           │ ✅ yakalar        │ ✅ yakalar (aynı IP)     
│ Hetzner Almanya bot                            │ ✅ yakalar        │ ✅ yakalar (aynı IP)     
│ Rus residential proxy ağı                      │ ❌ kaçar          │ ✅ yakalar               
│ TR datacenter'da yerel scraper                 │ ✅ yakalar        │ ❌ kaçar (TR sayılır)    
│ Almanya'dan alışveriş yapan Türk gurbetçi      │ ✅ geçer          │ ❌ KESER ⚠              
│ Apple Private Relay ile NL çıkışlı iOS müşteri │ ✅ bypass var     │ ❌ KESER ⚠              
│ TR'de VPN açarak gezen gerçek müşteri          │ ✅ bypass var     │ ❌ KESER ⚠               

Yani country-filter, datacenter filter’ın yakalamadığı çok küçük bir niş için fayda sağlıyor; karşılığında yurt
dışı gerçek müşterileri (gurbetçi, turist, VPN-kullanıcı, Apple Relay iOS) false-positive olarak kesiyor.

Plugin’in datacenter filter’ı bu son üç grup için zaten özel bypass mekanizmaları içeriyor: varsa cookie kontrolü, Apple Private Relay IP whitelist, login customer bypass.
Country-filter bu bypass’ları yok sayar — hepsini “yabancı IP = bot” sayar.

Sonuç: Country-filter gereksiz, datacenter filter zaten asıl sorunu çözüyor. Excluded Traffic sekmesinde “Auto-fetched (daily)” aktif edersen büyük ihtimalle “tek tek IP girmek çok zor” sorunun orada çözülecek.

Not: Meta ve Google reklam onayında Landing page crawl yapar.

• Bizim filter sadece “datacenter IP’den POST /wp-json/mcapi/v1/event çağrılarını” filtreliyor. GET /landing-page’i kimseyi engellemiyor. Meta’nın crawler’ı landing page’e ulaşabiliyor, pixel’i HTML’de görüyor, onay süreci sorunsuz işliyor.
• Bizim datacenter blocklist’imiz cloud sağlayıcılar (AWS, GCP, Azure, Cloudflare, DigitalOcean, Linode, Vultr, Hetzner, Alibaba, Oracle, Fastly) odaklı.
• Meta’nın kendi AS’ı (31.13.0.0/16 civarı, AS32934) ve Google’ın ad crawler AS’ları (AS15169 Googlebot ranges) listede YOK.
• facebookexternalhit Meta IP’sinden gelirse → datacenter filter’a uğramaz, normal şekilde sayfayı alır
• Googlebot veya AdsBot-Google Google IP’sinden gelirse → datacenter filter’a uğramaz
• Hatta GCP’den çıkan bir test (nadir senaryo) → datacenter filter’a uğrar AMA facebookexternalhit veya Googlebot UA’sı zaten ayrıca yakalanır → Purchase event muafiyeti dışında zaten event göndermiyoruz → net etki sıfır

Block’lanan IP’ler de aslında block’lanmıyor, sadece o olay eğer gerçek kullanıcı değilse meta’ya gönderilmiyor. (yeni versiyonda block ismi değişti, block kelimesi yanlış çağrışım yapıyor)

Hi Tim,

Thank you for the incredibly detailed reports. The PHP error log, the queue dump, the Action Scheduler stats — that level of detail let me identify exactly what’s going on. Quick summary, then specifics:

1. The “spurious” PageView and AddToCart events — confirmed bot/scraper activity, not a plugin bug

I went through the queue CSV you sent. The traffic profile is unmistakable:

14,036 AddToCart vs only 871 PageView events. Real shoppers always generate far more PageViews than AddToCarts (typical ratio is 5–20× the other way). This inversion means clients are calling the cart endpoint directly without ever navigating the site. (which is impossible)

Top source IPs are all known hosting providers:

2a01:4f8:151:841e::2 (171 hits) → Hetzner IPv6

43.130.139.214, 43.130.107.148, 43.131.63.234, 8.219.99.6 (96+ hits combined) → Tencent Cloud (Singapore / HK)

47.237.254.73, 47.236.133.154 (57+ hits) → Alibaba Cloud

User-agents are realistic Chrome/macOS strings — that’s why our existing UA-based bot filter in 3.5.3 lets them through. The bots are paying attention to fingerprint detection.

This isn’t visitor activity. These are competitor-research scrapers, ad-fraud bots, and price-monitoring tools hitting your add_to_cart endpoint directly.

2. What 3.6.0 does about it (already coded and tested, still working on an elegant solution)

The next version adds a server-side datacenter IP filter with the following stack: (real users don’t use datacenters)

A 9,000+ CIDR blocklist covering AWS, GCP, Azure, DigitalOcean, Hetzner, Tencent, Alibaba, Linode, Vultr, OVH, Oracle, Fastly — the exact providers your CSV is dominated by. Updates daily from a CC0-licensed upstream.

A “real-user bypass” so legitimate visitors behind VPNs/corporate proxies don’t get caught: ad-click IDs (fbclid/gclid/ttclid), Apple iCloud Private Relay egress IPs (whitelisted from Apple’s published list), logged-in WooCommerce customers, and visitors with a _fbp (Meta Pixel) or _ga (Google Analytics) cookie set from a previous visit.

Purchase events are never blocked — your revenue tracking stays clean by design.

A funnel-chain recovery mechanism: if a real user happens to be filtered (rare edge case) and then completes a Purchase, the plugin replays their full funnel (PageView → ViewContent → AddToCart → InitiateCheckout) so Meta still sees the complete journey.

I’ve tested this end-to-end against synthetic bot traffic and against real edge cases (Apple Private Relay, click-ID bypass, etc.). On a sample run, ~95% of datacenter-source events get filtered before they reach the queue or your logs.

In the meantime, the Wordfence rule you mentioned will help — blocking known scraper ASNs (AS24940 Hetzner, AS45090 Tencent, AS37963 Alibaba) at the firewall is the right interim move.

3. GTM template “Unrecognized value [EVENT]” import error — fixed

This was a real bug in the 3.5.3 template. The container had a built-in variable entry of type “EVENT” that GTM’s deserializer rejected on import in some regions. The variable wasn’t actually used by any tag or trigger — just dead weight in the JSON. Removed in 3.6.0.

4. Event time showing 2 hours ahead — I’d like to confirm one thing on your side

The plugin stores all timestamps in UTC and converts to your site’s local timezone via WordPress’s wp_date() for display. That logic is correct as far as I can verify it. To rule out a config issue: in your WP admin, Settings → General → Timezone, what is the value set to? Specifically:

Is it set to a city like Europe/Prague?

Or is it set to a manual offset like UTC+2?

If it’s the manual offset, that can produce the exact +2h drift you’re seeing because the offset gets applied twice in some code paths. Switching to Europe/Prague (which respects DST automatically) usually fixes it. If it’s already on Europe/Prague, that’s unexpected and I’ll need to dig further.

5. Log “stopped at exactly 1,000 entries” — this isn’t expected, I’d like more info

The plugin doesn’t have a 1,000-row hard limit anywhere in the code. The retention cleanup runs once per day and is based on age (15 days by default), not row count. So a hard stop at 1,000 is unusual.
Is the wp_mcapi_logs table actually capped at 1,000 rows, or are you seeing only 1,000 in the admin panel display (which has a UI cap) while the table itself has more? A quick SELECT COUNT(*) FROM wp_mcapi_logs; would clarify.

6. Bonus answer to your queue draining concern

3.6.0 ships a Sending Method toggle in Event Management → Behavior:

Asyn (default, current behavior): events batched every 60s via Action Scheduler. Good when cron is reliable.

Sync: events sent synchronously on the same HTTP request that triggered them. Useful if you ever again see queue backlog without drain. Trade-off is +500ms on add-to-cart and checkout requests, but you’ll never have a “queue stuck” state.

For your situation today (15K backlog), the queue is draining — the Action Scheduler stats you sent show 3,808 successful runs. The reason it’s not catching up is bots are arriving faster than the dispatcher can drain at 60s ticks. Once you’re on 3.6.0, the datacenter filter will drop ~95% of those bot events at the door, so the queue stays small.

Thanks again for the detailed bug reports — exactly the kind of feedback that improves the plugin for everyone.

Best,
Suhan

Hi Tim — thanks for the update.

(1) Glad it sorted itself out. Old Meta Pixel plug-ins will be updated with the template.
0c574 is the correct version.

(2) The free-shipping progress bar plugin is a strong lead. 3.5.3 (shipping today)
already includes a fix for one variant of the cart-widget replay issue: the AJAX
add-to-cart payload was previously emitted as an inline script inside a
WooCommerce fragment, and WC caches fragments in browser sessionStorage, so any
later page load that re-rendered the cart widget would silently fire the script
again. 3.5.3 moves the payload to a self-clearing data attribute, so cached
fragments are inert on replay.

That should cover the browser-side noise. If the spurious events continue after
3.5.3, the next likely vector is your progress bar plugin re-invoking
woocommerce_add_to_cart on cart-page render. To confirm or rule out, after
upgrading could you check the Event Log on the cart page (no actual add-to-cart
action) and let me know if any AddToCart rows appear with source_info matching
items already in your cart?

(3) Event Log lives in a custom database table (wp_mcapi_logs by default — your
table prefix may differ). You can view/filter it from WP Admin → All-in-one CAPI
→ Logs. Filter by status=failed and event_name=PageView (or any event you suspect
bots are spamming), then click any row to see the full User-Agent. Two or three
real samples and I’ll extend the bot regex tightly.

Thanks again for the patience — 3.5.3 should be live in your auto-update channel
within a couple of hours.

v3.5.2 just shipped — full GTM API schema rebuild. (template is working)

The previous 3.5.x template wasn’t importing into modern GTM workspaces (Unknown entity type errors).
I tested the new build end-to-end in a fresh GTM workspace and it now imports cleanly with all 19 tags, 10 triggers, 13 variables, and the Meta Pixel custom template.

Please re-download the template from the plugin settings and re-import.
Thanks for the patience while we chased this through. : )

Regards,
Suhan