The challenging approach to implementing web analytic services

In one of our previous posts (if you haven’t seen it yet, it was this one), a small introduction about our journey about our testing and choices of different tracking tools have been described.

The previous blogpost covers a broad range of topics such as:

• explaining the reason for using one over the other
• the need for GDPR, CCPA, PECR,... and all the other magical acronyms that must be respected
• the necessary information expected from such tools (screen size, countries, etc.) in order to finally have some that allows you to create your own tailored tracking event - which is very useful for the creation of schemas, graphs, providing stats, and tendencies for creating beautiful spreadsheets

What about the integration into our frontend applications?

All of our experiments and changes have led us to consider some critical points in our projects:

• What is the amount of effort required to have it implemented in the simplest and quickest way possible?
• With the fewest changes possible by retaining the previously created custom event for use in the maximum track services tool
• Without significantly affecting the user experience (UX)

In short, which was the most agnostic approach to resolving such problems?

Agnostics approach?

In our situation, an agnostic approach would be to find a technology that allows us to implement a tracking solution without being constrained by the frameworks, libraries, and tracking services we use. If changes or migration are required, this solution should be able to be migrated while still providing the same type of results, especially in the frontend world where everything changes quickly, regardless of whether an SPA or SSR technology is used.

How to implement this approach?

During our long search, we came across a new exciting and promising library: walker.js by the Elbwalker team.

Using custom html attributes, you can create your own customized tracking event with this library. The library already supports the majority of the commonly expected event triggers, such as click, pageview, and submit. Of course, it also provides a way to programmatically trick those events if necessary 😉

Because this library is still in development, it is possible that some features are not yet available; for this and more information, please schedule a call with the Elbwalker's developer or create GitHub issues.

One of the most important requirements on your side when using this approach will be to establish a practical naming convention and documentation for your team and projects. After that, any actor in your frontend projects (developers and designers) can work on it with no other knowledge or patterns than those provided by walker.js.

Walker.js configuration is simple and well documented in your project. In a nutshell, it's done programmatically and requires an understanding of its fundamental command as well as the establishment of one or more destinations, which are your analytic services. However, as with most libraries nowadays, your SSR implementation will necessitate some attention.

Conclusion

Throughout our analytic journey, we faced challenges in determining which tools best suit your needs. We also faced challenges in determining the best approach to easily use and change them, and even use a couple of them at the same time. Of course, that is only one part of the journey, and there will be more challenges ahead.

What about you? What are your most recent challenges?