If you’ve ever changed event priorities in Meta’s Aggregated Event Measurement (AEM) settings and then stared at Events Manager wondering why nothing looks different, you’re not imagining it. The interface routinely lags behind what’s actually happening on Meta’s servers, and that gap gets worse right after domain verification changes or privacy-related configuration updates — which is exactly when people go looking to double-check their work.
Here’s what you’ll get from this: how Meta actually ranks events for AEM, why Events Manager often shows a stale priority order, how domain verification and privacy settings can quietly block or reorder events, and how to tell whether a change you made is actually live yet.
How Meta Aggregated Event Measurement Priority Works
AEM restricts conversion tracking for users who opt out of tracking on iOS or fall under a US state privacy law such as CCPA/CPRA. When those restrictions kick in, Meta limits reporting and optimization to a maximum of eight conversion events per verified domain, and you rank those eight in Events Manager under the Aggregated Event Measurement settings.
Each verified domain has its own priority list. You pick up to eight events and give each a rank from 1 (highest) to 8 (lowest). That order isn’t cosmetic — it decides which single event Meta reports and optimizes toward when several eligible events fire in the same restricted session. If both Purchase (priority 1) and AddToCart (priority 3) fire for the same user, only Purchase shows up in reporting.
Lower number, higher importance. Meta always counts the highest-ranked event that fires for that user’s restricted session, and this only touches the eight events you’ve actually ranked.
This has a direct effect on how you should set up optimization. Optimize a campaign for an event sitting further down your priority list — say, InitiateCheckout at priority 4 — and Meta will only attribute conversions for privacy-restricted users who reach that step without also triggering a higher-priority event in the same session. Underreporting shows up fast once you know to look for it.
A properly implemented Meta Conversions API setup won’t get you around AEM’s eight-event cap for privacy-restricted users, but it does close a lot of the attribution gaps that come from browser-side tracking loss, which is worth having in place regardless.
Why the Event Priority Order Can Look Wrong in Events Manager
The order shown in Events Manager can trail the real configuration by hours. Backend changes usually apply within minutes, but the screen itself can take much longer to catch up — so campaign delivery and reporting may already reflect your new order while the UI still shows the old one. This is most noticeable when you’re testing a change and checking back right away.
Meta doesn’t promise real-time UI updates anywhere in its documentation, because the ranking that actually drives AEM is set server-side and lives separately from what Events Manager displays. Run a test event or pull real-time reporting soon after a change, and you can end up seeing results that match your new priorities even though the order on screen hasn’t moved.
Some of that is just browser caching. Refresh the page first. If it’s still wrong, log out and back in, or open a private window — that forces the UI to pull a fresh copy from Meta’s servers instead of showing you whatever it had cached. Don’t trust a single browser tab as proof that a change has gone through.
If none of that fixes it, check domain verification on the pixel. AEM only works with a verified domain, and if verification is missing or pending, Meta can quietly ignore your priority changes or hold them in limbo. You’ll find domain status in Business Settings under “Brand Safety & Suitability,” or on the pixel’s own settings tab in Events Manager.
Watch for a “pending” or “in review” label next to your edits, too — that means the new order isn’t live yet. Meta doesn’t publish a firm SLA for this review, so it can sit for hours, especially during busy periods or if you’ve made several changes back to back.
How Domain Verification Affects Event Priority and Measurement
Only verified domains can set AEM event priorities at all. On an unverified domain, “Manage Events” is greyed out, and any attempt to reorder events just prompts you to verify the domain first.
Events firing on an unverified domain never enter the AEM prioritization queue, even if the pixel is active and the events are clearly landing. That’s an easy way to end up with incomplete conversion reporting on ad sets that are optimizing for those events without anyone noticing why.
Reassigning a pixel to a different verified domain, or changing which domain is verified, tends to blow away the existing priority order — you’ll likely need to rebuild it. That reset isn’t always instant on screen either; Events Manager can keep showing the old order while the backend catches up, sometimes for well over 15–30 minutes. There’s no reliable “last confirmed” timestamp in the UI, so if the priorities look off after a domain or pixel change, treat what you’re seeing as stale until you’ve reloaded and checked again.
You can confirm verification status in two places: Business Settings → Domains (verified domains get a green checkmark), and the top of the event configuration panel in Events Manager, which names the associated verified domain. Sort out verification before you touch anything else — troubleshooting event order on top of a shaky domain connection just wastes time.
Troubleshooting: When Priority Changes Don’t Apply
Start with domain and pixel status. In Events Manager, go to Brand Safety & Suitability → Domains and confirm the domain reads “Verified.” Make sure the pixel is assigned to that domain on the same screen — an unassigned pixel won’t reflect any priority changes, no matter what the UI shows elsewhere.
Give it time. Meta references up to 72 hours for changes to fully propagate through delivery and measurement systems. Events Manager itself might update quickly while the actual attribution logic lags behind, so it’s entirely possible to see conversions still crediting the old priority order for a few days after you’ve changed it. There’s no way to force this along faster.
Check the status column on each event. “Pending Review” can sit for hours if Meta’s review queue is backed up, and “Rejected” blocks that event from AEM entirely — remove or swap it out to unblock the rest of your priority changes.
If the order looks different for different people on your team, that’s almost always browser cache, not a real discrepancy — clear it or open a private window and compare again.
Still wrong after 72 hours, or the system status doesn’t match what you see on screen? That points to a platform-side issue rather than anything in your setup. Meta posts known outages and disruptions on its status page, which is worth a quick check before you spend more time troubleshooting your own configuration.
How Event Priority Interacts with US State Privacy Laws
AEM exists because of laws like California’s CCPA/CPRA, Colorado’s CPA, and Virginia’s VCDPA, which restrict sending user-level identifiers for residents who’ve opted out of the sale or sharing of their personal information. When Meta detects a covered user, it applies AEM rules to stay compliant — only the top-ranked event from your priority list gets reported for that interaction.
None of this applies to users outside those regimes, or anyone who hasn’t opted out — for them, you’ll see every eligible event in reporting regardless of priority order. AEM only narrows things down for the users legally entitled to that restriction.
Consent state is what drives all of this, so get it right at the source. If you’re running a Consent Management Platform, confirm its opt-out signal actually maps to what Meta expects. For the base Meta Pixel, that means setting dataProcessingOptions correctly when a user opts out:
fbq('dataProcessingOptions', ['LDU'], 0, 0);
Skip this and Meta may treat the event as fully consented — a compliance risk. Get it wrong the other way and Meta may drop the user from reporting entirely, or misprioritize their events. Test your opt-out flow directly: watch the event payloads in your browser’s dev tools, and cross-check with Pixel Helper or the diagnostics tab in Events Manager.
And a basic but easy-to-miss check: an event can only be ranked if it’s actually firing on your verified domain and sitting in your configured event list in Events Manager. If it’s missing there, it doesn’t matter how you intended to prioritize it — Meta can’t rank what it doesn’t see.
Frequently asked questions
How long does it take for Meta event priority changes to take effect?
Anywhere from a few hours up to 72 hours, and the Events Manager UI often updates before the underlying attribution logic actually does.
Why can’t I reorder events for my domain in Events Manager?
Event priority is only available on verified domains. If verification hasn’t gone through, or the pixel-domain link is broken, the reordering controls stay locked.
Does event priority affect every user, or just privacy-restricted ones?
Just the ones covered by state privacy laws like CCPA/CPRA, plus iOS users who’ve limited tracking via App Tracking Transparency. Everyone else still triggers all your configured events normally.
Not sure your tracking is telling you the truth?
Propulse Agency audits e-commerce tracking setups — server-side tagging, Meta CAPI, GA4 and consent — and fixes what is quietly costing you conversions.
Check Event Priority Against Actual Delivery
Before you trust your AEM setup, compare the priority order in Events Manager against what’s actually being delivered in Ads Manager reporting. Mismatch? Clear your cache and reload — changes to event order or domain verification can take hours to fully propagate.
Make sure the verified domain you’re checking is actually the one sending events, especially if your store runs multiple subdomains or a proxy setup. When you’re troubleshooting, test from a fresh browser profile and use Pixel Helper to see what’s really firing — don’t take the Events Manager UI’s word for it, since it can lag behind what’s actually reaching your ads. Fix domain verification and privacy opt-out handling first; sort event order after.
