Let’s say you have a client who insists on using a third party webform on their site. In this case, the third party is BuilderTrend. For the client this is the best option because it merges with their office workflow and the actual process of building a house. For you, the agency, this is a poison pill, because BuilderTrend has no inbuilt Google Analytics functionality. BuilderTrend put their webform inside an iframe, the most convenient solution for them. They don’t have to worry about conflicts with the host site, or communication barriers with their server. They just tell their customers to embed the iframe on the contact page, and the work is done.

For an agency, particularly one running a Google Ads campaign, iframe contact forms are exceptionally dangerous because they sever you from seeing what your users are doing. It destroys your ability to track conversions in Google Analytics (or at least makes doing so a non-trivial feat, more on this as we go). In the case of BuilderTrend (and a few other iframe form applications, such as MailMunch), we have found a solution for tracking conversions which is not elegant, but it’s at least feasible.

Why You Need Conversion Tracking on Your Website

Back in the day, in the nascent days of SEO, analytics were just an afterthought. After all, you could see how well you were doing by seeing how well you were ranking. Today, Google Analytics is a vital tool for tracking the success of a campaign. After all, you’re only doing as well as the conversions you’re getting.

Once you bring Google Ads into the equation, tracking conversions is super, super, super critical. The effectiveness of your ad spend is directly proportional to the accuracy of your analytics. The creepy AI brain over at Google headquarters will see who’s converting on your site, and then present ads to more people like that. When your analytics track legitimate conversions, this smart targeting will put you on the fast track to success. If your analytics can’t see who’s converting (because they’re hidden behind an iframe) then you might as well be flushing your ad spend down the toilet for all the good it’s doing you.

The Problem with iFrames

You can think of iframes as an HTML element which allows you to put a window into another website within your webpage. For all practical purposes, your website, where all your analytics code is, has no authority over the content within the iframe. If it’s a different domain expressed by the iframe then you can’t grab user data from it any more than you can grab the user data of people visiting whitehouse.gov or Amazon. It’s a tantalizing pool of mystery, right there out of reach. There’s no real javascript solution, and if there were, then the programming community would shut it down for security reasons. You can’t take screenshots of the iframe. You might be able to put a transparent div on top of the iframe and track cursor movements, but that won’t tell you if they succeeded in filling out the form.

There are solutions to this conundrum, which require the domain in the iframe to cooperate with you. Mostly they are variations of the cross-domain tracking solutions which you can use on multi-site campaigns. Generally you need Google Tag Manager on all the domains involved. GTM will tag the URLs with a unique user ID so that Google can match up user behavior even when different cookies are tracking those users in different locations.

Unfortunately, you need control of Google Tag Manager on both ends of the cross-domain tracking, and third party organizations like BuilderTrend can’t be bothered to help out like that. It would be a lot of extra labor hours for them to get something like that to work, and they probably worry about their customers taking advantage of the ability to insert arbitrary javascript code onto the BuilderTrend servers. In short, helping out their customers with analytics tracking would require a ground-up approach. Consider Ngage, a javascript-based chat app, which has well-documented Google Analytics event capabilities. Ngage started out as a search marketing company, so it’s not surprising that they prioritized their customers’ need to track conversions onsite.

Why BuilderTrend is so Awful

BuilderTrend of course recognizes the importance of analytics. If you look at the Tag Assistant on any page with an embedded BuilderTrend form, you will see that they have quite a lot of analytics tags on their side of the iframe. Data is money, and they are certainly not going to let any of their data go to waste. They’re just not going to spend any extra effort helping out their customers with data. It’s sheer carelessness and contempt for their customers, that they would release a conversion capturing feature that has no conversion tracking features. Shame on you, BuilderTrend, shame. I hope y’all read this and do right by your customers, and give them a way of tracking conversions which isn’t as janky as the solution I explain in the next section.

The Terrible Yet Workable Solution

This next part is where we make coding choices which are so outlandish and seat-of-your-pants imprecise that they would surely leave Google Tag Manager guru Simo Ahava spinning in his grave (he’s not actually dead, but like all Finns he presumably has a pit for curing salmon and making graavilohi).

It’s not strictly true that there’s no way to see what’s going on inside an iframe. The site inside the iframe has to want to communicate with you. Or, as is the case more often than you realize, you can listen in to the bleed-through signals. Let’s take a look at the BuilderTrend embed code. Yes, there’s an iframe with its sinister one-way window. But there’s also an attached piece of javascript. You might ask yourself, what’s that for? The answer is, it’s for the convenience of the developers. You see, BuilderTrend wants the easiest one-size-fits-all solution they can get. So if you have an embedded iframe which contains a user-customized form, how does the webpage know the best dimensions of the iframe? If the user adds a field or two, suddenly it needs to be longer. This is the purpose of the attached code, every time the iframe loads, it tells the javascript onpage the best height to style the form, to prevent the iframe from taking up too much space or using those annoying scroll bars.

There’s a comment in the attached BuilderTrend javascript which gives us a mesmerizing glimpse into the minds of the developers:

// there have been mulitiple ways of doing this over the years, unfortunately this has to support all of them

So apparently a lot of thought and development time has gone into deciding how to style the form so that it looks good onpage, but nothing for the marketing needs of their customers.

The backchannel method of communication between BuildTrend’s iframe and the client page is called postMessage. We can listen into this channel using your Chrome Developer tools. Open the page containing the iframe and then right click and select “inspect.” When the window opens up, change to the “console” tab and enter the following command:
monitorEvents(window, ‘message’)

By right-clicking on the BuilderTrend iframe and selecting “Reload Frame,” we can see that a postMessage comes through every time the iframe reloads. And if you fill it out, the iframe reloads again to display the thank you message, while once again sending a postMessage to inform the javascript function about the preferred dimensions. In the console window the important information will show up under the “data:” section.

Now that we know that the BuilderTrend servers send a postMessage with the form’s height every time the iframe reloads, we can now make an analytics event triggered by the postMessage. We like Google Tag Manager for this sort of project.

First thing we do is add a “Custom HTML” tag in GTM which pushes into the datalayer the two different data formats used to declare the frame height in the postMessage JSON.

<script>
    window.dataLayer = window.dataLayer ||[];
    var FrameHeightCount = 0;
    var JustHeightCount = 0;
    window.addEventListener('message',function(e) {
        if (e.data.FrameHeight) {FrameHeightCount++;}
        if (e.data.height) {JustHeightCount++;}
    window.dataLayer.push({
        'event' : 'BuilderTrend' + e.timeStamp,
        'bt_FrameHeight' : e.data.FrameHeight,
        'bt_JustHeight' : e.data.height,
        'bt_FrameHeightCount' : FrameHeightCount,
        'bt_JustHeightCount' : JustHeightCount
    });
});</script>

Once we have the relevant postMessage communications in the datalayer we can trigger events in both GA4 and UA.

The customization I made to this particular trigger was to delay activation three seconds after page load, so that the initial postMessage declaring the iframe height doesn’t register as a conversion.

Why This PostMessage Tracking Method is Useful But Also Very Fragile

The reason this is a terrible solution is because there’s a lot of points where the conversion tracking could break down. We know that BuilderTrend has a history of changing the coding implementation. At any point they could change the JSON structure sent through postMessage from their silly iframe and this could break conversion tracking, leaving all of us internet marketers high and dry.

However, it appears to very nearly match up with the actual numbers of leads coming through, which is the most important part for us.

An informal (and limited) survey of these sorts of iframe forms shows us that about half leak postMessage information. We were able to use a similar method to track conversions on a Mailmunch form:

This code is a little simpler, just sending a datalayer event whenever it sees a robust data field in the postMessage JSON.

So should you check your clients’ terrible iframe forms to see if they have postMessage events? And should you cobble together a fragile conversion tracking system? For sure. But that doesn’t mean that software companies like BuilderTrend should be left off the hook. They need to show respect and consideration to their customers and their marketing needs, so that we don’t have to engineer crazy hacks just to run a simple Google Ads campaign.