3 posts tagged with "server-side tracking"

Starting with Pixel Manager version 1.62.0, server-side purchase events (server-to-server / Conversions API) respect the consent choice your visitors make in the browser. If a visitor declines consent, the purchase event is no longer sent to the ad and analytics platforms through the server.

This is a behavior change for stores that use explicit consent management, and we want you to understand exactly what changes, why we made this decision, and what to do if your situation requires the previous behavior.

Tracking subscriptions is harder than tracking one-off purchases, and not because of the code. It is hard because the ad platforms themselves disagree about what a subscription even is. Meta has a full lifecycle event model. Google Ads has nothing. GA4 sits somewhere in the middle. A real WooCommerce store that runs subscriptions needs an implementation that respects what each platform actually accepts, and reports value in a way that reflects the customer lifetime value (CLV), not just the first month's charge.

This post explains exactly how the Pixel Manager for WooCommerce handles WooCommerce Subscriptions, what fires where, and which knobs you can turn.

On the surface, every WooCommerce plugin that talks about the Conversions API does the same thing: take an order, hash an email, POST a payload to an ad platform. In practice, the gap between "POSTs a payload" and "actually delivers reliable, deduplicated, attributable conversions across every payment gateway and edge case a real store throws at it" is enormous. This post is about that gap.