If you are running Meta ads in 2026, relying on the Meta Pixel alone is no longer enough. Browser-based tracking has been degraded by iOS privacy restrictions, ad blockers, and consent banners to the point where pixel-only setups miss over half of actual conversions. The Meta Conversions API (also called Meta CAPI) is the server-side tracking solution that closes that gap by sending conversion data directly from your server to Meta's servers, bypassing browser limitations entirely.
What this guide covers as of September 2026: This walkthrough reflects Meta's current Conversions API setup flow, as documented in Meta's Conversions API developer documentation: the CAPI Gateway, server-side Google Tag Manager, and manual/direct API methods; the fbp and fbc parameter requirements; and Event Match Quality scoring. Meta discontinued the standalone Offline Conversions API in May 2025. No newly announced 2026 changes to CAPI Gateway pricing or Event Match Quality scoring appear in Meta's current documentation beyond what this guide already covers.
This guide covers everything you need to know about the Meta Conversions API: what it is, how it compares to the Meta Pixel, the three main setup methods, the critical parameters that determine your data quality, how to configure event deduplication, how to connect your CRM, and how to optimize your Event Match Quality score for maximum ad performance.
Whether you are setting up Meta CAPI for the first time or migrating from the now-discontinued Offline Conversions API, this is the only guide you need.
What Is Meta Conversions API?
The Meta Conversions API (Meta CAPI) is a server-to-server tracking interface that sends web, app, and offline conversion events directly from your server to Meta's Facebook and Instagram ad platforms, bypassing the browser entirely. Unlike the Meta Pixel, which runs in the user's browser and depends on JavaScript execution, cookies, and uninterrupted page loads, the Conversions API operates independently of the browser environment, so purchases, leads, and other conversions still reach Meta even when a browser blocks the Pixel.
When a user takes an action on your website, such as completing a purchase, submitting a lead form, or adding an item to their cart, the Conversions API sends that event data from your backend infrastructure to Meta. This means that even when a browser blocks the Pixel, fails to load JavaScript, or restricts cookies, Meta still receives your conversion data. With the rollout of Meta's Adaptive Ranking Model, the quality of this signal data is more important than ever for ad ranking and delivery.
Meta designed the Conversions API as the long-term replacement for browser-dependent tracking. It now handles both online and offline conversion events through a single unified integration, which became especially important after Meta discontinued its separate Offline Conversions API in May 2025.
Meta Conversions API vs. Meta Pixel: What Is the Difference?
Understanding the difference between the Conversions API and the Meta Pixel is essential before deciding how to implement your tracking.
The Meta Pixel is a snippet of JavaScript code that loads in the user's browser. When a user visits your website or completes a conversion event, the Pixel fires and sends that data to Meta through the browser. This approach worked reliably for years, but privacy changes have steadily eroded its effectiveness. iOS 14.5's App Tracking Transparency framework, browser-based ad blockers, intelligent tracking prevention in Safari, and cookie consent banners all interfere with the Pixel's ability to fire and report accurately.
The Meta Conversions API sends the same event data, but from your server rather than the user's browser. Because server-to-server communication is not affected by ad blockers, cookie restrictions, or browser privacy features, CAPI captures conversions that the Pixel misses entirely. Stores running only pixel tracking typically see attribution accuracy drop to around 40% or lower, meaning more than half of their actual conversions go unreported.
The Meta Conversions API and the Meta Pixel differ mainly in where each one runs: the Pixel fires client-side in the browser, while the Conversions API sends the same event data server-side. That server-side path makes CAPI resistant to ad blockers, Safari's Intelligent Tracking Prevention, and iOS 14 App Tracking Transparency restrictions that degrade Pixel-only tracking.
| Aspect | Meta Pixel | Meta Conversions API |
|---|---|---|
| Data transmission path | Sends data from the user's browser to Meta. | Sends data from your server to Meta. |
| Reliability | Depends on JavaScript execution, cookie availability, and uninterrupted page loads. | Depends on your server being operational, which is more reliable and within your control. |
| Data richness | Captures only what happens in the browser. | Sends data from any source your server can access, including CRM records, point-of-sale systems, call tracking platforms, and offline events. |
| Privacy resilience | Directly affected by iOS App Tracking Transparency, ad blockers, and consent frameworks. | Operates server-side and is not affected by these browser-level restrictions. |
| Recommended setup | Run alongside CAPI to capture browser-side signals like scroll depth and page views. | Run alongside the Pixel in dual tracking, with event deduplication to prevent double-counting. |
Meta explicitly recommends running the Meta Pixel and the Conversions API together in dual tracking so the Pixel's browser-side signals and CAPI's server-side reliability combine into one complete data picture.
The Three Ways to Set Up Meta Conversions API
There are three primary methods for implementing Meta CAPI, each with different levels of complexity, cost, and flexibility. The right choice depends on your technical resources, platform, and whether you advertise exclusively on Meta or across multiple platforms.
Method 1: Meta Conversions API Gateway (Simplest Setup)
The Meta Conversions API Gateway is a managed, no-code solution that Meta provides for advertisers who want server-side tracking without custom development. It works alongside your existing Meta Pixel to automatically send server-side copies of Pixel events to Meta.
How it works. The CAPI Gateway monitors your Meta Pixel events. Whenever the Gateway detects a Pixel event firing in the browser, it simultaneously sends a server-side copy of that same event to Meta. Event deduplication is handled automatically, meaning you do not need to configure event_id matching manually.
Setup time. 2 to 4 hours.
Cost. Gateway hosting services run $10 to $400+ per month depending on your event volume and hosting provider. Stape, one of the most popular Gateway hosts, offers plans starting at $10 per pixel per month.
Best for. Advertisers who need a low-maintenance, automated setup with minimal technical work. Stores on Shopify or WooCommerce that want server-side tracking without developer involvement. Meta-only advertisers who do not need to send events to Google, TikTok, or other platforms through the same infrastructure.
Limitations. The Gateway mirrors what the Pixel sees. If a user's browser blocks the Pixel from firing in the first place, the Gateway has nothing to mirror, meaning it cannot capture conversions the Pixel misses entirely. It also only works with Meta and does not serve as a centralized tracking hub for other ad platforms. Customization options are limited compared to manual implementation or server-side GTM.
Method 2: Server-Side Google Tag Manager (Best Balance of Flexibility and Control)
Server-side Google Tag Manager (sGTM) runs in a cloud environment rather than in the user's browser. It receives events from your client-side GTM container (or directly from your website) and forwards them to Meta's Conversions API endpoint, as well as to any other ad platform you use.
How it works. Your website sends events to a GA4 web tag, which forwards them to your server-side GTM container hosted in a cloud environment (typically Google Cloud Platform, AWS, or a managed provider like Stape). The server-side container then processes these events and sends them to Meta via the Conversions API, to Google via their server-side tags, and to any other platform you configure.
Setup time. 4 to 8 hours.
Cost. $10 to $50 per month for server hosting, depending on traffic volume.
Best for. Advertisers running campaigns across multiple platforms (Meta, Google, TikTok, Pinterest) who want a single centralized tracking infrastructure. Businesses that need more control over what data is sent, how it is processed, and which platforms receive it. Organizations with moderate technical resources or access to a developer or analytics specialist.
Key advantage over Gateway. sGTM is not Meta-specific. It serves as a universal server-side tracking hub, meaning you set up server-side infrastructure once and use it for every ad platform. For businesses investing in multi-platform advertising, this makes sGTM the more strategic long-term choice.
Key caveat. GA4 events often originate in the browser. If the client-side GA4 tag never fires (due to ad blockers or consent rejection), the server-side container never receives the event either. sGTM improves tracking reliability significantly but does not achieve 100% capture in all scenarios.
Method 3: Manual / Direct API Implementation (Most Customizable)
Manual implementation means your development team writes server-side code that captures conversion events and sends them directly to Meta's Conversions API endpoint via HTTP POST requests. There is no intermediary platform between your server and Meta.
How it works. Your backend application detects a conversion event (a purchase completing, a lead form submission, an appointment booking) and constructs a POST request containing the event name, event time, user data parameters, and custom data. This request is sent to the Meta Events API endpoint using your access token for authentication.
Setup time. 20 to 40 hours of developer time.
Cost. $500 to $5,000+ one-time development cost. No ongoing hosting fees beyond your existing server infrastructure.
Best for. Businesses with custom-built platforms, complex funnels, or non-standard conversion events that cannot be captured by standard Pixel events. Organizations that need to send offline events (in-store purchases, phone conversions, post-sale upsells) that never touch a website. Companies with in-house development teams that want complete control over the data pipeline.
Key advantage. Total flexibility. You control exactly what data is sent, when it is sent, and how it is structured. This is the only method that can reliably capture events that never touch a browser at all, such as CRM lifecycle changes and offline conversions.
Setup Method Comparison
Next step: Once CAPI is sending clean, deduplicated event data to Meta, see which ad creative is actually earning those conversions with DataAlly's creative analytics platform. Check current pricing plans or talk to the team to connect your ad account.
Critical Meta Conversions API Parameters You Need to Know
The quality of your Conversions API implementation depends entirely on the parameters you send with each event. Sending incomplete or improperly formatted data degrades your Event Match Quality, which directly reduces how effectively Meta can optimize your campaigns.
Required Parameters
event_name. The name of the conversion event (Purchase, AddToCart, Lead, CompleteRegistration, ViewContent, InitiateCheckout, etc.). This must match Meta's standard event naming conventions.
event_time. A Unix timestamp representing when the event occurred. Send this as close to real-time as possible. Meta accepts events up to 7 days old, but delays beyond one hour reduce optimization effectiveness.
action_source. Tells Meta where the event originated. For website events, use "website." For CRM or offline events, use "system_generated" or "physical_store."
User Data Parameters
These parameters live inside the user_data object and determine how well Meta can match each event to a Facebook user profile.
em (email). Hashed with SHA256 before sending. This is the single highest-impact parameter for Event Match Quality, typically improving your score by up to 4 points.
ph (phone). Formatted in E.164 international format, then hashed with SHA256. Adds approximately 3 points to your EMQ score.
fn and ln (first name and last name). Lowercased and hashed with SHA256.
external_id. Your internal user or customer ID, hashed with SHA256. Helps Meta maintain consistent identity matching across sessions.
The fbp and fbc Parameters
These two parameters are critical for matching server events to browser sessions, and they have specific formatting requirements that many implementations get wrong.
fbp (browser ID). This value comes from the _fbp first-party cookie that the Meta Pixel sets in the user's browser. It identifies the browser session. Format: fb.1.[creation_timestamp].[random_number]. Example: fb.1.1596403881668.1116446470.
fbc (click ID). This value comes from the fbclid URL parameter that Meta appends when a user clicks your ad. Format: fb.1.[creation_timestamp].[fbclid_value]. Example: fb.1.1596403881668.AbCdEfGhIjKlMnOpQrStUvWxYz.
Critical rules for fbp and fbc. These values must NOT be hashed. Hashing them will break matching entirely. Only set fbc when a real fbclid exists in the URL. Never fabricate an fbc value, as this degrades data integrity. To send these values server-side, capture them from the browser (via hidden form fields, cookie reading on your server, or client-side JavaScript that passes them to your backend) and include them in the user_data object of your CAPI request.
Custom Data Parameters
currency. Three-letter ISO currency code (USD, EUR, GBP).
value. The monetary value of the conversion event.
content_ids. Product IDs for catalog-based events like Purchase and AddToCart.
content_type. Either "product" or "product_group" for catalog events.
How to Set Up Event Deduplication
If you are running the Meta Pixel and Conversions API together (which Meta recommends), you must configure event deduplication to prevent the same conversion from being counted twice.
How Deduplication Works
When Meta receives an event from the Pixel and a matching event from the Conversions API within a 48-hour window, it uses two fields to determine if they represent the same user action: event_name and event_id. If both fields match between the browser event and the server event, Meta recognizes them as duplicates and counts the conversion only once.
Important: Deduplication does not rely on user identifiers like email, phone, fbp, or fbc. Those parameters help with user matching (connecting the event to a Facebook profile), not event deduplication. Deduplication only checks event_name and event_id.
How to Generate and Pass event_id
The event_id must be a unique string that you generate once per user action and then pass to both the Pixel and the Conversions API.
Step 1. When a conversion event occurs, generate a unique identifier. Use a UUID v4, ULID, or any other method that produces a reliably unique string.
Step 2. Pass this identifier to the Meta Pixel as the eventID parameter in your fbq('track') call.
Step 3. Pass the same identifier to the Conversions API as the event_id parameter in your server-side POST request.
Step 4. Ensure both values are identical strings. Any mismatch, even a difference in casing or whitespace, will cause deduplication to fail and the event will be double-counted.
Event Order Matters
Meta deduplicates only when the browser event arrives first and the server event arrives second. If the server event arrives before the browser event, Meta may count both. In practice, this rarely causes issues because the Pixel fires instantaneously in the browser while server-side processing introduces a slight natural delay. However, if your server-side implementation sends events with significant latency (more than a few seconds), test your deduplication carefully.
Testing Deduplication
After implementation, verify deduplication is working by checking your Events Manager. Compare the total event count from "Browser" events and "Server" events individually against the deduplicated total. If the combined total roughly equals the individual totals (rather than doubling them), deduplication is functioning correctly. If your total event count appears doubled, review your event_id implementation. The most common failure points are mismatched strings, missing event_id on one side, or inconsistent event naming, and you can pull event counts straight from the command line instead of clicking through Events Manager by hand.
How to Connect Your CRM with Meta Conversions API
One of the most powerful applications of the Conversions API is sending CRM lifecycle events to Meta. This allows Meta to optimize campaigns based on what happens after the initial conversion, such as when a lead becomes a qualified opportunity, books a demo, or closes as a customer.
Without CRM integration, Meta only sees the initial form fill or signup. It has no visibility into which leads actually converted into revenue, which means it cannot distinguish between high-quality and low-quality leads when optimizing your campaigns.
Why CRM Integration Matters
When you send CRM events through CAPI, Meta can optimize for deeper funnel outcomes. Instead of optimizing for "lead" events (which may include a high percentage of unqualified submissions), you can optimize for "qualified lead," "demo booked," or even "closed-won" events. This fundamentally changes the quality of traffic Meta sends you.
HubSpot Native Integration
HubSpot offers a built-in Conversions API integration. After connecting your Facebook Ads account in HubSpot's settings, you can create conversion events that sync CRM lifecycle stage changes and form submissions directly to Meta through CAPI.
Requirements: You must have a Meta Pixel installed in your HubSpot account. Only form submissions and lifecycle stage changes that occur after creating the conversion event will be synced. Only HubSpot-created forms are supported; submissions from external forms embedded in HubSpot cannot be synced through the native integration.
Salesforce and Other CRMs
For Salesforce, Pipedrive, Zoho, and other CRMs that do not offer native Meta CAPI integrations, you have several options.
Third-party connectors. Platforms like Datahash, Stape, and LeadsBridge provide pre-built integrations that connect your CRM to Meta CAPI without custom development. Datahash supports Salesforce, HubSpot, Zoho, LeadSquared, Bitrix24, Freshsales, Microsoft Dynamics, and more.
Webhook-based setup. Most modern CRMs support webhooks in their automation tools. You can configure a webhook that fires whenever a deal changes stage or a contact reaches a specific lifecycle milestone, sending the relevant data to your Conversions API endpoint.
Server-side GTM. If you have already implemented sGTM, you can route CRM events through the same server-side container that handles your website events, keeping all your tracking infrastructure centralized.
Critical CRM Integration Detail: Preserving Click IDs
When a user clicks your Meta ad and lands on your website, the URL contains an fbclid parameter. To enable Meta to connect a CRM conversion (which may happen days or weeks later) back to the original ad click, you must capture and store the fbclid value with the contact record in your CRM at the time of initial form submission. When you later send the CRM event through CAPI, include this stored fbc value in the user_data object. Without this, Meta cannot attribute the downstream conversion to the original ad click.
What Happened to Meta's Offline Conversions API
If you previously used Meta's Offline Conversions API to track in-store purchases, phone conversions, or other offline events, you need to know that Meta permanently discontinued it in May 2025.
Version 16.0 of the Graph API was the last to support the Offline Conversions API. With Graph API v17.0 and all subsequent versions, the old system with separate Offline Datasets and manual CSV uploads is completely gone.
What this means for your setup. All offline conversion tracking now flows through the standard Conversions API. There is no longer a separate API, endpoint, or dataset type for offline events. When sending offline events through CAPI, set the action_source parameter to "physical_store" (for in-store events) or "system_generated" (for CRM or backend events) to distinguish them from website events.
Migration note. Some advertisers reported significant issues during the migration from the Offline Conversions API to CAPI, including drops of up to 70% in accepted events. If you migrated and noticed a decline in event acceptance, review your parameter formatting, ensure you are not hashing fbp and fbc values, and verify that your event_time values fall within Meta's 7-day acceptance window.
If you were using third-party tools like Zapier or Twilio Segment with the old Offline Conversions API, those integrations stopped functioning in May 2025. Both platforms now offer updated connectors for the standard Conversions API. In Zapier, make sure to select "Physical Store" as the Action Source when configuring offline conversion events.
How to Improve Your Event Match Quality Score
Event Match Quality (EMQ) is a score from 0 to 10 that Meta assigns to each of your conversion events. It measures how effectively Meta can match your server-side events to Facebook user profiles. Higher EMQ means better attribution, smarter audience optimization, and stronger campaign performance.
What EMQ Scores to Target
Purchase events: 8.8 to 9.3 is the ideal range. These events typically carry the most user data (email, phone, address) because the user has completed a transaction.
AddToCart events: Target 8.0 or above.
PageView events: 6.5 to 7.5 is normal. Users have not yet provided personal data at this stage, so matching is inherently more limited.
General benchmark: Meta's internal benchmark sits around 6 out of 10. Scores above 8 are excellent. Do not chase a perfect 10 at the expense of campaign performance. An 8.5 EMQ with strong conversion volume outperforms a 9.5 EMQ with poor campaign performance, and clean conversion data only pays off once you pressure-test creative variants against real conversion data.
The Highest-Impact Improvements
Send hashed email with every event. This is the single biggest lever. Adding the em parameter typically improves EMQ by up to 4 points. Hash all email addresses with SHA256 before sending. Lowercase the email first, remove leading and trailing whitespace, then hash.
Send hashed phone number. Format in E.164 international format (example: +14155551234), then hash with SHA256. This typically adds 3 points to your EMQ score.
Include fbp and fbc. These browser and click identifiers connect server events to browser sessions. Remember: do not hash these values.
Send multiple identifiers together. Meta's matching confidence increases dramatically when you send email + phone + external_id + fbp + fbc together rather than any single identifier alone. When your events contain only one or two identifiers, Meta has limited ways to confirm user identity.
Enable Advanced Matching. Turn on Advanced Matching in your Events Manager settings. This allows the Pixel to automatically capture additional user data from form fields on your website, which supplements the data you send through CAPI.
Monitoring EMQ
Check your EMQ scores in Events Manager at least weekly. Scores update every 48 hours, but stable improvements take 1 to 2 weeks to reflect. Performance impact (lower CPA, higher ROAS) typically shows within 2 to 4 weeks as Meta's algorithm adapts to improved signal quality, and you can track CPA and ROAS shifts across every channel once EMQ stabilizes.
Navigate to Events Manager, select your Pixel, click on any event (like Purchase), and look for the Event Match Quality score. If any event scores below 6.0, prioritize adding the missing user data parameters outlined above.
Step-by-Step: Setting Up Meta Conversions API with Server-Side GTM
For most advertisers running multi-platform campaigns, server-side GTM offers the best balance of control, flexibility, and cost. Here is the implementation walkthrough.
Prerequisites
You need a Meta Business Manager account with admin access, a Meta Pixel already installed on your website, a Google Tag Manager account with a web container, and a server-side GTM container hosted in a cloud environment (Google Cloud Platform, AWS, or a managed provider like Stape or Taggstar). Meta's own Conversions API help center article covers the account-level permissions required before you start.
Setting up the Meta Conversions API with server-side Google Tag Manager takes seven steps, from generating a Meta access token to monitoring your Event Match Quality score after launch.
- Generate a Meta access token in Events Manager. Open Meta Events Manager, select your Pixel, and generate a new access token in the Conversions API section; your server-side Google Tag Manager container needs this token to authenticate with Meta.
- Point your client-side GTM container at the server container. In your web Google Tag Manager container, configure GA4 event tags on Purchase, AddToCart, and Lead events to send data to your server-side GTM endpoint instead of, or alongside, GA4 directly.
- Create the Meta Conversions API tag in server-side GTM. Add the Meta Conversions API tag template to your server-side GTM container, enter your Pixel ID and access token, and map incoming GA4 event parameters to Meta's event_name, user_data, and custom_data fields.
- Map and hash your user data parameters. Connect email, phone, first name, and last name from your GA4 events to the matching Meta CAPI parameters, hashing the email, phone, and name fields with SHA256 while leaving fbp and fbc unhashed.
- Set up a shared event_id for deduplication. Generate one unique event_id per conversion in your website JavaScript, pass it to both the Meta Pixel's fbq('track') call and your GA4 event tag, then let server-side GTM forward that same event_id to the Conversions API so Meta deduplicates the browser and server events.
- Test the integration in Meta Events Manager. Open the Test Events tab, trigger a conversion on your website, and confirm the event appears from both Browser and Server sources with a deduplicated count that does not double your expected total.
- Monitor Event Match Quality after 48 hours. Check Events Manager for each event type's EMQ score once data has flowed for two days, and add any missing user data parameters if a score falls short of your target.
Common CAPI Setup Mistakes to Avoid
Hashing fbp and fbc. These browser and click identifier parameters must be sent in plain text. Hashing them breaks Meta's ability to match server events to browser sessions.
Fabricating fbc values. Only send an fbc parameter when a real fbclid exists in the URL from an actual ad click. Sending fabricated click IDs degrades your data integrity and can harm campaign optimization.
Delayed event sending. Send events as close to real-time as possible, ideally within minutes of the conversion. Events sent hours or days later provide less optimization value to Meta's algorithm.
Mismatched event_id values. If the event_id in your Pixel call does not exactly match the event_id in your CAPI request (including casing and whitespace), deduplication fails and events are double-counted.
Forgetting to capture fbclid for CRM events. If you plan to send downstream CRM events (like "demo booked" or "closed won") through CAPI, you must capture the fbclid from the landing page URL at the time of initial conversion and store it with the contact record. Without this, Meta cannot attribute the CRM event back to the original ad click.
Using the wrong action_source. Website events should use "website." CRM events should use "system_generated." Offline or in-store events should use "physical_store." Using the wrong value can cause events to be misclassified or rejected.
Frequently Asked Questions
What is Meta CAPI?
Meta CAPI (Conversions API) is a server-to-server tracking interface that sends conversion event data directly from your server to Meta's advertising platform. It works alongside the Meta Pixel to improve tracking accuracy, bypass browser-based privacy restrictions, and provide Meta with more complete conversion data for campaign optimization. In 2026, Meta recommends every advertiser running paid campaigns implement CAPI in addition to the Pixel.
Is Meta Conversions API free?
It depends on your setup method. The CAPI Gateway costs $10 to $400+ per month for hosting, server-side Google Tag Manager runs $10 to $50 per month, and manual or direct API implementation has no ongoing hosting fee but needs $500 to $5,000+ in developer time to build. Platform-native integrations, such as Shopify's built-in Conversions API connector, are typically free to enable.
Do I still need the Meta Pixel if I have CAPI?
Yes. Meta recommends running both together. The Pixel captures real-time browser events and user behavior signals. CAPI ensures reliable conversion tracking even when browser limitations prevent the Pixel from firing. Together, they provide the most complete data. When running both, configure event deduplication using matching event_id values to prevent double-counting.
How do I set up the Meta Conversions API?
There are three setup methods. The CAPI Gateway is a no-code option that mirrors your Meta Pixel events automatically, typically ready in 2 to 4 hours. Server-side Google Tag Manager routes events through a cloud container to Meta and other ad platforms, usually taking 4 to 8 hours. Manual or direct API implementation has a developer send events straight to Meta's endpoint, offering full customization but requiring 20 to 40 hours of development time.
How do I get a Meta Conversions API access token?
Open Meta Events Manager and select the Pixel you want to connect to the Conversions API. In the Pixel's settings, find the Conversions API section and click to generate a new access token. Copy that token and store it securely, since you will paste it into your server-side Google Tag Manager container or your direct API integration to authenticate requests sent to Meta.
What happened to Meta's Offline Conversions API?
Meta permanently discontinued the Offline Conversions API in May 2025. All offline conversion tracking (in-store purchases, phone conversions, CRM events) now flows through the standard Conversions API. When sending offline events, use the action_source parameter set to "physical_store" or "system_generated" to identify them correctly. Graph API v17.0 and later versions no longer support the old system.
What is a good Event Match Quality score?
For Purchase events, target 8.8 to 9.3. For AddToCart, target 8.0+. For PageView events, 6.5 to 7.5 is normal. Meta's internal benchmark is around 6 out of 10. The highest-impact improvement is sending hashed email addresses with every event, which can increase your EMQ score by up to 4 points.
