Enable Tag Manager to trigger (supported) pixels serverside

[peterbo]

If we think of a Tag Manager more like a data pipeline and less of a javascript library container, it would make sense to support serverside tracking.

The goal is to collect all data from a website via one client tracking solution and internally coordinate and enrich data to be sent to their destinations server side. This would also make handling of consent and privacy a lot easier, since you are 100% in control of what data is forwarded to external services. For example, you can prevent third party codes to set cookies or grab all kinds of client request data, or inject other code thorugh their Javascript libraries.

Some players, e.g. segment.com are doing this as a primary business objective, Tag Manager providers are starting to hop on the train as well (e.g. Google: https://developers.google.com/tag-manager/serverside/intro).

[tsteur]

Interesting @peterbo didn't hear about this before. Was just reading a wee bit about it. Just so I understand it correctly the serverside part would be eg a new subdomain that runs a specific package. The web container configures the JS tags to send the data (where possible) to the subdomain instead of the analytics provider directly and then the subdomain issues the request? Not sure yet how the data would be coordinated or enriched server side or maybe I'm understanding the concept wrong? Would the server side part be configurable or other people can hook into things?

And do I understand from a privacy/consent perspective you would be 100% in control because no matter what a tag manager user configures you would block / guarantee a certain data flow somehow server side?

I suppose this be mostly interesting for analytics tracking requests? Do we know if this works also for things like FB pixel etc (not sure if these requests can be proxied etc)?

Checking I'm understand things somewhat in the right direction :)

[peterbo]

Hey @tsteur - the subdomain thing is Google specific. GTM is not a "server" per se, so they urge you to spin up a GCE to trigger your serverside tags. For (on premise) Matomo, this wouldn't be a thing, because it can directly call the tags (because it's already running on a server).

I scribbled an (ugly) structure of this:

Basically, the request back to Matomo (with all info from the TagManager object (e.g. hydrated variables, executed trigger, etc.) is the trigger for the serverside tags that can then execute with a certain logic. Serverside tags are Pixels oder tracking APIs, so GET or POST methods would be needed for serverside Tags.

[tsteur]

Thanks for this @peterbo I understand it now how it works technically. What is not 100% clear yet is when this becomes interesting or for which audience this is interesting. Of course with Matomo the benefit is this would come out of the box but spinning up a GCE is a bit more work etc so I wonder when / why companies/orgs make this effort. I'm assuming of course when they need to guarantee a certain data flow so thinking of websites with sensitive data (health/banks/...)? Does the server side usually forward cookies and IP addresses and also set cookies? I'm assuming this would need to be done to ensure things work the way they should? And the main benefit would be that if for example no consent is given then you can guarantee no such data is being processed?

[peterbo]

Duplicate of https://github.com/matomo-org/tag-manager/issues/509

[mattab]

Copying the comments from @atom-box in https://github.com/matomo-org/tag-manager/issues/509

• In July, one user asked if they could, "use Matomo Tag Manager for the implementation of Tags in server side."

• In May, one user asked does Matomo have, "Server-Side Tag Manager (similar to GTM Server Side, but obviously, sticking with Matomo, and staying away from all products; so anything else outside of cloud too). This is for analytics, but not for tag management. Do you have anything for server side tag management please? "

• In March one user asked, "This maybe a really stupid question, but does Matomo support Google GTM Server-side Tagging?"

• "Most of the infrastructures I maintain are currently shifting towards server side tag management (to mitigate effects of GDPR, iOS script blocking). I am currently unaware of the Matomo efforts in this field."

[peterbo]

Hey @tsteur, sorry, I somehow forgot about this ticket and answer.

And the main benefit would be that if for example no consent is given then you can guarantee no such data is being processed?

One of the advantages, right. You don't have to control x different, 3rd party tools on the client side, but you only have one data stream (e.g. the dataLayer plus client info is streamed from the client side to the matomo server) and from there, you can customize the handling of all 3d parties. No 3rd party will have "direct contact" with the client anymore and you can strip PII, IP address and all other sensitive data from the 3rd party tracking. That is so popular, that there are more and more SaaSs doing (among other things) just that like server-side GTM, Jentis, Funnel.io, Segment.com, etc. So the demand for serverside data steering is definitely massive. This could be a feature of the TagManager or even a real "product" sitting on top of the TagManager.

Does the server side usually forward cookies and IP addresses and also set cookies?

That depends on what data the 3rd party needs. Usually no cookies but just certain data.

There is also TCF2 that could be handled with this server-side implementation. In addition, server-side TagManagement could also make app tracking more flexible. Currently, you can't manipulate / control / hydrate data coming from SDKs. In the future, all data that is coming in could be running through a server-side TagManager (data pipeline) where you can manipulate / control / hydrate the stream, defining a certain ruleset.

[atom-box]

Another upvote here for "let's do MTM serverside":

we have recently migrated away from Google Tag Manager and started using CloudFlare Zaraz to offload all the tracking tags to the CloudFlare Edge. I see Matomo has it's own tag manager, but from my reading of the docs it's more than likely similar to Google Tag Manager in that the Javascript tags are still running in the client browser and not offloaded to server side? Is that any support for CloudFlare Zaraz, or plans to support it? I do see you have a CloudFlare plugin, but not sure how that compares Zaraz?

[kendallb]

Simplest solution for those who are CloudFlare customers would be to write a support module for CloudFlare Zaraz and either have CloudFlare publish it or find a way to publish it yourself. We are already using it for our web sites and it works amazing to improve performance for all the Javascript triggers.

https://www.cloudflare.com/products/zaraz/

They have a dev kit now so you can build your own integrations.

[jgoslow]

+1 for this feature-set. Triggering tags on the browser has a number of downsides, but mainly the advantages I see here are:

• speed/performance improvements in getting some tags off of the front-end
• more reliable tracking
• Matomo already has a backend server running for every installation, so the tech overhead to add this feature is low.

[Chardonneaur]

Hi guys, i got a meeting today with someone looking for this feature.

[Chardonneaur]

I got a meeting yesterday for a user asking for this feature. To make it simple, here are the benefits and why people are asking for it:

• using MTM server-side will allows our users to collect 100% of the data because it’s more accurate.
• Google also has a GTM server side, and all the big companies are now asking for it.
• From a GDPR compliance perspective, it’s a much better option.
• Today, you might have 20 different scripts deployed for 20 different solutions. Tomorrow, you’ll only need one script, which will distribute the data to those 20 solutions. Essentially, the HTTP request that sends the data to third-party solutions will no longer be executed on the user’s browser, but instead on the server running MTM.

[Chardonneaur]

Another user asked for it today.