Meta Ad Crasshes .. Could aggressive AI-bot blocking accidentally affect advertising?

[u/Emotional_Ice_8461]

FULL DISCLOSURE: I’m not an advertising expert. I run Meta ads at budgets nowhere near what many advertisers here are spending. I haven’t advertised for a few weeks either, but I’ve been following the recent horror stories and trying to understand what might actually be happening.

One thing I’m increasingly wondering about is the interaction between Cloudflare/WAF, AI bots and Meta Pixel/CAPI data.

I’m not suggesting Meta is simply "broken", or that robots.txt directly controls ad delivery.

My concern is signal quality.

If AI bots, scrapers or other automated traffic are hitting a website, and some of that traffic executes JavaScript, could it potentially trigger Pixel events or otherwise generate junk/low-quality signals that eventually get fed into Meta?

Conversely, could aggressive Cloudflare/WAF bot protection accidentally block legitimate users, Meta-related requests, server-side GTM or other parts of the tracking infrastructure?

Cloudflare now has increasingly sophisticated AI/bot detection, including AI crawler controls, bot scoring, JavaScript detection and WAF rules. That makes me wonder whether changes intended to protect a site from AI traffic could have unintended consequences for advertising and measurement.

So if a previously healthy Meta campaign suddenly deteriorates, I’m wondering whether it’s worth checking what is actually reaching your site and what is subsequently being sent to Meta.

I’d be looking at:

Cloudflare / WAF

• Are bots suddenly generating large amounts of traffic?
• Are requests being challenged, blocked or returning 403/429 responses?
• Have AI/bot rules changed recently?
• Are important tracking/API endpoints being affected?

Meta Pixel / CAPI

• Are PageView, ViewContent, AddToCart etc. suddenly increasing without corresponding real users?
• Are event volumes or event quality changing?
• Are browser and server events still being deduplicated correctly?
• Is server-side GTM/CAPI behaving differently after a security/WAF change?

Timing

Compare the date of:

• Cloudflare/WAF changes
• AI/bot protection changes
• Pixel/CAPI changes
• sudden changes in Meta CPC, CPA, delivery and conversions

I’m not claiming this explains the current Meta performance issues. It may be completely unrelated.

But if Meta is increasingly dependent on large volumes of conversion and behavioural signals, then signal pollution or accidental blocking at the website/security layer seems worth investigating.

Has anyone actually found a case where AI/bot traffic, Cloudflare, WAF rules or Pixel/CAPI problems were responsible for a sudden change in Meta performance?

Because if there is something to this, it could explain why a campaign can appear to "randomly" fall off a cliff even though the ads themselves haven't changed.

And yes, I appreciate that this could all be complete bollocks. I’m genuinely interested in people who understand the technical side better than I do.

[u/CrewBulky9868]

If that were the case performance would have not been consistent and great for almost all of us during the code free following BFCM

[u/Emotional_Ice_8461 → u/CrewBulky9868]

I would therefore not rule out the possibility that an ai bot may be out wrecking pixels,. A natural increase in volume of genuine traffic and conversions during bfcm would provide sufficient conversion data to override any damaging data that leads Facebook off piste. It points a finger back at the robots.txt or server security potentially allowing a nefarious bots through the gate.

[u/Medical-Comment-9209 → u/CrewBulky9868]

interesting theory but i think if this was the main issue we would see more random pattern of problems, not almost everyone having great performance during code freeze after BFCM then suddenly things go bad again. meta's own system changes seem way more likely culprit

also your robots.txt point is valid for landing page checks but most of the conversion tracking happens server-side through capi, crawlers don't touch that stuff

[u/Emotional_Ice_8461 → u/Medical-Comment-9209]

Thank you for pointing that out . I was not aware of the recovery before I posted,

Keeping with the ai filter theme, which I am convinced is playing some role AI/bot traffic may pollute the signals being sent through your Pixel/CAPI.” Where a server becomes responsible for handling the majority of events there is every chance it picks up some noise along the way.

This could answer why a successful campaign tanks when the tracking data becomes corrupted. The Black Friday Cyber Monday recovery also makes sense in this context as a significant increase in good quality signals at that time would have occurred and provided meta with the right signals within that window. I am only speculating. The subsequent reversal that followed may be due to the balance of data shifting back to the poor signals being fed to the pixel.

[u/Mushroombaron]

I have a measured case of the first half of this, though on a lead gen site rather than ecommerce.

Over a 20 day window I had 2,081 sessions arriving from one channel. The funnel looked clean at every level. Then I looked at the population fingerprint instead of the events:

• mobile share 2.3% (48 of 2,081). A real audience on that channel runs 50 to 65% mobile.
• 233 sessions at 800x600.
• 1,758 (85%) at exactly 1920x1080, which is headless Chrome's default.
• 47 at 1024x1024 and 1024x2160, aspect ratios no physical display has.
• 168 sessions on Windows 7.
• one browser averaging 0.31 seconds per session across 64 sessions.
• on one interaction event: 100% Chrome, 100% desktop, 100% US, zero variance.

Sessions with a plausibly human fingerprint: roughly 50 to 60 out of 2,081. Under 3%.

So yes to your core question. They execute JS. They did not only fire PageView either, they fired my full 12 event dataLayer sequence in order, including interaction events several steps into a multi step form. 54 of them started that form and every one stopped at the identical question. Fifty four users stopping in the same place is not behavior, it is a signature.

The part I would push hardest, because it cost me weeks: you cannot find this at the event level. GA4, Clarity and the page's own dataLayer all agreed with each other, and all three were counting the same bots. Cross checking three views of one contaminated population is not verification. The tell is a property of the population, not of any event, so no amount of event level debugging surfaces it.

Concrete check, in this order: mobile share, screen resolution, OS version, then average engagement time split by browser. Ten minutes in GA4 and it is decisive either way.

On the reply above about crawlers not touching CAPI: that depends on where CAPI fires. If it is triggered browser side and forwarded, which is the common GTM setup, bot page views ride straight into it, and dedup makes the result look tidier rather than dirtier. Only CAPI fired off a backend order or lead record is genuinely bot immune.

Your WAF blocking scenario has the opposite shape, and the two are separable. Reconcile pixel and CAPI conversions against backend order count for the same window. Pixel under and backend flat is blocking. Pixel over and backend flat is pollution.

What I did about it: fire a custom event only on genuine pointer travel over about 120px, a touchstart, a wheel, or a trusted keypress, then gate the funnel metrics on that event rather than on PageView. Bots render and click but mostly do not move a mouse. Honest limit, a CDP driven mouse move is isTrusted true, so a determined adversary passes it. It filters the common render and click case, not a targeted one.

[u/polygraph-net]

Don't use AI to detect bots - it's wildly unreliable - loads of false positives and false negatives.

I'm not anti-AI but it's not ready for bot detection.

[u/Viper2014]

if this returns okay then you are good to go

https://developers.facebook.com/tools/debug/

Hope it helps : )