This article will focus on how custom code is used on Launch and why, even with our best effort, it will still long live inside the Tag Management eco-system.
I am not a guardian of custom code in Tag Management System. There is a “famous” (in our analytics world) article written from Jan Exner on how we should try to avoid the usage of custom code in your implementation.
It is worth a good read so here it is : https://webanalyticsfordevelopers.com/2019/01/08/2019-challenge-no-custom-code/
Overall, I do agree with Jan Exner here. Custom codes are just the door to implementation hell.
“Fortunately for me”, I have been to both side of the fence 🙂
On the Agency side and on the Client side.
“Leading” a team of Analyst (who were smart enough to lead themselves) and I am now helping clients doing some implementation.
Launch as a solution…
During my days at the client side, I didn’t have Launch to implement Analytics as easily as I can now. Launch is very flexible and enable you to create Data Elements in order to then be able not to use any custom code for your Analytics variables.
You can just map the Analytics Variable with Data Elements and avoid seeing code every time you open you Analytics set up in Launch.
Thanks to that approach, non-technical people are able realize implementation task and help the analytics team move forward on their tracking.
If you have specific need, you can also create an Extension for Launch in order to simplify the process of more complex implementation. That is a very valuable that I see more and more clients do.
Outgrowing the launch limitation by developing tools for their own needs.
With this last piece, we start to reach the limit of the no-code policy.
As you want to create these kind of extensions, you actually need to code, a lot.
This approach is literally “more code for less code”.
You need to create all kind of logic to take care of all of the possible cases that could happen when using your extension.
However, I maintain that this is a valuable approach and could really help drive the analytics adoption in your company. As more and more people are able to use the tool, more and more people will see its capacities and possibilities.
This will bring more focus and more light on your analytics department.
… Launch as a limitation
The name of that article finishes by “… Long Live Custom Code”. So it has to come back at some point. 🙂
Firstly I feel that the article from Jan Exner has been taken a bit too seriously. My feeling is (I am not the author) that it is a manifesto for simplification and it is its primary goal.
At some point, you do have to go back to custom code. Custom code on itself isn’t bad, the writing of that custom code is what could go bad.
The main problem that everyone fears from custom code is the spaghetti code. Codes that don’t make sense and no one knows about it.
When you have particular page where you want to track different clicks on that page. By doing it only with the UI, you would most certainly use different rules that are all listening to a click event to collect a specific event.
With custom code, you could have only one rule where every click are gather into one coding section.
The no-code policy will create multiple rules that you have to manage separately. If you condition for selecting the correct page change, you will need to update all of these pages independently. That is increasing the amount of time the analytics team needs to budget for maintenance of existing implementation.
The same goes with Extensions, if you create one, there is a big chance that there is a dependency on some tool. This tool update, you will need to update the extension itself.
It is simpler as only one element would need an update but it requires special skills (JS development).
Data Elements can also be a good example of a false-good idea. By using Data Elements, you may be able to hide the code from your end-user but there is gonna be some times where you will need to open that Data Element / Pandora box. The code didn’t vanish.
If your intention was to hide the monstrous nature of what needs to be done to retrieve that element, it is going to bite you in the a…
I am dealing a lot with Data Elements nesting, that Data Elements are calling themselves and that would not be considered as a good practice.
Yes it does reduce code duplication but when you have this kind of relationship, when does it turn to be a good idea ?
Or you will have left the company long ago and not your problem anymore.
I have seen many companies that are relying too much on legacy. Being aware that you are on the verge of collapsing your overall implementation due to that is not a pleasant feeling.
Even it works. People ask you how and you don’t have a complete answer and that is not satisfying, for everyone….
When to use Custom Code / UI ?
This is where it is hard to clearly state a rule for that kind of element. I have my idea but it is definitely not a rule. It is more my way of working.
- The person that is deciding on the implementation strategy should be tech-savvy. it doesn’t mean being a developer but it needs to understand the implication of the decision he is doing.
We are doing a job that required a lot of technical knowledge, I am a guardian of the saying : “everyone can do it”. However, at some point, you expect that everyone in our industry is tech-savvy. If not now, willing to be in the future.
Effort should be met half-way, anyone not willing to learn a bit of code in data analysis may not be at the right place. - You should strive to simplify the implementation.
That requires to some times rely on UI implementation when it can be done (as the simplest method) but sometimes do custom codes when it is required.
Why re-inventing the wheel when someone smarter and better than you created a function for what you want to achieve ?
It is a bit contradictory from what I have said early about being tech-savvy but being tech-savvy will help you identifying the use-cases where the UI is the correct approach (90% of time) and reserve the “hell-door” for real needs. - Coding simple is beautiful.
Before doing anything ultra-performance on your code, try to do something that makes sense and that people can maintain. Not only you.
This may come from my python spirit but I feel that JS developers could learn from it.
Efficiency coming from ultra-complicated code that no-one can update is the demon child of every analytics implementation. - Reflect on your current situation.
One of the biggest problem is that is that the custom code starts clean and then turns into monstrous abomination that you spend hours to update.
If that is the case, you should probably think on refactoring it. - Some time, you have no choice.
More you grow mature and more complicated your use case are becoming.
Therefore, it involves more and more logic and it can’t be help that the code is complicated.
Then live with it but make sure that you write the complicated code in a simple way. 🙂
I hope that article helped you having better view on what the “No Custom Code” means (on my interpretation).
Feel free to share your feedback on that, I know that this problem appears in every project and analytics implementation and there is no simple answer. I just hope to bring to a light.