That’s a great question about capturing gclid
for offline conversions with Mautic and Square Appointments.
The approach ledzee mentioned capturing the gclid
in a cookie and passing it to a Mautic hidden form field is a common and effective method, especially for form submissions.
To address your goal of capturing the gclid
right on the first page load and linking it to the Mautic anonymous visitor record, you’re on the right track with the anonymous record creation.
To grab the gclid
reliably on the first page load, you can use a bit of JavaScript to read the URL parameter and then use the Mautic tracking script’s API or a custom pixel push to associate that value with the current anonymous profile.
This is more robust than relying on a cookie that might expire or be blocked.
For your anonymous record to become a known contact when an email is provided via a form, Mautic generally handles this by merging the anonymous tracking data (including the gclid
you’ve pushed) with the new contact record created upon form submission, provided the form submit is tracked correctly.
The Zapier push from Square would ideally be updating an existing Mautic contact record, but if the email is a unique identifier, Mautic will match the incoming data to the previously anonymous contact.
While the cookie-and-form-field method works, for a truly robust and scalable setup that integrates Mautic, Square, and Google Ads for offline conversions, especially with an iframe involved, a server-side tracking approach using APIs and a dedicated tracking platform is often superior.
Instead of relying solely on client-side browser behavior (which can be blocked or lost), you would leverage the Mautic API, the Square API, and the Google Ads API, orchestrated by a system like Google Tag Manager (GTM) with a server-side component such as Stape or Google Cloud Platform.
Here is why this is a better solution:
When a visitor lands on your page, GTM captures the $gclid$ and immediately sends a Standard Event like page_view
to your server-side tracking environment (Stape or GCP).
This environment then uses the Mautic API to update the anonymous contact’s record with the gclid
.
When the booking happens in Square’s iframe, you may not have direct access to the form submission, but after the booking, Square’s API can send a webhook or Zapier can push the booking confirmation data (including the email and a unique ID) to your server.
This unique ID and email are then used to query the Mautic API to retrieve the associated gclid
and other necessary data.
Once you have the gclid
and the conversion value, your server-side system can then use the Google Ads API to send the offline conversion, which is far more reliable and secure than client-side methods.
This structure provides more resilience against browser privacy restrictions, maintains a single source of truth for your data on the server, and gives you complete control over when and how the conversion is sent to Google Ads, allowing you to bypass the limitations of the iframe and Square’s lack of direct conversion tracking.