A website that tracks your ads: Meta Pixel, Conversions API and GA4

The Pixel is a script that runs in the visitor's browser and reports what they do: viewed a page, filled in a form, booked. That is also its weakness. If the script is blocked, does not load in time, or the visitor leaves before it fires, the event never reaches Meta. Your ad brought in a lead and your ads account never hears about it.

On iPhones there is a second layer. Apple's rules on user privacy say that in iOS 14.5 and later an app must ask the user's permission through App Tracking Transparency to track them across other companies' apps and websites. Many people decline, which reduces what ad platforms can see and match. The result for an advertiser is the same: fewer conversions reported than really happened, and campaigns optimising on partial data.

The Conversions API sends events from your server to Meta, rather than from the visitor's browser. When someone submits a form on your site, your server records it and tells Meta directly. That does not depend on a script loading in the browser, so it is not lost when the script is blocked or the page closes early.

Meta's own advice is to run both. Its documentation on duplicate events says that for optimal ad performance it recommends implementing the Conversions API alongside the Meta Pixel, and that advertisers who send the same events through both must set up deduplication. The standard way is to give each event the same name and the same event ID on both sides; Meta then keeps one and discards the duplicate.

Meta reports what Meta's ads did. Google Analytics 4 shows what your whole site is doing, from every source: search, Google Ads, social, email, direct. In GA4 you can mark the actions that matter as key events, such as a booking, a quote request or a call click, and see which channels and campaigns lead to them.

If you run Google Ads, the same key events can feed its conversion tracking, so Google's bidding works from real leads rather than clicks. Between the two, you can answer the question that matters: which spend brings customers, and which does not.

• The Meta Pixel on every page, loaded so it does not slow the page down.
• The Conversions API sending the same key events from the server, with a shared event ID on both sides so nothing is counted twice.
• GA4 with your real business actions marked as key events, not just page views.
• Google Ads conversion tracking from those same actions, if you advertise on Google.
• Consent handled properly for the visitors and places that require it.
• A simple report of leads by source, so you can see what each campaign produced.

Every event should be tested end to end before a campaign relies on it: submit the form, see it arrive in Meta's Events Manager and in GA4, and check it was counted once.

No. Ad tracking is set up on custom builds only. The standard website and app plans do not include it, because doing it properly means working through your actual campaigns, forms and consent requirements with you, not ticking a box.

On a custom build we scope it with the rest of the site: which actions count as a lead, which ad accounts and analytics properties are involved, and how you want to see the results. The scope and the price are fixed on a call before anything is built.

If you spend very little, start simpler: GA4 with your key events marked, and the Pixel if you advertise on Meta. You will see roughly what is working. Server-side tracking earns its place when ad spend is large enough that missing a share of conversions changes decisions, or when campaigns are optimising for leads and need every one counted.

Either way, the tracking is only as good as the site it measures. A slow page or a confusing form loses the lead before any tag fires. That is the part we start with.

Tell us what you advertise, where, and what counts as a lead for your business. We will say plainly what setup fits, and whether you need the full server-side version at all. Book a call, or read about the studio first.