Why Embedded Forms and iFrames Lose UTM and Click IDs

You run ads with clean tags. Someone lands on your WordPress page, fills the HubSpot or Typeform box that sits in the middle of the design, and a lead arrives. Name and email are there. Source is blank. Every fill looks like Direct even when you know the click came from Google or Meta.

That blank row is not a broken pixel. It is the embed. The form looks like part of your site. The browser still treats it as another website. Your UTM values and click IDs sit on your domain. The form submit happens somewhere else.

This post explains why iframe form UTM tracking fails on WordPress, what free LeadSource 1.0.8 can see on a native form, and what it cannot see when the fill never hits WordPress. It does not invent an iframe bridge. It does not claim a 90 day cookie or a first-plus-last stamp.

Why the embed looks like your site and still loses the tags

An iframe is a window inside your page that loads another page. Visitors see one layout. The browser sees two origins. Your page is yoursite.example. The form may be forms.hubspot.com, form.typeform.com, calendly.com, or a Zoho embed URL.

The tagged landing URL lives on your origin. Query keys like utm_source and gclid belong to that address bar and to scripts that run on your page. The iframe document has its own address, its own cookies, and its own scripts. Your page script cannot reach into that frame to fill hidden fields. The frame script cannot read your cookies or your full URL.

So the visitor can arrive from a paid click, browse your services, and still submit a form that never saw the tags. The lead reaches the SaaS inbox. Your WordPress attribution row never fires, because WordPress never processed the submit.

This pattern shows up with HubSpot iframe embeds, Typeform, Calendly, Google Forms, Jotform iframes, and similar tools. Lazy-loaded embeds make the gap worse. The form paints late, after the visitor has already moved past the tagged first paint.

The origin wall (URL, cookies, referrer)

Three browser rules stack on top of each other.

First is the same-origin policy. JavaScript on your site cannot read or write the iframe’s DOM when the host differs. You cannot quietly copy utm_campaign into a field inside someone else’s form.

Second is cookie isolation. A first-party session cookie set on your domain is not sent with requests to forms.hubspot.com. Safari, Firefox, and Chromium keep tightening third-party cookie access. You cannot expect the SaaS form to inherit your LeadSource cookie.

Third is referrer loss. When the iframe submits, the form platform often sees its own embed URL as the context, not your tagged landing page. Cross-origin referrer policy can also strip path and query, so even a partial referrer may drop the UTM keys.

Fixing only one of those three still leaves the other two. That is why a one-line “append the tags to the iframe src” tip feels clever on a quiet Tuesday and fails after the next platform change.

What free LeadSource 1.0.8 sees on a native WordPress form

The free LeadSource plugin is built for forms that submit through WordPress. Native hooks in 1.0.8 are Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Formidable Forms, Fluent Forms, Elementor Pro Forms, Everest Forms, and Forminator. You do not add shortcodes or maintain hidden UTM fields for those builders.

Capture runs in the visitor’s browser on your pages. A small vanilla script reads the URL on load and stores traffic source data in a first-party session cookie. On a successful native submit, the form hook attaches that session data to a LeadSource row in your WordPress dashboard. Referrer has a server-side fallback. Caching does not block the browser capture, because the read happens on the visitor’s machine.

What it stores when the tags are present includes utm_source, utm_medium, utm_campaign, utm_term, utm_content, and the click IDs named in today’s readme (gclid, fbclid, msclkid, li_fat_id, ttclid). The listing does not name gbraid or wbraid. Landing page is the first page of the session. Attribution is same session only. The cookie ends when the browser closes. It is not first-plus-last touch and not a 90 day window.

The overview of that flow is in How to Track Lead Sources in WordPress Forms. Same-session honesty is covered in Same Session Attribution vs 90 Day UTM Cookies. Mobile handoffs that look like “lost UTMs” are covered in Why UTM Tracking Breaks on Mobile WordPress Forms.

If you need those UTM and gclid values on a CRM contact after a native fill, map from the WordPress side. That path is in How Do I Get WordPress Form UTM and GCLID Data onto a CRM Contact.

What it cannot see on a HubSpot, Typeform, or Calendly iframe

Free LeadSource hooks WordPress form plugins. It does not hook HubSpot’s servers, Typeform’s servers, Calendly’s servers, Google Forms, or Zoho Forms when those tools collect the submit outside WordPress.

When the visitor submits inside a cross-origin iframe, your PHP never runs a form-submit hook for that fill. No LeadSource row is created for that SaaS entry. The name may land in HubSpot or Typeform. The LeadSource dashboard stays empty for that click, even if the person arrived on a fully tagged WordPress URL a minute earlier.

That is not a setting you forgot. It is the architecture. A WordPress plugin can only attach source data to a submit that WordPress actually processes.

Some platforms offer a JavaScript embed that paints fields in your page DOM instead of a hard iframe. That can help their own tracking or hidden-field tricks. It still is not a LeadSource native hook. LeadSource’s free list is the nine WordPress form plugins above. Do not treat a HubSpot JS embed as if it were Gravity Forms.

Fragile workarounds (URL append, postMessage) and why they are not this plugin

People often paste the same three tips.

Append UTM keys to the iframe src with custom JavaScript. That can work when the form platform reads those query keys and stores them. It breaks when the embed URL format changes, when the script races the iframe load, or when you forget a click ID. LeadSource does not ship or support that bridge.

Use window.postMessage between parent and iframe. That needs listeners on both sides. You control your page. You do not control HubSpot or Typeform code unless they document a listener. LeadSource does not advertise a postMessage iframe bridge.

Proxy or cookie-bridge the embed so it looks first-party. That is DNS and reverse-proxy work, not a free plugin checkbox. Do not claim LeadSource does it.

If you keep the SaaS form, test those workarounds yourself against that vendor’s docs. Do not expect the LeadSource dashboard to show those platform entries.

When to switch to a native form and keep the LeadSource row

If the job is “see which campaign produced this named lead,” a native WordPress form is the clean path. Contact Form 7, WPForms, Gravity Forms, Fluent Forms, and the other hooked builders submit on your server. LeadSource can attach the session stamp at that moment. You still send the lead to HubSpot or another CRM with a plugin or Zap if you need the contact record there. The attribution capture happens before the handoff.

Keep the iframe when the SaaS form is non-negotiable for booking logic, multi-step surveys, or a CRM workflow you will not rebuild this quarter. Then accept that free LeadSource will not stamp that SaaS entry, and plan either a vendor-side hidden-field setup or a later native rebuild.

Free 1.0.8 covers basic UTM and click IDs on native fills with no paid plan. LeadSource Pro is $99 a year when you want lead journeys, per-source email routing, scheduled reports, or white label. Reach for Pro when journey depth or routing is the job, not as a magic iframe fix. Pro does not turn a HubSpot iframe into a WordPress form hook.

Short checklist

1. Confirm whether the form is a native WordPress shortcode or block, or a third-party iframe.
2. If it is native and in the 1.0.8 list, install LeadSource, run the wizard, and test a tagged visit that stays in one browser session.
3. If it is a cross-origin iframe, stop expecting a LeadSource row for that SaaS submit.
4. Prefer a native form when campaign-level named leads matter more than the SaaS embed skin.
5. If you must keep the iframe, use that platform’s documented URL or hidden-field method, and test after every embed change.
6. Do not invent a 90 day cookie or a first-plus-last claim to paper over a blank Direct row.

Blank Direct on an embedded HubSpot or Typeform fill is usually the origin wall, not a missing LeadSource setting. Put the form on WordPress when you need the LeadSource row. Leave the SaaS iframe when you accept that the stamp stays outside free LeadSource.