[Enhancement] Add "last triggered" date information to tags

[SW-Vincent]

Websites evolve a lot, and sometimes the team in charge of tagging is not always told.

It'd be useful to have the date of the last trigger of the tag in order to know weither the tag is still working or not.

[snake14]

Hi @SW-Vincent . Thank you for taking the time to suggest that enhancement. Sadly, I don't see that change being made soon. Unless the tag sends a request back to the Matomo server, we wouldn't know that the tag has been fired. I suppose we could update the JavaScript to periodically send a new request type back to the Matomo server containing a list of all of the tags that have been triggered.

What do you think @AltamashShaikh ?

[AltamashShaikh]

@snake14 yes we need to send some info back to server and log that, in order to show the date, we need to think more on this on how to store the data, if a website has too many tags firing, this will result in extra tracking request for Cloud also,

[SW-Vincent]

this will result in extra tracking request for Cloud also

Wouldn't be this quite light, as only the last hit (tag reference + date) would be stored ?
Unlike the usual Analytics data, any new occurrence of hit for the same tag reference would result in the previous hit to be deleted i assume. Would each new hit still count within Matomo Cloud plan then ?

This may also raise concerns about versionning and preview though :

• the main point is to see weither or not the current version of tags has been triggered recently , but we do not have a synthetic view of live version atm
• if the tag or the triggers of the tag change, i wonder if the status shouls be reset to never triggered
• if a new versio is created and a tag do not change, the status is inherited from previous version

[snake14]

this will result in extra tracking request for Cloud also

Wouldn't be this quite light, as only the last hit (tag reference + date) would be stored ? Unlike the usual Analytics data, any new occurrence of hit for the same tag reference would result in the previous hit to be deleted i assume. Would each new hit still count within Matomo Cloud plan then ?

@SW-Vincent It's not so much the size of the request as it is adding new requests being sent to the server. Adding new requests being sent to the server would likely count against a Cloud customer's quota. Finding the right balance of sending the data in a timely fashion without adding too many new server requests would be a challenge, especially when trying to make sure any data gets sent before the visitor might close the window.

Good points about the versioning and preview. Also things that would need to be taken into consideration if we were to try implementing this enhancement.

[SW-Vincent]

It's not so much the size of the request as it is adding new requests being sent to the server

I was referring to the number of hits actually stored rather to the hit size.

Within website views, all hits sent are stored and "stack-up" to each other, but within this feature only the last hit per tag is stored, which means although the number of hits sent might be hight, the number of hits actually stored remains roughtly the same over time.

For the server, it means way less elements to store, for the billing plan it depends weither we consider the hits sent or the hits stored.

[snake14]

It's not so much the size of the request as it is adding new requests being sent to the server

I was referring to the number of hits actually stored rather to the hit size.

Within website views, all hits sent are stored and "stack-up" to each other, but within this feature only the last hit per tag is stored, which means although the number of hits sent might be hight, the number of hits actually stored remains roughtly the same over time.

For the server, it means way less elements to store, for the billing plan it depends weither we consider the hits sent or the hits stored.

@SW-Vincent Correct. What we're discussing would be storing a single new data-point per tag. The concern that @AltamashShaikh and I have is that it would likely increase the number of API requests, which could potentially lead to quota issues for our Cloud customers.

[Stan-vw]

If I understand it correctly, this would create an extra hit for cloud customers for every tag every time we send this information.
If a customer has 20-100 tags that fire multiple/many times per second because they have a high volume website, this could start eating into their cloud hits quota.

I'm not sure if it's possible to run this only once per day, so that you'd know if your tag is still active months down the line (rather than having stopped working due to changes to the website, as described in the original post). If someone has 100 tags, and every day they indeed get 100 extra hits that adds up to 3000 extra hits per month. To me, that sounds reasonable for someone that's so active with tags, especially if you can choose to have this turned on/off.

@AltamashShaikh @snake14 you might have ideas on the feasibility of this?

I'm also wondering how many people would use this feature. It might be pretty niche, what do you think @SW-Vincent ?

[SW-Vincent]

If someone has 100 tags, and every day they indeed get 100 extra hits that adds up to 3000 extra hits per month. To me, that sounds reasonable for someone that's so active with tags, especially if you can choose to have this turned on/off.
I'm also wondering how many people would use this feature. It might be pretty niche, what do you think @SW-Vincent ?

As long as the impact on quota is reasonable, this is a really good feature for agencies or structures that have separates persons / activity poles responsibles for development and tracking.
If you can chose to switch this option on / off, it's even better !

Also, as the whole point is knowing weither tags triggers from times to times or not, one hit per tag per day is enough.

Finally, it might be useful if we could set alerts on tags not being triggered per day / week / month.

[AltamashShaikh]

@Stan-vw Fire once a day would still increase 1 HTTP call, which will increase the load as it will query the DB runtime to determine, which tags are fired or not.

1. A HTTP call to check which all tags are triggered (this will add a load to our servers as the query would be realtime)
2. We won't be sure that the tracking call will be triggered only once as multiple people can view the site at sametime, depends on sites traffic per second.

[AltamashShaikh]

@Stan-vw We had a discussion on this and the best solution is to give an option to "Track each tag fired" as an event, the event could be something like this.
eventCategory: TagManager, eventName: {Name of the Tag}, evenAction: {Name of the trigger}

And someone can easily create an alert if we track it as an event.

Mockup

[Stan-vw]

That seems like a really clean way to implement it @AltamashShaikh , nice!

Did the team also discuss how we can make it cost effective, such as tracking it maximum once per hour/day?
I'm not sure I really understand your comment above: yes it'll make an extra http request and the new data will need archiving, but at 1 hit per tag per day this seems like an extremely minimal investment.

It'd be good to see some numbers around the case where multiple people view a site at the same time. For example let's assume 10 million views per day and they're all in the same country and they all happen within 1 workday (8 hours), e.g. it's a huge website in America/India/China. There would be a peak load of ~2 million views in an hour, let's say a peak of 40 thousand in a minute, let's say 1 thousand in a second. If the website has 20 tags, how many extra hits do we expect to be fired for the "track all tags as an event" feature in this example?

[AltamashShaikh]

So the TagManager code runs on client side and the decision to track "fired tag" as an event, will also happen on client side. Now we want this event to be fired only once, but 1 client won't know that the tag has been fired by another client, so every client will send this request to server and server will decide if it should track or not.

For server this is resource intensive as we need to first scan the database, to check if we have any records for today or not and insert in db if not present.

Now if we have 2 million hits on a site and an event is fired each time a page is loaded, we will send 2 Million hits to the server which will check 2 million times that if we have the data or not and insert only once.

Each of this request to check and insert in DB would be a HTTP call and hence doesn't sound as good solution that we check 2 million times but insert only once.

[Stan-vw]

Thanks for explaining. So if I understand it correctly, it wouldn't reduce the #hits at all, hence not really a solution.

@AltamashShaikh do you think we could update the last time a tag was fire simply by using metadata from events that are coming in through each tag? or would that be tag-dependent

[AltamashShaikh]

was fire simply by using metadata from events that are coming in through each tag? or would that be tag-dependent

We need to develop a way to pass the tag info in requests and process the same, but this will cover only hits being sent to Matomo, we also have 3rd part tags like GA, FB conversion pixels and etc.