[{"data":1,"prerenderedAt":540},["ShallowReactive",2],{"guide-server-side-tracking-facebook-ads":3},{"id":4,"title":5,"answer":6,"authorId":7,"body":8,"category":409,"ctaVariant":410,"dataset":409,"description":411,"examples":412,"extension":413,"faqs":414,"heroImage":439,"intro":440,"meta":441,"navigation":443,"path":444,"publishedAt":445,"seo":446,"sources":447,"stats":513,"stem":538,"updatedAt":445,"__hash__":539},"blog\u002Fblog\u002Fserver-side-tracking-facebook-ads.md","Server-Side Tracking for Facebook Ads (2027)","Server-side tracking for Facebook ads means sending conversion events to Meta from your own server through the Conversions API, instead of relying only on the browser-based Meta Pixel. It exists because browser signal degrades: Safari caps cookies at seven days, roughly 29.5% of internet users use ad blockers at least sometimes, and about half of app users decline tracking under ATT. Meta's own guidance is to run the Conversions API alongside the Pixel and send the same events through both, not to replace one with the other. The hard limit is matching: an event Meta cannot match to an account cannot be used for attribution or optimisation at all.","likit-sae-lee",{"type":9,"value":10,"toc":396},"minimark",[11,16,20,23,26,29,38,42,45,48,51,54,57,60,63,66,69,73,76,79,82,90,93,97,100,168,171,174,177,190,194,197,200,203,206,210,213,220,226,229,240,246,252,258,262,265,348,351,355,358,361,364,367,370,374,377,385,393],[12,13,15],"h2",{"id":14},"what-server-side-tracking-actually-means","What server-side tracking actually means",[17,18,19],"p",{},"Strip away the vocabulary and there are only two ways a conversion reaches Meta.",[17,21,22],{},"The first is the browser. A visitor loads your page, the Meta Pixel script runs in their browser, and the browser sends an event to Meta directly. Meta learns about the purchase because the customer's own device told it. Everything about that path depends on the customer's browser: whether the script loaded, whether an extension blocked it, whether a cookie survived long enough to identify the session, whether the tab was closed before the request fired.",[17,24,25],{},"The second is your server. Your backend already knows the order happened, because it processed the payment. Instead of hoping a browser tag fired, your server sends the event to Meta itself, over HTTP, from infrastructure you control. That is the Conversions API, and that is what \"server-side tracking\" means in a Meta context. Nothing more exotic than that.",[17,27,28],{},"The difference is who is telling the story. In the client-side model, the narrator is a script inside a browser that is increasingly designed to distrust it. In the server-side model, the narrator is the system that holds the actual record of the transaction. The second narrator is more reliable about the fact of the conversion. It is often worse at knowing who the customer was, which turns out to be the whole game.",[17,30,31,32,37],{},"Two clarifications before going further, because both cause confusion. Server-side tracking is not the same thing as server-side tagging through a container, which is a related but separate architecture. And \"Pixel ID\" and \"Dataset ID\" are the same identifier under a renamed container: Meta's own Dataset Quality API documentation describes the parameter as the ID of the dataset (Pixel). The Pixel was renamed into a dataset, not retired. If you have read otherwise, our guide on the ",[33,34,36],"a",{"href":35},"\u002Fblog\u002Fmeta-pixel-to-dataset-migration","Meta Pixel to Dataset migration"," untangles the naming.",[12,39,41],{"id":40},"why-the-browser-stopped-being-a-reliable-narrator","Why the browser stopped being a reliable narrator",[17,43,44],{},"This is the part most guides get wrong in 2027, because they are still telling a story that stopped being true in 2025.",[17,46,47],{},"The lazy version goes: cookies are dying, Chrome killed third-party cookies, the cookieless future is here, therefore server-side. That is false. On 22 April 2025 Google announced it had decided to maintain its current approach to offering users third-party cookie choice in Chrome and would not roll out a new standalone prompt. The deprecation everyone planned for did not happen. If a page tells you the cookie apocalypse arrived via Chrome, it is repeating a 2024 press cycle that reversed.",[17,49,50],{},"The true story is messier and, for advertisers, worse.",[17,52,53],{},"Start with Safari, where the restriction is real and old. Apple's Intelligent Tracking Prevention 2.1, shipped in February 2019, caps all persistent cookies created through document.cookie at seven days. ITP 2.2, two months later, tightened that to one day when a domain classified with cross-site tracking capability navigated the user to the page and the landing URL carries a query string or fragment. Read that condition again, because it describes an ad click precisely: someone taps your Facebook ad, arrives with an fbclid parameter in the URL, and the click identifier your site writes has a one-day life. A considered purchase does not close in a day. Then in March 2020 Apple went further, announcing that cookies for cross-site resources are now blocked by default across the board. Safari has had no third-party cookie allowance for years.",[17,55,56],{},"Firefox is the other restrictive browser, and its mechanism is different from Safari's. Mozilla rolled out Total Cookie Protection by default to all users worldwide in June 2022. Rather than capping cookie lifetimes, it confines every cookie a site or its embedded third-party content sets to a cookie jar assigned to only that website. The cookie still exists, it just cannot be read from anywhere else, which is the same practical outcome for cross-site tracking.",[17,58,59],{},"Now add the users who never let the script run at all. As of Q2 2025, 29.5% of internet users worldwide use ad blockers at least sometimes, an estimated 1.77 billion people, according to GWI data via DataReportal reported by Backlinko. Note the qualifier: that is people who block at least some of the time, not a share of your sessions. But it means that for a meaningful slice of your visitors, your browser tag is not degraded. It is absent. No amount of tuning a client-side tag recovers an event that never fired.",[17,61,62],{},"Then apps. App Tracking Transparency opt-in reached 50% globally three years after launch, up ten points from rollout, with the United States at 44% and the United Kingdom at 46%, per AppsFlyer's 2024 findings. Half of app signal is consented, so half is not. And the prompt is close to universal: as of Q1 2024, 84% of gaming app developers and 68% of non-gaming developers show the ATT prompt. This is app-only and iOS-only, so do not let anyone stretch these numbers onto your website traffic. But if any part of your funnel touches an iOS app, half your signal is a coin flip you already lost.",[17,64,65],{},"The last piece is the one that changed the calculus. On 17 October 2025 Google retired the Privacy Sandbox measurement stack: ten technologies, including the Attribution Reporting API and Topics, on both Chrome and Android. CHIPS, FedCM and Private State Tokens survived. The privacy-preserving replacement for cookie attribution that the industry spent six years preparing for is gone.",[17,67,68],{},"Put those together and the honest 2027 position is this. Cookies persist in Chrome under a user-choice model. Safari caps their lifetime and blocks cross-site reads entirely, and Firefox jars them per site. ATT caps app signal at roughly half. Close to three in ten users block scripts at least some of the time. And the standards-based replacement was cancelled. Server-side tracking is not urgent because cookies ended. It is the practical option because the alternatives to it either got restricted or got withdrawn, and nothing else arrived.",[12,70,72],{"id":71},"server-side-is-an-addition-not-a-replacement","Server-side is an addition, not a replacement",[17,74,75],{},"The single most common mistake is treating this as a migration. It is not.",[17,77,78],{},"Meta's deduplication documentation states plainly that for optimal ad performance it recommends advertisers implement the Conversions API alongside their Meta Pixel. Its best-practice guidance goes further: use the Conversions API in addition to the Meta Pixel, and share the same events using both tools. Meta is not asking you to send half your events one way and half the other. It is asking you to send the same events twice, deliberately, and let its systems reconcile them.",[17,80,81],{},"That sounds wasteful until you see what each side contributes. The browser holds identifiers the server frequently cannot reconstruct: the fbp cookie Meta itself set, and the fbc click identifier derived from the ad click. The server holds truth about the transaction and fires regardless of blockers, tab closures, or a customer who paid on a laptop and never came back. Neither feed is complete. Together they cover more of the surface than either alone.",[17,83,84,85,89],{},"Meta then deduplicates events received within 48 hours of the first event. There are two methods: event_id combined with event_name is the primary one, with a fallback on event_name plus fbp and\u002For external_id. Getting that key right is the difference between a clean picture and a doubled purchase count. We are only flagging it here as a waypoint, because the mechanics deserve their own treatment: our guide to ",[33,86,88],{"href":87},"\u002Fblog\u002Fmeta-pixel-capi-deduplication","Meta Pixel and CAPI deduplication"," walks through the keys, the window, and the failure modes properly.",[17,91,92],{},"On the value of doing this at all, be careful with the numbers you repeat. Meta says advertisers with a Conversions API setup for web events saw an average 17.8% lower cost per result versus those without. That figure is Meta's own internal data, reported via PPC Land, with no published methodology or sample size. It is directional, it is the vendor's own claim about the vendor's own product, and it is web events only. Use it as a reason to investigate, never as a forecast you put in a deck. Any vendor promising you a specific percentage of \"recovered conversions\" is selling, not citing.",[12,94,96],{"id":95},"the-three-ways-to-deploy-it-and-what-each-really-costs","The three ways to deploy it, and what each really costs",[17,98,99],{},"There are three routes, and the choice is mostly about which resource you have least of.",[101,102,103,122],"table",{},[104,105,106],"thead",{},[107,108,109,113,116,119],"tr",{},[110,111,112],"th",{},"Route",[110,114,115],{},"What you actually do",[110,117,118],{},"Real cost",[110,120,121],{},"Best when",[123,124,125,140,154],"tbody",{},[107,126,127,131,134,137],{},[128,129,130],"td",{},"Direct Conversions API",[128,132,133],{},"Write and maintain an integration that posts events from your backend to Meta",[128,135,136],{},"Engineering time, ongoing maintenance, full ownership of hashing and dedup keys",[128,138,139],{},"You have developers and want control over exactly which parameters ship",[107,141,142,145,148,151],{},[128,143,144],{},"Conversions API Gateway",[128,146,147],{},"Configure a no-code setup in Events Manager, provisioned into your own cloud",[128,149,150],{},"You host it and you pay for it: AWS EKS, AWS ECS Express, or GCP resource or partner fees",[128,152,153],{},"You have budget but no engineering capacity, and want auto-generated dedup keys",[107,155,156,159,162,165],{},[128,157,158],{},"Partner integration",[128,160,161],{},"Enable CAPI through an existing platform integration",[128,163,164],{},"Fastest to live, least control over what is sent",[128,166,167],{},"Your stack already has a supported integration and you can accept its parameter defaults",[17,169,170],{},"The direct route is the honest one. You decide which customer information parameters travel, you control normalisation and hashing, you own the deduplication key. You also own every bug in it. This is the route with the highest ceiling on match quality and the highest demand on your team.",[17,172,173],{},"The Gateway is the most misunderstood. It is self-serve and no-code, configured in Events Manager, which makes it sound like a switch you flip. But Meta's documentation is explicit that the Gateway is provisioned inside your business's own cloud account, on AWS EKS, AWS ECS Express, or GCP, and the business carries the cloud resource or partner fees. You are not offloading infrastructure to Meta. You are standing up infrastructure you now operate, monitor, and pay for, with Meta supplying the configuration layer. The upside is real: it auto-generates deduplication keys, which removes a whole class of manual error. Just do not budget it as free. Note also that the three-cloud list is Meta's currently documented set and could change.",[17,175,176],{},"The partner route is fastest and it is where most smaller advertisers land. The trade is control. You get whatever parameters the integration decides to send, in whatever shape it sends them, and when your match quality is mediocre your options for improving it are limited to whatever that integration exposes. That is an acceptable trade for many teams. It stops being acceptable the moment match quality becomes your bottleneck and you cannot reach the code that would fix it.",[17,178,179,180,184,185,189],{},"For the actual wiring, whichever route you pick, our ",[33,181,183],{"href":182},"\u002Fblog\u002Ffacebook-conversions-api-setup","Facebook Conversions API setup guide"," covers the steps. And if you are still deciding whether you need this at all, ",[33,186,188],{"href":187},"\u002Fblog\u002Ffacebook-pixel-vs-conversions-api","Facebook Pixel vs Conversions API"," frames the decision.",[12,191,193],{"id":192},"one-feed-many-places-a-conversion-can-happen","One feed, many places a conversion can happen",[17,195,196],{},"A detail worth understanding, because it explains why this architecture won.",[17,198,199],{},"Every server event carries an action_source parameter declaring where the conversion happened. Meta documents nine values: email, website, app, phone_call, chat, physical_store, system_generated, business_messaging, and other. That one parameter is why a single Conversions API integration now covers web purchases, app installs, in-store sales, phone enquiries, chat conversions and CRM stage changes.",[17,201,202],{},"Think about what that means for a business whose conversion is not a web checkout. A high-consideration purchase closes on a phone call. A furniture sale closes in a showroom. A B2B lead becomes revenue in a CRM six weeks later. None of those events has a browser anywhere near them, so no Pixel will ever fire for them. Server-side is not a better way to track those conversions. It is the only way.",[17,204,205],{},"This is also where the value stops being about recovering lost web events and starts being about telling Meta what actually matters. If you optimise toward form submissions because that is what the browser can see, you are optimising toward the wrong thing. If your server sends the qualified opportunity, six weeks later, with the right action_source, you are optimising toward revenue. That is the bigger prize, and it has nothing to do with cookies.",[12,207,209],{"id":208},"the-limits-nobody-puts-in-the-pitch-deck","The limits nobody puts in the pitch deck",[17,211,212],{},"This is the section that matters most, because every constraint below has burned somebody.",[17,214,215,219],{},[216,217,218],"strong",{},"Sending an event is not the same as Meta being able to use it."," Meta's best-practice documentation is precise about this: you cannot use unmatched events for attribution or ad delivery optimisation, but you can still use them for basic measurement. So an unmatched event is not deleted. It is demoted to a number on a dashboard that can never influence delivery or credit. Your dashboard can show a healthy stream of received events while a large share of them contribute nothing to attribution or optimisation, which is exactly the trap of judging server-side by volume sent.",[17,221,222,225],{},[216,223,224],{},"Matching requires at least one properly formatted customer information parameter."," A server event needs a minimum of one correctly formatted user_data parameter to be eligible to match. Contact information, meaning email, phone, name, date of birth, gender, city, state, zip and country, must be SHA-256 hashed. A second group is explicitly sent unhashed, and Meta's parameter table says \"do not hash\" against each: client_ip_address, client_user_agent, fbc, fbp, subscription_id, fb_login_id and lead_id. Hash one of those and it will not match. Fail to normalise before hashing and it will not match. The formatting is not pedantry, it is the whole mechanism.",[17,227,228],{},"external_id is the parameter that catches people out, because it belongs to neither group cleanly. Meta recommends hashing it but does not require it, so hashing external_id is not the bug it is often reported to be. What actually matters is consistency: send it in the same form from the browser and from the server, because external_id doubles as a deduplication fallback key. Hash it in one feed and send it raw in the other, and you have not broken matching so much as broken dedup.",[17,230,231,234,235,239],{},[216,232,233],{},"Match quality is measured, and you can read it."," Event Match Quality is scored out of 10 and measures how effectively the customer information sent from your server matches event instances to a Meta account. Meta's Dataset Quality API returns a composite score per event. Treat that score as the primary health metric of a server-side setup, ahead of event volume. Our guide to ",[33,236,238],{"href":237},"\u002Fblog\u002Fmeta-event-match-quality-emq","Meta Event Match Quality"," covers how to raise it.",[17,241,242,245],{},[216,243,244],{},"The seven-day rule rejects the whole batch."," Server-side does not mean you can backfill history whenever you like. If any single event_time in a batch is older than seven days, Meta rejects the entire request and processes zero events. One bad timestamp poisons the batch. Filter before you send, and log the response, because a nightly job that silently fails every night looks identical to a nightly job that works until someone checks the numbers.",[17,247,248,251],{},[216,249,250],{},"Server-side does not create consent."," Moving the request from a browser to your backend changes the transport, not your obligations. The proof is inside Meta's own parameter list: data_processing_options exists specifically so advertisers can signal limited data use on a server event. That parameter would be unnecessary if server-side stepped outside privacy rules. It does not.",[17,253,254,257],{},[216,255,256],{},"Some rules are genuinely unresolved, and you should verify rather than trust."," Two examples worth naming, one settled and one not. The Aggregated Event Measurement cap of eight conversion events per domain is verifiable as a January 2021 Meta announcement, and it was lifted on 15 May 2023, when Meta announced that event prioritization was no longer necessary (DEPT and Adviso both confirm the date independently). The reason it is worth naming anyway is that the correction has not propagated: plenty of current advice still presents the 2021 cap as binding, and plenty more dates its removal to 2025. Check your own domain's event configuration in Events Manager rather than planning around either. Second, the Offline Conversions API's retirement date is contested: vendor blogs assert May 2025, Meta's own current offline-events documentation carries no sunset notice, and at least one report says the deprecation was delayed. Confirm it yourself before you migrate anything on the strength of a blog post.",[12,259,261],{"id":260},"reading-the-symptoms-when-it-goes-wrong","Reading the symptoms when it goes wrong",[17,263,264],{},"Server-side failures rarely announce themselves. The integration keeps returning success, the events keep arriving, and the numbers quietly stop meaning anything. Here is how the common symptoms map to causes, and where in this cluster the fix lives.",[101,266,267,280],{},[104,268,269],{},[107,270,271,274,277],{},[110,272,273],{},"Symptom",[110,275,276],{},"Likely cause",[110,278,279],{},"Where to look",[123,281,282,293,304,315,326,337],{},[107,283,284,287,290],{},[128,285,286],{},"Purchases roughly doubled overnight",[128,288,289],{},"Deduplication key missing or mismatched between the two feeds",[128,291,292],{},"event_id must be identical on the browser and server event for the same conversion, and both must arrive within the 48-hour window",[107,294,295,298,301],{},[128,296,297],{},"Events received, match quality low, performance flat",[128,299,300],{},"Too few user_data parameters, or a hashing error",[128,302,303],{},"Add correctly formatted parameters; check nothing in the unhashed list got hashed",[107,305,306,309,312],{},[128,307,308],{},"Whole nightly batch returns an error, zero events processed",[128,310,311],{},"One event_time older than seven days",[128,313,314],{},"Filter the export by the seven-day boundary before sending",[107,316,317,320,323],{},[128,318,319],{},"Server events match far worse than browser events",[128,321,322],{},"fbp and fbc are not being captured and passed through to the backend",[128,324,325],{},"Those identifiers originate in the browser; the server cannot invent them",[107,327,328,331,334],{},[128,329,330],{},"CRM conversions never appear",[128,332,333],{},"Missing or wrong action_source, or events falling outside the seven-day rule by the time the deal closes",[128,335,336],{},"Send the event when the stage changes, not in a monthly reconciliation job",[107,338,339,342,345],{},[128,340,341],{},"Numbers were fine, then drifted after a site release",[128,343,344],{},"A checkout refactor changed the field feeding the hash or the dedup key",[128,346,347],{},"Diff what the integration sends before and after the release",[17,349,350],{},"Two habits prevent most of this. First, log Meta's response rather than firing and forgetting, because a rejected batch and a successful one look the same from the outside if nobody reads the reply. Second, treat any deploy that touches checkout, the customer record, or the tag manager as a change to your measurement, and check the event stream after it ships. Most tracking incidents are not tracking bugs. They are ordinary releases that nobody thought to check against the ad account.",[12,352,354],{"id":353},"what-server-side-tracking-will-not-fix","What server-side tracking will not fix",[17,356,357],{},"Worth saying plainly, because the expectation gap is where disappointment lives.",[17,359,360],{},"It will not make your reporting match your backend exactly. Better signal narrows the gap. Nothing closes it, because attribution is modelled and your backend is counted, and those are different kinds of number.",[17,362,363],{},"It will not fix a bad offer. Attribution tells you which ads got credit. It has no opinion on whether the ad was worth clicking.",[17,365,366],{},"It will not fix creative. If your account is plateauing, cleaner event data will tell you that more accurately and slightly sooner. It will not produce the next thing worth testing. That comes from looking at what is actually working in your category, building the creative, and getting it live, which is a loop a platform like AdPlay.ai is built to run. Tracking is how you read the result, not how you get one.",[17,368,369],{},"And it will not run itself. This is infrastructure. Hashing changes when a field changes. Dedup keys drift when someone refactors a checkout. Match quality decays quietly. Put the EMQ score on a dashboard somebody actually looks at, or you will discover the problem the month the numbers stop making sense.",[12,371,373],{"id":372},"where-to-start","Where to start",[17,375,376],{},"If you have nothing server-side today, the sequence is unglamorous.",[17,378,379,380,384],{},"Confirm the Pixel is still healthy first, because you are adding to it, not replacing it. If it is misbehaving, our guide on ",[33,381,383],{"href":382},"\u002Fblog\u002Ffacebook-pixel-not-tracking","why the Facebook Pixel is not tracking"," is the right first stop. Then pick a deployment route honestly, based on whether you have engineering time or hosting budget. Start with one event, usually Purchase, sent both client-side and server-side with a matching event_id. Watch the deduplication behave for a few days. Read your Event Match Quality score, and improve it by adding correctly formatted parameters before you add more event types. Only then expand the taxonomy.",[17,386,387,388,392],{},"Then read your attribution honestly. Better events do not change how Meta assigns credit across time, and a lot of the confusion attributed to tracking gaps is really about windows: our guide to the ",[33,389,391],{"href":390},"\u002Fblog\u002Ffacebook-ads-attribution-window","Facebook ads attribution window"," covers that.",[17,394,395],{},"The whole point of this work is a shorter, truer feedback loop between what you shipped and what it earned. Server-side tracking is a good investment in that loop. It is not the loop.",{"title":397,"searchDepth":398,"depth":398,"links":399},"",2,[400,401,402,403,404,405,406,407,408],{"id":14,"depth":398,"text":15},{"id":40,"depth":398,"text":41},{"id":71,"depth":398,"text":72},{"id":95,"depth":398,"text":96},{"id":192,"depth":398,"text":193},{"id":208,"depth":398,"text":209},{"id":260,"depth":398,"text":261},{"id":353,"depth":398,"text":354},{"id":372,"depth":398,"text":373},null,"neutral","What server-side tracking means for Facebook ads, why browser signal keeps degrading, the three ways to deploy the Conversions API, and the limits nobody mentions.",[],"md",[415,418,421,424,427,430,433,436],{"question":416,"answer":417},"Does server-side tracking replace the Meta Pixel?","No, and Meta says so directly. Its deduplication documentation states that for optimal ad performance it recommends advertisers implement the Conversions API alongside their Meta Pixel, and its best-practice guidance adds that you should use the Conversions API in addition to the Meta Pixel and share the same events using both tools. The two feeds carry different strengths. The browser contributes identifiers the server often cannot see on its own, such as the fbp cookie and the fbc click identifier. The server contributes events the browser never fires, either because a script was blocked or because the conversion happened somewhere a browser was not present at all. Sending both and letting Meta deduplicate is the documented design, not a belt-and-braces hack. If you are weighing one against the other, our guide on the Meta Pixel versus the Conversions API works through that comparison properly.",{"question":419,"answer":420},"Did Chrome killing third-party cookies force everyone to go server-side?","Chrome did not kill third-party cookies, and any guide that says otherwise is out of date. On 22 April 2025 Google announced it had decided to maintain its current approach to offering users third-party cookie choice in Chrome and would not roll out a new standalone prompt, reversing the plan it had signalled the year before. The more consequential news came later: on 17 October 2025 Google retired ten Privacy Sandbox technologies, including the Attribution Reporting API and Topics, across Chrome and Android. So the honest framing is not that cookies ended. It is that Safari restricts them hard (a seven-day lifetime cap since 2019, and no cross-site cookies at all since 2020) and Firefox has confined them to per-site jars by default since Total Cookie Protection shipped to everyone in June 2022, while Chrome keeps them under a user-choice model, and the standards-based replacement for cookie attribution that the industry spent years preparing for was cancelled. First-party server-side feeds became the practical option by default rather than by mandate.",{"question":422,"answer":423},"Why is my Conversions API sending events but nothing improves?","Almost always because the events are not matching. Meta's wording is precise: you cannot use unmatched events for attribution or ad delivery optimisation, but you can still use them for basic measurement. An unmatched event is not a weaker event, it is one that can be counted but never used to optimise or attribute. A server event needs at least one correctly formatted customer information parameter to be eligible to match at all, and quality climbs with more of them. Contact information such as email, phone, name, date of birth, gender, city, state, zip and country must be SHA-256 hashed before it is sent. Other parameters, including client_ip_address, client_user_agent, fbc, fbp, subscription_id, fb_login_id and lead_id, are sent unhashed. external_id sits in between: Meta recommends hashing it but does not require it, and what matters is that you send it in the same form from browser and server, because it doubles as a deduplication fallback key. A common failure is hashing a field Meta tells you not to hash, or hashing an unnormalised value. Check your Event Match Quality score in Events Manager before you touch anything else.",{"question":425,"answer":426},"What is the Conversions API Gateway, and is it free?","The Gateway is Meta's self-serve, no-code route to server-side events, configured in Events Manager, and it is not free. Meta's documentation is clear that the Gateway is provisioned inside your own business's cloud account, on AWS EKS, AWS ECS Express, or GCP, and that the business carries the cloud resource or partner fees. So you skip the engineering work of writing an integration, but you inherit a piece of cloud infrastructure to own, monitor and pay for. In its favour, the Gateway auto-generates deduplication keys, which removes one of the most common sources of manual error. Treat it as a trade of developer time for hosting cost and operational responsibility, not as a shortcut that costs nothing.",{"question":428,"answer":429},"Can I upload historical conversions through the Conversions API?","Not far back, and the failure mode is unforgiving. Meta rejects the entire request and processes zero events if any single event_time in the batch is older than seven days. One stale timestamp does not get dropped quietly while the rest succeed, it takes the whole batch down with it. This matters most for CRM and offline feeds, where a sales team might close a deal on Monday and update the record on Friday. Build your export around the seven-day boundary, filter before you send rather than after Meta rejects, and log the rejection response so a silently failing nightly job does not run for three weeks before anyone notices.",{"question":431,"answer":432},"Does server-side tracking let me bypass consent requirements?","No. Moving an event from the browser to your server changes where the request originates, not what you are allowed to collect or what you promised the user. If a visitor declined tracking, sending their purchase from your backend instead of from a blocked tag does not make that legitimate. Meta's own server event parameters include data_processing_options, which exists specifically so advertisers can signal limited data use on a server event. That parameter would be pointless if server-side placed you outside privacy obligations. Server-side is a delivery mechanism. Consent, data minimisation and your privacy notice are separate obligations that follow the data, not the transport.",{"question":434,"answer":435},"Is the eight conversion event limit still in force?","No, it was removed. Meta introduced Aggregated Event Measurement for the iOS 14 era and, in a January 2021 announcement, capped campaign optimisation at eight conversion events per domain. That cap is gone: Meta announced on 15 May 2023 that event prioritization was no longer necessary and that advertisers are no longer limited to eight events for iOS users, a date and substance confirmed independently by DEPT (31 May 2023) and Adviso (4 July 2023). Meta now auto-aggregates eligible events. Be careful with what you read here, because a lot of published advice still dates this change to 2025 or still describes the 2021 cap as current. Open Events Manager and look at your own domain's event configuration rather than planning an event taxonomy around a number a blog repeated from 2021.",{"question":437,"answer":438},"What happened to the Offline Conversions API?","This is genuinely unclear, and we would rather say so than invent a date. A number of vendor blogs assert that the Offline Conversions API was retired in May 2025. Meta's own current documentation page for sending offline events using the Conversions API carries no deprecation or sunset notice, and at least one industry report indicates the deprecation was delayed rather than executed. Those two things cannot both be casually true, so treat any confident retirement date you read as unverified. In the meantime, the modern pattern for offline conversions is a standard server event carrying action_source set to physical_store or another appropriate value. Confirm the current status in Events Manager and Meta's developer documentation before you migrate anything.","\u002Fimages\u002Fblog\u002Fserver-side-tracking-facebook-ads-hero.webp","Your Meta reporting says 40 purchases. Your backend says 61. Somebody suggests server-side tracking, and within a week you are reading about gateways, hashing, deduplication keys, and a match quality score out of 10. The short version: the browser stopped being a trustworthy narrator, and your server is the only witness left that saw the money move.",{"reviewedAt":442},"2026-07-15",true,"\u002Fblog\u002Fserver-side-tracking-facebook-ads","2027-09-08",{"title":5,"description":411},[448,452,455,458,461,464,467,470,474,478,481,485,488,492,495,499,503,507,510],{"label":449,"url":450,"year":451},"Meta for Developers - Handling Duplicate Pixel and Conversions API Events","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocs\u002Fmarketing-api\u002Fconversions-api\u002Fdeduplicate-pixel-and-server-events\u002F","2026",{"label":453,"url":454,"year":451},"Meta for Developers - Conversions API Best Practices","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocumentation\u002Fads-commerce\u002Fconversions-api\u002Fbest-practices",{"label":456,"url":457,"year":451},"Meta for Developers - Conversions API Gateway","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocumentation\u002Fads-commerce\u002Fgateway-products\u002Fconversions-api-gateway",{"label":459,"url":460,"year":451},"Meta for Developers - Server Event Parameters (action_source, event_time, data_processing_options)","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocumentation\u002Fads-commerce\u002Fconversions-api\u002Fparameters\u002Fserver-event",{"label":462,"url":463,"year":451},"Meta for Developers - Dataset Quality API (Event Match Quality)","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocumentation\u002Fads-commerce\u002Fconversions-api\u002Fdataset-quality-api",{"label":465,"url":466,"year":451},"Meta for Developers - Conversions API Customer Information Parameters","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocs\u002Fmarketing-api\u002Fconversions-api\u002Fparameters\u002Fcustomer-information-parameters\u002F",{"label":468,"url":469,"year":451},"Meta for Developers - Sending Offline Events Using the Conversions API","https:\u002F\u002Fdevelopers.facebook.com\u002Fdocumentation\u002Fads-commerce\u002Fconversions-api\u002Foffline-events",{"label":471,"url":472,"year":473},"Meta for Developers - Preparing our Partners for iOS 14 (Aggregated Event Measurement, 8-event cap as announced)","https:\u002F\u002Fdevelopers.facebook.com\u002Fblog\u002Fpost\u002F2021\u002F01\u002F19\u002Factions-partners-mobile-web-advertisers\u002F","2021",{"label":475,"url":476,"year":477},"DEPT - Meta's removal of Aggregated Event Measurement and its implications for advertisers (dates the eight-event cap removal to 15 May 2023)","https:\u002F\u002Fwww.deptagency.com\u002Fen-dk\u002Finsight\u002Fmetas-removal-of-aggregated-event-measurement-aem-and-its-implications-for-advertisers\u002F","2023",{"label":479,"url":480,"year":477},"Adviso - Meta announces the evolution of its Aggregated Event Measurement protocol (independent confirmation of the 15 May 2023 date)","https:\u002F\u002Fwww.adviso.ca\u002Fen\u002Fblog\u002Fguides-en\u002Fevolution-aggregated-measurement-meta",{"label":482,"url":483,"year":484},"Google Privacy Sandbox - Next steps for Privacy Sandbox and tracking protections in Chrome","https:\u002F\u002Fprivacysandbox.google.com\u002Fblog\u002Fprivacy-sandbox-next-steps","2025",{"label":486,"url":487,"year":484},"Google Privacy Sandbox - Update on Plans for Privacy Sandbox Technologies","https:\u002F\u002Fprivacysandbox.google.com\u002Fblog\u002Fupdate-on-plans-for-privacy-sandbox-technologies",{"label":489,"url":490,"year":491},"Apple WebKit - Intelligent Tracking Prevention 2.1","https:\u002F\u002Fwebkit.org\u002Fblog\u002F8613\u002Fintelligent-tracking-prevention-2-1\u002F","2019",{"label":493,"url":494,"year":491},"Apple WebKit - Intelligent Tracking Prevention 2.2","https:\u002F\u002Fwebkit.org\u002Fblog\u002F8828\u002Fintelligent-tracking-prevention-2-2\u002F",{"label":496,"url":497,"year":498},"Apple WebKit - Full Third-Party Cookie Blocking and More","https:\u002F\u002Fwebkit.org\u002Fblog\u002F10218\u002Ffull-third-party-cookie-blocking-and-more\u002F","2020",{"label":500,"url":501,"year":502},"Mozilla - Firefox rolls out Total Cookie Protection by default to all users worldwide","https:\u002F\u002Fblog.mozilla.org\u002Fen\u002Fproducts\u002Ffirefox\u002Ffirefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide\u002F","2022",{"label":504,"url":505,"year":506},"AppsFlyer - ATT data findings, three years post-ATT","https:\u002F\u002Fwww.appsflyer.com\u002Fcompany\u002Fnewsroom\u002Fpr\u002Fatt-data-findings\u002F","2024",{"label":508,"url":509,"year":484},"Backlinko - Ad Blocker Usage Statistics (citing GWI via DataReportal)","https:\u002F\u002Fbacklinko.com\u002Fad-blockers-users",{"label":511,"url":512,"year":451},"PPC Land - Meta upgrades Pixel and Conversions API to close the gap for small advertisers","https:\u002F\u002Fppc.land\u002Fmeta-upgrades-pixel-and-conversions-api-to-close-the-gap-for-small-advertisers\u002F",[514,518,522,526,530,534],{"label":515,"value":516,"source":517},"Internet users worldwide using ad blockers at least sometimes, Q2 2025","29.5%","GWI via DataReportal, reported by Backlinko, 2025",{"label":519,"value":520,"source":521},"Global ATT opt-in rate, three years after launch","50%","AppsFlyer, 2024",{"label":523,"value":524,"source":525},"Safari's cap on persistent cookies set via document.cookie","7 days","Apple WebKit, 2019",{"label":527,"value":528,"source":529},"Privacy Sandbox technologies Google retired in October 2025","10","Google Privacy Sandbox, 2025",{"label":531,"value":532,"source":533},"Window in which Meta deduplicates Pixel and server events","48 hours","Meta for Developers, 2026",{"label":535,"value":536,"source":537},"Lower cost per result for advertisers with web Conversions API (directional, Meta's own data)","17.8%","Meta, reported by PPC Land, 2026","blog\u002Fserver-side-tracking-facebook-ads","PBpgyUuoEslCqcMieUrDZzMH5hd4qUKZCOC8ITULZHI",1786093701316]