Meta Pixel and Conversions API setup

The Meta Pixel and the Conversions API are the two ways your website tells Meta that someone who saw an ad went on to enquire, book or buy. I set both up for UK businesses already advertising on Facebook and Instagram, connect them so each sale or lead is counted once, and make sure neither sends anything before a visitor has agreed to marketing cookies.

What this fixes, and what changes afterwards

Meta’s delivery system decides who sees your ads largely from the conversion signals it receives. When those signals are missing, doubled or late, it optimises towards the wrong people and Ads Manager reports a cost per result you cannot trust. The Meta Pixel on its own is a browser script, so it loses events to ad blockers, Safari’s tracking limits, slow pages and people who close the tab before the thank-you page loads.

The Conversions API sends the same events from your server, shop platform or CRM instead, which closes many of those gaps. Done properly, the result is a cleaner record of real enquiries and orders, fewer phantom or duplicated conversions, and campaigns that learn from what actually happened. It does not create conversions that did not occur, and it does not make reporting perfect; it makes it closer to your own sales records.

Who it suits, and who it does not

• UK online shops whose Meta purchase numbers drift away from the orders in Shopify, WooCommerce or their own checkout.
• Service businesses running Meta ads for enquiries, where the form, booking tool or phone call sits outside the ad platform’s view.
• Businesses that inherited a Pixel from a previous agency and are not sure who owns it or what it sends.
• Anyone who has added a cookie banner and watched reported conversions fall without knowing which part of the drop is real.

It is not worth commissioning if you are not running Meta ads, or plan to stop. If you have a small shop on a mainstream platform with a single product range, the platform’s own Meta integration may already cover most of this, and an hour checking its settings will tell you whether anything more is needed.

What gets set up

The UK consent and data protection side

Under PECR, the Pixel’s cookies are not strictly necessary, so they need consent before they are set. Moving tracking to a server does not take it outside PECR: if a server event describes someone’s visit and relies on identifiers read from their device, I treat it as needing the same consent. A setup that sends server events for visitors who clicked “Reject” is a compliance problem, however good the match quality looks.

Hashed email addresses and phone numbers are still personal data under UK GDPR, because Meta can match them back to an account. Before customer details go to Meta you need a lawful basis for sharing them, a privacy notice that names Meta as a recipient and says why, and acceptance of Meta’s business tools terms. I flag what your privacy notice needs to cover and which events carry personal data. I am not a solicitor, so for the final wording and your lawful basis I suggest your data protection lead or legal adviser signs it off.

How I run it

1. Access. You add me as a partner in your Meta business portfolio and give me a role in Tag Manager or your site platform. I never need your passwords.
2. Current state. I record what fires today, on which pages, with what data, and how it behaves when cookies are accepted or refused.
3. Event plan. A short written map of each event, its trigger, its parameters and where its value comes from, agreed with you before I build.
4. Build. Pixel and Conversions API set up through the agreed route, with consent gating and deduplication in place.
5. Testing. Meta’s Test Events tool, a real test enquiry or order, and checks that each conversion appears once with the right value.
6. Monitoring. I watch Events Manager diagnostics after launch and compare reported conversions with your own records.

If you want to check an existing setup yourself first, my guide on how to check your conversion tracking works walks through the same first tests.

Common problems on UK sites

• The Pixel loads before the cookie banner has been answered, because it was pasted into the theme or added by a plugin the banner does not control.
• The banner blocks the Pixel correctly, but a plugin sends every server event regardless of the visitor’s choice.
• Two or three copies of the Pixel, from an old app, a theme snippet and a Tag Manager tag, counting each order more than once.
• Purchase values sent in dollars, or with VAT and delivery included on some orders and not others, which makes return on ad spend meaningless.
• A Lead event that fires when the submit button is pressed, including when the form then fails validation.
• Server events sent with no customer details or cookie values, so Meta can match very few of them.
• A Pixel owned by a former agency’s business account, which the advertiser cannot fully control.

What you receive

• A working Pixel and Conversions API connection, deduplicated and gated by consent.
• The event map: every event, its trigger, parameters and value source.
• A test record showing each event arriving once, and the consent behaviour for accept and reject.
• Notes on the privacy notice points to review with whoever handles data protection for you.
• Handover notes your team or agency can follow to add events or fix breaks later.

Cost: each quote is written in GBP after a first call, once I know how your site is built and which route suits it, and is agreed in writing before work starts.