New installation & setup

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,

3.6.0 just shipped — should resolve everything you flagged.
The queue-leak you spotted is fixed (rows now correctly drop when an event’s send_to targets a platform with no credentials configured, instead of accumulating).
I also ran end-to-end tests against the timezone scenario you mentioned and the plugin behaves correctly across the time-difference cases I could reproduce.

Really appreciate the thorough review — these were exactly the kind of edge cases that would have been painful to debug in production.

Regards,
Suhan