So we potentially can’t use a first-party domain for the server-side container for business reasons I won’t go into.
A couple of questions that would help finish our setup.
Is it still worth setting up the server-side container on a third-party domain, then utilising the benefits of FB CAPI and Google ads server-side tracking? Or might as well stick with browser-side events?
If server side still has enough benefits, are we better off sending FB events through CAPI only? As read this can help get around some of the limitations of IOS and Safari with the 7-day expiry.
The main reason to implement all of this is to improve attribution on Facebook and Google ads.
Any pointers around the be would be amazingly helpful.
There is no point in using server-side tracking without your own subdomain.
In this case the cookie will be set by a third-party domain and will actually be a third cookie - i.e. it will work worse than just a cookie set via JS.
We will be using a custom domain for the main site, but we have some microsites (hosted on other domains) that we can’t have a custom domain for right now, so just wanted to know if even worth setting up for these.
Can I just ask about the difference between using the standalone Stape Facebook CAPI integration vs the full server-side container setup? i.e we can still send events using this and benefit on the microsites?
If we can get some benefit from Facebook CAPI integration on these microsites that would be enough for now.
If those other other sites can’t have their subdomains it makes very little sense to go server-side for those.
You answered it yourself, CAPI Gateway is a standalone tool and that would be the main difference, because you can utilize sGTM for many other destinations while the Gateway only gives you FB. Also the Gateway will just replicate all Pixel events, while in a container setup you explicitly control what you send.
To be most beneficial, Gateway would also ask you to create a custom subdomain anyway, so same story in the end.