Meta killed the 8-event AEM cap in June 2025. The standalone AEM configuration tab in Events Manager was retired at the same time. If your current tracking guide still tells you to pick and rank eight events for your WooCommerce store, it is describing a system that no longer exists — and the internet is full of those guides.

Here’s the thing: the real lever was never which eight events you picked. It was always event schema consistency across Pixel and CAPI. That lever was partially masked by the cap. Now there is no cap, and schema discipline is the only thing between your store and a clean signal.

Why Your WooCommerce Event Schema Still Decides Your CPA#

In June 2025, Meta removed the 8-event limit and eliminated manual event prioritization (Conversios, 2025). All eligible events are now measured automatically. As the same source puts it: AEM is now fully automated — no ranking, no caps, no manual setup. Implementation quality is your priority: configure your Pixel and CAPI correctly, maintain consistent event schemas, and ensure deduplication.

Translation: Meta has moved the work you used to do in a configuration tab into the quiet parts of your stack — the event ID, the parameter names, the currency codes, the hashing — and if any of those drift, your Advantage+ performance drifts with them.

What Actually Changed

• No cap. All eligible web events count, not just the eight you previously ranked.
• No ranking. You do not pick a priority order. Meta’s system handles it.
• No configuration tab. The AEM settings page is gone from Events Manager.
• Dedup is required. Meta treats deduplication as a performance requirement in 2026 — matching event_name + event_id is what lets it combine Pixel and CAPI signals without double-counting (AGrowthAgency, 2025).

The new pay-off structure is simpler and meaner: send clean, consistent, well-matched events and the system rewards you; send noisy events and it quietly discounts them. There is no button to push to change that.

Why Outdated Guides Still Rank#

Run the query “AEM 8 events WooCommerce” today and most top results still describe the old prioritization workflow. Plugin documentation pages, agency blog posts from 2023, forum answers that never got updated. Meta did not announce the June 2025 change with a press splash; it shipped quietly.

That means your baseline assumption, if you’ve been reading industry content, is probably that the cap still exists. It doesn’t. And the advice you’re following — add InitiateCheckout, AddToCart, ViewContent, Purchase, Lead, Subscribe, CompleteRegistration, and a custom event to your 8-slot priority list — is doing nothing. The rules changed. Your CPA has been paying for the disconnect ever since.

The Four Things That Actually Control Your CPA Now#

1. Stable, Shared event_id

Every conversion Meta receives has an event_id: a unique identifier that lets Meta know the Pixel fire and the CAPI fire refer to the same purchase. If the two match, Meta dedupes. If they don’t, Meta counts the purchase twice.

On a WooCommerce store, the natural event_id is the order ID. Server-generated, unique, stable, already available on the Pixel side via the WooCommerce JavaScript context and on the CAPI side via the REST API. It is the single most obvious shared identifier a WooCommerce store has. Most stores don’t use it.

Instead, WooCommerce stores routinely mis-align IDs across channels — the Pixel plugin generates a random JS-based event_id, server-side CAPI uses the WooCommerce order ID, and GA4 uses a prefixed transaction_id — producing silent double counts and broken reconciliation (Splinternet Marketing, 2026). The event_id problem for server-side GTM on WooCommerce is the same bug in a different suit.

2. Identical Value and Currency Across Sources

The Pixel purchase and the CAPI purchase must carry the same value and the same currency. This sounds trivial. In practice, stores break it constantly — Pixel reports cart total including tax, CAPI reports subtotal excluding tax; Pixel reports in the customer’s display currency, CAPI reports in the store’s base currency; Pixel rounds to two decimals, CAPI sends the full float.

Every one of those drifts is a mismatch. Meta’s dedup logic is forgiving about minor variance, but consistent drift trains Meta to treat the two sources as two events, not one.

3. Stable event_name Casing

“Purchase” and “purchase” are not the same event to Meta. Nor are “AddToCart” and “Add_To_Cart”. If a plugin updates and quietly changes casing on one side, the Pixel source and the CAPI source stop lining up. The cap being gone does not help you here — Meta’s matching is exact.

4. Event Match Quality (EMQ)

EMQ is Meta’s internal score of how well the customer parameters you send (email, phone, name, IP, user agent) let it match the conversion back to a Facebook account. Higher EMQ means more events attributed to more ads, which means Advantage+ has more signal to optimise on.

As one 2026 guide put it: match quality matters more than raw event count. A smaller number of well-matched events often outperforms a larger number of weak ones (wetracked.io, 2026). If you haven’t audited what Event Match Quality actually measures on a WooCommerce store, that is the audit worth running before any Advantage+ campaign change.

The Signal Loss That Compounds All of This#

None of the above matters if you’re sending nothing. Pixel-only WooCommerce conversion tracking typically misses 20-30% of real conversions to ad blockers, ITP, and consent rejection (Ads Uploader, 2026). Server-side captures the same population at 90-95% versus pixel’s 70-80% (Cometly, 2026). And 31.5% of internet users worldwide run ad blockers (Statista, 2024), a number that only goes up from here.

So the post-June-2025 reality is this: Meta rewards consistent, well-matched, deduplicated events, but every event your pixel loses to an ad blocker is an event Meta never gets to measure in the first place. You need both — server-side coverage and schema consistency. Either one alone leaves money on the table.

Here’s How You Actually Do This#

Transmute Engine™ is a first-party Node.js server that runs on your own subdomain (e.g., data.yourstore.com). It uses the WooCommerce order ID as the canonical event_id by default, sends matched Pixel and CAPI events with identical value, currency, and event_name, and hashes customer parameters server-side for EMQ. One source of truth for the schema, routed to Meta CAPI, GA4, Google Ads, and BigQuery simultaneously — from your own domain, outside the ad blocker’s reach.

The cap being gone is a gift. What you do with the schema is whether you unwrap it.

Key Takeaways#

• The 8-event cap is gone. Removed June 2025. AEM is fully automatic. The configuration tab is retired.
• Most ranking tutorials are outdated. If a guide tells you to pick 8 events, it is describing a system that no longer exists.
• Schema consistency is the lever now. Matching event_id, value, currency, event_name across Pixel and CAPI.
• The WooCommerce order ID is the canonical event_id. Stable, unique, server-generated, already available to both sides.
• Pixel alone misses 20-30%. Server-side captures 90-95% — both are needed, clean schema on top.
• EMQ and deduplication are the scoreboards. Higher match quality, fewer double-counts, more Advantage+ signal.

Frequently Asked Questions#

Audit Your Schema#

Open Events Manager, pick a recent purchase, and check whether the Pixel event_id and the CAPI event_id are the same string. If they are not, Meta is counting that purchase twice — and has been for every purchase before it. See how Seresa closes the schema.