Detection: Upper-funnel campaign in a purchase-driven account

Key: wrong_objective Severity: High Confidence: 75–90%

What this detection looks for

We flag a campaign as wrong-objective when all of these are true:

1. The campaign is active
2. Its objective is one of the upper-funnel objectives: Traffic (OUTCOME_TRAFFIC / LINK_CLICKS), Engagement (OUTCOME_ENGAGEMENT / POST_ENGAGEMENT), Awareness (OUTCOME_AWARENESS / BRAND_AWARENESS), Reach, or Video Views
3. The campaign has either ≥ $500 of spend in the audit date range OR has produced at least 1 purchase
4. Elsewhere in the same account, a sales-objective campaign is producing purchases — proving the account's real goal is conversions, not clicks

Why this matters

Meta's delivery system optimizes for the objective the campaign is set to. A Traffic campaign asks Meta to find users likely to click. A Sales campaign asks Meta to find users likely to buy. These are different audiences. The Traffic audience is larger, cheaper to reach, and converts worse.

When you run a Traffic campaign in an account that exists to sell things, you are paying Meta to find people who click but rarely buy. The spend is not zero-value — some incidental purchases do happen — but the cost per purchase is multiples higher than a Sales-objective sibling would deliver.

The historical justification for Traffic objectives (cheap clicks → pixel data → better optimization later) is largely obsolete in 2026 since Meta's event-based optimization no longer benefits meaningfully from extra raw click volume.

How we calculate confidence

How we calculate the estimated monthly cost

We treat 75% of the campaign's spend as misaligned with the account's actual purchase goal, and project it to a 30-day month at the same daily run rate.

monthly_recoverable = (campaign_spend × 0.75) × (30 / days_in_range)

We do not take 100% because some incidental purchases do flow through these campaigns and that value should not be claimed as recoverable.

What would change our mind

This finding can be a false positive in a small number of cases:

• The campaign is a deliberate top-of-funnel layer in a multi-stage account. Some account structures use a Traffic campaign as a prospecting top, retargeting site visitors via a separate Sales campaign. This works, but only when the Traffic CPC is meaningfully cheaper than what a Sales objective would deliver — and only when retargeting actually closes the loop. Verify both before excluding this finding.
• The campaign is testing creative. Some teams use a low-cost Traffic campaign to A/B test thumbnails or hooks before promoting winners into Sales campaigns. If the campaign is small (under ~$500/mo), check intent.
• The brand is run on awareness for valid reasons. A new brand with no conversion event volume may legitimately need Awareness or Video Views campaigns first. We require account-level purchase signal before flagging, but new brands can still trip this.

How to fix it

1. Note what the campaign is currently optimizing for and what its actual conversion volume is.
2. Duplicate the campaign with a Sales objective (or Leads if you generate leads). Use the same creative and audience to start.
3. Run both for 7–10 days with equivalent budget so the new campaign exits learning.
4. Compare cost per purchase, not cost per click, between the two.
5. Pause the Traffic campaign when the Sales campaign produces a lower cost-per-purchase, or when the Traffic campaign's incremental purchases stop covering its incremental spend.

What we look at to make this detection

• objective and effective_status on each campaign
• Purchase conversions per campaign, summed across the audit date range (offsite_conversion.fb_pixel_purchase and offsite_conversion.custom.<your-purchase-event>)
• spend insights metric per campaign, summed across the audit date range
• Whether at least one sales-objective campaign in the account produced purchases in the date range (this is the account-level signal that the account exists to sell things)

Source

This methodology page is generated from apps/api/app/services/detections/wrong_objective.py. The detection code is open for inspection. We do not have hidden rules.