How an affiliate tracking SDK works

An affiliate tracking SDK is a small amount of code that does two jobs reliably so you don't have to reinvent them: catch the click ID when a referred visitor lands, and report the conversion when they buy. Understanding what's inside it — and how it relates to server-to-server postbacks — tells you when to reach for the SDK and when a raw postback is the better tool.

What does an affiliate tracking SDK do?

An affiliate tracking SDK captures the click ID from an inbound affiliate link, persists it across the user's session, and later fires a conversion event back to the tracker with that click ID attached. It packages the fiddly, easy-to-get-wrong parts of client-side tracking — reading the ID, storing it, and reporting reliably — into a few function calls.

What are the core functions inside it?

Two functions do the real work: one runs on landing to capture attribution, the other runs at conversion to report it.

1. Initialize / capture: on page load, the SDK reads the click ID from the inbound URL and stores it (for example in local storage) so it survives navigation through your site.
2. Track conversion: at the point of sale, you call the SDK's conversion function with the value and a unique order reference; it attaches the stored click ID and sends the event to the tracker.
3. Optionally, the SDK exposes helpers for the click ID and for setting customer context, but capture-and-convert is the heart of it.

How does the SDK relate to server-to-server postbacks?

The SDK is the client-side counterpart to the server-side postback, and they share the same currency: the click ID. The SDK captures and reports from the browser; the postback reports from your backend. They aren't rivals — many setups capture the click ID with the SDK on landing and then report the conversion with a server postback once the order is confirmed, getting client-side capture and server-side reliability together.

The SDK and the postback are two doors into the same room. Whichever you walk through, you're carrying the same click ID — that's what makes them interchangeable where they overlap and complementary where they don't.

When should you use the SDK versus a raw postback?

Use the SDK when the conversion completes in the browser, and use a raw server-to-server postback when the order is finalized on your backend. The decision is simply about where the conversion truth lives.

• Use the SDK for client-side conversions — single-page checkouts, in-browser signups, and flows where the success state is known on the client.
• Use a raw postback for server-completed orders — payment confirmations, async order processing, and anything where the backend is the source of truth.
• Use both together for capture-on-client, report-on-server, which is the most robust pattern.
• Prefer the server postback whenever fraud resistance matters most, since it can't be tampered with from the browser.

Afflio ships a tracking SDK that handles click-ID capture and reports conversions over cookieless S2S, so whichever integration path fits your stack — SDK, postback, or both — attribution rides on the same server-anchored click ID and survives the browser privacy settings that break cookie-based tracking.