The Reliable Way to Fire a Google Ads Conversion (Thank-You Page Beacon)

The Conversion That Fired on Desktop and Vanished on Mobile

We built a download funnel for an Australian lead-gen site: a visitor submits a form, we capture the lead in the CRM, send the email, hand them the file instantly, and fire the Google Ads conversion. On every desktop test it worked perfectly. The file downloaded, the conversion landed, the bidding had clean data to learn from.

Then we checked the same funnel on a phone. The form submitted. The lead was captured. And nothing else happened. No file. No conversion. No error in the console that a marketer would ever see. Just a visitor staring at a form that looked like it had done nothing.

This is the worst class of conversion bug, because it does not announce itself. A blocked download or a missing conversion event never throws a red error in Google Ads. The conversions simply arrive at a lower rate than reality, and your Smart Bidding quietly trains itself on a lie. If half your traffic is mobile and mobile silently drops the event, you are telling Google your campaigns are half as effective as they actually are.

The fix turned out to be small, but it changed how we think about where a conversion should ever be fired.

Why window.open() Dies After an await

The original funnel did something that looks completely reasonable. After the form submitted, the code awaited the CRM capture and the email send, and then called window.open() to trigger the file download in a new tab.

The problem is the await. Mobile browsers — Safari on iOS especially — guard window.open() with the popup blocker, and the rule they enforce is user activation. A new window is only allowed to open as the direct result of a user gesture, like a tap. When you call window.open() synchronously inside a click handler, the browser sees an unbroken chain from the tap to the open, and allows it.

But the moment you await something — a fetch to your CRM, an email API call, anything asynchronous — that direct chain is broken. By the time the promise resolves and your code reaches window.open(), the browser no longer considers the call user-initiated. It treats it as a script trying to spawn a window on its own, and silently blocks it. Desktop browsers are far more lenient, which is exactly why the bug sails through your desktop test and only bites real mobile users.

So the download never opened, and because the conversion was being fired in that same fragile post-await block, it never fired either. One broken assumption took out two things at once.

The Fix: Stop Opening Windows, Start Navigating

The instinct is to fight the popup blocker — move the window.open() earlier, open a blank tab first and fill it later, or chase some workaround. Do not. Every one of those is brittle and breaks again on the next browser update.

The durable fix is to stop opening a new window after the await entirely. You have two clean options. The first is to redirect the current page once the work is done, because a same-page navigation does not need user activation the way a popup does. The second — and the one we shipped — is to send the user to a dedicated thank-you page that handles the download and the conversion itself.

That second option is more than a workaround. It moves the conversion event off the fragile JavaScript callback chain and onto something far more reliable: a real page load at a real URL.

The Dedicated Thank-You Page Is the Most Reliable Beacon

Here is the principle worth keeping. A conversion fired inside a JavaScript callback depends on that callback completing correctly — no awaits breaking the chain, no exceptions swallowed, no race condition between the redirect and the tag. A conversion fired on the load of a dedicated thank-you page depends on one thing only: the visitor arriving at that URL.

A page-load beacon on a dedicated thank-you URL fires once, on a genuine navigation, with no dependency on the success of an async chain. The visitor either reached /thank-you or they did not, and if they did, the conversion fires. That is a far smaller surface area for failure than a tag buried three callbacks deep in a form handler.

This is not a theory we recommend and do not practise. It is exactly how Jordan James Media's own site tracks Google Ads conversions. Our contact form and our landing page both route to dedicated thank-you pages, and the conversion tag fires on those pages loading — not inside the submit handler. The form's only job is to get the visitor to the thank-you URL. The thank-you page's only job is to confirm success and fire the beacon. Each piece does one thing, and the thing that matters most happens on a navigation that is hard to break.

Trigger the Download From the Same Page Load

Once you have a dedicated thank-you page, the download problem solves itself. You no longer need window.open() at all, because you are already on a fresh page that the user navigated to deliberately.

Trigger the file download from the thank-you page's own load — set the document location to the file, or render a hidden anchor with the download attribute and click it on mount. Because this happens on a page the user actively navigated to, there is no popup blocker to fight. The same page load that fires your conversion beacon also hands over the file. One navigation, two outcomes, both reliable.

It also gives the visitor a real destination instead of a form that appears to have done nothing. They see a confirmation, the file starts downloading, and you can put your next call to action right there on the page. A dead-end submit handler gives you none of that.

Verify the Beacon in a Real Mobile Browser

The last discipline is the one that catches the bugs nobody plans for: never trust that a tag "should" fire. Confirm it fired, in the environment where it broke.

When we shipped the thank-you page, we did not call it done because the code looked correct. We loaded the live thank-you URL in a real browser, watched the network tab, and confirmed the conversion request to Google actually went out before declaring victory. For a bug that only appeared on mobile, the verification has to happen on mobile or in a mobile emulation profile — the exact place the original window.open() failed.

This is the same lesson behind almost every silent tracking failure: a misrouted redirect, a blocked popup, a Content Security Policy that quietly strips the tag's request. None of them throw an error a marketer would notice. The only defence is to watch the actual network request leave the actual browser, not to assume the tag did its job because the page returned a 200.

The Pattern, Distilled

If you run Google Ads against any kind of gated download or lead magnet, here is the defensive pattern in one breath. Centralise the conversion event on a dedicated thank-you URL and fire it on page load. Trigger the file download from that same page load. Never call window.open() after an await — redirect or navigate instead. And always confirm the beacon fires in a live mobile browser, not just on your desktop.

Conversion tracking fails quietly by nature. The events do not error; they just stop arriving, and your bidding degrades on data that understates your real performance. Moving the event onto a real navigation, on a page that exists only to confirm success, is the single highest-leverage change you can make to stop the leak.

What's Next

If your conversions look softer than your actual lead volume, the trigger is the first place to look — and a dedicated thank-you page is usually the fix. See our conversion rate optimization service for how we rebuild leaking funnels, our Google Ads management service for the campaign side, and how a www redirect broke $330K worth of Google Ads conversions for the redirect-shaped cousin of this same silent-failure problem.