Last updated
Revenue First Analytics can send PageView, ViewContent, AddToCart, InitiateCheckout and Purchase events to Meta through the Facebook Conversions API from your server, and optionally load the Facebook Pixel in the browser. Events are sent only for visitors with marketing consent and never in Privacy mode, and the buyer’s email, phone, name and address are SHA-256 hashed before they leave your site.
The integration is off by default. It is useful when you run Meta ads and want purchases reported server-side, so that ad blockers and browser restrictions do not hide conversions from your campaigns.
What does the integration send?
| Event | When | Sent from | Event data |
|---|---|---|---|
| PageView | Every page load | Browser pixel; the server sends it instead when the browser pixel is turned off | Page URL |
| ViewContent | A WooCommerce single product page is viewed | Server | Product ID, name, price, currency |
| AddToCart | A product is added to the WooCommerce or EDD cart | Server | Product ID, name, price times quantity, currency, quantity |
| InitiateCheckout | The checkout page is opened with items in the cart, once per session | Server | Product IDs, cart total, currency, item count |
| Purchase | The buyer lands on the WooCommerce thank-you page or the EDD receipt page, once per order | Server | Product IDs and quantities, order total, currency, item count, order ID |
Purchase is sent from the thank-you page on purpose: that request carries the buyer’s IP address, User-Agent and _fbp/_fbc cookies, which Meta uses for matching. An order that is only confirmed later by a payment webhook, where the buyer never returns to your site, is still counted in your Revenue First Analytics reports but does not produce a Purchase event for Meta.
How are browser and server events kept from double counting?
The plugin splits the work instead of sending everything twice. The browser pixel, when enabled, sends only PageView. The server sends ViewContent, AddToCart, InitiateCheckout and Purchase, plus PageView only when the browser pixel is disabled. Every event also carries an event_id: for Purchase it is Purchase_ followed by the order key, which is the same on every attempt, and the plugin marks the order as sent so a refreshed thank-you page does not send it again. Other events get a unique ID per send.
If another plugin already loads the Facebook Pixel on your site, turn off Inject browser pixel here so PageView is not loaded twice; the setting description says the same.
Which visitor data is sent to Meta?
Each server event includes a user_data block built the way Meta requires:
- The visitor’s IP address and User-Agent, in plain text (Meta requires these for server events).
- The
_fbpand_fbccookies set by Meta, if present. - An
external_id: the SHA-256 hash of the_rfa_vidvisitor ID, only for identified visitors. - For Purchase: the billing email, phone, first name, last name, city, state, zip and country from the order, each lowercased, trimmed and SHA-256 hashed. Phone numbers are reduced to digits and spaces are removed from city and zip before hashing.
- For the other events, when the visitor is logged in: their account email, first name and last name, hashed the same way.
None of the billing details are written to the analytics tables; they are read from the order only for this request. Events are never sent for logged-in administrators when Exclude admin users is on, or for known bots when Exclude bots is on. The request to graph.facebook.com is non-blocking with a one-second timeout, so it does not slow down the page.
When are events allowed to be sent?
Every event, browser and server, requires marketing consent. What that means depends on your tracking mode; see Choosing a Privacy Mode.
| Tracking mode | Facebook events |
|---|---|
| Privacy mode | Never. The integration does nothing and the card says “Not available in Privacy mode: Facebook receives visitor data, which requires marketing consent.” |
| Consent mode | Only after the visitor accepts the marketing category, through a WP Consent API banner or window.rfa.setConsent(). The pixel is loaded at that moment; if consent is withdrawn later, the pixel is told to stop with fbq('consent', 'revoke'). |
| Full tracking | Always, for every visitor. |
How to wire the marketing category to your banner is covered in Connecting Your Cookie Banner.
Set up the integration
- Open Rev Analytics, click the Settings gear icon in the top bar and scroll to the Facebook Conversions API card.
- Turn on Enable Facebook CAPI. The remaining fields appear.
- Enter your Pixel ID. In Facebook Events Manager, select your Pixel in the left sidebar (or create one); the ID is the 15 to 16 digit number shown at the top of the page.
- Enter an Access Token. In Events Manager open your Pixel’s Settings tab, scroll to the Conversions API section, click Generate access token and copy it. The token is masked after you save.
- Optionally enter a Test Event Code while testing (see the next section).
- Leave Inject browser pixel on unless another plugin already loads the Pixel.
- Click Save changes.
The card lists the events it sends and links to Facebook’s official Conversions API guide. The other settings on the screen are described in Revenue First Analytics Settings Explained.
Verify events with the test event code
- In Events Manager, open your Pixel and switch to the Test Events tab. Facebook shows a code such as
TEST12345. - Paste it into Test Event Code (optional) in the plugin and save.
- In a browser where marketing consent has been given (or in Full tracking), view a product, add it to the cart, open the checkout and place a test order. Make sure you are not logged in as an administrator if Exclude admin users is on, or those events will be skipped.
- Watch the Test Events tab: server events arrive with the Conversions API label, PageView from the browser pixel.
- Clear the Test Event Code and save again, otherwise live events keep landing in the test view instead of your real data.
What to put in your privacy policy
When this integration is on, Meta is a third party that receives personal data: hashed contact details plus the IP address and User-Agent. The suggested policy text the plugin adds to WordPress’s Policy Guide includes a sentence for this: if the visitor accepts marketing cookies and you have enabled it, purchase and cart events are sent to Meta (Facebook) through the Conversions API, with email, phone and address hashed. Add Meta’s privacy policy link and keep the marketing category in your banner separate from statistics. The full list of what is stored and shared is in Cookies, Data Stored and Data Retention.
If you use Google Tag Manager or GA4 instead of, or next to, Meta, the same cart and purchase events are also available on window.dataLayer; see Google Tag Manager and dataLayer Events for WooCommerce.