--- title: "Pixels, conversions APIs and data quality" description: "Why conversion data matters more than ever Ad platforms optimise towards the conversions you send them. If data is missing, delayed or wrong, the…" url: https://optimizeall.com/learn/paid-social-advertising/pixels-and-conversions-api updated: 2026-10-05 --- Paid Social Advertising · Budgets, bidding, tracking and consent · lesson 8 of 17 · 16 min # Pixels, conversions APIs and data quality ## Why conversion data matters more than ever Ad platforms optimise towards the conversions you send them. If data is missing, delayed or wrong, the algorithm learns from a distorted picture, and your reported results are unreliable. With browser tracking limits, ad blockers and privacy changes, a single browser pixel often misses conversions. ## Browser pixels A **pixel** (Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, X Pixel) is a small piece of JavaScript on your website. When someone takes an action, it sends an **event** to the platform, for example: - PageView - ViewContent - AddToCart - InitiateCheckout - Purchase (with value and currency) - Lead / CompleteRegistration Pixels are easy to install through tag managers or e-commerce integrations (for example Shopify, WooCommerce or Salla apps), but they depend on the visitor's browser and consent choices. ## Server-side conversions APIs A **conversions API** (Meta Conversions API, TikTok Events API, LinkedIn Conversions API, X Conversion API) sends events directly from your server or a partner platform to the ad platform. Benefits: - More resilient to browser restrictions and ad blockers. - Can include offline or back-end events (for example a lead that becomes a paying customer in your CRM, or a cash-on-delivery order that is actually delivered). - Often improves the platform's ability to match events to people. Conversions APIs still require you to respect consent and privacy law. Sending data from a server does not make it lawful by itself. ## Using both: deduplication Best practice is usually to run **both** pixel and server events. To avoid counting the same purchase twice, send a shared **event ID** (and the same event name) from both sources so the platform can **deduplicate**. Test deduplication with the platform's diagnostic tools (for example Meta's Events Manager test events). ## Match quality Server events include **customer information parameters** (such as hashed email or phone, IP address, user agent and click IDs like fbclid or ttclid) that help the platform match an event to an ad interaction. More accurate, consented parameters generally improve **event match quality**, which improves attribution and optimisation. Personal identifiers must be hashed as the platform specifies and collected lawfully. ## Priorities for iOS and aggregated measurement Since Apple's App Tracking Transparency, platforms use aggregated and modelled measurement for some iOS traffic. Settings and requirements have evolved over time (for example, Meta has changed how it handles web event configuration). Keep your domain verified in each platform where required and follow current guidance in the platform's events manager. ## Cash on delivery and offline conversions In Pakistan and parts of the Gulf, many orders are cash on delivery (COD), and some are refused at the door. If you optimise for "Purchase" at checkout, the algorithm may learn to find people who order but do not pay. Options include: - Sending a separate **"Delivered" or "Paid" event** via the conversions API when the order is confirmed. - Using order-confirmation calls or WhatsApp confirmation before counting a conversion. - Comparing ad-reported purchases with delivered orders when evaluating campaigns. ## Tracking QA checklist - Pixel installed once (not duplicated by a theme and a plugin). - Standard events fire at the right moment with correct value and currency. - Server events sent with event IDs matching browser events. - Consent choices respected: tags wait for consent where required. - Test purchase completed and visible in events manager. - UTMs on all ads for analytics cross-checking. - Domain verified in each ad account where required. ## Worked example A Riyadh fashion store sees Meta report 180 purchases while Shopify shows 140. Investigation finds the pixel fires twice: once from the theme and once from an app. After removing the duplicate and adding deduplicated server events, reported purchases align more closely with store data and CPA reporting becomes trustworthy. ## Common mistakes - Duplicate pixels inflating conversions. - Missing value and currency on purchase events. - Server and browser events without matching event IDs. - Optimising for COD orders that are never paid. ## How to implement: three routes 1. **Partner integration (easiest):** Shopify, WooCommerce, Salla, Zid, BigCommerce and similar platforms offer official apps that send both pixel and server events with deduplication. Start here if your store platform supports it. 2. **Server-side tag manager or gateway:** server-side Google Tag Manager, or a platform gateway product such as Meta's Conversions API Gateway, forwards events without custom code. 3. **Direct API calls from your backend:** most control; needs a developer. Use this for CRM or delivery events that never happen in a browser. ## Hands-on: sending a server event to Meta's Conversions API (Python) A minimal, production-minded example. Keep secrets in environment variables, hash identifiers, reuse the browser's `event_id` and handle errors. Check Meta's docs for the current Graph API version before you ship. ```python import hashlib, os, time import requests PIXEL_ID = os.environ["META_PIXEL_ID"] TOKEN = os.environ["META_CAPI_TOKEN"] # never hard-code API_VERSION = os.environ.get("META_GRAPH_VERSION", "v23.0") # check current version def sha256(v: str) -> str: return hashlib.sha256(v.strip().lower().encode("utf-8")).hexdigest() def send_purchase(order: dict, consent_marketing: bool) -> None: if not consent_marketing: return # respect the user's choice where consent is required # drop empty identifiers (e.g. no click cookie) rather than sending nulls order = {k: v for k, v in order.items() if v is not None} payload = {"data": [{ "event_name": "Purchase", "event_time": int(time.time()), "event_id": order["event_id"], # same ID the browser pixel sent "action_source": "website", "event_source_url": order["page_url"], "user_data": { "em": [sha256(order["email"])], "ph": [sha256(order["phone_e164"].lstrip("+"))], "client_ip_address": order["ip"], "client_user_agent": order["user_agent"], **({"fbc": order["fbc"]} if "fbc" in order else {}), # _fbc cookie / fbclid **({"fbp": order["fbp"]} if "fbp" in order else {}), # _fbp cookie }, "custom_data": {"currency": order["currency"], "value": round(order["value"], 2)}, }]} url = f"https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events" try: r = requests.post(url, params={"access_token": TOKEN}, json=payload, timeout=10) r.raise_for_status() except requests.RequestException as exc: # log and queue for retry; never block the customer's checkout on this call print(f"CAPI send failed for order {order['event_id']}: {exc}") ``` While testing, add a `test_event_code` from Events Manager to the payload so events show in **Test events** without affecting reporting. TikTok's Events API, LinkedIn's Conversions API and Snap's Conversions API follow the same pattern (event name, time, deduplication ID, hashed identifiers, value) with their own field names – follow each platform's documentation. ## Worked example 2: sending qualified leads back from a CRM A Dubai property developer's Meta lead ads generated thousands of cheap leads, many unreachable. The team adds two CRM-triggered server events – **qualified_lead** (the sales team confirmed budget and timeline) and **site_visit_booked** – sent through the Conversions API with the lead's hashed email and phone. After enough events accumulate, they optimise a lead campaign towards qualified leads. Cost per lead rises; cost per site visit falls. The CRM, not the form, becomes the source of truth. ## How to measure success - **Deduplication working:** platform purchases close to store orders for tracked journeys, with no double counting (check event overlap in Events Manager or each platform's diagnostics). - **Match quality:** Meta's event match quality score and similar diagnostics trend up as you add consented identifiers. - **Coverage:** share of store orders that reach each platform as server events, monitored weekly with an alert if it drops. For server-side tagging, consent-aware CAPI set-ups and monitoring at a professional level, continue to **Privacy-First Measurement**. ## Video lecture: Pixels and conversions APIs: feeding the algorithm clean data Lecture coming soon · 11 chapters · about 8 minutes. Read the full transcript below. 1. Pixels and conversions APIs 2. Browser pixels 3. Conversions APIs 4. Deduplication and match quality 5. Three implementation routes 6. Code walkthrough 7. Example 1: Riyadh fashion store 8. Cash on delivery 9. Example 2: Dubai property (illustrative) 10. QA and success measures 11. Recap and try this now ## Lecture transcript ### Pixels and conversions APIs Imagine teaching someone to cook by describing dishes over a crackling phone line. Half the words drop out, and sometimes you say salt twice. Their cooking would be a mess, and it wouldn't be their fault. That's what happens to ad algorithms when your conversion data is missing, delayed or duplicated. They optimise towards whatever you send them. In this lecture you'll learn how browser pixels and server-side conversions APIs work, why you should run both, how deduplication and match quality work, how to handle cash on delivery, and you'll see a real, production-minded code example for sending a server event. ### Browser pixels Let's start with the pixel. A pixel, like the Meta Pixel, TikTok Pixel, LinkedIn Insight Tag or X Pixel, is a small piece of JavaScript on your website. When someone takes an action, it sends an event to the platform: page view, view content, add to cart, initiate checkout, purchase with value and currency, or lead. Pixels are easy to install through tag managers or store apps for Shopify, WooCommerce, Salla or Zid. But they depend on the visitor's browser. Ad blockers, browser privacy features and consent choices all mean some events never arrive. A pixel alone often misses conversions. ### Conversions APIs Now the conversions API. Meta's Conversions API, TikTok's Events API, LinkedIn's and Snap's Conversions APIs send events directly from your server, or a partner platform, to the ad platform. Three benefits. They're more resilient to browser restrictions and blockers. They can send events that never happen in a browser at all, like a lead becoming a paying customer in your CRM, or a cash on delivery order that's actually delivered. And they often improve matching. But here's the important caveat. Server-side sending doesn't make data collection lawful by itself. Consent and privacy law still apply. ### Deduplication and match quality The best practice is to run both, and that creates a problem: the same purchase might be counted twice. The fix is deduplication. Send the same event name and a shared event ID from the browser and the server, and the platform counts it once. Think of it like a receipt number. If two copies of receipt one-two-three-four arrive, the accountant knows it's one sale. Then there's match quality. Server events include customer information, like hashed email or phone, IP address, user agent and click IDs, that help the platform match the event to an ad interaction. More accurate, consented identifiers usually mean better attribution and optimisation. ### Three implementation routes How do you implement it? Three routes. The easiest is a partner integration: Shopify, WooCommerce, Salla, Zid and similar platforms have official apps that send both pixel and server events with deduplication built in. Start there if you can. Second, a server-side tag manager or a gateway product, which forwards events without custom code. And third, direct API calls from your own backend. That gives the most control and is how you send CRM or delivery events. In the lesson text there's a Python example for Meta's Conversions API. Let's walk through the key lines. ### Code walkthrough First, the secrets. The pixel ID and access token come from environment variables, never hard-coded in your code. Second, a small function hashes identifiers with SHA two fifty-six after trimming and lowercasing them. Third, the function checks consent and returns early if the user hasn't agreed where consent is required. Fourth, the payload: event name Purchase, the event time, the same event ID the browser pixel used, action source website, hashed email and phone, IP address, user agent, the click cookies, and the value and currency. And finally, the request has a timeout and error handling, so a failed call is logged and retried, and never blocks the customer's checkout. ### Example 1: Riyadh fashion store Now a simple worked example. A fashion store in Riyadh sees Meta report a hundred and eighty purchases while Shopify shows a hundred and forty. The team opens Events Manager and finds the pixel firing twice on every order: once from the theme code and once from an app. They remove the duplicate, turn on the official integration's server events with deduplication, and run a test purchase that now appears exactly once. Reported purchases line up much more closely with the store, and for the first time, the team trusts its cost per purchase. Duplicate pixels are one of the most common and most expensive tracking bugs. ### Cash on delivery Cash on delivery deserves special attention. In Pakistan and parts of the Gulf, many orders are paid on delivery, and some are refused at the door. If you optimise for purchase at checkout, the algorithm learns to find people who order but don't pay. The fix is to send a separate delivered or paid event through the conversions API when the order is confirmed, and to evaluate campaigns on delivered orders. Some teams also confirm orders by call or WhatsApp before counting them. Your reported cost per purchase will rise on paper, but you'll be buying real customers. ### Example 2: Dubai property (illustrative) Now a realistic lead-generation scenario. A Dubai property developer's Meta lead ads produced thousands of cheap leads, and many never picked up the phone. So the team added two CRM-triggered server events. Qualified lead, when the sales team confirms budget and timeline. And site visit booked. Both are sent through the Conversions API with the lead's hashed email and phone. Once enough events built up, they optimised the lead campaign towards qualified leads. Cost per lead went up. Cost per site visit went down. That's the pattern: the CRM, not the form, becomes the source of truth, and the algorithm learns what a good lead really looks like. ### QA and success measures Before and after any site change, run a tracking QA. Pixel installed once, not duplicated by a theme and a plugin. Standard events firing at the right moment with the correct value and currency. Server events sent with event IDs that match the browser. Consent respected. A test purchase visible in Events Manager, using a test event code while you're testing. UTMs on all ads for cross-checking. And your domain verified where required. How do you measure success? Deduplication working, so platform purchases sit close to store orders for tracked journeys. Match quality trending up. And a weekly check that the share of orders reaching each platform hasn't suddenly dropped. ### Recap and try this now Let's recap. Platforms optimise towards the events you send, so data quality is performance. Run browser pixels and server-side conversions APIs together, deduplicated with shared event IDs, and send consented identifiers for better matching. Start with a partner integration if you can, use direct API calls for CRM and delivery events, and keep secrets in environment variables with proper error handling. In cash on delivery markets, optimise and evaluate on delivered orders. Here's your try this now. Run the tracking QA on a site you manage or a test store, and fix one issue. For professional server-side setups, continue to Privacy-First Measurement. ## Key takeaways - Platforms optimise towards the events you send, so data quality directly affects performance. - Use browser pixels plus server-side conversions APIs, deduplicated with shared event IDs. - Better, lawfully collected match parameters improve event match quality; consent still applies to server events. - For cash-on-delivery markets, consider sending delivered or paid events so optimisation targets real buyers. ## Try it Run a tracking QA on a site you manage (or a test store): check for duplicate pixels, confirm purchase value and currency, and verify deduplication in the platform's test tool. - [Previous: Budgets, auctions and bid strategies](https://optimizeall.com/learn/paid-social-advertising/budgets-and-bidding) - [Next: Consent, privacy and signal loss in paid social](https://optimizeall.com/learn/paid-social-advertising/consent-and-signal-loss) - [All lessons of Paid Social Advertising](https://optimizeall.com/learn/paid-social-advertising)