Conversion pixels and server-to-server postbacks, explained
How a conversion gets reported back to your tracker — the image pixel versus the S2S postback, the click ID that anchors attribution, the transaction ID that prevents duplicates, and the JSON response you can store in your CRM.
A conversion pixel is a tiny snippet you place on your confirmation or thank-you page that tells LimeliJourney a conversion just happened. A server-to-server (S2S) postback does the same job, except your server sends the request directly instead of the visitor's browser. Both arrive at the same endpoint on your tracking domain, /conv, and both close the loop that turns a recorded click into attributed, payable revenue. Here is how to install one well.
Pixel or postback?
The image pixel is a 1x1 transparent <img> you drop on the confirmation page. It always returns quietly and can never visibly break your page, which makes it the simplest option. The S2S postback is a POST your own server sends with the same field names — the right choice whenever the conversion carries personal data, since nothing sensitive ever appears in a URL. There is also an iframe variant, needed only if your affiliates run their own HTML pixels.
Whichever you use, always fire at your own tracking domain: the domain is what identifies your account.
The click ID anchors attribution
When a visitor arrives through a tracking link, the click ID (ll_cid) is appended to your landing page URL. Carry that value through to the pixel. It links the conversion to its original click and automatically back-fills the affiliate, campaign, channel, and creative — you do not have to name any of them yourself.
If the pixel fires without a click ID, the tracker falls back to the ll_cid cookie set in the visitor's browser at click time and credits the last click, as long as it is still inside the offer's attribution window (30 days by default, extendable to 90 or 365). A cookie from another account is never honored, and an explicit click ID always wins regardless of age. Because some browsers withhold cookies on shared subdomains, passing the click ID through your funnel remains the most reliable integration — one more reason first-party tracking earns its keep.
One transaction ID prevents duplicates
The txn value is your transaction ID — an order or transaction number that is unique per conversion. It shows as the Transaction ID in your reports, and it deduplicates: re-firing the pixel with the same txn updates the existing conversion instead of creating a second one. Retries, page refreshes, and revised amounts are all safe. The generated snippet ships with a placeholder you must replace with a real value; leave the placeholder in and each fire is recorded on its own, so a forgotten substitution costs you double-fire protection, never your data.
Reading the outcome
A server fire — a POST, or a GET with format=json — returns a small JSON acknowledgement: ok, recorded, a minted conversion_id, and a status. Store the conversion ID in your CRM to tie your record to ours. The status is the real outcome: converted means stored and credited, unattributed means no click matched, duplicate means a re-fire or matched rule, and a handful of others each name a specific cause. Read it right in your server logs to self-diagnose without opening any dashboard.
You can also send rev to report the sale amount (required for revenue-share billing) and lead identity like email and phone by POST, which stitches the conversion to a single contact.
Want us to install a live pixel and watch a conversion land and attribute on your own data? Book a demo and we will set it up with you.