Conversion event mapping and postback backfill

Conversion event mapping turns advertiser-specific callback names into stable reporting events without erasing the original source value. Postback backfill then gives you a controlled way to deliver eligible historical conversions that were received before traffic-source feedback was configured or completed.

This is the layer after basic postback setup. First the callback must resolve to the correct click. Then the event must mean the right thing in reports and in any outbound conversion delivery.

Why conversion names need mapping

Advertisers rarely use one universal event vocabulary. The same business outcome may arrive as:

• sale;
• purchase;
• complete_payment;
• approved;
• qualified_lead.

Those names are evidence from the sending system. Keep them, but map them to a stable category your campaign and traffic source understand.

For example:

Advertiser event	Tracked event
lead_created	lead
lead_approved	qualified_lead
order_paid	purchase
order_refunded	refund

Do not map every callback to purchase. A submitted lead, approved lead, sale, refund, and chargeback can carry different value and should remain distinguishable when the business model depends on that difference.

Start with the inbound postback

The advertiser or network calls the Tracked postback endpoint with the original click ID and supported event fields. Tracked uses that ID to resolve the campaign journey.

Decide whether the callback is the primary conversion or a secondary funnel event. An untyped Offer callback is primary and can use the supplied payout or the configured Offer payout. Supplying conversion_type or its type alias makes the callback secondary and sets its payout to $0, even when the request also includes payout.

A valid callback should answer four questions:

1. Which click produced the event?
2. What did the advertiser call the event?
3. What stable reporting event should it become?
4. Is it eligible for outbound feedback to the connected traffic source?

If the first question is unresolved, mapping cannot repair the attribution. Follow the postback setup guide before changing event aliases.

Keep source events and reporting events separate

Preserving both values makes debugging much easier.

The source event tells you what the advertiser sent. The canonical event tells reports and integrations how Tracked classified it. If a new advertiser starts sending approved_sale instead of sale, you can update the mapping without pretending the historical source data used the new name.

This also prevents one integration’s naming convention from becoming the vocabulary for every campaign.

Map events at the correct offer and campaign boundary

Tracked maps the advertiser value on the originating offer and the exact provider event name on the campaign that will send feedback. Confirm both objects and the connected traffic source before saving the mapping.

For each mapping, document:

• the exact inbound event name;
• the stable Tracked event;
• the outbound event expected by the provider;
• whether the event is primary, secondary, or reversal-like;
• the date the rule becomes active.

Avoid broad wildcard rules until you know every event they will capture.

What postback backfill is for

Backfill is useful when Tracked already received and attributed eligible advertiser callbacks, but outbound traffic-source feedback was not delivered because the exact event mapping was not ready.

Examples include:

• an event alias was missing;
• the campaign did not yet have the provider's exact event name;
• historical callbacks were classified after the mapping was added.

Backfill is not a way to invent conversions or reconstruct historical revenue. The source callback must already exist and resolve to real campaign evidence. Tracked's confirmed historical feedback uses the mapped provider event name with $0 revenue.

A safe backfill workflow

1. Define the event mapping

Confirm the original advertiser event and its intended canonical event. Test the mapping with a new controlled conversion first.

2. Confirm outbound delivery configuration

Verify the target campaign, traffic source, exact provider event name, original platform click ID, and supported delivery method. A generic successful request does not prove the provider accepted the event into reporting.

3. Bound the time range

Use the smallest useful interval. A narrow range is easier to audit and limits the impact of a bad mapping.

4. Preview eligibility

Count callbacks that:

• belong to the mapped offer and campaign;
• have a mapped event;
• contain a valid original platform click ID;
• have not already completed the same outbound delivery;
• are in the currently eligible confirmed batch.

5. Run the authorized backfill

Backfill is a separate confirmed write after mapping. Review the eligible count and exact provider event name before sending; choosing “not now” keeps the history classified in Tracked without sending feedback.

6. Verify both sides

Check Tracked’s delivery record and the provider’s later reporting state separately. A queued or accepted request is not the same as a conversion appearing in an ad platform report.

Prevent duplicate conversion feedback

Retries are normal. Duplicate business events are not.

Send a stable conversion-level identity when the source supports it; Tracked uses that explicit identity first. Without one, it falls back to the click ID, normalized event type, and a fixed 60-second receipt-time bucket. The bucket uses fixed boundaries rather than a rolling window, so identical retries on opposite sides of a boundary can receive different fallback keys. Before backfilling, distinguish:

• an event that never attempted delivery;
• an event whose delivery failed and can be retried;
• an event the provider accepted;
• a genuinely new repeat conversion.

Do not deduplicate solely on click ID when one click can produce several legitimate events.

Where Tracked fits

Tracked keeps the inbound callback, original event, mapped conversion, outbound feedback, and attributed journey connected. That makes it possible to diagnose whether a discrepancy began at the advertiser callback, the event mapping, the delivery adapter, or the destination platform.

Native integrations, configurable postbacks, and conversion APIs have different contracts. The integration comparison explains what each connection can move and where mappings apply.

Frequently asked questions

What is conversion event mapping?

It translates an advertiser’s event name into a stable reporting event while preserving the original value for diagnosis.

When should I use postback backfill?

Use it when eligible advertiser callbacks were already received and attributed but the exact outbound event mapping had not been configured. Tracked presents the eligible historical batch for a separate confirmation.

Can backfill create a conversion that Tracked never received?

No. Backfill should operate on existing eligible conversion evidence, not fabricate historical events.

How do I avoid sending the same event twice?

Use stable conversion identities, inspect prior delivery state, and backfill only events that have not already completed the same provider delivery.

Start free and connect conversion events to campaign evidence.