Pinterest Server-Side Tracking (the Conversions API), Explained Simply

If you’ve installed the Pinterest tag correctly, verified it fires, and your reported conversions still look lower than what you know actually happened — you’re not going mad, and the tag isn’t broken. You’ve hit the structural ceiling of browser-based tracking, and server-side tracking is the answer to it.

This topic gets explained badly, usually in language that assumes you already know what an API is. So let’s do it properly, in plain English, including the honest answer to whether you actually need it.

Why browser tracking loses data

The ordinary Pinterest tag runs in your visitor’s browser. When someone buys something, code on your page sends a message to Pinterest from that person’s device. Simple, and it works — right up until something stops the message leaving.

Plenty of things do. Ad blockers block it outright, and a meaningful share of people run one. Browser privacy features restrict or shorten the storage these systems depend on. Some people decline tracking when asked. Add it up and a real portion of your genuine conversions never gets reported — silently, with no error anywhere, so your results simply look worse than they are.

The insidious part is that this doesn’t look like a data problem. It looks like your Pinterest campaigns underperforming, and people respond by changing perfectly good pins or cutting spend on something that was actually working.

What server-side tracking changes

Instead of asking the visitor’s browser to tell Pinterest what happened, your *server* tells Pinterest directly. The order is confirmed on your system, your system sends the message, and the visitor’s browser — with all its blockers and restrictions — is never involved.

That message travels server to server, which is why it can’t be blocked by anything running on the visitor’s device. It’s the same information, taking a different and much more reliable road.

The deduplication problem

Here’s the trap, and it’s worth understanding before you start rather than after. If you run the browser tag *and* server-side tracking, both will report the same purchase. Unless you tell Pinterest they’re the same event, it counts two — and your conversion numbers roughly double overnight in a way that looks fantastic and is entirely fictional.

The fix is an event id: a unique identifier attached to both messages for the same action. Pinterest sees the same id twice, understands it’s one event reported by two routes, and counts it once. This is not optional, and it’s the single most common way a server-side setup goes wrong.

If your numbers jump dramatically the week you switch this on, assume deduplication is broken before you assume you’ve had a great week. That instinct will serve you well across all of analytics, honestly.

Match quality, and hashing

A server-side event has to be matched to a person Pinterest recognises, otherwise it can’t attribute the conversion to a pin. That matching relies on identifiers you send along with the event.

Email is the strongest signal, with phone number and click identifiers close behind. Weak signals like IP address alone won’t match reliably, so an event carrying only those may be technically delivered and practically useless.

Critically: these identifiers must be hashed before they leave your server — converted into an irreversible string rather than sent as plain text. Pinterest matches on the hash, so you never transmit a readable email address. Any implementation guide telling you to send raw personal data is one to walk away from, and normalising the value consistently before hashing matters too, since an inconsistently formatted input produces a hash that matches nothing at all.

Do you actually need this?

Honest answer: many people don’t, and it’s worth saying so.

If you’re a blogger sending traffic to articles and measuring success in visits and email signups, the browser tag is almost certainly enough. The added accuracy doesn’t change any decision you’re making, and the setup cost is real — this is developer work, or at minimum a platform integration you’ll need to configure and test properly.

It becomes worth it when money is attached to the measurement. If you’re running paid Pinterest ads and deciding budgets from reported conversions, under-reporting directly causes you to switch off campaigns that are profitable. If you’re a shop where a few percentage points of attributed revenue is a meaningful number, the same applies. At that point the accuracy pays for the setup quickly.

A reasonable middle path: get the browser tag right first, run it for a couple of months, and see whether the numbers it produces are good enough to make decisions with. If they are, stop there. If you’re constantly suspicious they’re too low, that suspicion is your signal to invest.

You may not have to build it

Before anyone books developer time: check whether your platform already offers this as an integration. Several of the larger ecommerce platforms and tag-management tools have a built-in Pinterest connection that handles the server-side sending, the event ids and the hashing for you, and it’s usually a matter of connecting an account and choosing which events to send.

That route is dramatically cheaper and far less error-prone than a custom build, because the fiddly parts — the ones this post spends most of its words warning you about — are already solved and tested. Only write it yourself if your setup is genuinely unusual or no integration exists for your stack. There’s platform-specific context in Pinterest for Shopify and for WooCommerce.

How to roll it out without breaking anything

1. Keep the browser tag running — server-side supplements it, it does not replace it.
2. Implement one event first, usually the purchase or signup, not all of them.
3. Attach a shared event id to both the browser and server versions from day one.
4. Hash every identifier before sending, and normalise the format consistently.
5. Compare a week of reported conversions against your own records before trusting anything.
6. Only then extend to the remaining events.

And keep an independent record throughout, because the whole reason this problem exists is that platform-reported numbers are hard to audit from the outside. Your own analytics and properly tagged links give you a second opinion, which is what turns a disagreement between systems into something you can reason about rather than something you have to take on faith. There’s more on that in tracking Pinterest traffic in Google Analytics.

Better measurement only pays off if you act on it, mind. Knowing precisely which pins and keywords produce revenue is the point of all this plumbing — and seeing which topics are worth pursuing in the first place is where PinPinterest comes in.

Next: get the browser tag right first, make sure your site is claimed, and see where this sits in the stack.