Why Your Custom Conversion Is Lower Than Your Standard Event (And Your CRM Agrees With the Standard Event)

The usual complaint about custom conversions is that they report too much, or nothing at all. This is the other one, and it gets written about far less: the custom conversion consistently comes in under the standard event, the standard event lines up almost exactly with the leads in your CRM, and so the number you trust and the number you optimise towards are not the same number. There is a specific, boring mechanic behind most cases of this.

A custom conversion is a filter, not an event

Worth restating because the whole problem follows from it. A custom conversion does not create any new data. It sits on top of events that are already arriving and selects a subset of them according to a rule you defined.

That means a custom conversion can only ever be equal to or smaller than the event stream it is filtering. If it is smaller, the rule is excluding something. The question is never "why is the data missing". It is always "what is my rule failing to match".

Most custom conversions are defined on a URL rule, because that is the path of least resistance: the thank-you page has a distinctive address, so you write a rule that matches it. This works perfectly, right up until some of your events stop having a URL.

Server events frequently carry no URL

Here is the collision. A browser event is fired by a page, and the page knows its own address, so the event naturally carries it. A server event is constructed by your server or a third-party integration, and the URL is a field someone has to populate deliberately.

In the Conversions API that field is event_source_url. It is not automatically present. Plenty of integrations, particularly ones that fire from a backend workflow, a form processor or a CRM webhook, send a perfectly valid event with user data, event name and value, and no source URL at all, because at the moment the event is constructed there is no page involved.

Now re-read what a URL-rule custom conversion does. It matches events whose URL contains your thank-you path. An event with no URL does not contain your thank-you path. It is not matched, and it is not counted.

The standard event still counts it, because the standard event does not care about the URL. So you end up with exactly the pattern described above: the standard event is complete, the CRM agrees with it, and the custom conversion is quietly short by however many of your events came from the server side.

Why this is worse than it looks

If the custom conversion were only a reporting line, this would be an annoyance. The problem is that people set custom conversions as the optimisation goal on the ad set, because it is more specific than the standard event and feels more precise.

When that happens, the undercount stops being cosmetic. Delivery is now being optimised against a partial view of who converts, and the part that is missing is not random. It is systematically whichever conversions happened to be reported server-side, which may correlate with device, browser, consent state or funnel path. You are not optimising towards a smaller sample of the same people. You are optimising towards a biased one.

It also means your reported cost per conversion is inflated against reality, which affects every budget and bidding decision made on top of it. If you are setting cost caps against a number that is structurally low, see bidding with incomplete conversion data for how far that drifts.

Confirming it in about ten minutes

1. Open the standard event in Events Manager and look at how events are arriving. You want the split between browser and server for that event. If it is a hundred per cent browser, this is not your problem and you should look elsewhere.
2. Compare the gap to the server share. If your custom conversion is short by roughly the proportion of events arriving server-side, you have almost certainly found it. The numbers rarely match to the unit, but the shape is unmistakable.
3. Inspect a recent server event. Look at the parameters actually received. If event_source_url is absent or empty, that is the confirmation.
4. Check the rule itself for over-specificity. A rule matching an exact URL will also miss query strings, trailing slashes and locale prefixes. A rule matching a path fragment is more forgiving.

This is a different question from Events Manager and Ads Manager disagreeing on totals, which has its own set of legitimate causes; that comparison is covered separately. Here both tools agree on the standard event. It is the custom conversion that is the odd one out.

The deduplication wrinkle

There is a second-order version of this that is harder to spot.

If you are sending the same conversion from both the browser and the server, deduplication is supposed to collapse them into one. That is correct behaviour and you want it. But the surviving event is not guaranteed to be the browser one, and if the server copy is the one that is kept, it carries the server copy's parameters, which may not include a source URL.

The result is a URL-rule custom conversion that undercounts intermittently rather than consistently, which sends people looking for a pattern in their campaigns that does not exist. If your gap is erratic rather than proportional, this is worth checking. The mechanics of deduplication are covered in fixing duplicate pixel and CAPI events.

Two fixes, and which one to prefer

Populate the source URL on server events. If the integration allows it, set event_source_url to the page the user was on when the conversion happened. This keeps your existing rule working and is the smaller change. It is also generally good practice, since that parameter does more than satisfy your custom conversion.

Or stop filtering on the URL. The more robust option is to define the custom conversion on something every copy of the event carries regardless of origin: the event name plus a parameter you control, such as a content category, a lead type or a value threshold. A rule built on a deliberate parameter does not care whether the event came from a page or a server.

The second is the better answer if you are going to optimise towards it. URL rules are convenient precisely because they require no cooperation from anyone, and that is also why they break: nobody updating the site knows that a reporting rule depends on the address of a page.

What the gap looks like with numbers on it

An example makes the diagnostic sharper, because the thing you are looking for is a ratio rather than a quantity.

Say your standard Lead event records 400 in a month, and your CRM agrees: 400 real enquiries, give or take a handful. The custom conversion built on the thank-you page URL reports 250. The missing 150 is not random breakage, it is 37.5 per cent of the total.

Now look at how those 400 events arrived. If roughly 37 per cent of them came from the server, you have your answer without inspecting a single parameter. The proportion is the fingerprint. Browser-side events carry the URL and match the rule; server-side ones do not and are dropped by it.

What makes this worth doing as arithmetic rather than intuition is that it also rules the explanation out. If only five per cent of events arrive server-side and your custom conversion is short by a third, this is not your problem and you should stop looking at it. Most of the time spent on discrepancies is spent on confirming the wrong theory, and a ratio check takes two minutes.

After you fix it

Two things to expect once the rule matches properly, both of which look alarming if you are not ready for them.

The custom conversion will step up to meet the standard event, and that jump lands on the day you made the change rather than being spread backwards. Anyone reading a month-on-month comparison will see a sudden improvement that nothing in the campaigns explains. Note the date somewhere visible, because in six weeks nobody will remember why the line moved.

Your reported cost per conversion will also drop, for the same reason, and it was never as high as the dashboard claimed. If you had cost caps or target CPA values set against the inflated figure, they are now calibrated against a number that no longer exists, and delivery will change accordingly. Revisit those at the same time rather than discovering the interaction a week later.

The general lesson

Any rule that infers meaning from an incidental property of your site is borrowing against a change nobody will tell you about. URL rules are the most common example, but the family is bigger: rules that depend on a page title, on a referrer, on a parameter added by a plugin.

They do not fail loudly. The custom conversion does not error, it just selects fewer events, and the number keeps being reported with complete confidence. The only way you find out is by comparing it against something you independently trust, which in this case was a CRM. That comparison is the habit worth keeping, and if you only do it when something feels wrong, you will be doing it weeks late.