CAPI Suite: Meta Pixel, Pinterest & TikTok for WooCommerce

Quick start (3 steps)

1. 01Install and activate the plugin. WooCommerce must already be active.
2. 02Open CAPI Suite → Main Settings and paste your Meta Pixel ID + Access Token . Add TikTok and/or Pinterest credentials if you use them. Empty fields for platforms you don’t use are fine.
3. 03(If you use GTM) Download the bundled gtm-template.json from the GTM Container ID box, import it into your GTM container in Merge mode, set the pixel-code constants to your real IDs, and publish.

Server-side events start flowing on the next page view. Send a test from Event Management → Test Modes to verify credentials before going live.

Recommended GTM dedup configuration

To prevent duplicate browser+server events:

1. 04In Meta Events Manager → your Pixel → Settings → Event Setup , turn off “Track Events Automatically Without Code”. This plugin handles all event sending.
2. 05In your GTM container, pause or delete any auto-created tags starting with FB_ .

The bundled GTM template ships GA4 + Meta tags pre-wired to the GA4 ecommerce dataLayer, plus TikTok tags that read from a CONST - TikTok Pixel Code variable and Pinterest tags that read from CONST - Pinterest Tag ID .

The Pinterest tags are new, and one of them ships paused. Earlier releases said Pinterest tags had to be built by hand because the Community Template could fail to import inside a container export. That is no longer true — it was re-tested against a real container, both as a Merge into an existing workspace and as a fresh import, and the Pinterest template and all eight tags came through intact — so they are bundled now. Seven of them are on by default: PageVisit, ViewContent, ViewCategory, AddToCart, InitiateCheckout, AddPaymentInfo and Search. Three of those (ViewContent, InitiateCheckout, AddPaymentInfo) are events the Conversions API has no name for at all, so the browser tag is the only way Pinterest ever hears about them.

Pinterest - Checkout is paused on purpose, and only you can finish the check. Pinterest matches a tag event to a Conversions API event on event_id , and the tag passes it — but that pairing has not been confirmed on a live Pinterest account, and this plugin’s author has no Pinterest ad account to confirm it on. Left paused, your Pinterest sales keep being reported from the server only, exactly as they are today, and cannot be counted twice. To finish the check: set CONST - Pinterest Tag ID , enable the tag, publish, make one real sale, and open Pinterest Events Manager. One checkout event means the pairing works and you can leave it on. Two means it does not — pause it again. One more thing if you report subscriptions separately: Pinterest’s tag takes a fixed event name, so that tag sends checkout for a renewal too, while the server side deliberately reports renewals as custom .

If you cannot import the JSON template (locked container, workspace permissions) or want to set up GTM manually, the full step-by-step walkthrough ships with the plugin at wp-content/plugins/easy-meta-capi/docs/GTM-MANUAL-SETUP.txt .

Verify

Open CAPI Suite → Event Log after browsing your store. Successful dispatches show as “Success (Meta)” / “Success (TikTok)” / “Success (Pinterest)”. The Dashboard widget shows queue health at a glance.

If the log stays empty, a JS optimizer is probably deferring the plugin’s inline scripts — see the cache-plugin FAQ. Detailed GTM setup, Google Ads Enhanced Conversions, and other platform tags live in docs/GTM-MANUAL-SETUP.txt . Consent Mode v2, Strict server-side consent, CMP auto-block, and WC Subscriptions are documented under Advanced Configuration below.

Advanced Configuration

Setup details for Consent Mode v2, the strict server-side consent mode (GDPR PII gating), CMP auto-block compatibility, and the WooCommerce Subscriptions integration. None of these are required for a basic CAPI setup — turn them on as your store needs them.

Consent Mode v2 Setup (GDPR / EU Compliance)

If you serve EU visitors, Google’s browser tags stop writing cookies when consent is denied — typically losing 20–50% of measured event volume . Google Consent Mode v2 recovers part of it: when consent is denied, those tags switch to cookieless pings (anonymous beacons carrying event name, value, currency and timestamp but no client identifier), and Google models the conversions from them and shows them mixed with observed ones in your reports.

How to enable. Popular CMP plugins (Cookiebot, CookieYes, Complianz, Iubenda, Termly, OneTrust) all have a native Consent Mode v2 toggle in their settings — find and enable it. The CMP then calls gtag('consent', 'default', {denied}) before GTM loads and gtag('consent', 'update', {granted}) after the visitor accepts.

If you use a consent banner, import the container again. The container shipping with this release stops the Meta, TikTok and Pinterest tags from firing for visitors who declined: all 23 of them now wait for ad_storage and ad_user_data before they run. Download it again and import it as described above, choosing Merge and then Overwrite conflicting tags, triggers, and variables — overwrite is what replaces the tags you already have. Tags you built yourself, under names the template does not use, are left alone.

The same import returns the template’s ID constants ( CONST - Meta Pixel ID , CONST - GA4 Measurement ID , CONST - TikTok Pixel Code , CONST - Pinterest Tag ID , CONST - Google Ads Conversion ID , CONST - Google Ads Purchase Label ) to their placeholder text, so enter your own values again before you publish. CONST - Google Ads Conversion ID now takes the number on its own — 1234567890 , not AW-1234567890 — because the Google Tag in the template adds the AW- prefix itself.

The bundled GTM template includes a paused “Consent Defaults (Pre-CMP)” tag. Enable it only if your CMP doesn’t set gtag('consent', 'default', ...) on its own (rare with modern CMPs).

Strict server-side consent mode (PII gating for CAPI)

Consent Mode v2 only controls browser tags. Server-side CAPI fires from PHP, never sees gtag('consent', ...) signals — so it transmits hashed PII regardless of cookie-banner choice. Fine outside the EU; a GDPR concern inside it.

The Privacy & Consent (Server-side) section has a Strict server-side consent toggle (default OFF). When enabled and the visitor has denied marketing consent in your CMP, identifying PII ( em , ph , fn , ln , address, fbp , fbc …) is stripped from the CAPI payload. The event still ships with event_id , value , currency , contents — Cookiebot, CookieYes, and Complianz cookies are read automatically; other CMPs supply state via the mcapi_marketing_consent_granted filter.

Whose answer is used. A Purchase usually fires later than the checkout it belongs to — when the order reaches a paid status, which for a redirect gateway can be hours or days, in a cron tick or a gateway webhook where the shopper’s browser is nowhere in sight. The shopper’s consent answer is therefore recorded onto the order at checkout (both the classic and the block checkout) and read back from there at send time. That is what makes the toggle honour the customer’s own choice rather than whoever’s browser happened to trigger the send — a shop manager working in wp-admin, for instance, whose own banner choice used to decide it. An order placed before this version, or created without a checkout, has no recorded answer and is treated as “no signal”, the same as a visitor with no CMP cookie; a renewal inherits the answer given at the original purchase.

Why this matters alongside Consent Mode v2. Denied-consent browser pixels switch to cookieless pings — modeled, not observed. With Strict server-side consent ON, your server-side CAPI ships alongside that ping carrying the same event_id . Meta dedupes by event_id and now has an observed server signal feeding the same conversion record the cookieless ping created — cleaner Event Match Quality than browser-only or naïve “send everything” CAPI, and GDPR-defensible because no identifying data leaves your server.

Default OFF preserves match quality for existing non-EU setups. Recommended ON once Consent Mode v2 is configured in your CMP.

CMP Auto-Blocking and the Plugin’s Inline Scripts

CMPs with “auto-blocking” (Cookiebot, CookieYes, others) scan every <script> tag on load and convert anything they suspect of tracking to type="text/plain" until consent. The plugin’s inline scripts only POST first-party events to your own REST endpoint — but a generic auto-blocker can’t tell. To avoid a silent break, every plugin-rendered inline script ships with opt-out attributes for Cookiebot ( data-cookieconsent="ignore" ), CookieYes ( data-cookieyes="cookieyes-necessary" ), and Complianz ( data-cmplz-no-cookielaw="1" ). For other CMPs (OneTrust, Quantcast, in-house), append your own attribute via the mcapi_inline_script_attrs filter.

WooCommerce Subscriptions Integration

By default, every WooCommerce Subscriptions auto-renewal sends a fresh Purchase to Meta CAPI — credited to the original acquisition ad. Reported ROAS keeps climbing month after month from the same conversion, polluting optimization signals.

The plugin auto-detects WooCommerce Subscriptions and exposes:

Subscription Renewal Behavior (radio):

1. 06Default — renewals send as regular Purchase . Existing setups unchanged.
2. 07Skip — renewals not sent. Cleanest ROAS hygiene; you forfeit Meta’s LTV signal from renewals.
3. 08Subscribe / SubscriptionRenewal events — Meta’s standard Subscribe for sign-ups + a SubscriptionRenewal custom event for renewals. Purchase stays clean, advertisers using LTV-bidding can opt into both.

As of 3.11.0 there is no separate “Tag” mode: it was byte-identical to Default with the customer-status checkbox below also ticked, so it was retired in favor of that existing combination. A store already saved on Tag keeps behaving exactly as before — it’s migrated automatically on upgrade.

Tell Meta whether each buyer is new or returning (checkbox, works on any WooCommerce store — not only subscription sellers): adds custom_data.customer_status ( new_customer / re