I'm curious as to whether or not you've studied the implications of executing certain 3rd party tags from a server side context.
I work in ad-tech, and we rolled out a feature much the same as this almost 4 years ago now. The issue is that many tracking scripts rely on 1st party signals (and seemingly, ips) for end-users to capture the full value of their use. Facebook and GAds specifically perform quite poorly when executed in a 3rd party context. Not that they don't track, but that they're often unable to attribute the event to the correct (or any) user. This works against efforts like re-targeting and optimization. In FB's case, their own server-side attribution solution has a "match rate", which in practice is quite low for any event that does not include 1st party information. FB cookies are only available for a subset of active customers as well.
It's indeed one of the toughest nuts, and also the one reason we don't simply "Cloud Load" all third-parties. It really is a case-by-case thing, but in general we developed some pretty sophisticated loading techniques to overcome exactly this issue. We gave quite a thorough example of how we're loading the Facebook Pixel on https://zaraz.com/engineers. I don't want to just copy-paste it here, but I'd be happy to say more about it if you have any questions. The short answer is yes, it's hard, we don't always do things server-side partly because of this, but we find other ways to still optimize even if some things have to go client-side.
Your approach makes sense, have you managed to validate that these signals are equivalent in-platform (Facebook)? I don't know how deep I should go, but there's also a distinction between events tracked in Events Manager vs those tracked in Ads Manager, as well as a suite of changes w/ regards to Aggregated Event Management (AEM) that's rolling out now.
For your server side integration are you using the Conversion API or are you reconstructing the GET signatures for their FB pixel?
We don't have access to the internals of these system obviously, but we've worked very very closely with some of our customers to make sure nothing weird is happening after switching. It previously required a lot of fine-tuning, now it's usually quite smooth.
For the FB Pixel, we're doing both :) We do use the Conversion API (with the first-party cookie), but we sometimes do reconstruct the GET request on our backend and pass the final URL to the browser to execute. Most tools are not as complicated though.
I work in ad-tech, and we rolled out a feature much the same as this almost 4 years ago now. The issue is that many tracking scripts rely on 1st party signals (and seemingly, ips) for end-users to capture the full value of their use. Facebook and GAds specifically perform quite poorly when executed in a 3rd party context. Not that they don't track, but that they're often unable to attribute the event to the correct (or any) user. This works against efforts like re-targeting and optimization. In FB's case, their own server-side attribution solution has a "match rate", which in practice is quite low for any event that does not include 1st party information. FB cookies are only available for a subset of active customers as well.
What has been your experience w/ these things?