Some time ago, we tried to implement the FB CAPI GW on one of our sites using Stape. The basic configuration in Stape and FB was easy but I couldn’t manage configure the Meta Pixel to send the data to the subdomain that was configured in Stape.
If I get the whole thing about using the FBCAPIGW is to send the events from the Meta Pixel to the Stape CAPIGW instead of facebook[.]net. Instead of using a third-party domain like facebook.net as destination, we should use a subdomain like capigw[.]subdomain[.]com and send the events there. As it’s a subdomain of the current website, it’s less prone to script blockers. As stated on the Stape website “Receiving data through a first-party domain (DNS routing) can enhance measurement performance.”
If this is correct, how do I have to configure the FB Meta Pixel to send the data to the subdomain configured in the CAPIGW in Stape? Sending it to the default capigw[.]stape[.]io (or so) would also be another third-party domain.
Back then, I tried to set the endpoint in the Meta Pixel Script to point to the subdomain using “fbq(‘set’, ‘endpoint’, ‘URL’);” but that didn’t work.
Back then, I followed the documentation here: How to Configure Meta Conversions API Gateway | Stape. Although everything worked well, in the end, the data wasn’t sent to the subdomain configured in DNS routing. Therefore, no better performance :).
How do I have to do this or do I have a misunderstanding of the concept of it?
As we would like to try it again, I would be thankful for any ideas/insights on this matter.
Meta Conversions API Gateway works based on the data that Meta pixel sends. This means that every time CAPIG sees an event triggered by Meta pixel, it sends server events.
CAPIG Gateway works automatically, and all you need to do is add the pixel to your Gateway. No additional actions are required to send events to the Gateway Hub, regardless of whether you have configured Data Routing (custom domain) or your Hub is still on the standard Gateway Hub domain.
You can find instructions and general information in our guide: Meta Conversions API Gateway: step-by-step setup guide | Stape
If you provide us with your Stape account or your website, we will be able to verify the correctness of the settings.
Thanks for your fast response. Okay, in that case, everything was correctly configured as in the end, I saw browser and server events.
But this leads to the question of how using the CAPIGW differs from just using the Meta Pixel, except for getting the events from an additional source (server-side). As the Meta Pixel is sending the events still to a third-party domain (facebook.net, and capigw.stape.com or so), it doesn’t have any benefit in terms of seeing more events that probably would have been filtered out / blocked by the browser when using a third-party domain instead of a first-party domain.
Wouldn’t the latter be the goal? To have the Meta Pixel send those events to the CAPIGW through a first-party domain (subdomain)?
I’m sure I have a misconception about CAPIGW and its benefits. But maybe you can share some words on this?
To give you more context, we’re currently implementing the “full” solution with sGTM using Stape, but we also want to see if there’s a “reduced” variant for clients that only use Meta ads. I was thinking of the CAPIGW, but I can’t see how it’s beneficial.
First of all, it is highly recommended to connect your own subdomain to your GW, so that events will not be sent to a third-party subdomain, but to the subdomain of your site where events are tracked.
In general Meta CAPI GW - is a simple and cheap solution for connecting server events. It has less protection against adblockers and ITP restrictions than integration via sGTM. So if you have the opportunity and/or Meta is an important traffic source for you, it is definitely better to configure all tracking via GTM/sGTM. GW is a solution if such a possibility is not available due to higher cost of servers + cost of configuration.