How to check what your Facebook pixel is actually sending (a 10-minute Test Events walkthrough)

Most people have never looked at what their pixel sends. It's a ten-minute job and it's often a shock. So here's the walkthrough, plus what to do with what you find, because the finding is only half the job.

Step 1. Open Events Manager and go to your dataset. Find Test Events.

Step 2. Open your own site in another tab and do the thing a patient would do: land on a treatment page, open the booking form, submit it with dummy details. Use an email you control.

Step 3. Watch the events appear in Test Events. Click each one to open it.

Step 4. Look at the parameters. Specifically the page URL, the event name, and anything that looks like a custom field.

Step 5. Ask yourself the one question that matters: if I read only this, what would I know about the person?

If the answer is "which treatment they want" or "which condition they have", that's your problem. If the answer is "nothing much", good, keep going.

Now, what to do with what you find. I'd sort the findings into three piles.

Pile one: URLs and page titles. These are the easiest to fix. They come from the address and the page, and they can be cut down to your domain before the event leaves.

Pile two: event names. These are set in your tag or plugin setup. They can be replaced with neutral names, with a small note somewhere of what each code means.

Pile three: form fields and custom data. These are the hardest, because someone decided to send them. Ask why each one is there. If nobody can explain it, it probably shouldn't be.

Then write it down. A simple table: event, what it carries, the fix, who owns it. That table becomes your record. If you're ever asked to explain your setup, "here's what we found, what we changed, and what's sent now" is a much stronger answer than a shrug.

Bonus: do the same on your thank-you page. It's the one people forget, and it's often the most descriptive of all. Also repeat the test after every site change. New pages are how leaks come back.

Let me help you read what you find, field by field, because Test Events shows a lot and it's easy to skim.

Start with the event name at the top. Is it a standard name, like Lead or Purchase, a code, or something you or an agency invented? Custom names are the ones to read twice.

Then look for the URL, usually shown as the event source or in the parameters. Read the whole path, including anything after a question mark. Campaign parameters and coupon codes can carry meaning too, like ?utm_campaign=acne-treatment or a discount code named after a condition.

Then look at the user data section. You should see hashed values for email and phone, not readable ones. If you see something readable that looks like a name or an address, ask why.

Then look at anything labelled custom data or content. If your store or plugin sends product names, categories or form values there, they're in the event.

And note the timing. Test Events shows when the event arrived. If the confirmation page fires the event late or twice, that's a duplicate to fix.

How often should you run it? After every significant site change, and on a schedule, say monthly. Ten minutes a month is far cheaper than a week of lost conversions. And when you find something, write down what it was, where it came from and how you fixed it. That log is worth more than it looks.

For reference, DataCops keeps a delivery log with a row per conversion, so the check you just ran in Test Events can be repeated for every event that leaves, not just one.