Blog · Meta Ads · Conversion Tracking
Virtual PracharOmicron III, Greater Noida, Uttar Pradesh 201310 · 16 min read · Nov 2026
An online store runs Facebook and Instagram ads for a month. Its order system shows a healthy number of orders, but Ads Manager reports noticeably fewer purchases. Nobody made an obvious mistake. Some of the gap may come from reporting rules such as attribution windows. Some may come from tracking itself: a browser-based tag only works if the visitor's browser loads it and lets it run.
That is why the Meta Pixel vs Conversions API question matters. The Pixel sends events from the visitor's browser. The Conversions API sends events from your server or business systems. This guide explains both, shows how they work together, and helps you choose, without promising that any setup will capture every conversion.
Illustration only. It does not show real tracking data.
Meta Pixel is the browser-based starting point and is enough for many simple websites. Conversions API sends events from your server or business systems and can fill gaps where browser signals are lost. Many e-commerce and lead-generation businesses use both, with deduplication, where their platform supports it. Neither is a guarantee of perfect attribution or better ad results.
Browser-side Browser
The Meta Pixel is a piece of code on your website that reports visitor actions to Meta from the visitor's browser. Businesses install it to measure what people do after clicking an ad, to build audiences from site activity, and to give Meta event data that supports campaign optimisation.
Each report is an event: a named action such as a page view or a purchase, sometimes with details like value and currency. Meta connects event data to ad activity where it can, which is how a website action becomes an advertising conversion.
Choose events that match your actual site and goals. A store needs purchase and cart events. A service business may care more about enquiries. More events are not automatically better.
A practical e-commerce example. A shopper clicks an ad, browses a product, adds it to the basket and pays. The Pixel can report each step as it happens in the browser:
| Standard event | What it signals | Typical use |
|---|---|---|
| PageView | A page loaded | Baseline site traffic |
| ViewContent | A product or key page was viewed | Product interest, retargeting |
| Search | A site search was made | Intent on larger catalogues |
| AddToCart | An item was added to the basket | Mid-funnel e-commerce signal |
| InitiateCheckout | Checkout was started | Checkout drop-off analysis |
| AddPaymentInfo | Payment details were entered | Late-stage checkout signal |
| Purchase | An order was completed | Revenue and return measurement |
| Lead | A form or enquiry was submitted | Lead generation campaigns |
| CompleteRegistration | A sign-up was completed | Accounts, apps, memberships |
| Contact | Someone started contact (call, chat, message) | Service businesses |
Browser-side Browser
Setting up the Pixel means installing the base code (directly, through a tag manager or through a supported website-platform integration) and then configuring events. Events can carry parameters, such as value, currency and product IDs, which make them more useful for measurement. A Pixel also commonly uses first-party cookies to recognise a browser, including a browser ID and, after an ad click, a click identifier.
Because the Pixel depends on the browser, several things can stop an event from being observed: ad blockers, browser tracking-prevention settings, cookie limits, slow or interrupted page loads, and visitors who decline consent. Consent and privacy settings should control when the Pixel fires. Missing some events is normal for browser-only tracking, but the amount varies by audience and site.
This is the core reason the Conversions API exists: it sends events from a source that does not rely on the visitor's browser running your tag.
Server-side Server
The Conversions API (CAPI) lets your website server or another business system send events directly to Meta, instead of relying on the visitor's browser to do it. Meta introduced server-side event sharing because browser-only tracking is exposed to ad blockers, cookie limits and other browser restrictions.
The difference is where the event comes from. With the Pixel, the browser reports "this person bought something". With CAPI, your own system reports it after it has recorded the order. That can make events more complete, and it lets you send events that never happen in a browser at all, such as a lead that your team marks as qualified.
Most businesses that use CAPI keep the Pixel too, so Meta receives both browser and server versions of the same action.
Not every integration supports every event or parameter. What you can send depends on your platform, your architecture and the integrations available to you.
Server-side Server
| Event field | What it is | Why it matters |
|---|---|---|
| event_name | The action, such as Purchase or Lead | Must match the Pixel event name for deduplication |
| event_time | When it happened, as a Unix timestamp | Wrong times make events look stale or misplaced |
| event_id | A unique ID for this action | The key to deduplicating against the Pixel |
| action_source | Where the action happened, for example website | Tells Meta the type of source |
| event_source_url | The page URL, for website events | Adds context and can help matching |
| user_data | Customer information used for matching | Some fields are hashed, some are not (see below) |
| custom_data | Details such as value and currency | Purchase events need an accurate value and currency |
Customer details such as email and phone are normally normalised (for example, lower-cased and trimmed) and then hashed before sending. Hashing is not the same as anonymisation, and it does not make data collection automatically compliant. Technical fields such as the browser ID, click ID, IP address and user agent are sent as they are, not hashed. Send only what you need, and never send sensitive personal information without a clear need and legal basis.
The payload on the right is a simplified, illustrative example. It uses placeholders, not real data. Take exact field names, the API version and the authentication method from Meta's current documentation, and keep the access token on your server only, never in frontend JavaScript.
{
"data": [{
"event_name": "Purchase",
"event_time": <unix_seconds>,
"event_id": "order_10492",
"action_source": "website",
"event_source_url": "<order_confirmation_page_url>",
"user_data": {
"em": ["<sha256_of_normalised_email>"],
"client_ip_address": "<visitor_ip>",
"client_user_agent": "<visitor_user_agent>",
"fbp": "<_fbp_cookie_value>"
},
"custom_data": { "currency": "INR", "value": <order_value> }
}]
}Side by side
| Factor | Meta Pixel (browser) | Conversions API (server) |
|---|---|---|
| Browser or server | Browser-based | Server-side |
| Data source | Website browser | Website server or a supported business system |
| Implementation | Pixel code or a supported integration | Server integration or a supported platform integration |
| Browser restrictions | More exposed to browser restrictions | Less dependent on browser execution |
| Ad blockers | Can affect browser events | Not affected in the same browser-dependent way |
| Event data | Browser-observed information | Server-supplied event information |
| Setup complexity | Often simpler | Depends on your server and integration |
| Maintenance | Pixel and event configuration | API, event payloads and server upkeep |
Server-side does not mean free of limits. CAPI is still subject to privacy rules and consent requirements, and it can only send data that your system actually has and that you are allowed to share. Poor data quality hurts either method.
Using both
Yes, and Meta supports this combined setup. The Pixel collects events as they happen in the browser, and CAPI shares events from your server. Each can catch things the other misses, so together they can give Meta a fuller picture than either alone.
The catch is duplication. If a customer buys once, both channels may report that purchase. Event deduplication is how Meta recognises the two reports as one action.
It works only when the events correspond. The browser event and the server event must use the same event name and the same event ID. Meta's documentation currently describes a limited time window for matching, which is about 48 hours, so confirm the current rule before you build.
Events are not deduplicated automatically. They are deduplicated only if your implementation sends matching names and IDs correctly.
Matching
Event Match Quality (EMQ) describes how well Meta can connect an event you send to a person on its platforms. Better matching can support measurement, because an event Meta cannot connect to anyone cannot be tied to an ad interaction. Events Manager shows match quality for supported events, along with diagnostics that suggest which details are missing.
Matching relies on the customer information you provide. More complete and accurate parameters generally help, but a higher score does not guarantee more conversions or better ad performance, and this guide does not quote benchmark scores.
| Parameter | Handling |
|---|---|
| Normalise, then hash | |
| Phone number | Normalise (digits with country code), then hash |
| First and last name | Normalise, then hash |
| External ID | Your own customer ID; hash as Meta advises |
| IP address, user agent | Send as collected; not hashed |
| Browser ID, click ID | From Meta cookies where available; not hashed |
Only send what you are allowed and need to send. Follow your consent and privacy obligations first, and treat matching quality as a diagnostic, not a target to chase at any cost.
Trade-offs
Decision guide
There is no universal answer. The right setup depends on your website platform, goals, technical resources and privacy obligations. Use the table as a starting point, not a rule.
| Business type | Suggested approach | Main consideration |
|---|---|---|
| Small business | Pixel initially, evaluate CAPI | Simplicity and measurement needs |
| E-commerce | Pixel + CAPI where supported | Purchase accuracy and deduplication |
| D2C brand | Combined approach where appropriate | Customer journey and event quality |
| Lead generation | Pixel plus suitable server or CRM events | Lead quality and downstream events |
| Custom website | Evaluate server-side implementation | Technical resources and maintenance |
Implementation
Meta's interface, terminology and API versions change. Confirm current names and steps in Meta's own documentation before you follow any list below. Events Manager now uses "dataset" alongside "Pixel" for the same kind of data source.
Never put access tokens or other secrets in frontend JavaScript, page source or shared documents. This sequence is a general outline, not a substitute for Meta's current API instructions.
Troubleshooting
| Issue | Possible cause | How to identify | Fix, then verify |
|---|---|---|---|
| Pixel not firing | Code missing, blocked, or consent stops it | No events in Test Events or helper tool | Reinstall or fix the trigger; re-test a full journey |
| Missing Purchase events | Confirmation page not tracked | Orders exist but no Purchase events | Fire Purchase on order success; compare counts |
| Duplicate Purchases | Page reloads, or both sources without dedup | Reported purchases exceed orders | Fire once per order; add matching event IDs; recheck counts |
| Wrong event names | Custom names or typos | Event list shows unexpected names | Use standard names consistently; check the list |
| Wrong currency or value | Wrong field or format | Values differ from the order system | Map the correct fields; compare several orders |
| Missing event ID | ID not set in Pixel or server | Diagnostics warn about event ID coverage | Pass the same ID from both sides; confirm the warning clears |
| Deduplication failure | Names or IDs do not match | Both sources counted | Align names and IDs exactly; test one order |
| CAPI events not arriving | Bad credentials, wrong dataset, payload error | No server events in activity | Check token, dataset ID, errors; send a test event |
| Wrong timestamps | Wrong unit or time zone | Events appear at odd times | Send Unix seconds in UTC terms; check event times |
| Bad customer info format | Not normalised or hashed correctly | Low matching, diagnostic notes | Normalise, then hash as documented; recheck match quality |
| Missing consent handling | Tags fire regardless of choice | Events fire before consent | Gate Pixel and server sending on consent; test both choices |
| Wrong data source | Events sent to the wrong Pixel or dataset | Another dataset shows the events | Correct the ID; confirm in the right dataset |
| Test events counted as real | Test code left on live traffic | Events appear only in test view | Remove the test code; confirm live events arrive |
| Browser and server mismatch | Different data or triggers per side | Counts or values differ between sources | Align triggers and fields; compare side by side |
| Outdated integration or API version | Old plugin, retired version | Diagnostics or errors mention versions | Update the integration; verify events still flow |
Monitoring
Use Events Manager as your main view. Event activity shows what Meta received and from which source. Test Events lets you check browser and server events as they arrive. Diagnostics flags problems, including event ID coverage and deduplication issues, and match quality shows how well events can be linked to people.
Then compare Meta's numbers with your own: orders in your store, leads in your CRM. Watch for missing events (reported far below real) and duplicates (reported above real).
Expect some difference. Ads Manager conversions depend on attribution settings and windows, reporting methods, privacy restrictions and processing delay. Your own records may include cancelled or refunded orders, other traffic sources and different time zones. A gap does not always mean broken tracking, and no setup can eliminate every discrepancy.
Responsible tracking
Server-side tracking does not bypass privacy obligations. If you collect or share personal data, you need a lawful basis and, where required, valid consent, for both Pixel and CAPI.
In India, the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 apply in phases. The Rules were notified in November 2025. As of this article, the main obligations on notice, consent and security are scheduled to apply from around mid-May 2027, with older rules still in place until then. Check the current status before you rely on it. If you target people in other regions, their local laws may also apply.
This is general information, not legal advice. Ask a qualified professional about your specific obligations.
Checklist
Where Virtual Prachar fits
Measurement only helps when the campaign behind it is sound. Virtual Prachar plans Facebook Ads around the offer, the audience and the page people land on, and we hold back from scaling spend when that page cannot keep a visitor. We also run Google Ads for people already searching and LinkedIn Ads for role-based B2B reach.
If your leads live in a CRM, knowing where they came from is part of the same picture. This article does not claim that we install the Pixel, build Conversions API integrations or guarantee tracking results. Raise your measurement needs when you brief us, and see all services to find the right fit.
FAQs
The Pixel sends events from the visitor's browser. The Conversions API sends events from your server or business systems.
Yes. It remains the standard way to collect browser events and is the starting point for most setups, often alongside CAPI.
Not in every case. It is less dependent on the browser, but harder to set up, and many businesses benefit most from using both.
Yes. Send matching event names and event IDs from both so Meta can deduplicate.
It is how Meta treats a browser event and a server event for the same action as one conversion, using matching event names and IDs.
It describes how well Meta can match your events to people using the customer information you send. It is a diagnostic, not a guarantee of results.
Server events do not rely on the browser running your tag, so ad blockers do not affect them in the same way. They do not bypass consent or privacy rules.
Not always. A simple site can start with the Pixel and add CAPI when measurement gaps and resources justify it.
Yes, supported events such as Purchase and Lead can be sent, including events from a CRM where an integration allows it.
No. Accuracy depends on correct setup, data quality, consent and attribution, and no method captures everything.
Use Test Events and diagnostics in Events Manager, plus a browser helper extension, and walk through a real journey on your site.
No. You remain responsible for consent, data minimisation and lawful handling of customer information.
Conclusion
The Pixel tracks from the browser and is simple to start with. The Conversions API tracks from the server and can fill gaps the browser misses, at the cost of more technical work. The right choice depends on your size, website, conversion goals, resources and privacy obligations. A well-built combined setup can help where it suits you, but neither method guarantees perfect attribution or better ad results. If you want to plan your Meta campaigns and what to measure, contact Virtual Prachar.
Thanks. We will get in touch soon.