Read the Conversions page
See every conversion postback in both directions, understand why one conversion produces two rows, and find the evidence when a partner says they fired.
This article explains the Conversions page: what each column means, who the Partner and Buyer actually are, and why the same conversion usually appears twice.
Open it to answer two questions. Did my partner get told? And who told us this converted?
Why one conversion makes two rows
A buyer confirms a lead it bought on a cost-per-acquisition contract. That is an incoming row. Datahubb then tells the traffic source or supplier that the lead converted. That is an outgoing row.
Both carry the same transaction id. They are not duplicates, and the Direction column says which is which.
Direction
Direction is written from Datahubb's point of view, which is the opposite of how a partner would describe the same event.
| Direction | Meaning |
|---|---|
| Outgoing | Datahubb told this partner that a conversion happened |
| Incoming | A partner told Datahubb that a conversion happened |
Partner
The Partner column names one party per row, and it means the same thing in both directions.
- On an outgoing row, the partner is the recipient the postback was addressed to.
- On an incoming row, the partner is whoever sent the lead: its traffic source when it has one, otherwise the supplier that generated it.
A row names a traffic source or a supplier, never both. Because both can carry the same company name, the column states which kind of party it is underneath the name.
A supplier reads as company, alias, and id. All three earn their place, because one client can own a supplier row per campaign, so two rows can legitimately share a company and an alias and the id is the only part that says which one a row means. It is also what you quote in a support ticket.
Buyer
The Buyer column names the buyer that reported the conversion, and it is filled on incoming rows only. An outgoing postback is addressed to a partner, so it has no buyer and the cell is empty by design.
The practical consequence: filtering by a buyer hides every outgoing row, because none of them has one. That is the question being asked rather than a bug.
Delivery
Delivery answers whether the partner's endpoint accepted the postback.
| Label | Meaning |
|---|---|
| Delivered | The partner's endpoint accepted it |
| No response | The request never produced a response at all, so the partner was never told. Usually an unreachable or blocked URL. |
| Failed | The partner's endpoint rejected it |
No response and Failed are worth reading differently, because the fix is different. One is a URL nobody answered. The other is an endpoint that answered and refused.
A row sent through the Meta CAPI preset carries a badge beside its transaction id. A preset send is not an ordinary postback: the payload is built to Meta's schema and lands in an ad account rather than a partner's own endpoint.
Filters
| Filter | Notes |
|---|---|
| Campaign | Scopes the Partner, Buyer and Affiliate lists below it. Changing it clears them, because their options are campaign-scoped. |
| Partner | Traffic sources and suppliers in one list, grouped under headings |
| Buyer | Grouped by contract type, and returns incoming rows only |
| Affiliate | Hangs off traffic sources. The supplier half of a Partner selection is ignored here. |
| Direction | Incoming or outgoing |
| Event type and Sub-type | Cascading. Sub-type applies to click events only. |
| Date range and search | Always applied |
The Partner filter is grouped and typed because ids are only unique within a type. A workspace can have both a traffic source 8 and a supplier 8. Searching the dropdown for a group name keeps that whole group, so typing "supplier" still narrows to suppliers.
The search box matches part of either the transaction id or the external id, case-insensitively. Both are what people actually paste in.
Open a conversion
Click any row to open the details drawer. It carries the lead context, the partner and buyer, and the full postback log.
Outgoing rows show the HTTP method, response status, body mode, request body, request headers, and the response body.
Incoming rows show Received from, the address the postback arrived from, and the headers it carried. This is the evidence for the most common question on this page: when a buyer says they fired a postback and the lead did not move, the URL alone cannot say whether the request ever arrived, from where, or what it carried. Credential headers are stored redacted.
Expected result
You can point at a specific conversion, say which direction it travelled, name the partner and buyer, and show whether the recipient's endpoint accepted it.
Troubleshooting
- The same conversion appears twice. Expected. One incoming row, one outgoing row, sharing a transaction id.
- The Buyer column is empty. The row is outgoing. Outgoing postbacks are addressed to a partner and never carry a buyer.
- A buyer filter returns no outgoing rows. Working as intended. Drop the buyer filter to see both directions.
- The Partner column is blank. The lead resolved neither a traffic source nor a named supplier. Check the lead itself.
- Delivery says No response. The partner's URL was unreachable or blocked. Confirm the address with them, then re-check the postback config.
- Received from and headers are blank on an older row. Those fields were added later and historical rows do not carry them.
Frequently asked questions
Comments
No comments yet — be the first to share your thoughts.