Attribution Loss

Iframe Embedded Forms

There are a few primary issues:

1. They prevent any on-page scripts from setting any hidden field values used for appending attribution data to lead records (e.g., utm_* parameters and other similar data).

2. They break features like Google's "Enhanced Conversions" (and similar flavors by other platforms) that need access to the submitted user-data to send in a SHA256 hashed format.

3. If the <iframe> is loaded from a separate root domain (they usually are), and the form doesn't redirect the parent frame on submission, conversion measurement will likely suffer.

The above is a non-exhaustive list. Apart from all of the measurement issues that exist, they often pose major user-experience and/or accessibility issues as well.

Common Offenders

Pardot

The best solution for Pardot is to simply NOT use their embedded forms and instead submit data to "form handlers" inside the software. Yes -- you will lose some of the "progressive profiling" and auto field filling features etc... but, you will keep your sanity longer term by staying away from them.

If you MUST use their embedded forms 👇

1. Make sure you are embedding them using a subdomain off the same root domain and the pages where they are embedded.

2. Enlist a developer to implement cross-origin messaging via window.postMessage()to set hidden fields appropriately and also push event payloads to the parent frame on successful form submission.

HubSpot

The (new) default for embedded forms on HubSpot is to use an <iframe>. However, this behavior can be disabled inside the form editor(s) to render the form in what they call "Raw HTML Mode". This is almost always the preferred approach, but you may need to enlist a developer to write some simple CSS to style the form appropriately.

Embedded Calendars/Schedulers (Calendly etc..)

These schedulers are notorious for using <iframe> embed methods. Luckily most of them offer their own window.postMessage()events/messages that can be subscribed to via a few lines of javascript inside Google Tag Manager.

Cross-Domain Redirects

Most tracking tags/scripts utilize 1st party cookies (e.g. cookies stored/accessible on your own domain) to set both a client/browser pseudonymous ID, and a "click" identifier.

Using Google Ads as an example -- its tags/pixels set the following cookies to attribute a conversion in a given "window" of time:

This works fine -- assuming that the conversion being measured does not occur on a different "root" domain from where the ad destination URL sent the visitor. To illustrate, if a Google Ad sends visitors to www.level.agency/contact, Google Ads can access those cookies on any subdomain of level.agency and thus measure conversions there.

In the event that a visitor would navigate (or be redirected to) a different root domain (e.g. levelagency.com) Google Ads would no longer be able to access the cookies stored on the .level.agency domain -- and any conversion that would occur there would not be measured accurately.

Luckily, Google Ads provides a means of "decorating" links to different domains to "persist" the cookies from one domain to another (thus fixing the issue). However, redirects pose a different challenge. Google cannot "decorate" a redirect automatically like they can with a link click. This means that you need to manually write a script to pass (and then set) the cookies appropriately.

URL Parameters Stripped via 301 Redirect