SubID tracking uses a partner-defined sub-identifier to distinguish traffic sources, placements or campaigns beneath one affiliate account. A SubID is source context, not a user identity or proof of a conversion. Agree on its meaning and propagation before comparing performance.
SubID tracking example: two placements, one affiliate
An affiliate may aggregate many traffic sources. Imagine one sending traffic from a news widget and a comparison page. Use stable placement labels to distinguish the sources, preserve them through the agreed feed and click contract, and compare the same reporting period. These fictional labels illustrate the workflow; they are not Nexus request parameter names.
- News widget: inspect its source-level clicks and reported results.
- Comparison page: inspect the separate placement under the same affiliate.
- Missing SubID: keep the unknown source visible rather than guessing its origin.
Preserve source context
Nexus can require or preserve sub-ID context in XML request configuration. Naming and allowed values should be agreed with the partner before launch.
- Source
- Placement
- Campaign reference
- Partner-defined segment
Apply policy at the correct level
Member limits protect the account boundary while sub-ID reporting helps operators investigate quality and performance beneath it.
Avoid identity ambiguity
Sub-IDs should not be treated as authenticated identity. They are request context and must be validated and interpreted within the partner contract.
This guide describes Nexus product architecture and general AdTech operating concepts. Exact enforcement and integration behavior depends on the enabled revenue engine and agreed deployment configuration.
Published by Nexus Soft.
Content revised
Sources and product scope
Product references describe available controls and their limits. Examples are illustrative.