为什么需要Facebook转换API来在第三方Cookie日落之后继续跟踪用户？
我希望这个问题在这里是主题的，因为它涉及Facebook跟踪的技术方面。
几个月前，Facebook发布了他们的转换API（CAPI），以使他们可以直接从服务器发送用户活动事件，而不是使用经典的Facebook像素从客户端发送事件。
据说，他们发布了CAPI，因为Facebook像素使用第三方Cookie来识别用户，并且在2023年的某个时候，Google Chrome将开始阻止第三方Cookies。这种更改应该使客户端的Facebook像素无用，或者至少是每个营销博客所说的话。
事实是，从我在浏览器DevTools中看到的内容，Facebook像素在第一方上下文上插入了名为_FBP的cookie（还有另一个名为_FBC的cookie，如果访客从Facebook广告降落在网站上）。这两个cookie是用户和网站独有的。然后，Facebook像素将cookie值作为查询参数附加到每个事件中Facebook服务器的GET请求。
因此，如果Facebook像素正在生成并阅读这些第一方Cookie＆amp;在每个事件中将它们作为查询参数附加，转换API有什么关系？据说它应该解决第三方cookie阻止的问题，但是我们在这里没有使用第三方cookie，无论如何我们将值附加到URL中的cookie，而不是在cookie标头中发送值。
我想我在误会一些东西。任何帮助都非常感谢！谢谢！
I hope this question is on-topic here, as it's about the tech side of the Facebook tracking.
Some months ago, Facebook released their Conversions API (CAPI) to make it possible to send them user activity events directly from your servers, instead of sending the events from the client using the classic Facebook pixel.
Supposedly, they released CAPI because the Facebook pixel uses third-party cookies to identify the user, and at some point in 2023 Google Chrome will start blocking third-party cookies. This change should render the client-side Facebook pixel useless, supposedly, or at least that's what every marketing blog out there says.
The thing is, from what I can see in my browser devtools, the Facebook pixel inserts a cookie named _fbp on a first-party context (and also another one named _fbc if the visitor landed on the website from a Facebook ad). These two cookies are unique to the user and the website. Then, the Facebook pixel attaches the cookie values as query params to the GET request that does to the Facebook servers on every event.
So, if the Facebook pixel is generating and reading these first-party cookies & attaching them as query params on every event, what's the deal with Conversions API? Supposedly it should solve the problem of third-party cookies blocking, but we're not using third-party cookies here, and anyway we are attaching the value to the cookie in the URL instead of sending the values in the cookie headers.
I guess I'm misunderstanding something. Any help is much appreciated! Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
问题中的逻辑是完全正确的。我认为混乱主要来自术语。
Facebook帖子喜欢这个不要将第三方饼干与第一方饼干进行比较；相反，他们将它们与第一方数据进行了比较。该术语通常是指客户自愿提供的数据，例如以表格中输入的电子邮件和电话号码，以及该应用程序或商店可能使用的持久用户标识符。
当像素跟踪使用JavaScript代码的事件时，它确实可以访问当前
_FBPcookie，该cookie可能与付费广告单击有关，或者可能来自其他设备。例如，如果在购买后跟踪的事件在感谢页面上，则通常不会在那里提供个人身份信息。相比之下，所有这些都是服务器端。如果客户之前已在网站上注册，则服务器将具有原始的点击ID，名称，电子邮件等。因此，与像素跟踪相比，在许多情况下，服务器端集成将具有更多的数据来归因转换。
换句话说，这不是cookie的类型。如果
_FBPcookie是无用的，则在服务器上存在其他数据可能会很有用。从理想（对于广告平台）世界中，第一方饼干成为一个局限性，跨域第三方cookie将始终可用，并且不需要
_FBP第一方饼干是因为跟踪像素可以在任何网站上访问Facebook.com cookie。像这样的第三方饼干仍在Chrome中部分可用（直到2024年），但多年来一直没有在Safari中使用。因此，第一方cookie以及服务器端集成是行业移动的地方。对于客户立即购买而又永远不会返回的网站，第一方Cookies可能完全足够，但是对于其他任何东西来说，它们是一个严重的限制。
转换API集成，可确保其可以访问原始点击ID，cookie，个人数据等（而不是尝试通过第一方域代理像素请求，希望跟踪阻滞剂不会像许多人一样注意做）可以对广告管理器数据产生巨大的影响。
The logic in the question is entirely correct; I think the confusion mostly stems from terminology.
Facebook posts like this one don't compare third-party cookies with first-party cookies; instead, they compare them to first-party data. This term typically refers to the data customers provide voluntarily, such as emails and phone numbers entered in forms, as well as persistent user identifiers that may be used by the app or a store.
When a pixel tracks an event with JavaScript code, it indeed has access to the current
_fbpcookie, which may be relatable to a paid ad click or it might be from a different device, for example. For instance, if the event tracked is on the thank you page after a purchase, there would often be no personally identifiable information available there.Contrastingly, it's all available server-side. If a customer has signed up on the website previously, the server would have the original click ID, name, email, and so forth. So in many cases, server-side integration would have a lot more data to attribute the conversion, compared to Pixel tracking.
In other words, it isn't the type of cookies; it's the presence of additional data on the server that may be useful to attribute the conversion if the
_fbpcookie is unhelpful.First-party cookies become a limitation in a sense that in the ideal (for ad platforms) world, where cross-domain third-party cookies would've always been available and there would be no need for
_fbpfirst-party cookie because the tracking pixel has access to the facebook.com cookies on any website. Third-party cookies like this are still partially available in Chrome (until 2024), but hasn't been available in Safari for years.Thus, first-party cookies plus a server-side integration is where the industry moved. First-party cookies may be entirely sufficient for a website where customers buy immediately and never return, but for anything else, they're a serious limitation.
A Conversions API integration that ensures it has access to the original click ID, cookies, personal data, etc. (instead of attempting to proxy the Pixel requests via the first-party domain in the hope that tracking blockers won't notice, as many do) can make a huge difference in the Ads Manager data.
这不仅仅是第一与第三方。即使是由JavaScript而不是安全服务器设置的第一方Cookie也会受到Apple ITP的影响，这将在7天后在任何此类cookie中过期。
It's not just about first vs third party. Even first-party cookies, if set by JavaScript instead of a secure server, are impacted by Apple's ITP, which will expire any such cookies after 7 days.