Server-Side Conversions Without Site Access: A Media Buyer's Playbook

The daily reality of affiliate media buying is server-side conversions without site access: the sale registers on a landing page owned by an advertiser, you cannot place a pixel or edit a single tag there, and the only route back to the ad platform runs through your own server. This guide maps that route. It covers what you control in this situation, how the server event gets built and delivered, what the missing landing domain costs you in match quality, and how to prove the whole chain works before you scale.

Server-side tracking is what makes the situation survivable. Without access to the page, browser-side measurement simply does not exist for you - there is no tag of yours on the domain where the conversion happens.

The Situation: The Conversion Happens Where You Have No Access

Run an in-house store and you own the whole measuring surface: the checkout page, the pixel on it, the order data behind it. Buy traffic for an affiliate offer and every part of that surface belongs to someone else. The advertiser's page fires the advertiser's pixels, serves the advertiser's analytics, and reports to the affiliate network - not to you.

Meanwhile the ad platform that sold you the click still expects to hear about conversions. Its optimization needs conversion signals tied to the clicks it sold, and its reporting is what you use to judge creatives, audiences, and budgets. So the measurement problem does not disappear - it moves. Someone has to carry the conversion fact from the advertiser's domain back to the platform, and the only systems in that chain that answer to you are your tracker and your server.

This is why the whole situation reduces to one question: what can you capture on the parts of the funnel you do own, and how reliably can you forward it?

What You Actually Control: Your Links, Your Tracker, Your Server

Even with zero access to the landing page, three points of the funnel are fully yours:

1. The click itself. Your ad points at your tracker link (or a prelander you host), so the platform's click ID - fbclid, ttclid, rdt_cid - arrives on a page you control. The tracker stores the click with that identifier before anyone redirects anywhere.
2. The redirect to the offer. Your tracker appends its own sub ID to the offer URL, and the network promises to echo that sub ID back in its postback. This is the contract that makes matching possible later.
3. The delivery infrastructure. When the network's postback announces a conversion, it lands in your tracker - and from there, forwarding the event to the platform is your code, your tracker's integration, or your automation.

Everything the platform needs to credit a conversion can be assembled from those three points: the click ID from step one, the conversion facts from the postback in step three, and the timestamps and values the network reported. Click ID preservation is the load-bearing part - where fbclid and ttclid get lost catalogues the failure points.

The Delivery Path, Step by Step

The full path from a paid click to a platform-side conversion event:

1. A user clicks your ad. The platform appends its click ID; your tracker records the click, the click ID, the IP, and the user agent.
2. The tracker redirects the user to the offer, appending your sub ID to the offer URL.
3. Somewhere on the advertiser's page, the user converts. The network receives confirmation of the action from the advertiser afterwards.
4. The network fires a server-to-server postback to your tracker, echoing the sub ID and carrying the conversion details - status and payout among them.
5. Your tracker matches the postback to the stored click and delivers the conversion to the ad platform as a server event, through its platform integration or an automation acting for it.

Keitaro documents both ends of this path: the S2S postback that receives the network's announcement - with {external_id} carrying the click ID and {conversion_revenue} the payout - and a built-in integration that forwards matched conversions into Meta's Conversions API (Keitaro's Facebook Conversions integration). The general mechanics of each hop are in the complete affiliate conversion tracking guide.

One property of this path matters more than the rest: it is entirely server-to-server after the click. No browser on the path belongs to the conversion moment, so nothing depends on the landing page loading your scripts - because it never loads yours.

What the Platform Requires From the Server Event

A server event is a structured POST, and each platform documents its minimum. Meta's requirements for website events are explicit: the event must carry action_source, event_source_url, and client_user_agent, and non-web events need only action_source (Conversions API parameters). The event's event_time may sit at most seven days in the past, and a single stale event fails an entire request (using the API).

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1790000000,
      "event_source_url": "https://your-tracker.example/offer/47",
      "event_id": "postback-88412",
      "action_source": "website",
      "user_data": {
        "client_ip_address": "203.0.113.24",
        "client_user_agent": "<user-agent-of-the-original-click>",
        "fbc": "fb.1.1790000000.IwAR0abc"
      },
      "custom_data": {
        "currency": "USD",
        "value": 49.99
      }
    }
  ]
}

Two fields in that example deserve attention in the no-access situation. event_source_url cannot be the advertiser's checkout - you have no sanctioned knowledge of it - so buyers point it at their own offer URL or tracker redirect. And fbc exists in the payload only because the tracker captured fbclid at click time: Meta documents that the _fbc cookie value can be constructed from the fbclid URL parameter when the browser never set the cookie (fbp and fbc parameters).

For Reddit, the Conversions API accepts server events within seven days of the conversion and deduplicates against the pixel by conversion ID; the direct integration guide lives on Reddit's API documentation. TikTok's server-side counterpart is the Events API, which takes the same role in TikTok's funnel.

What You Lose Without the Landing Domain

A pixel on the conversion page quietly harvests matching material: the _fbp and _fbc cookies of that domain, the browser context, sometimes a hashed email from a form. Without site access, none of that material exists at the moment of conversion - the advertiser's domain never collects it for you.

What compensates is everything captured at click time on your side:

The practical consequence shows up in Meta's Event Match Quality: events forwarded with a click ID, IP, and user agent score useably, while events with nothing but a timestamp drift toward the bottom of the scale (About Event Match Quality). Our match key and event quality glossary entries break down the fields per platform.

The Meta-specific mechanics of reporting affiliate conversions through custom event names have their own deep dive: Facebook CAPI custom conversions for affiliate offers.

Platform by Platform: Where the Event Goes

The situation is platform-agnostic; the delivery surface is not.

Delivery channel choice - the tracker's native integration versus a standalone automation versus a hand-built POST - is compared in postbacks versus the Conversions API. The short version: a tracker integration keeps wiring in one place, and an automation layer on top adds retries, dedup, and per-offer value rules that trackers alone tend to lack.

Verifying the Setup Before Scaling

The chain has enough moving parts that trust is not a strategy. Before scaling:

1. Fire a test click and walk the funnel to a real or network-simulated conversion.
2. Confirm the postback reached the tracker with a non-empty sub ID - Keitaro's S2S postback log shows which subid initiated the send and the source's response.
3. Confirm the server event reached the platform: Meta's Test Events tool displays arrivals in near real time, and events become visible in Events Manager within roughly 20 minutes (get started with the Conversions API).
4. Check the event's match quality signals in Events Manager and fix the thin ones - usually a missing click ID or user agent - before budget goes up.

For free single-shot tests of the Meta leg, Pixel Activator fires test events with nothing but a dataset ID and a token. The postback troubleshooting checklist covers the failure modes between the steps.

Sending Conversions Without Site Access: Frequently Asked Questions

Sources