How To Write a GTM Auto-Event Listener with No Coding Skills

I’ll repeat myself once again. Auto-event listeners are one of the key concepts in Google Tag Manager. Just like a trigger, variable, tag, or data layer. In fact, more than half of my Google Tag Manager blog posts mention auto-event listeners one way or another.

Auto-event listeners are these super useful JavaScript functions which track particular interactions on a web page. In case something noteworthy occurs, they fire Data Layer events which can be used as triggers in GTM. Furthermore, those events contain valuable data which can be transferred to other tools, like Google Analytics, Adwords, Mixpanel, you name it.

There are a bunch of default GTM auto-event listeners (like Form submission, Timer, Pageview, etc.) and a lot more custom auto-event listeners available online (like Youtube, Scroll Tracking, Form abandonment, all available at the Library of GTM Recipes).

Unfortunately, these auto-event listeners do not cover all possible situations and don’t fulfill ALL our needs. What should we do then? The best option would be to ask developer’s help. But from my experience, they’re always busy with their deadlines and a bunch of queued tasks. What if we could write an auto-event listener ourselves (even though we have almost no coding skills)?

You + JavaScript?

1.5 months ago I did a survey. The objective was to better know my audience, to understand its pains and needs. Turns out, most of you couldn’t write intermediate or complex JavaScript functions, some of you could do some minor tweaks to examples found online.

P.S. I’m pretty sure there are some developers among readers as well, but they’re too busy to participate in such surveys 🙂

Welcome to the club! I’m am one of you too.

I want to learn JavaScript, I know some basics, and I can do minor tweaks in examples found online. But lack of time and a bit of laziness stops me from diving deeper into the world of JS.

Sounds familiar? So what options do we have?

Well, we can always wait for Simo to post some new ideas/solutions. Let’s not forget Lunametrics, Cardinal Path, and others who make our lives much easier.

But what if I told you there’s a chance that you could write new tracking code by yourself? In fact, 1.5 months ago I wrote Zopim Auto-Event Listener which tracks chat widget’s interactions, all by myself. You can do that too!

 

Before we continue

I admit that the title of this blog post sounds like a click bait. That’s why I want to post a short disclaimer before we continue.

This tactic that I used to write an auto-event listener for Zopim won’t work in ~90% of other situations. In other words, there’s a slight chance of 10% that my approach will work for you (P.S. these numbers are based on my experience).

90% failure rate? Well, that must be a terrible solution! – you might say.

Yes, it might. But if someone told you that there’s a slight chance that you could solve a problem by yourself, instead of looking for someone else to fix it. Would you accept that chance?

I would.

So if you’re still reading this post, thank you. Bear with me and I’ll show you how deep the rabbit hole goes.

 

When does this tactic work?

First of all, this method will support only those 3rd party solutions/systems/platforms/forms/widgets/etc. which:

• Offer a JavaScript API.
• And have a very well documented API reference. I mean, really dumbed down and containing ready-to-use simple code examples.

Zopim Chat satisfied both of these requirements.

What does it mean? First of all, you won’t be able to track some super custom website interactions which were developed specifically for that client. Imagine that your client had hired an agency which developed a website. Instead of using some popular chat solution, they decided to code their own.

Usually, such custom solutions do not have a JavaScript API which we could use for tracking purposes. No JS API = no easy way to write an auto-event listener.

Meanwhile, Zopim offers a really decent API reference which various code examples. Thanks to its functionality, you can listen to events when the chat was started, ended, etc.

Example. Let’s write our own listener, right now!

Since I have already published Zopim chat auto-event listener, I will not explain it in this blog post. It’s not fun to walk the same path twice. Let’s create something else from scratch!

Another popular chat solution is Tawk.to (which is totally free!).

Imagine that your client (or you) wants to track moments when a chat started and ended. Each time such interactions occur, you have to fire a Google Analytics event.

What do you do?

Now, I will show you my regular process how to write an auto-event listener. Few things to keep in mind. This method is not universal and in many cases won’t work. All I’m going to show you is a low-hanging fruit. If you want something fancier, learn JS or find a developer.

Nonetheless, this tactic has already worked for me multiple times.

 

Step 1. Check if there are any ready-made solutions

First of all, you need to check whether there is a ready-made Tawk.to listener somewhere on the web. Last time I checked it, there was none. There were some tutorials how to track chat interactions, but no out-of-the-box *sad face*

 

STEP 2. Let’s check whether there is a JavaScript API

Open Google and enter Tawk.to Javascript API. It’s crucial that you look for JavaScript API, not regular API. Your search results should look like this:

Great! Tawk.to indeed offers JavaScript API. We’re one step closer to writing an auto-event listener.

If you wish to track some other interactions and that particular platform/app/etc. does not offer a JavaScript API, I have bad news: my method won’t work. In that case, you have now 3 options: 1. Learn JavaScript, 2. Hire a developer to write an auto-event listener, or 3. Wait for someone else to post a tutorial online (the worst option).

Anyway, don’t celebrate too soon. Finding Tawk.to JS API is only a part of the process.

 

STEP 3. Let’s see which API methods are available

Now, check whether the API is well documented and easy-to-understand even for those who do not know how to code. On the left side of the Tawk.to API reference, you’ll find a list of API methods.

These methods let you communicate with Tawk.to chat widget:

• You can send requests and get some information, e.g. get chat status.
• Control the chat widget, e.g. hide it, show it, etc.
• Or listen to certain events, e.g. chat widget is maximized, chat started, chat ended.

Bingo! The latter two events are exactly what we need. We’re one step closer to success but there’s still something we need to verify.

 

STEP 4. Are code examples ready-to-use and very simple?

Even if the API offers useful methods and the documentation is very well written, there’s still one requirement left. Is the API Reference really dummy-proof? Will a non-developer be able to use it with ease?

Honestly, it is not a very common practice to write super simple code examples in API references which could be useful for non-devs or beginners. Sometimes it’s even next to impossible.

For example, Wistia offers a very well-written Javascript API reference, but examples are not designed for entry-level developers, thus you and I won’t able to write our own custom auto-event listeners.

In Wistia’s case, we’re lucky to have Lunametrics because their developers posted this awesome Wistia listener for GTM. But there are still lots of situations where a ready-made tracking solution just simply does not exist.

OK, let’s go back to Tawk.to. I have navigated to onChatStarted method and found this example of code snippet:

This is perfect! Let me explain what’s happening. This code is ready to use. It states: if onChatStarted occurs, initiate the function. Currently, that function is empty but we can easily embed the dataLayer.push event just by replacing the text //place your code here with the actual data layer code.

 

STEP 5. Add dataLayer.push event(-s)

Copy that code from Tawk.to API documentation and paste to some plain text or code editor (e.g. Notepad, Notepad++, Sublime, etc.)

Tawk_API = Tawk_API || {};
Tawk_API.onChatStarted = function(){
    //place your code here
};

Remove //place your code here

Tawk_API = Tawk_API || {};
Tawk_API.onChatStarted = function(){
};

Prepare dataLayer.push event code (various GTM experts recommend to use window.dataLayer.push instead of plain dataLayer.push):

window.dataLayer.push({
 'event': 'tawkto',
 'chatStatus': 'started'
 });

Now, merge the Tawk.to code snippet with window.dataLayer.push. This is what a final result should look like:

Tawk_API = Tawk_API || {};
Tawk_API.onChatStarted = function(){
 window.dataLayer.push({
 'event': 'tawkto',
 'chatStatus': 'started'
 });
};

Do the same with onChatEnded (just change chatStatus attribute’s value to ended):

Tawk_API = Tawk_API || {};
Tawk_API.onChatEnded = function(){
window.dataLayer.push({
 'event': 'tawkto',
 'chatStatus': 'ended'
 });
};

Great! We’re very close to finishing the Tawk.to auto-event listener!

 

STEP 6. Create a Custom HTML tag and test

In Google Tag Manager account, create a new Custom HTML tag. Every code snippet in this tag must be surrounded by <script> and </script>.

Now, paste both onChatStarted and onChatEnded code snippet that you prepared in the previous chapter of this blog post.

Done! Save the tag and assign the trigger you want, e.g. All Pages.

Yes, I know that the code above can be a bit optimized. That’s exactly what my developer told me when I showed him what I made. But is this auto-event listener broken? No. Will it break my website? No. Then it’s good enough for a beginner like me and you 🙂

Don’t forget to test this listener with GTM Preview and Debug mode. Load the page with Tawk.to chat widget enabled and start (or end) the conversation. A Data Layer event called tawkto should appear in the event stream. Click it and check what data was passed to the Data Layer. It should look like this.

 

STEP 7. Success

If everything worked as I have described, create Data Layer variable chatStatus (learn how to access data in the Data Layer) and create a Custom Event Trigger tawkto.

Congratulations! You have written your first GTM Auto-Event Listener. How does it feel to be a hacker? 😀

So there you have it, my super secret way to write an auto-event listener without coding skills. I hope you found it useful. I also hope that experienced JavaScript developers will not condemn me for creating false illusions that anyone can code JavaScript without some skills.

 

Final words: how to write an auto-event listener with no coding skills

Auto-event listeners are really useful JavaScript functions which track particular interactions on a web page. In case something interesting occurs, they fire Data Layer events which can be used as triggers in GTM. Furthermore, those events contain valuable data which can be transferred to other tools, like Google Analytics, Adwords, Mixpanel, you name it.

There are a bunch of default GTM auto-event listeners (like Form submission, Timer, Pageview, etc.) and a lot more custom auto-event listeners available online in the Library of GTM Recipes.

Unfortunately, these auto-event listeners do not cover all possible situations and do not fulfill ALL our needs. What can we do then?

Here’s what I do when I need to track something specific:

1. First, I always double or triple check if there are any ready-made tracking solutions for GTM. Chances are someone has already described how to track certain form, video player, or whatever.
2. If the search is unsuccessful, I check whether that 3rd party tool (which you want to track) offers a JavaScript API. This blog post won’t help you much if there’s no JavaScript API available.
3. After I have found the API Reference, I verify whether it’s well-documented and easy-to-use for total beginners.
4. Also, it’s really important to check if API methods are of any use.
5. Finally, I embed the window.dataLayer.push code snippet in the code example found in the API reference and add that code to a GTM Custom HTML tag.

Keep in mind that this solution is not very universal, it works in rare cases because it’s not a common practice to have a super well-written API documentation with dumbed-down code examples.

But from my experience, this has already worked several times.