How to abstract Custom Dimension settings so I don't need to set them in every tag again

[loldenburg]

I have a new, absurdly redundant-looking PP Tag Manager setup where each tag (e.g. “click on button x”, “virtual pageview y”) defines dozens of custom dimensions to set, plus the same for dozens of sites… This can’t be the norm…

I am thus looking for something like the “GA Config Tag” where I can say "whenever a Piwik Pro request is triggered, also set custom dimension 1 to {{Data Layer Variable content.language}}, custom dimension 2 to {{Data Layer Variable user.login_status}} etc…).

Please tell me there is sth like this and I am just missing it…

[kuba]

What about setting it in the main Piwik PRO tag or the Custom Dimension template? In both cases, all other templates (such as custom event) should reuse this configuration.

[loldenburg]

Thanks, I had not seen that…
Btw is there like a demo video / guide for how to set up a scalable tracking setup with PP Tag Manager?
Can’t be the norm that you set up billions of individual “Tags” per Site:

(this is just the first page)

[kuba]

I think you can slim it down a lot, but then you have to use custom code tags which you’d like to avoid I guess (for more advanced setups). Then you simply go with one template and control the data and triggers via datalayer and variables for instance.

[loldenburg]

Thx, I am fine with Custom Code as long as it seems sensible. I find this to be a case where it can be justified as the redundancy removal potential is gigantic.

[anthonybartczak]

@loldenburg

To answer one of your questions

where I can say "whenever a Piwik Pro request is triggered, also set custom dimension 1

The setCustomRequestProcessing method is usually used to modify query parameters of a tracking request but it can also be used to execute some code on each request.

It might be pretty difficult to give some specific advice without taking a deeper look into the Tag Manager setup first or knowing how it works in general. Note that the tips mentioned below won’t work for everyone, some of them might be a bit too basic or are already applied to your setup.

Unifying event tags

Let’s say you have multiple similar elements you’d like to track. We can use a navbar as an example here.

Depending on how your website is built, you can use the same class or id attributes that occur across multiple HTML elements. In this case we could use a “Click Classes > contains > menu-” and use the built-in Click Element or Click URL variables to categorize the custom event.

Some of them might require you to write more complex CSS or XPath syntax but it could be worth it in case you are trying to minimize the amount of tags.

Using dataLayer events

In my experience, quite a lot of Tag Manager clutter comes from trying to work around the limitations of the website or app that you are working with. Whether it’s because you don’t have access to unique attributes or the attributes are simply generated dynamically - you can try to implement dataLayer pushes in the source code.

This usually requires you to either have a website developer or have some technical knowledge yourself.

Using Piwik PRO Analytics goal tracking

In some cases using goals instead of custom events for tracking important interactions could be a solution. Even though the Piwik PRO Analytics goal conversion feature might seem limited compared to the Tag Manager, it can eliminate a couple of tags from your setup.

Using a meta setup

This will only work in case you have created multiple Piwik PRO sites.

The meta setup is a great way to minimize the amount of tags required for each individual Piwik PRO site. Not only will it reduce the amount of clutter in a single Tag Manager property, it will also allow you to manage tags, triggers and variables from a single global view.

[loldenburg]

Thanks for sharing additional hints!

Yes, I am definitely not a fan either of setting up all events in a TMS, especially when they are based on absurdly complex DOM selectors, that’s just waiting for the next website HTML change to destroy everything again. With a Data Layer, it is more effort initially, but it is usually more robust, because the website developers see in their code that there is actually a “tracking” there.