Hi all, We're pushing to get proper tracking sorted and start running some paid ads online. We're aiming to create low friction landing pages so we wanted to display a button that pops up an embedded Request form. First roadblock 🚫 was that we can only use the button once on the page, which is a problem because you want multiple CTA. So we just used the button at the top of the page and displayed the complete form at the bottom of the page. Second roadblock 🚫 we just found is that tracking doesn't work on the embedded Jobber forms. What is everyone else doing to make their landing pages work and track form submissions etc.??Currently I see the only option as opening the form into a new page, which adds a ton of friction but we can't just give up tracking... 🤷♂️

You've diagnosed this correctly. The iframe security boundary is the real issue — it's not a configuration problem you can work around on your end.The "use your own form + Zapier" path is actually more powerful than it might seem as a workaround. A native form on your landing page gives you full GA4 tracking, GTM event firing, clean attribution per campaign — everything the embedded Jobber form can't provide.Worth knowing: Jobber's native Zapier connector includes a Create Client action, but you can't map a custom lead source. There is also a Create Request action however it only creates a basic Request; you can't map all of the details from your custom form. There's a Jobber-specific integration in the app marketplace called Adhesion Connect that does support both of these things. It supports Create Request (with full form submission mapping into the Request details) and Create Client with custom fields and custom lead source, so you can map UTM parameters and campaign data directly into the request record in Jobber along with any additional information your form captures.The lead source tracking you were trying to solve for with GA4 can actually live inside Jobber too, not just in your analytics platform. It's a better setup for paid campaigns than the embedded form would ever have been — you just have to build it that way intentionally.

Embedded forms + G4A/Google Analytics = Broken? | Home Service Community

8 Replies

Esther
Contributor 3
25 days ago
You’re basically dealing with the friction vs tracking tradeoff most people run into with embedded forms.
The problem usually isn’t GA4 itself- embedded/iframe forms often don’t pass submission events back properly, so conversions disappear unless you set up custom GTM events or a thank-you redirect.
Personally, I’d avoid sending users to a separate page if possible because every extra click tends to hurt conversions.
What I’ve seen work best:
Keep the embedded form for lower friction
Track via Google Tag Manager custom events
Or redirect to a thank-you page after submission so GA4 has a clean conversion event
And agreed on the single CTA limitation — that’s pretty restrictive for actual landing page behavior since people convert at different scroll points.
- Conrad
  Contributor 4
  25 days ago
  Thank you Esther, that helps explain it. Really appreciate your reply.
  At first look I'm leaning towards a thank you page - I see this is a simple option in Jobber settings. 👍 This page doesn't need to be unique to each request form?
  Is there any reason you'd opt for Google Tag Manager, will that give more flexibility in the long term?
  I should add that we're planning on running a number of different campaigns year round - would that change which option you'd use?
  - Esther
    Contributor 3
    25 days ago
    Glad it helped, Conrad.
    You definitely don’t need a unique thank-you page for every form if you’re just trying to track overall conversions. One thank-you page can work perfectly fine.
    That said, if you’re planning to run multiple campaigns year-round, I’d probably lean toward GTM long-term because it gives you much more flexibility once the campaigns start scaling.
    The big advantage is that you can track:
    Which campaign generated the lead
    button clicks
    scroll depth
    abandoned forms
    specific landing page performance
    different conversion actions
    
    A single thank-you page is the fastest/simple setup, but GTM gives you cleaner attribution and better optimization data over time, especially once ad spend increases.
    Honestly, most businesses don’t realize the issue isn’t getting traffic… It’s not knowing which traffic is actually converting profitably.
    You could even start with the thank-you page now for simplicity, then layer GTM in later once campaign/data volume grows.
- Conrad
  Contributor 4
  25 days ago
  Also just noticed this from the Google AI Overview:
  If you have the Jobber request form directly embedded on your website using an iframe code, this redirect will take place within the iframe box itself.
  Will that situation still allow for tracking on the new page load..? Or is this where you'd opt for GTM as the more robust option?
Randy_Warner
Contributor 4
12 days ago
You've diagnosed this correctly. The iframe security boundary is the real issue — it's not a configuration problem you can work around on your end.
The "use your own form + Zapier" path is actually more powerful than it might seem as a workaround. A native form on your landing page gives you full GA4 tracking, GTM event firing, clean attribution per campaign — everything the embedded Jobber form can't provide.
Worth knowing: Jobber's native Zapier connector includes a Create Client action, but you can't map a custom lead source. There is also a Create Request action however it only creates a basic Request; you can't map all of the details from your custom form. There's a Jobber-specific integration in the app marketplace called Adhesion Connect that does support both of these things. It supports Create Request (with full form submission mapping into the Request details) and Create Client with custom fields and custom lead source, so you can map UTM parameters and campaign data directly into the request record in Jobber along with any additional information your form captures.
The lead source tracking you were trying to solve for with GA4 can actually live inside Jobber too, not just in your analytics platform. It's a better setup for paid campaigns than the embedded form would ever have been — you just have to build it that way intentionally.
- Conrad
  Contributor 4
  8 days ago
  Thanks for the tip on Adhesion Connect. I see the benefits to a native form so we'll work on building this out.
  We do have the GA4 tag added to our request forms within Jobber, so I'd have expected that to pick up the iframe events but I don't know. My head is in a spin after trying to figure this out.
Esther
Contributor 3
25 days ago
Yes, that’s exactly where iframe tracking starts getting messy.
If the thank-you page loads inside the iframe, GA4 may not reliably treat it as a proper pageview/conversion on the parent site, depending on how the embed is handled. That’s why iframe-based forms are notorious for messy attribution.
In that situation, GTM usually becomes the more robust option because you can fire custom events based on interactions instead of relying purely on page loads/redirects.
Honestly, this is one of those setups where “simple” can become limiting pretty quickly once you start scaling campaigns and trying to optimize based on real data.
If it were me, I’d probably:
Use the thank-you redirect initially if it tracks cleanly enough
But plan for GTM/event tracking as the long-term setup once campaigns are running consistently
The important thing is making sure the tracking foundation is reliable before ad spend ramps up; otherwise, you end up optimizing campaigns using incomplete data.
- Conrad
  Contributor 4
  13 days ago
  I thought we had this solved but just keep running into roadblocks... 😅
  Never mind tracking the Thank You page load, Jobber doesn't allow that when using embedded forms:
  Researching it more it looks like any kind of tracking won't be able to "see" whats happening within the iframe due to browser security boundaries. Essentially tracking is broken because of the way the iframe is setup on the Jobber side:
  _gl linker injection - ignored by Jobber
  client_id param injection - ignored by Jobber
  postMessage listener - Jobber doesn't send one
  
  The root cause is a browser security boundary. Jobber's iframe runs in a third-party context, generates it's own throwaway GA client ID, and provides no mechanism to override it or signal submission to the parent page.
  So it seems like the options are to redirect to the standalone request form/Client Hub. Or use our own form and either create requests manually or use something like Zapier? But it seems absolutely insane that a complete job management software like Jobber wouldn't allow analytics tracking. 🤷‍♂️ Not at all usable for paid ad campaigns because they would be optimised on incomplete data which will directly affect bidding performance.

Forum Discussion

Embedded forms + G4A/Google Analytics = Broken?