Offer Rotation Tracking: Many Offers, One Pixel, No Mixed Conversions

As a discipline, offer rotation tracking looks harmless until the first mixing incident: three offers rotating through one campaign, one pixel, one event name - and a report that says the campaign works while saying nothing about which offer pays. Rotation multiplies a small mapping problem into a data-ownership problem, because every conversion must stay attached to the offer that produced it through four more hops of plumbing. This guide builds the mapping that survives rotation: label the offer on the click, carry the label through the postback, map each offer to its own event and value, and read per-offer truth in custom conversions instead of one blended number.

The transport chain the labels ride on is built in the postback-to-CAPI guide; this page is about keeping offers distinct inside it.

Why Rotation Breaks Naive Tracking

With a single offer, every Purchase implicitly belongs to it - no labeling needed. Rotate offers and the implicit link dies: a Purchase event says "someone paid" but not which funnel produced the payment, which creative deserves the credit, or which payout value matches which offer's economics.

On the platform side the consequence is exact: the optimizer and the reports can only split conversions along labels you transmitted. The event's event_name and its custom_data parameters are the only offer-specific information in the payload (server event parameters). If three offers all send Purchase with different values, the platform will happily optimize the blend - and the blend optimizes toward whichever offer converts cheapest, not whichever pays most.

The tracker-side consequence mirrors it: unmatched or unlabeled conversions make per-offer ROI arithmetic impossible, and rotation decisions become guesses.

Label the Offer at the Click

Rotation happens in the tracker - its streams decide which offer a click sees - so the click row is where the offer label is born. Keitaro's postback contract gives the label a ride home: sub_id_1 through sub_id_30 are documented as "extra data to update the click record," which is exactly where an offer tag belongs, and the alias system maps whatever parameter name the network uses onto those fields (Keitaro postback documentation).

The labeling chain:

1. Each rotation branch appends its own marker to the offer URL - the offer's sub ID parameter carries a distinct value per offer.
2. The network's postback echoes the marker back through those sub ID fields.
3. The tracker stores the marker on the conversion's click row; the delivery layer reads it when building the platform event.

From that point on, offer identity is data, not guesswork: the S2S postback macros - {external_id} for the click, {conversion_revenue} for the payout, {_offer_name} for the offer itself - let the delivery layer address each offer distinctly (S2S postbacks).

Map Each Offer to Its Own Event

Two documented shapes cover rotation on the platform side:

Custom events keep offers separated at the platform's top level - each name builds its own custom conversion, appears in reporting separately, and can serve the ad set's optimization dropdown (custom conversions). Parameter labeling keeps the event list short and splits offers inside Events Manager by rule; the cost is that the raw event count blends until a rule separates it.

Either shape works; mixing them mid-flight does not. Renaming events after volume accumulates splits each offer's history across two names - the single most common self-inflicted wound in rotation tracking.

Value Rules Under Rotation

Rotation makes value discipline mandatory, because offers have different money:

1. Per-offer payout as value. The postback's {conversion_revenue} is the offer's own payout - forwarded as value with its currency (custom data parameters). A blended average value poisons every offer's optimization at once.
2. Per-offer acceptance windows. The platform's event_time window is seven days for Meta's Conversions API regardless of offer (using the API) - but offer-specific confirmation lags differ, so slow offers get closer to the edge.
3. Per-offer identity. Multi-action offers need the tid-style transaction parameter so repeats do not overwrite (postback URL); rebilling offers need their own cycle events, as in the subscription funnel.

Configuration belongs to the offer, not the campaign: name, value source, status mapping, and identity rule defined per offer in one place - the delivery layer - so rotation can shuffle traffic without editing wiring.

The Traps That Merge Offers' Data

1. The shared Purchase. All offers firing the standard Purchase name with different values: the optimizer optimizes the blend, the reports cannot split, and pausing the losing offer looks like pausing the campaign.
2. The averaged value. Sending a mean payout instead of the actual payout per conversion - value-based optimization learns a fiction and bids toward it.
3. The mid-flight rename. Changing event names after history accumulated: each offer's record splits across old and new names, and neither half has enough volume to optimize.
4. The unaliased parameter. A network posting clickid instead of the expected name, with no alias configured: postbacks arrive unmatched, and one offer silently reports zero.

Each trap has the same antidote - labels as data, defined per offer, applied by the delivery layer - and the same test: one conversion per offer through the real chain, verified in the postback log and Test Events (get started), before rotation scales. The postback troubleshooting checklist covers the failure modes the test flushes out.

Offer Rotation Tracking: Frequently Asked Questions

Sources