[Stape webinar] Meta CAPI in 2026: what changed, what works, and your questions answered

Yes. CAPI Gateway can work with a web GTM setup.

Best practice is to use a single data source. Correct deduplication can reduce the risk of duplicates, but the setup should still be kept as clean as possible.

In this case, there is no need to use both CAPI Gateway and Signals Gateway at the same time. One or the other should be used.

Yes. sGTM is the most flexible option and offers the widest range of features. However, it usually takes longer to set up compared to simpler gateway-based solutions.

Meta supports the net_revenue parameter, which can be used to pass the actual profitability of an event instead of only the total value.

However, net_revenue should be sent alongside the standard value parameter, not instead of it. The best practice is to send both.

For leads submitted directly through Meta Lead Forms, FBC and FBP may be available on the original lead event. For later CRM events, matching usually needs to rely on other identifiers, such as email, lead ID, or customer ID.

If FBC/FBP values are available, they should be saved in the CRM so they can be reused later in webhooks. For offline or in-store steps, a custom workaround can also be used, such as passing saved identifiers through a webhook or QR-code flow.

For Meta, the best practice is to send both web and server-side events, as long as the setup is configured correctly and deduplication is working.

Server-side events should not simply replace browser events unless there is a specific reason to do so. A combined browser + server event stream is the recommended approach for Meta.

A properly configured setup can reach very high tracking accuracy. Using an own CDN or same-origin approach for the tagging server URL helps bypass ITP restrictions, while Stape Custom Loader helps reduce the impact of ad blockers.

With these elements configured correctly, tracking accuracy can reach up to around 99%.

Meta’s CAPI parameter documentation is the best reference: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters

As a general rule, all available user data should be sent where possible, such as email and phone number. For eCommerce, the minimum set of quality event data should include value, currency, and contents.

Email and phone number usually contribute the most to Event Match Quality.

The most common approach is to save user and click data in Stape Store during the landing or signup event, then reuse that data later when the purchase or conversion event happens.

Email is the strongest identifier in this scenario.

FBC should be sent only when it is available. It is usually available when the user clicks through from a Meta ad.

The key requirement is to make sure the user has given valid consent where required by local legislation.

Technically, these gateway solutions are not very different. The main differences are usually setup simplicity, support, and how the solution is managed.

If the existing Stape setup is already configured correctly, switching to Meta’s one-click/free solution is unlikely to bring a noticeable improvement in Event Match Quality, event coverage, deduplication, or attribution accuracy.

Unfortunately, there is no workaround for restrictions that Meta has already imposed on the account.

The technical setup does not need to be different by default. The main difference is local legislation, especially around consent requirements.

The freshest and fastest data is the most valuable. Meta’s systems react quickly to incoming signals, so real-time data helps the algorithm show ads to the right users sooner.

A short delay is still better than no data, but the ideal setup is to send events as close to real time as possible.

The recommended setup is to use both Meta Pixel and Conversions API.

Pixel and CAPI complement each other: Pixel captures browser-side signals, while CAPI helps recover data that may be lost in the browser. Meta also shared that advertisers saw an average 17.8% CPA improvement when adding any version of CAPI on top of Pixel.

A hybrid setup is recommended because it usually provides stronger optimization signals than using only one method.

One of the key recent updates is the ability to send net revenue, which supports profit-based optimization rather than only revenue-based optimization.

Another important update is the Append Value standard event. It allows advertisers to retrospectively assign value, lifetime value, and net revenue to a purchase that already happened.

Overall, Meta is moving toward making CAPI more flexible, so advertisers can send business-specific signals such as margin data, attribution data, and other values that reflect what matters most to their business.

Yes, server-side tracking can still be valuable.

Meta Lead Ads forms can track form submissions by themselves, but not all leads have equal business value. Server-side tracking makes it possible to send qualified leads, CRM outcomes, and later-stage conversion data back to Meta.

This helps Meta optimize not just for form submissions, but for leads that are actually valuable to the business.

 CAPI Gateway remains a core part of Meta’s Conversions API product set. It is accessible, quick to implement, and useful for improving web event coverage.

There is no universal “better” option. CAPI Gateway is a good fit when a business needs a fast, simple setup. More advanced methods, such as server-side GTM or custom backend integrations, can be better when the business needs data enrichment, filtering, more control, cross-channel journeys, or more complex backend logic.

A business can also start with CAPI Gateway and later layer a more advanced implementation on top, with deduplication handled on Meta’s side.

The best approach is to follow established best practices from Meta, Stape, and trusted tracking experts.

This includes reviewing implementation quality, avoiding common setup mistakes, checking what data is sent, and using the webinar follow-up resources for detailed implementation guidance.

Stape and Meta Pixel are different types of tools.

Meta Pixel is Meta’s browser-side tracking product. Stape is an infrastructure and hosting provider that can support server-side tracking, including Meta Conversions API implementations.

They are not mutually exclusive. A typical setup can use Meta Pixel together with Meta CAPI hosted through Stape or another server-side solution.

The effectiveness is generally similar to other sectors, as long as the nonprofit sends relevant and allowed signals.

Conversions API follows the same data policies as Meta Pixel. If certain data fields are restricted because of the sector, regulations, or policies, those restrictions also apply to CAPI.

CAPI is not a workaround for restricted data, but nonprofits can still benefit from better signal coverage when they send all permitted, relevant data.

Yes. Stape provides several MCP options, including Stape MCP, Google Tag Manager MCP, GA4 MCP, and Google Ads MCP. Meta also has its own Meta Ads MCP.

MCP effectiveness depends on two main factors: the user’s domain knowledge and the quality of instructions given to the model, and the quality of the LLM used with the MCP.

A setup can technically be created with little knowledge, but it will likely take more time and require more debugging. Some tracking and tool knowledge is still important for guiding the AI and validating the output.

The priority is compliance. A healthcare setup must follow all applicable legal, regulatory, and platform-specific rules.

Once the implementation stays within those requirements, the available Meta tools can optimize using the data that is allowed to be sent. Restricted data should not be sent through Pixel or CAPI.

Meta does not have a direct equivalent to Google’s Advanced Consent Mode or cookieless pings.

The advertiser is responsible for deciding whether data can be sent. If the user’s consent state does not allow sending a conversion or setting a cookie, that data should not be sent to Meta.

The practical rule is simple: send data only when the consent state allows it.

It depends on the definition of “true server-to-server.”

A purely server-to-server setup would send signals from one backend directly to another without browser involvement. CAPI Gateway often starts with browser-collected data and sends it through a server path.

However, many tracking events originate in the browser by nature. In practice, CAPI Gateway still provides server-side benefits, including stronger signal persistence and, depending on the setup, better cookie behavior. A fully browser-free server-to-server setup usually requires a much more robust technical stack.

One-click solutions are useful for simple setups, but they are less flexible.

Clients may later need custom logic, such as excluding specific events, controlling which parameters are sent, filtering data, or sending events to multiple platforms. Server-side GTM provides more control and can support many destinations, not only Meta.

If a business already needs GTM for other platforms and advanced logic, moving everything to a one-click solution may become redundant.

The choice is not determined only by industry or business type.

It depends more on how advanced the tracking stack needs to be, how much the team is willing to invest, how many systems are involved, and how much control the marketing team requires.

Simpler businesses may be fine with a gateway. More complex businesses, multi-platform setups, or teams with advanced data requirements usually benefit more from server-side GTM.

Yes. Additional cost or profitability-related information can be passed using fields such as net revenue.

This supports more profit-aware optimization and reporting, rather than relying only on gross conversion value.

Centralization depends on the Meta datasets/pixels.

If all countries report to one dataset, a central CAPI setup can be used. If each country uses its own pixel/dataset, then events must be sent to the relevant dataset, so there is no single CAPI destination in practice.

Server-side GTM can be especially useful in this situation because it makes it easier to manage multiple destinations and routing rules. Gateway-based options can also support multiple pixels, but sGTM gives more control.

Not anymore.

A longer window may not be very useful because the signal becomes stale. Meta optimization benefits from fresh data, and three months is already far from real time.

It depends on the business model.

For SaaS or subscription businesses, updating LTV every month for every customer can become too complex. A better approach is often to calculate a predicted lifetime value on the backend and send that expected value.

For other business models, where purchase value changes are more event-specific, updating the value may make sense.

Platform rules and restrictions should always be followed.

Meta may generally recommend sending more data because it improves optimization, but if a specific event, pixel, industry, or policy restriction does not allow certain personal data, that data should not be sent.

If Meta does not accept the data for that event or account, there is no practical workaround; the data will not be used.

The answer was only partially covered.

For matching logic, transaction ID is expected to be the main identifier for Append Value, especially for purchase-related adjustments. Other signals such as FBC, FBP, and first-party data may also be considered, but transaction ID is likely the main stitching key.

The exact limits, accepted lookback window, and zero-value behavior were not confirmed during the webinar and require follow-up.

It is not the same as having only Meta Pixel on the web.

If the event happens in the browser, Pixel should usually still be used together with CAPI. If the event is server-only and cannot be tracked in the browser, then CAPI is the correct method.

For CRM data, the correct action source depends on what the event represents. If it is related to Meta Lead Ads and includes lead IDs, the CRM action source can be important. If the CRM event represents a purchase or conversion that started on the website, it may still be treated as a website conversion.

Cross-domain tracking should be handled intentionally. Stape has blog resources on cross-domain tracking, and support can provide additional guidance if needed.

Restore can be one possible solution, but it is not the whole setup. Cross-domain tracking requires proper handling of identifiers and attribution across domains, and it can also be managed with server-side tracking.

Usually not.

For subscription businesses, the better approach is generally to predict lifetime value in advance and send the predicted value, instead of updating it every time a subscription cycle occurs.