Every pixel event your site sends gets an EMQ boost when it carries customer data. PixelYourSite already sends IP, browser cookies, and full customer details for logged-in users and WooCommerce customers automatically, so their events score well. The gap is anonymous visitors who fill out a form but never log in. Once PYS recognises their field names, every event they trigger — page views, button clicks, form submissions — carries their hashed name, email, and phone data to Meta. Connect your AI assistant and you can find that gap, scan the form, configure the field names, and close it in one conversation.
This guide assumes you have CAPI enabled and are looking to improve your score.
To use this workflow, you need PixelYourSite MCP connected to your site and an AI assistant configured to use it. See Getting Started with PixelYourSite MCP for setup instructions.
The scenario
A services site has a contact form on its /contact page. It gets dozens of submissions a day. Those visitors browse the site, fill the form, and leave. Because they never log in and never reach a WooCommerce checkout, PYS can’t identify them. Their events reach Meta with only IP, browser agent, and cookies. EMQ sits at 6.2 across the board.
The field names on the form are non-standard. The form is built with Contact Form 7 and uses your-name, your-email, and your-phone. PYS’s default detection doesn’t catch your-name or your-phone: it only recognises name, first_name, phone, and telby default.
Step 1: Check your current advanced matching configuration
Ask: “What is my current advanced matching setup for Facebook?”
The assistant reads your configuration and reports:
- Which field-name lists are populated (first name, last name, email, phone)
- Which dimensions have no field names configured
- Whether the Facebook Advanced Matching switch is enabled
- What PYS is sending automatically from logged-in users and WooCommerce
In this scenario, the assistant finds:
- Facebook Advanced Matching: enabled
- Email: detected automatically (type=”email” fields)
- Phone:
phone,tel: but notyour-phone - First name:
first_name,first-name,name: but notyour-name - Last name:
last_name,last-name: not configured for this site at all
The gaps are clear: the contact form’s non-standard field names aren’t being read.
Step 2: Scan the contact page
“Scan my contact page: https://yoursite.com/contact“
The assistant fetches the page and returns every form field it finds with its name, id, type, and label. For this form it finds:
| name | type | label |
|---|---|---|
your-name | text | Your Name |
your-email | Your Email | |
your-phone | text | Your Phone |
your-message | textarea | Message |
your-email is already handled by type=”email” detection. your-message is irrelevant. The fields that matter are your-name and your-phone.
Step 3: Add the field names
The assistant proposes:
- Add
your-nameto first name field names - Add
your-phoneto phone field names
“Yes, add them.”
Two-step confirm: the assistant shows a preview of the changes, you confirm, and they are saved.
Step 4: Verify
EMQ doesn’t update instantly: it reflects the last 7 days of events. Check back in Events Manager after a few days of form traffic. Adding name and phone data typically moves the score from the 6-range to the 8-range across all event types, depending on traffic volume.
Ask: “Check my advanced matching configuration again” to confirm the new field names appear in the lists.
What happens technically
When a visitor fills out the contact form, their browser fires blur events as they leave each field. PYS reads the value of any field whose name attribute matches something in your configured lists and stores it in a pys_advanced_form_data cookie. Every CAPI event that fires after that carries those hashed values as customer parameters.
The visitor doesn’t have to submit the form. They just have to have typed in it.
Multiple forms, one configuration
The field-name lists are site-wide. If your site has a newsletter signup at /newsletter that uses subscriber_email and subscriber_name, those can be added to the same lists. Any form on any page using those field names gets picked up automatically.
“Scan my newsletter page too: https://yoursite.com/newsletter“
The assistant scans it, identifies the relevant fields, and proposes the additions with your confirmation.
What this does for other platforms
The same field-name configuration feeds TikTok match rate, Google Ads Enhanced Conversions, and GA4 User-Provided Data. You configure the field names once in PYS and all platforms with their matching switch enabled benefit.
What MCP can’t do here
- Access your Events Manager EMQ score directly. That lives in Meta’s interface.
- Scan JavaScript-rendered forms. If your form loads dynamically, inspect the field names in your browser’s dev tools and tell the assistant directly: “Add
subscriber-emailto my email field names.” - Add a country code to phone numbers. If your phone fields don’t include a country code, Meta receives numbers without one, which matches less well. That fix is on the form side.