With the sunsetting of Universal Analytics (UA) now very close, I hope that you are all set for the move to GA4.
As I have suggested in previous posts, my initial loathing of GA4 has definitely softened and there are many aspects of the new platform that I actually quite like. To tell the whole truth, it is really the combined power of Google Tag Manager (GTM) and GA4 that I have been admiring. GTM played very nicely with UA but that felt a bit like a cheeky romance rather than the beautiful marriage that is the GTM and GA4 union. You cannot really enjoy GA4 without embracing GTM.
I wanted to share an example of how GTM can be used to help create meaningful reports in GA4 and share how we use a lookup table to help report on forms completed on this website.
As with many WordPress sites, we use the excellent Gravity Forms to create and publish forms. We actually have a handful of different forms, not just the main contact form. There are actually several ways in which you can track form submissions in GTM / GA4 and I don’t want to run through each and every approach, but I hoped it would be useful to share how using lookup tables can really help with reporting.
GTM has an inbuilt form submission trigger. It works well and is, in my humble opinion, a much better approach to tracking form submissions than the alternatives, especially button clicks or page views of a ‘thank you’ page. It is also easy to add various parameters to the event that you send to GA4, including the form ID.
The problem that you face with Gravity Forms is that the default form IDs are not especially helpful. Whilst we can easily pass the form ID into GA4, I would suggest that a report showing ‘gform_38’ form completions is not as helpful as one showing ‘Main Contact Form’ form completions. There are ways to get around this, using hidden fields for example, but I am a big believer in KISS (keep it simple, stupid) and any individual tweaking of forms opens up all sorts of opportunities to get it wrong.
Luckily, there is an easy way to get around this problem and I will now show you how to approach things in GTM and GA4. I am assuming a base knowledge of how to use both GTM and GA4 – please feel free to contact us if you are bamboozled by any of the following as we can hold your hand through the process and can train your team about how to use GA4.
1] List forms that you wish to track
Whilst we will use a catchall to handle rogue forms, it is a good idea to start by drawing up a list of forms that you want to track in your GA4 reports. We have five forms that I wanted to detail : the main contact form, an recruitment form, a newsletter sign up form, a new customer questionnaire and a form that we used to collect people’s attitudes towards GA4.
You need to inspect the page source of any page on which the form you wish to track in order to find its form ID. If you are using Gravity Forms, you can probably just pick out the form ID that is shown in the plugin section and add ‘gform_’ before the number, although you should check the source code to make sure that your site is using that standard approach.
2] Create GTM lookup table
You now need to create a custom variable in GTM and use the ‘Lookup Table’ option, which is within the ‘Utilities’ variable type section. You need to give it a name and then fill in the ‘input’ and ‘output’ options, which tells GTM how to rewrite anything that you put in the input box. This is what our lookup table looks like:
You can choose whatever ‘output’ you wish – these will be the labels that you see in your GA4 reports, so choose whatever feels right for you. The ‘input’ data needs to be *exactly* right though and you must ensure that you use the right form IDs.
You have the option to set a default value when creating the lookup table. If you have ensured that you have got all the forms on your site covered in the lookup table, there shouldn’t really be any need for this option but it doesn’t do any harm to put one in, as it is a helpful prompt in GA4 to show that you have missed a form. Using the form ID variable as the default value is arguably a better approach than I have used in the example above as that will write in the ID of the form that you have missed and it will help you diagnose which form has been missed.
3] Create GTM trigger
As I mentioned, I don’t want this post to be a beginner’s 101 guide to configuring tags in GTM, but you will need a trigger to fire when a user fills out one of the forms that you wish to track. This is what we use:
As shown, we use the inbuilt form submission tracking and I find it to be very good. I always select the option to check validation, to reduce the risk of possible overcounting if there are errors on the form, but cast the net extremely wide by enabling the trigger on every page of the site. You could limit the trigger to specific pages if you like, but I haven’t run into any problems using this approach.
The one downside to allowing the trigger on every page is that you may have some forms other than your gravity forms, e.g. log in / search boxes, so limit it to firing only where the form ID contains ‘gform’. This will restrict it to firing only when one of the gravity forms is submitted, which is what we want to achieve.
4] Create GTM tag
The last piece of the jigsaw is to create the tag itself, which is based on a GA4 event. This is how we have configured our tag:
I hope that this is fairly self explanatory, but there are a couple of points to note.
We use ‘generate_lead’ as the event name. You may ask why we haven’t used something more descriptive like ‘form_submission’ or ‘gravity_form_completed’. I used to do this as it felt natural and helped give some context to events shown in GA4 but, strictly speaking, you should use Google’s recommended events wherever possible. ‘generate_lead’ should be used for form submissions. Whilst the tracking will still work if you use your own naming conventions, I would draw your attention to the following text on the page that I have just linked to:
You should send recommended events with their prescribed parameters to get the most details in your reports and to benefit from future features and integrations as they become available.
Your guess is as good as mine as to what the ‘future features and integrations’ actually represent, but I would suggest that it is a good idea to set off on the right foot rather than having to change all your events in the future. This does have a consideration when drilling into reports in GA4 itself – see step 6 below.
5] Test
Once you have worked through the steps above, you need to launch Google Tag Assistant, which you can do by using the ‘Preview’ mode in GTM, in order to make sure all is working as planned. To demonstrate this, I filled out the GA4 research form that we have on https://browsermedia.agency/blog/ga4-panic-stations/.
Hey presto, we can see that the tag fired successfully when the form is submitted:
If we look at the actual details of the data sent to GA4, we can check that the lookup table has worked as planned:
As you can see, a ‘generate_lead’ has been fired with ‘GA4 Panic’ used as the form_id parameter. If you scroll up to the lookup table screenshot above, you will see that this is exactly what it should be sending rather than the obscure ‘gform_41’ form ID.
Eureka.
6] Create GA4 custom dimension
Or maybe not.
One of the frustrations that I have with GA4 is that it can be fairly difficult to drill down into data and find the extra detail that you will no doubt want to see. Event parameters is a good example of this. Whilst readily available in realtime reporting and explore reports within GA4, the ‘out of the box’ detail you will see when looking at event reports will not show any event parameter data. It would be entirely logical to expect event parameter data that you send with your GA4 events to be shown when looking at Event reports within the ‘Engagement’ section of GA4. You will, however, be disappointed to find that there is no such data shown by default.
To add this fairly obvious helpful extra layer of data to the standard report, you will need to head to GA4 admin section and create a custom dimension, which is found in the ‘Custom definitions’ section. You can call it whatever you want to see on your reports, but I went with the inspirational ‘Form Id’:
Although very easy to do (you just need to make sure that you use ‘Event’ in the Scope drop down and then select the event parameter that you set up above), it feels a little unnecessary and I am sure that I am not the only one to have spent a few frustrating moments trying to find the event parameters in GA4, having seen them firing when testing the tags. On that note, please be aware that it can take up to 48hrs for data to show reliably in GA4, so don’t panic if you are sensing a lag in data being reported. You are not alone.
7] Enjoy your GA4 form submission reports
Assuming that you have made it this far and people have actually been filling out the forms that you are tracking, you should now be able to drill down into the ‘generate_lead’ event and see a snapshot of which forms have been filled in, e.g.:
I hope you would agree that this is vastly more useful than a report full of ‘gform_38’ type labels?
The form names that you have assigned in the lookup table will also be used in Explore reports, where you can really start to drill into more detail, such as creating a report that will quickly show which traffic sources have the best conversion rate, so you will benefit from more descriptive names across all GA4 data.
So there you have it – an easy way to avoid having to set up individual events for each form that you are using. This approach is flexible and scaleable. You will need to update the lookup table as you publish new forms, but everything else should take care of itself. As I said, GTM and GA4 work very well together.
