Meta Ads Overspend at Night? Use Tracking Data to Prove It

Meta Ads budget behavior is only the beginning

Meta's budget documentation describes daily budgets as average daily spend over a week, and Meta may spend more on some days and less on others. That matters because not every daily overspend is automatically a platform failure.

But that does not end the investigation.

If a campaign spends heavily during a strange hour, and the business does not receive proportional purchases, leads, or revenue, you still need to inspect delivery quality, traffic quality, and conversion quality.

That requires data Meta does not fully own:

This is why UTM tracking, Facebook Ads UTM tracking, click ID capture, and server-side event logs are not just reporting conveniences. They become your audit trail when something expensive happens.

If your tracking only lives in GA4 summaries or last-click CRM fields, you may not be able to reconstruct the incident.

The first question: was this just bot traffic?

The initial suspicion was simple: maybe a bot or crawler generated traffic after 10PM and caused Meta to spend into junk behavior.

That was worth testing, but the data did not support a simplistic “foreign bot dump” story.

For the 10PM MST peak hour, the audit found:

The traffic was also not concentrated in a few repeat IPs. The busiest IP had only 24 events, and the top 100 IPs represented only 8.83% of the hour.

So the stronger story was not “one obvious bot attacked us.”

The stronger story was: Meta delivered a large amount of broad, mostly US, Meta-signal traffic late at night, but the conversion quality did not justify the spend spike.

The second question: did conversions rise with spend?

The spend overlay made the problem much clearer.

In the 10PM to midnight MST window, the site saw approximately:

• $23,219.63 in screenshot-digitized Meta spend.
• 6,307 tracked events.
• 5,984 Meta-signal events.
• 6 purchases.
• $582 in tracked purchase value.
• 0.0951% event-to-purchase rate.

Before 10PM MST, the event-to-purchase rate was 0.4131%.

That means the suspect window converted at roughly a quarter of the pre-10PM rate by raw tracked events.

The 11PM MST hour was even more concerning: approximately $18,959 in spend, 1,571 tracked events, and 0 purchases.

Important caveat: the spend values were digitized from a Meta screenshot, so the exact finance claim should be replaced by an official hourly Meta export before sending the final refund request. But the tracking pattern was strong enough to justify escalation and a platform-side delivery review.

You cannot collect the evidence after the money is gone

A tracking audit is only useful if the data was captured at the time of the visit.

For Meta Ads overspend, Facebook Ads attribution issues, refund requests, bot traffic investigations, and conversion quality audits, you want these fields available in a queryable place:

This is why a tool like UTMSimple, or a UTM Grabber-style first-party tracking setup, becomes more than a form-field utility.

It becomes the logbook for paid media truth.

If you already care about Facebook Ads UTM tracking, common tracking problems, AI bot traffic and conversion tracking, or Meta Event Match Quality, this is the next layer: can you defend your spend when the platform behaves strangely?

The tracking system made the data possible. Codex made the workflow fast.

The session behind this article used a practical AI-assisted workflow:

1. Confirm AWS CLI access with the handl profile.
2. Query Amazon Athena against first-party tracking events stored in a data lake.
3. Aggregate hourly traffic, Meta-signal traffic, OS groups, user agents, IPs, visitors, events, purchases, and purchase value.
4. Pull Athena result files from S3.
5. Generate charts locally.
6. Digitize the Meta spend screenshot carefully and label it as approximate.
7. Rebucket website events into the ad screenshot timezone.
8. Pull IP geography and hosting/proxy flags for the suspect hour.
9. Create a written evidence memo with charts and next-step language for the platform rep.

Normally, a senior analyst might spend hours moving between Ads Manager, Athena, spreadsheets, scripts, IP tools, screenshots, and report writing.

With Codex coordinating the local shell, AWS CLI, files, Python charting, and report generation, the useful version was done in about 30 minutes.

This is where MCP-style connected tools matter. MCP is designed to let AI applications connect to external systems such as files, databases, tools, and workflows. Codex also has tooling for shell, MCP/connectors, files, and local execution. That means the analyst no longer has to manually copy every number from system to system.

But AI did not replace the tracking system.

It amplified it.

If the click IDs, UTMs, event names, ad IDs, timestamps, IPs, user agents, and purchase data were never captured, Codex would have nothing reliable to query.

Use this checklist when Meta Ads spend looks wrong

1. Define the exact suspect window. Use the ad account timezone and the website/server timezone. Convert both.
2. Export hourly Meta spend. If you only have a screenshot, label the spend as approximate until you get the export.
3. Pull first-party events. Include all events, not only conversions, so you can see traffic volume and quality.
4. Mark Meta-signal sessions. Use fbclid, _fbc, _fbp, UTM source/medium, referrer, and ad IDs.
5. Calculate conversion quality. Compare event-to-purchase, event-to-lead, revenue per spend, or qualified lead rate before and during the suspect window.
6. Check IP and user-agent concentration. A true bot issue often has concentration, strange user agents, hosting ranges, or repeated patterns.
7. Check country and region. Do not assume bad traffic is foreign. Prove it.
8. Break down by ad ID and ad set. A refund request is stronger when it names the affected assets.
9. Write the ask carefully. Request a pacing review, delivery-quality review, invalid traffic review, and refund/credit review. Avoid overstating what the data does not prove.
10. Fix tracking gaps afterward. If important fields were missing, improve the tracking system before the next incident.

The uncomfortable lesson is simple:

You do not need perfect tracking every day, until the day you suddenly need it very badly.