Sending conversions back to ad platforms with postbacks

A lead is not the result most advertisers care about. The result is the appointment that gets booked or the contract that gets signed, and that usually happens days later, inside a CRM. If the ad platform never hears about it, it keeps optimizing for form fills instead of for the people who actually became customers.

Postbacks close that gap. Your CRM makes one simple call to EventsIQ saying "this click turned into a sale", and EventsIQ works out which campaign the click came from and sends the event to that campaign's Meta pixel, TikTok pixel or Google Ads account.

The postback URL

Your account's postback URL is on Settings → Postbacks. It looks like this:

https://YOUR_EVENTSIQ_HOST/cv?click_id={click_id}&event=sold&value={value}&key=YOUR_KEY

Copy the real one from that page with the Copy button, which fills in your host and key. Then give it to your CRM, replacing the braced parts with however your CRM writes its own placeholders.

If your CRM was set up for another tracker, you may only need to change the hostname, because EventsIQ also accepts the common alternative names: clickid, eiq_click or cid for the click id, ct or event_name for the event, and payout, amount or revenue for the value. GET and POST both work, with values in the address, in a form body or in JSON.

Getting the click id into your CRM

Your CRM can only send back a click id it was given. When your routing sends the lead to the CRM, include the lead's click id in the body template. It is one of the runtime values in the token picker. From then on the CRM stores it with the contact and can send it back when the deal moves forward.

Treat the key like a password

Anyone with your key and a valid click id could send fake sales and distort what the ad platform learns. If the key leaks, click Rotate key. The old URL stops working at once, so update your CRM straight after.

One event name, a different pixel event per integration

Events are your own names for the stages your CRM sends, set up on the Postbacks page. For each one you choose a readable label and how its value works: whatever the CRM sends, the same amount every time, or no value at all. Names are matched ignoring capitals and spaces, so Sold and sold are the same event.

What the ad platform receives is decided somewhere else: on each Conversion API integration, under Postback events. Each row there says "when my CRM sends this event, send the network that event".

For example, Acme Solar might map its events like this:

For Meta and TikTok you type the event name the pixel should receive. For Google you pick one of your Import from clicks conversion actions. On Meta you can also choose to send a row as a CRM event rather than a conversion.

The important consequence: the postback never names a pixel. The click belongs to a campaign, and the campaign has a conversion integration. Five campaigns on three different ad accounts can all send sold, and each sale goes to the right pixel or Google Ads account automatically. One postback URL serves every campaign you run.

An integration with no Postback events rows sends nothing, whatever your CRM sends, and the integration sheet says so.

What is sent with each event

You do not configure the matching data. EventsIQ fills it in from the lead: hashed email, phone, name and location, the network's own click ids (such as fbc and fbp for Meta, ttclid for TikTok and gclid for Google), the sale value and the event time. Personal details are hashed with SHA-256 before they leave, as each network requires.

Duplicates are refused

CRMs retry calls, and people mark the same deal as sold twice. Either way, a sale should only be counted once.

EventsIQ allows each click to send each event once. A second sold for the same click is answered, but nothing is sent to the network, and the log row says it was already reported. Different events on the same click are separate, so appointment followed later by sold both go through.

Why the CRM always gets a success reply

When EventsIQ decides not to send something, for example because the event name is misspelled, it still answers the CRM with a success status and puts the reason in the reply. Many CRMs retry a refused call indefinitely, and a spelling mistake is not fixed by retrying. The two exceptions are a wrong key, which is refused as unauthorized, and too many requests.

Where EventsIQ can tell which account the call belongs to, the reason also appears in Activity → Conversion Logs as a skipped postback row, with a badge saying what kind of reason it is:

• Setup: something is not configured. For example, no event of that name exists, the campaign has no conversion integration, or the integration has no row for this event.
• Rule: a rule said not to send it. For example, the event is turned off, or it was already reported for this click.
• Lead data: the lead is missing something the network needs.

A missing click id, an unknown click id or a wrong key is refused before EventsIQ knows whose account the call is for, so those appear only in the reply to the CRM. If Conversion Logs shows nothing at all, run the same call with curl and read the reply.

Retrying a failed postback from the logs

Sometimes the network itself refuses an event or does not answer, for example because a pixel was misconfigured or the connection lost access. In Conversion Logs those rows show as Failed (the network answered and refused) or Error (no answer, such as a timeout).

Fix the cause first, then open the row and click Retry this postback. The retry is logged as a new attempt, so you can see both the original failure and the result of the retry.

Testing the whole chain

Before you rely on it, run one test:

1. Submit a test lead through a campaign link.
2. Open it in Activity → Lead Logs and copy the click id under The click this came from.
3. Call the postback URL with that click id, for example with curl and event=sold&value=250.
4. Open Conversion Logs. You should see a postback row for sold and the event sent to the network.

One limit worth knowing

A postback finds the lead by its click id. Leads from Meta, TikTok, Google and Snapchat instant forms never pass through a tracking link, so they have no EventsIQ click id and cannot be sent through the postback URL today. Their sales are reported at the moment a destination buys them, through the routing's CRM events.

For everything that comes through your own landing pages, postbacks let the ad platform learn from the outcome you care about, and your CRM never needs to know about pixels.