Postback (server-side) vs Pixel (browser-side). Use both for best attribution with deduplication. Postback critical for iOS / affiliate funnels.

Postback vs pixel — which to use

Both are conversion tracking mechanisms with different trade-offs. Pixel = browser-side JavaScript snippet. Postback = server-to-server HTTP call. For most setups: use both with deduplication. For specific scenarios, one is mandatory and the other inappropriate.

Who is this for

Mediabuyers choosing between (or combining) tracking methods, especially anyone who lost attribution after iOS 14.5 (browser pixel less reliable) or runs affiliate funnels (browser pixel often unavailable).

At a glance

Use cases per method

Use browser pixel when

• Direct e-commerce on your own site: customer browses your store, you control the funnel end-to-end
• Lead-gen forms on your site: form submission happens on your domain
• Awareness / engagement signals: page views, time on site, scroll depth (these don't need server-side)
• Initial setup: pixel is fastest to deploy (Meta Pixel, Google Tag = 5-10 min)
• Augmenting CAPI/postback: pixel for browser-side, CAPI/postback for server-side, dedup'd via event_id

Use postback (S2S) when

• Affiliate funnels: conversion happens on the offer site you don't control; can't install pixel there
• App installs: tracker logs install via MMP (AppsFlyer, Adjust, etc.); ad platforms need server-side signal
• Off-site conversion events: CRM updates, ticket purchases on third-party platforms
• iOS-heavy audience: ATT opt-outs invalidate browser pixel; postback unaffected
• Privacy-conscious users: ad blockers don't affect server-to-server
• Server-side data you already have: your backend logs conversions; just fire to Wevion

Use BOTH (recommended for high-value conversions)

For purchases or other high-value conversions:

• Install pixel for fast/easy initial signal
• Add CAPI (meta-105) or postback (com-110) for resilience
• Match via event_id for deduplication
• Wevion handles both surfaces; ad platforms count as 1 conversion via dedup

This is industry-standard since iOS 14.5 (2021).

Decision tree

Is conversion on YOUR site?├─ YES → install pixel + CAPI (for Meta) or postback (for tracker-driven setups)│       Both fire, both attribute, dedup via event_id│└─ NO → must use postback (or equivalent server-side)    Pixel cannot fire on a domain you don't control

What you lose without each

Lose pixel: you lose

• Easy initial attribution signal
• Browser-side enrichment (user-agent, referrer, page details for context)
• Automatic event triggering (no integration needed)

Lose postback: you lose

• Server-side resilience (iOS, ad blockers)
• Off-site conversions
• Tracker-driven funnels
• Late-binding conversions (e.g. refunds processed days later via tracker)

Real-world examples

Example A: D2C e-commerce on Shopify

• Setup: Meta Pixel (browser) + Meta CAPI (server via Wevion using Shopify orders) + Wevion's postback NOT needed
• Why: Shopify handles server-side via Wevion's CAPI integration (meta-105)
• Result: > 95% attribution accuracy across iOS + Android + desktop

Example B: Affiliate lead-gen via Keitaro

• Setup: Keitaro tracker → Postback to Wevion's Meta postback store
• No browser pixel: offer site is partner-owned, can't install
• Why: postback is the only way to capture the conversion server-side; pixel is not possible
• Result: server-side conversion captured in Wevion reporting, no iOS/ATT impact (Wevion stores it; it is not re-sent to ad platforms)

Example C: Multi-platform e-commerce with mixed funnels

• Setup: pixel + CAPI on direct funnel; postback for tracker-driven affiliate channel
• Why: different funnels, different mechanisms
• Result: unified attribution across all funnels in Wevion analytics

What you'll see when both are firing

In Wevion /pixels:

• Pixel events with counts (browser side)

In Wevion's stored postback conversions (GET /api/v1/postback/conversions):

• Postback conversions with counts (server side), deduped internally on (sheet_id, transaction_id)

In Ads Manager:

• The conversion source is switchable between the browser/pixel source and the postback source

In Meta Ads Manager → Events Manager → diagnostics:

• For pixel + Meta CAPI (via meta-105), events labeled "Browser + Server" (deduplicated via event_id). Note: Wevion's postback store is separate and is not what feeds these CAPI diagnostics.

Common questions

• "Will I be double-counted if I run pixel + Meta CAPI?": no, IF you use event_id matching between the browser pixel and the CAPI send (see meta-105). Wevion's Meta postback store is a separate reporting source, not a CAPI send.
• "Which is more accurate?": postback wins on iOS / ad-blocker / privacy contexts for capturing off-site conversions. Pixel wins on browser context enrichment. Combined = best coverage.
• "Can I just use postback and skip the pixel?": yes for tracker-driven funnels where you only need the conversion recorded in Wevion reporting.
• "How is a duplicate postback handled?": Wevion dedups on (sheet_id, transaction_id); pass a stable transaction_id from your tracker.

FAQ

Should I use postback or pixel in Wevion?

It depends on where the conversion happens. A browser pixel is easiest to deploy and best for direct e-commerce and lead-gen forms on your own site, while postback (S2S) is essential for affiliate funnels, app installs, and iOS-heavy or ad-blocker audiences where the conversion happens off-site. In Wevion, the browser/pixel source and the postback source are switchable in Ads Manager reporting; for browser+server dedup on Meta, pair the pixel with Meta CAPI (meta-105).

Will running both pixel and postback double-count conversions?

They are separate reporting sources, not summed. Wevion's postback is a Meta-only conversion store (deduped internally on (sheet_id, transaction_id)), while the pixel is the browser source; in Ads Manager you switch which source you view. For browser+server dedup within Meta itself, use the pixel + Meta CAPI with matching event_id — that is what produces the "Browser + Server" labeling in Meta Events Manager diagnostics.

When must I use postback instead of a pixel in Wevion?

Use postback whenever the conversion happens off a site you control. Affiliate funnels convert on a partner-owned offer site where you cannot install a pixel, app installs are logged server-side by an MMP, and off-site events like CRM updates never touch your domain. In these cases a browser pixel cannot fire, so postback (S2S) is the only option.

Which tracking method is more accurate in Wevion?

It depends on context. Postback wins on iOS, ad-blocker, and privacy-heavy audiences because it is unaffected by ATT opt-outs or blockers. Browser pixel wins on context enrichment like user-agent, referrer, and page details. Combining both, deduplicated via event_id, gives the best overall attribution and is the industry standard since iOS 14.5.

Do I need event_id if I only use one tracking method?

Not for deduplication, since there is only one source to reconcile. However, Wevion still recommends passing event_id because it helps with debugging. If you later add a second surface, matching event_ids let pixel and postback dedup automatically. Most trackers can pass a conversion ID as the event_id in the postback URL builder.

Related articles

• Postback (S2S) tracking overview
• Set up Meta Pixels and Conversions API
• Set up your first pixel for tracking