First-party attribution for WooCommerce
WooCommerce runs on your own server, on your own domain, in PHP you control. That is the best possible starting position for first-party attribution — and almost nobody uses it, because the ecosystem defaults to JavaScript tags.
Durable id (server-set) + client events (behaviour) + server events (truth) + dedup key
Snippet in the theme header + a `woocommerce_payment_complete` hook for the server-side confirmation. The one decision that matters on WooCommerce: who writes the visitor id. Written by JavaScript it lives 7 days in Safari; written by a server it lasts as long as you set it.
Hook into `wp_head` for the snippet and set the first-party cookie from `init` so it goes out on the HTTP response, not from JavaScript.
What WooCommerce gives you for free
Every stack has a natural advantage for first-party measurement. Use it before reaching for a tag manager.
Everything is same-origin — no cross-domain checkout
You can set the visitor cookie from PHP, which escapes ITP's 7-day cap entirely
Order hooks give you an authoritative server-side purchase event
What breaks on WooCommerce
The failure modes specific to this stack — the ones a generic install guide will not warn you about.
Page caching breaks server-set cookies
Full-page cache plugins serve a cached response, so your `Set-Cookie` never reaches the visitor.
Fix Exclude the cookie-setting from cache, or set the id from a tiny uncached endpoint.
Plugin conflicts on the same hook
Multiple analytics plugins listening on `woocommerce_payment_complete` can fire duplicate purchase events.
Fix De-duplicate on the order id; a shared key makes double-firing harmless.
Guest checkout loses the email link
Without an account, the email exists only on the order.
Fix Send the order email with the purchase event so the person record is complete.
Frequently asked questions
How do I set a durable visitor cookie in WordPress?
From PHP, on the `init` hook, with `setcookie()` — HttpOnly, SameSite=Lax, first-party. Because your server writes it, Safari's 7-day cap on JavaScript cookies does not apply.
Which WooCommerce hook should fire the purchase event?
`woocommerce_payment_complete` — it fires when the payment is confirmed, not when the order is created, so you do not credit abandoned or failed orders.
Does caching break this?
It can. A full-page cache will serve a response whose Set-Cookie header was generated for someone else, or strip it entirely. Exclude the id-setting path from cache.
Do I still need the JavaScript snippet?
Yes, for behaviour — pageviews, clicks, form submits. The server side confirms the money; the client side explains the path.
Related guides
See the receipt for every conversion.
Flowsk Signals stitches the anonymous click to the email to the purchase — first-party, server-side, de-duplicated on a key you choose. One snippet, $29/mo, and a journey you can inspect event by event.
More free tools
Same deal — instant, no signup.