SHARE

How to track forms which don't redirect to a thank you page

Many contact forms now use Javascript to submit and do not redirect to a new page. So to track the form, unless you trigger an event on the submit button, you need to listen for a piece of text (usually saying thank you).

We have created a custom HTML script that listens to the changes in the page and triggers an event called ‘formSubmitted’.

This event can then be used to fire a separate tag with event details to Google Analytics.

We’ve tested this on our contact form at Littledata and here’s how you can set it up too.

Step 1

The first step is to go through the contact form and see what the steps are in completing it.

On ours, you just enter the information in the fields and press “SUBMIT MESSAGE”. When the message is sent out, the button will say “SENT!”. Here the only thing that changed was the text on the button from ‘submit message’ to ‘sent’.

We built this HTML script that listens to the changes on the page, but you’ll need to change line 10 to be whatever the message is in your form.

You will also need to change line 15 if you have multiple forms on the page.

&lt;script&gt;
// **** Littledata Javascript form tracker ****
// Generates a GTM custom event called 'formSubmitted'
// When an on-page form is submitted
// CHANGE the text to match the message displayed
// when the form is successfully completed
// It is not case sensitive
var text = "sent!"
// By default it will search for text within the first form
// Set to false if text is outside a form
// or change to a higher false if there are multiple forms
var formIndex = 0;
// OPTIONALLY, restrict the search to an HTML element ID
// If you leave this blank, the whole page will be searched;
// this causes the script to run more slowly
var targetId = ""
// **** No changes needed to the script below ****
text = text.toLowerCase()
dataLayer = dataLayer || [];
if (!formIndex &amp;&amp; targetId.length == 0) console.error('Form tracker needs either a form or an element ID')
var checkEveryMilliseconds = 500;
formTrackerInterval = window.setInterval(function(){
var target = ""
if (formIndex &gt;= 0) {
var form = document.getElementsByTagName('form')
target = (form.length &gt; 0) ? form[formIndex].textContent : "";
}
else target = document.getElementById(targetId).textContent
target = target.toLowerCase()
if (target.indexOf(text) &gt; -1) {
window.clearInterval(formTrackerInterval);
dataLayer.push({
event: 'formSubmitted'
})
}
},checkEveryMilliseconds)
&lt;/script&gt;

Step 2

Now we need to add the script to listen out for when the form is submitted.

Create a custom HTML tag in your GTM container.

You can name the tag ‘LISTENER Contact form submit event’ or anything else you will remember it by.

Choose the tag type ‘Custom HTML’.

Copy and paste your HTML/Javascript into the textbox, and remember to change the var text (line 10) with your own text.

Step 3

This tag needs a firing trigger, specifying the rules when it needs to be activated.

If you can, only fire on specific pages – the script will slow down the page a little, as it runs every half a second to check the form.

Give the trigger a descriptive name – here I’ve chosen “PAGE About us”

Select trigger type as ‘Custom Event’ and for the event name put ” gtm.load “, which means this trigger at page load.

We want this trigger to work on a specific page only, so the firing rule goes ‘page path equals /about-us’, which means that our trigger will work on the www.littledata.io/about-us page only.

If you have a number of pages that have the form you’re tracking, then you could use ‘contains’ rule and select part of the link that is applicable to all. For example, if all of your links have word ‘contact’ in them, then your firing rule would say ‘page path contains contact’.

Step 4

Now that you have your listener tag set up, you need to create a separate tag to send the event details to Google Analytics.

Again, give it a descriptive name so you know what it’s for – here I’ve used ‘GA event – contact form submitted’.

Further reading:

Alexandra

Previously led retail and digital marketing for LEGO Certified Stores and PANDORA. She’s experienced in PPC, affiliate, e-commerce, travel and news websites. She has a Master's degree in economic analysis.

Subscribe to our blog

Thanks for signing up!

Related posts

Google Analytics referral spam is a growing problem, and since Littledata has launched a feature to set up spam filters for you with one click, we’d like to correct a few myths circulating.
1. Google has got spam all under control
Our research shows the problem exploded in May – and is likely to get worse as the tactics get copied.
From January to April this year, there were only a handful of spammers, generally sending one or two hits to each web property, just to get on their reports.
In May, this stepped up over one thousand-fold, and over a sample of 700 websites, we counted 430,000 spam referrals – an average of 620 sessions per web property, and enough to skew even a higher traffic website.
The number of spammers using this tactic has also multiplied, with sites such as ‘4webmasters.org’ and ‘best-seo-offer.com’ especially prolific.
Unfortunately, due to the inherently open nature of Google Analytics, where anyone can start sending tracking events without authentication, this is really hard for Google to fix.
2. Blocking the spam domains from your server will remove them from your reports
A few articles have suggested changing your server settings to exclude certain referral sources or IP addresses will help clear us the problem.
But this misunderstands how many of these ‘ghost referrals’ work: they are not actual hits on your website, but rather tracking events sent directly to Google’s servers via the Measurement Protocol.
In this case, blocking the referrer from your own servers won’t do a thing – since the spammers can just go directly to Google Analytics. It's also dangerous to amend the htaccess file (or equivalent on other servers), as it could prevent a whole lot of genuine visitors seeing your site.
3. Adding a filter will remove all historic spam
Filters in Google Analytics are applied at the point that the data is first received, so they only apply to hits received AFTER the filter is added.
They are the right solution to preventing future spam, but won’t clean up your historic reports. To do that you also need to set up a custom segment, with the same source exclusions are the filter.
You can set up an exclusion segment by clicking 'Add Segment' and then red 'New Segment' button on the reporting pages and setting up a list of filters similar to this screenshot.
4. Adding the spammers to the referral exclusion list will remove them from reports
This is especially dangerous, as it will hide the problem, without actually removing the spam from your reports.
The referral exclusion list was set up to prevent visitors who went to a different domain as part of a normal journey on your website being counted as a new session when they returned. e.g. If the visitor is directed to PayPal to pay, and then returns to your site for confirmation, then adding 'paypal.com' to the referral exclusion list would be correct.
However, if you add a spam domain to that list then the visit will disappear from your referral reports... but still, be included under Direct traffic.
5. Selecting the exclude known bots and spiders in the view setting will fix it
Google released a feature in 2014 to exclude known bots and spiders from reports. Unfortunately, this is mainly based on an IP address - and the spammers, in this case, are not using consistent IP addresses, because they don't want to be excluded.
So we do recommend opting into the bot exclusion, but you shouldn't rely on it to fix your issue
Need more help? Comment below or get in touch!

From May 2018 the new General Data Protection Regulations (GDPR) will come into force in the European Union, causing all marketers and data engineers to re-consider how they store, transmit and manage data – including Google Analytics.
If your company uses Google Analytics, and you have customers in Europe, then this guide will help you check compliance.
The rights enshrined by GDPR relate to any data your company holds which is personally identifiable: that is, can be tied back to a customer who contacts you. The simplest form of compliance, and what Google requires in the GA Terms of Use, is that you do not store any personally identifiable information.
Imagine a customer calls your company and using the right of access asks what web analytics you hold on them. If it is impossible for anyone at your company (or from your agencies) to identify that customer in GA, then the other right of rectification and right of erasure cannot apply.
Since it is not possible to selectively delete data in GA (without deleting the entire web property history) this is also the only practical way to comply.
The tasks needed to meet depends on your meaning of ‘impossible to identify’!
Basic Compliance
Any customer data sent ‘in the clear’ to GA is a clear break of their terms, and can result in Google deleting all your analytics for that period.
This would include:
User names sent in page URLs
Phone numbers captured during form completion events
Email addresses used as customer identifiers in custom dimensions
If you’re not sure, our analytics audit tool includes a check for all these types of personally identifiable information.
You need to filter out the names and emails on the affected pages, in the browser; applying a filter within GA itself is not sufficient.
But I prefer a belt-and-braces approach to compliance, so you should also look at who has access to the Google Analytics account, and ensure that all those with access are aware of the need not to capture personal data and GDPR more generally.
You should check your company actually owns the Google Analytics account (not an agency), and if not transfer it back.
At the web property level, you should check only a limited number of admins have permission to add and remove users, and that all the users only have permission to the websites they are directly involved in.
Or you could talk to us about integrations with your internal systems to automatically add and remove users to GA based on roles in the company.
Full Compliance
Other areas which could possibly be personally identifiable and you may need to discuss are:
IP addresses
Postcodes/ZIP codes
Long URLs with lots of user-specific attributes
The customer’s IP address is not stored by Google in a database, or accessible to any client company, but it could potentially be accessed by a Google employee. If you’re concerned there is a plug-in to anonymise the last part of the IP address, which still allows Google to detect the user’s rough location.
ZIP codes are unlikely to be linked to a user, but in the UK some postcodes could be linked to an individual household – and to a person, in combination with the web pages they visited. As with IPs, the best solution is to only send the first few digits (the ‘outcode’) to GA, which still allows segmenting by location.
Long URLs are problematic in reporting (since GA does not allow more than 50,000 different URL variants in a report) but also because, as with postcodes, a combination of lots of marginally personal information could lead to a person. For example, if the URL was
mysite.com/form?gender=female&birthdate=31-12-1980&companyName=Facebook&homeCity=Winchester
This could allow anyone viewing those page paths in GA to identify the person.
The solution is to replace long URLs with a shortened version like
mysite.com/form
And for bonus points...
All European websites are required to get visitors to opt in to a cookie policy, which covers the use of the GA tracker cookie.
But does your site log whether that cookie policy was accepted, by using a custom event?
Doing so would protect you from a web-savvy user in the future who wanted to know what information has been stored against the client ID used in his Google cookie. I feel this client ID is outside the scope of GDPR, but guaranteeing that the user on GA can be linked to opt-in consent of the cookie will help protect against any future data litigation.
The final area of contention is hashing emails. This is the process used to convert a plain email like ‘me@gmail.com’ into a unique string like ‘uDpWb89gxRkWmZLgD’. The theory is that hashing is a one-way process, so I can’t regenerate the original personal email from the hash, rendering it not personal.
The problem is that some common hashing algorithms can be cracked, so actually the original email can be deduced from a seemingly-random string. The result is that under GDPR, such email hashes are considered 'pseudonymized' - the resulting data can be more widely shared for analysis, but still needs to be handled with care.
For extra security, you could add a ‘salt’ to the hashing, but this might negate the whole reason why you want to store a user email in the first place – to link together different actions or campaigns from the same user, without actually naming the user.
There are ways around that strike a compromise. Contact Littledata for a free initial consultation or a GDPR compliance audit.