Passing UTM values to iframe embedded forms

[Anonymous]

I'm currently looking to pass UTM values from URLs through hidden form fields. I'm currently testing various things and have used the script provided here​ by Ryan Vong​ to capture the UTM values in a cookie.

It works on Marketo landing pages, but not currently on our main website, where we have Marketo forms embedded in iframes. As the form is not directly on the page, it can't 'see' the UTM values so isn't able to collect them.

I'm sure there is a workaround, but as I'm not a developer it would take me some time to figure out - I'm hoping a member of the community may already have a solution!

Thanks in advance.

[Anonymous]

Josh Hill​, Sanford Whiteman​, Jon Bourne​ - many thanks for your helpful suggestions. I would prefer to embed the form directly on the page but it would require a lot of work editing existing pages.So will look into implementing your suggestion, Sandford.

[Jon_Bourne]

Hi Ben​. I work with Ryan​ and have also helped develop this script. Our team has been brainstorming regarding UTM tracking and reporting over the past few months, and we have rewritten this particular script from scratch to improve upon the methodolgy. (I suppose we need to update the blog post, too!)

Here is the latest version of the UTM tracking script: http://bit.ly/2gdKeTm​

While it may not address your particular iframe use case, this version of the script is better than older versions in several ways:

1. First, it adds the hidden form fields for you, so you don't have to add them manually on your forms.
2. Also, the cookie is deleted upon successful form submission, so that the UTM values are logged only once.
3. Next, the cookie domain is auto-detected so that you usually don't need to bother changing the default setting. (Note that this currently works for only a handful of TLDs. If you don't use a .com, .net, .org, .co.uk, .co or .us TLD, you'll want to set this manually at the top of the script. Hoping to include better domain detection in a future version.)
4. Last but not least, the setup is much simpler and better explained. Your Marketo fields are easily mapped at the top of the script.

As for the iframe itself, Sanford is correct that you can dynamically create the iframe inside a specific div and pass the query string into it. But why are you using an iframe in the first place? What are you trying to solve for? Is there a reason the default form embed code will not work directly on the page instead of using an iframe?

One final thought: the tracking script can only read cookies from the primary domain name where it is hosted. If you are hosting it, for example, in your Marketo instance at pages.example.com, the cookie created will be set for example.com rather than pages.example.com. This means that if/when the same script runs on your website at example.com, it can access the same cookie there as well. This is not true, however, when the two domains are different; the script can only read the tracking cookie for the same domain from which it was set.

(Incidentally, we're also working on a solution to merge records, known or anonymous, from different Munchkin-tracked domains into the same Marketo lead record. We have a working proof of concept, but it is not production-ready code yet. Ping me if you're interested.)

Josh​ and Sanford​​, thank you both for chiming in to help Ben.

[SanfordWhiteman]

1. Next, the cookie domain is auto-detected so that you can usually don't need to bother changing the default setting.

Jon, this functionality is broken. Recommend you read the blog posts here and here.

[Jon_Bourne]

Sanford, you are correct in that it is insufficient to detect every possible TLD/public domain and, consequently, private domain. Regex only gets you so far. However, given that, to date, our team has controlled the installation of the script, I have not been too terribly concerned about this known issue; we usually will manually set the cookie domain when and where needed as opposed to relying on the auto-detect functionality.

That said, I appreciate the excellent research and write-ups you posted. Nice work! Since you have on your blog already granted permission for its use with appropriate attribution and copyright, I will probably include findPrivateSuffix() in the next iteration of this script.

[SanfordWhiteman]

Sure, go ahead and use it. Your regex only covers a few possibilities, so "usually don't need" seemed off. Note the regex will fail on hundreds of .com and .net domains. It's not just about other TLDs.

[Anonymous]

Wow, this is great stuff Jon Bourne​. Regarding the domain being auto-detected, do you know if this will work on our .cn (Chinese) website? We have a .com and .cn version of the site and, due to the way things are set up, it would be easier to use one script. However, if you recommend manually setting the cookie domain anyway then I will do this and use different versions for each domain.

[Jon_Bourne]

Hi Ben. Yes, you'll need to set the cookie domain manually at the top and host two separate instances of the script—one on each domain. As a security feature, Javascript can only read cookies for the domain on which it is hosted; if you have two (or more) entirely different domains, you will need to host an instance of the UTM tracking script on each domain.

Oh, and if you're targeting China specifically, make sure you're not loading scripts or other page assets from any Google servers. They're blocked (along with many other providers). We've run into this before and had to move these assets to clients' web servers or Design Studio.

[Anonymous]

Jon Bourne​...firstly, thanks again for the script - I've implemented it and it's working well.

There is one specific issue though: let's say a lead comes to the site via a link with utm_campaign, utm_source, utm_medium and utm_term parameters. This info is stored in the relevant fields when the lead fills out a form. They then come back to the site later via a different link with only utm_source and utm_medium present. In this instance, the utm_source and utm_medium fields are overwritten, but utm_campaign and utm_term data remains from their previous visit, so we end up with a mixture of mismatched data. Does that make sense?

Do you know of a way to overcome this? The ideal scenario would be something in the form/script that says 'when at least one UTM value is present, overwrite new UTM values and clear the fields where a new UTM value doesn't exist'.

It's probably a somewhat narrow use case, but I can see it applying to leads where UTM Term and UTM Content data is captured (on leads from paid search, for example), as many links won't have this level of detail and may just have campaign, source and medium.

[Anonymous]

Thanks again for the reply. I have another question on this - do you suggest using the script across the whole site? So, if someone arrives at the homepage via UTM-tagged link, that's captured in the cookie and written to the lead when they fill out a form.

Or do you suggest just adding it to pages with a form, so only visits to those pages are tracked?

[SanfordWhiteman]

Ben, I think I can safely speak for Jon here: using cookies to persist UTM info means you want to keep a trail back to the first touch (possibly also including the conversion touch, if present, and other touches in-between). So while the script's code may intelligently react to navigation over time -- excluding paths and terms, expiring cookies after a period of time, keeping a rolling window of touches -- you almost always want the <script> itself to load on every page.

Also, it wouldn't make sense to use cookies if your sole goal were to pass URL data from a main document to an IFRAMEd form on the same page: cookies won't work across private domain suffixes, and the cookie will be set even if the person doesn't convert (i.e. it will be present on future visits to any page matching the cookie domain).  It's meant to be part of a larger scope.

[Anonymous]

Thanks, good to know. I think in our case using the script everywhere will be best, as we do want to try and build a picture of all touches, not just the immediate touch prior to a conversion. This is part of a bigger project to do better attribution.

[SanfordWhiteman]

A not uncommon problem, and thanks Josh for the @.

Passing the query string from the outer document to an inner IFRAME is as simple as augmenting the src of the IFRAME. However, you do not want to do this after the IFRAME has loaded, or you will cause it to reload, creating visible overhead for the lead and extraneous hits on the server. Instead, what I typically do is create a DIV container for the IFRAME on the page, with the base information hard-coded:

<div class="iframe-container" data-iframe-src="http://example.com/iframe.html" data-iframe-width="100%" data-iframe-height="700" data-iframe-frameborder="0"></div>

Then use JS to inject the IFRAME inside that container when we have the query string to add to the src.

[Ande_Kempf]

Sanford Whiteman​ would this work for IFRAMEs in Marketo landing pages? I'm running into a similar issue where we need to track the click within an IFRAME. Background: The IFRAME contains a quiz and there are a few variables on what content will display after x amount of questions are asked. We need to track how viewers got to the content piece from the quiz within the IFRAME. We placed JS into the IFRAME in the Marketing LP - but, either Marketo is appending the code and making it unusable or there's an error in the JS.

Would placing the IFRAME into a DIV container work for this use case?

[SanfordWhiteman]

Would placing the IFRAME into a DIV container work for this use case?

Doesn't matter what the IFRAME is inside, it's still a separate document and subject the same cross-window/cross-domain security restrictions.

Is the IFRAME running under the same private parent domain as the main document (i.e. they both end with .example.com or .example.co.uk)?

Can you show me the actual URL where you have this running, with the attempt to add Munchkin to the inner IFRAME document?

[Ande_Kempf]

Yes, the iframe is running under the same private parent domain (both end in .com)
Here is the URL.

[SanfordWhiteman]

Yes, the iframe is running under the same private parent domain (both end in .com)

.com is the public parent domain.  These two docs don't share a private domain, one's on pages.dyn.com and the other on community.spiceworks.com.

This means they won't automatically share tracking data, due to longstanding browser security barriers. (Note you don't even have Munchkin in the inner SpiceWorks IFRAME anyway.)

As long as you can make changes to the IFRAME code, you can enable Marketo tracking for the quiz actions, but it'll take a little custom JavaScript on both sides to handle this special communication.

[Ande_Kempf]

Thanks for taking a look and pointing that out about the domain and that the Munchkin. Appreciate it!

[Josh_Hill13]

Look for Sanford Whiteman 2 (FigureOne)​ 's solutions. I'd also suggest hiring a developer or asking webdev to help.