Affiliate SubID tracking: identify partners, offers and placements

Learn how SubID tags and click IDs separate partner reporting, how to map network parameters, and which tracking-link scenarios to test.

SubID is a reporting label, not an identity system

A SubID is an additional value attached to an affiliate link so traffic can be grouped in network reports. It can distinguish a publisher, placement or campaign. It is not a password, a permission check or proof that a conversion belongs to the person who supplied the value.

Admitad’s mobile publisher documentation describes five SubID parameters for granular reporting. That is a provider-specific capability: check the actual field names, character limits and returned values for every network you connect.

Separate four different identifiers

A useful internal model has a stable partner ID, an offer ID, a placement ID and a unique click ID. The partner identifies the business receiving attribution. The offer identifies the destination campaign. The placement identifies where the visitor saw the link. The click ID identifies one recorded outbound visit.

For example, partner p17 may promote offers o3 and o9 from a receipt page. Its two shareable links should resolve to different partner–offer records. Each visit then creates a new click ID. Do not reuse a single click ID for all visits from the same partner.

Map your identifiers at redirect time

Resolve the shareable link on your server, check that both the partner link and offer are active, and record the click before redirecting. The network adapter inserts the required values into the approved destination URL. Keep that mapping configurable rather than assuming every provider calls a field subid.

As an illustrative mapping, one provider field might carry the click ID while another carries the placement ID. The database retains the partner and offer relationship. Avoid including email addresses, names or other personal data in URL tags; opaque internal identifiers are easier to manage and less revealing.

Handle edits, retries and missing tags

If a visitor edits a visible partner parameter, the server should not silently reassign ownership. Resolve ownership from the stored link record. If an offer is disabled, show a controlled fallback instead of redirecting to an arbitrary URL.

Keep the generated destination or its relevant tracking configuration with the click record. This helps investigate later reporting mismatches when campaign settings have changed. A conversion without a resolvable click should enter an unmatched queue, not a guessed partner account.

Tests before a real campaign

Test using provider-approved procedures; do not simulate paid customer actions against live campaigns. Continue with the postback implementation guide to connect a recorded click to later conversion events.

Continue reading

Have a specific integration in mind? Talk to us.