One of the more frustrating moments in our server-side GTM + Meta Conversions API implementation came after everything appeared to be working.

The setup seemed perfect:
  • Events were firing and requests returned 200 OK.
  • Deduplication was functioning correctly.
  • User data was present and match quality had improved.

And yet… Meta still refused to optimize. No purchases showed up as usable conversion events, campaigns stayed stuck in “Learning,” and diagnostics remained vague. Nothing was technically broken, but the results weren’t there.

The issue turned out to be deceptively simple: We were sending the wrong event name.

The Setup: Business Events, Not Platform Events

From the outset, we made a deliberate design decision:

“The application should emit business events, not advertising platform events.”

That’s why our WooCommerce site emits jw_purchase instead of the standard Purchase. We did this to keep the data unambiguous and keep vendor logic out of our application code. This is a good design decision—and it wasn’t the mistake.

The Symptom: Meta Receives Events but Won’t Optimize

Here is what we saw in the dashboard:

  • Events appear in Meta Events Manager.
  • Server-side requests succeed.
  • event_id deduplication works.
  • But: Meta treats the event like a custom event, not a core signal.

This usually presents as: “This event is not eligible for optimization.”

The Key Insight: Optimization is Hard-Coded

Meta’s Conversions API supports any event name for tracking, but optimization and Value-Based Bidding are hard-coded to a small set of standard events (like Purchase).

If your event name is jw_purchase, Meta will ingest the data, but it won’t automatically connect it to the “Purchase” objective in your ad sets. To Meta, it’s just a “custom event” with no inherent meaning.

The Solution: Mapping via Custom Conversions

Instead of rewriting our server-side logic or changing our code, we solved this directly within **Meta Events Manager**. We had to explicitly tell Meta that our custom event represents a standard business outcome.

We created a Custom Conversion with the following logic:

Step Action
1. Event Selection Select jw_purchase as the data source.
2. Standard Event Mapping Choose “Purchase” as the Standard Event for optimization.
3. Value Tracking Toggle “Use Value” so Meta picks up the price/currency sent via sGTM.

By doing this, we bridged the gap between our internal naming convention (jw_purchase) and Meta’s optimization engine without touching a single line of code in GTM.

The Bigger Lesson

This experience highlights a critical truth about modern tracking: Platforms are rigid, but your data doesn’t have to be.

  • Your **application** should use names that make sense for your business.
  • Your **tracking platform** (Meta) requires names that make sense for its algorithm.

Whether you map the event name in sGTM or through a Custom Conversion in Meta, the goal is the same: translation. Once Meta understands that jw_purchase is a Purchase, the optimization engine finally has the fuel it needs.