CAPI Suite: Meta, Pinterest, TikTok, GTM

Description

Stop paying $30–150/month for a GTM Server Container. Send Conversions API events to Meta, Pinterest, and TikTok directly from your WordPress server. Free, no premium tier, no SaaS subscription.

Three platforms in one plugin. Most competitors handle Meta only, or sell Pinterest and TikTok as separate add-ons. This one ships Meta + Pinterest + TikTok server-side dispatch + a clean GTM dataLayer in a single install. The same event_id flows everywhere, so each platform deduplicates browser + server events instead of double-counting.

Real customers aren’t filtered as bots. Behavioral bot detection + ~9,500-CIDR datacenter IP filter (daily auto-refresh) keeps Lighthouse audits, scrapers, and ad-fraud bots out of your Events Manager — without blocking VPN shoppers, Apple iCloud Private Relay users, logged-in customers, or paid-ad clickers. Purchase events are never blocked. Pre-Purchase events that do get filtered are replayed on eventual purchase, preserving the full funnel.

What it does

• Meta + Pinterest + TikTok CAPI — 14 event types, classic + block checkout, HPOS compatible. Per-platform retry: only the failing side is retried.
• GTM dataLayer — Standards-compliant pushes for GA4, Meta Pixel, Pinterest Tag, TikTok Pixel.
• Datacenter IP filter + Blocked Traffic tab — Paginated audit log (IP masked to /24), per-provider breakdown, one-click «Block this CIDR» on Event Log rows.
• CCPA / Limited Data Use — Honors CMP opt-out signals; tags Meta + TikTok payloads with LDU. Optional GDPR strict mode strips PII when consent is denied.
• Cache-safe — Works with LiteSpeed, WP Rocket, Varnish, Cloudflare full-page cache. Click IDs captured client-side into 1st-party cookies; landing pages stay fully cacheable.
• Debug log + Dashboard widget — Per-event delivery status, date/type filters, retention 1–90 days.

This plugin is free. Not «free with limits» — just free. Every feature works, no pro version behind a paywall.

If it helps your store, please leave a review — it genuinely helps other merchants find this plugin.

External Services

This plugin connects your website to external services to send event data.

• Service Used: Meta Conversion API (graph.facebook.com)
  • Purpose: To send user interaction and e-commerce event data from your server to Meta’s servers for ad performance measurement, optimization, and audience building.
  • Data Sent: Event details (product ID, price) and user parameters (IP address, user agent, hashed email/name/phone, Facebook cookies) are sent when a user performs a key action.
• Service Used: TikTok Events API (business-api.tiktok.com)
  • Purpose: Same as Meta CAPI, providing server-side conversion tracking for TikTok Ads optimization and attribution.
  • Data Sent: Event details (product ID, price, currency) and user parameters (IP address, user agent, hashed email/phone/external_id, ttp / ttclid cookies) are sent upon user action. Optional under the merchant’s TikTok credentials — the plugin only sends to TikTok if the credentials are configured.
• Service Used: Pinterest Conversions API (api.pinterest.com)
  • Purpose: Same as the Meta CAPI, providing reliable tracking for ad performance and audience building on Pinterest.
  • Data Sent: Event details and hashed user parameters are sent upon user action.
• Service Used: Google Tag Manager (googletagmanager.com)
  • Purpose: To load a JavaScript container from Google’s servers that allows you to manage and deploy marketing and analytics tags.
  • Data Sent: The plugin provides your GTM Container ID to Google to fetch the correct script. GTM itself may collect data based on how you configure your tags.
• Service Used: Cloud-provider IP range list — raw.githubusercontent.com/rezmoss/cloud-provider-ip-addresses
  • Purpose: Used by the optional Datacenter IP filter to keep the bot blocklist current. Daily background fetch downloads CIDR ranges for AWS, Google Cloud, Azure, Cloudflare, DigitalOcean, Linode, Vultr, Oracle Cloud, and Fastly so events from those ranges can be filtered out before reaching Meta / Pinterest / TikTok.
  • Data Sent: None. The plugin only downloads public IP-range manifests; no visitor data is sent to GitHub.
  • License: Source repository is CC0-licensed.
• Service Used: Apple iCloud Private Relay egress IP list — same raw.githubusercontent.com/rezmoss/cloud-provider-ip-addresses source (folder apple_private_relay/)
  • Purpose: Used by the optional Datacenter IP filter to whitelist real Apple visitors who exit through Apple’s relay infrastructure. Daily background fetch downloads the merged CIDR list so iOS Safari users on Private Relay aren’t mistaken for datacenter bots.
  • Data Sent: None. The plugin only downloads the public manifest; no visitor data is sent.

Shared hosting note. Some restrictive shared hosts block outbound HTTPS by default. If event delivery silently fails after install, ask your host to whitelist the following domains for outgoing connections: graph.facebook.com, business-api.tiktok.com, api.pinterest.com, and raw.githubusercontent.com (only needed if you keep «Auto-fetched» enabled on the Blocked Traffic tab — covers both the datacenter blocklist and the Apple Private Relay whitelist).

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, GA4 and Meta browser tags will not fire when a visitor refuses or has not yet acted on the cookie banner. The GTM tags wait for a gtag('consent', 'update', ...) signal that grants the relevant categories. Without Google Consent Mode v2 wired up, this typically costs a store 20–50% of its measured event volume in GA4 and Meta Events Manager. The data does not become «untrackable» — Google models it back, but only if you tell GTM that consent management is in play.

How Consent Mode v2 actually recovers the lost data

When a visitor denies consent, GA4 and Google Ads tags do not stop firing — they switch to cookieless pings: small anonymous beacons that carry no client identifier (no _ga, no _fbp, no IP retention) but include enough conversion context (event name, value, currency, timestamp) for Google’s machine learning to perform conversion modeling. Modeled conversions appear in your standard reports, mixed with directly-observed ones, with a «modeled» footnote. Google publicly reports that Consent Mode users recover, on average, 20–50% of the conversions they would otherwise have lost to consent denial. The Meta Pixel GTM template reads the same ad_storage / ad_user_data / ad_personalization signals that Consent Mode v2 sets — so a single CMP integration repairs both GA4 and Meta attribution at once. Server-side CAPI continues to operate independently.

This plugin’s job is to push events to the dataLayer regardless of consent state. The CMP’s job is to tell GTM which categories the visitor allowed. GTM does the actual gating and signals back to the vendors.

Step 1: Enable Consent Mode v2 in your CMP

Most popular CMP plugins have native Consent Mode v2 support. Find the toggle in your CMP plugin’s settings:

• Cookiebot — Settings → «Enable Google Consent Mode» (v2 is default in current versions)
• CookieYes — Site Settings → «Google Consent Mode» → enable
• Complianz — Integrations → Google Consent Mode → enable
• Iubenda — Cookie Solution → Advanced settings → «Enable Consent Mode» → «v2 (advanced)»
• Termly — Settings → Google Consent Mode → enable
• OneTrust — Geolocation Rules → Consent Mode → enable + map categories

Once enabled, your CMP will automatically call gtag('consent', 'default', {...denied}) before GTM loads, then gtag('consent', 'update', {...granted}) after the visitor accepts.

Step 2: (Optional) Enable the Consent Defaults tag in GTM

If you imported the GTM container template, it includes a paused Custom HTML tag named «Consent Defaults (Pre-CMP) — Disabled, see readme». Enable this tag only if your CMP does not call gtag('consent', 'default', ...) on its own (rare with modern CMPs):

1. In GTM, open the tag.
2. Click the pause icon to enable it.
3. Change its trigger from CE - PageView Meta to the built-in «Consent Initialization – All Pages» trigger (visible in the trigger picker dropdown — guarantees this fires before any other tag).
4. Submit and publish.

The tag sets all four consent types (ad_storage, ad_user_data, ad_personalization, analytics_storage) to denied with a 500 ms wait_for_update window. Your CMP’s gtag('consent', 'update', ...) call then grants the categories the visitor approved.

Step 3: Verify it is working

• GTM Preview Mode — Open a page with the GTM Preview, click on Consent Initialization (top of timeline). Confirm default consent values appear for all four categories. After accepting in your CMP, click Consent events lower in the timeline; you should see update calls flipping the relevant categories to granted.
• Browser DevTools — Network tab, filter for g/collect (GA4) or tr (Meta Pixel). Each request should include a gcs= query parameter. gcs=G100 means denied, G111 means granted, G101 means analytics-only. If you see gcs= you have Consent Mode active. If you do not, the CMP wiring is incomplete.
• Tag Assistant (tagassistant.google.com) — Connect to your site, fire any event, click on it, scroll to the «Consent» panel. Should show the current state and any updates within the session.

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

Consent Mode v2 controls the browser tags. The plugin’s server-side CAPI calls do not see gtag('consent', ...) signals — they fire from PHP, hash the visitor’s email/phone/address, and POST directly to graph.facebook.com. By default this happens regardless of cookie-banner choice, which is fine for non-EU stores but a GDPR concern for European traffic.

The Privacy & Consent (Server-side) section in the plugin settings adds a «Strict server-side consent mode» checkbox (default OFF). When enabled, the plugin reads your CMP’s cookie before queuing each event:

• Cookiebot — CookieConsent cookie, looks for marketing:true|false
• CookieYes — cookieyes-consent cookie, looks for advertisement:yes|no
• Complianz — cmplz_marketing cookie, value allow / deny
• Other CMPs — supply state via the mcapi_marketing_consent_granted filter (return true / false / null)

If marketing consent is explicitly denied, identifying PII fields (em, ph, fn, ln, ct, st, zp, country, external_id, fbp, fbc, Pinterest click ID) are stripped from the CAPI payload. The event still ships — IP, user-agent, event_id, value, currency, content_ids, contents are retained — so Meta still receives a deduplicated server signal it can fold into conversion modeling, but the data is no longer personally identifying. If the cookie state is unknown (no recognized CMP) or consent is granted, behavior is unchanged.

How this complements Consent Mode v2. When a visitor denies marketing consent, your browser-side GA4 / Meta Pixel switches to cookieless pings — small anonymous beacons that Google’s ML uses to model the conversions you would have measured. That recovers some of the data, but it’s modeled, not observed. With Strict server-side consent mode enabled, your server-side CAPI continues to fire alongside the cookieless ping — it ships the same event_id the browser ping carries, with value / currency / contents filled in from the order, just without the PII. Meta deduplicates the two events by event_id and now has a full server-side observed signal feeding the same conversion record the cookieless ping created. That is a cleaner input than what either browser-only or naïve «send everything» CAPI provides — and it is GDPR-defensible because no identifying user data is transmitted without consent.

The toggle is OFF by default so existing setups don’t see a sudden drop in CAPI matching once they update; turn it on after you’ve configured Consent Mode v2 in your CMP.

CMP Auto-Blocking and the Plugin’s Inline Scripts

Some CMPs (especially CookieYes and Cookiebot when «auto-blocking» is enabled) scan every <script> tag on page load and convert any tag they suspect of tracking into type="text/plain" until consent is granted. The plugin’s inline scripts (mcapi-pageview-init, mcapi-viewcontent-events, mcapi-viewcategory-events, mcapi-inline-bootstrap) only POST first-party events to your own /wp-json/mcapi/v1/event endpoint — they do not directly track the visitor — but a generic auto-blocker cannot tell the difference. If they get blocked, no events reach the queue, and the plugin’s Event Log stays empty.

To prevent this, every plugin-rendered inline script carries CMP exemption attributes:

• data-cookieconsent="ignore" — Cookiebot’s documented opt-out
• data-cookieyes="cookieyes-necessary" — categorizes the script as essential for CookieYes
• data-cmplz-no-cookielaw="1" — excludes from Complianz auto-blocking

These attributes are added automatically. If you use a CMP not listed above (OneTrust, Quantcast Choice, in-house CMPs), you can append more attributes via the mcapi_inline_script_attrs filter:

add_filter( 'mcapi_inline_script_attrs', function( $attrs ) { return $attrs . ' data-your-cmp="ignore"'; } );

WooCommerce Subscriptions Integration

If your store sells subscriptions via WooCommerce Subscriptions, by default Meta CAPI receives a fresh Purchase event every time a subscription auto-renews. Meta then attributes the renewal revenue to the original ad campaign that brought the customer in, so your reported ROAS keeps climbing month after month from the same conversion. Most subscription advertisers want to keep their Purchase metric clean of recurring-revenue contamination so optimization signals stay honest.

The plugin auto-detects WooCommerce Subscriptions and adds a «WooCommerce Subscriptions Integration» section to the settings page with two controls:

Subscription Renewal Behavior (radio):

• Default — send renewals as regular Purchase events. No change in behavior; existing setups keep working.
• Skip — do not send renewals to Meta CAPI at all. Cleanest path for ROAS hygiene; you lose the LTV signal Meta could derive from renewals (most stores using value-based bidding don’t rely on this anyway).
• Tag — still send a Purchase, but include custom_data.customer_status = "subscription_renewal" so you can filter renewals out in Events Manager / Custom Audiences / Custom Conversions.
• Subscribe / SubscriptionRenewal events — send Meta’s standard Subscribe event for new sign-ups and a SubscriptionRenewal custom event for recurring orders. Renewals do not pollute the Purchase metric; advertisers who use Meta’s LTV-bidding can opt into both events.

Tag every Purchase with customer_status (checkbox):

When enabled, every Purchase event (subscription or not) carries a custom_data.customer_status field with value new_customer, returning_customer, or subscription_renewal. Meta’s Advantage+ Shopping Campaigns can use this signal to bid differently for new-customer acquisition vs. retention. The classification uses the customer’s prior completed-or-processing order count; for guest checkouts it falls back to billing email lookup so a returning shopper without an account is still recognized.