AdOperator names its click-tracking macro {conversion}, which is a genuinely confusing choice — it has nothing to do with a sale or a goal completion, it's simply the unique ID for the click itself, and mistaking it for a conversion-tracking pixel is an easy way to break attribution before you've even started. Get past that naming trap and AdOperator's macro set is straightforward: three tokens covering click, campaign, and publisher sub ID. Append them to your destination URL and ValidVisit attributes and scores every AdOperator visit against the publisher that actually sent it.
Cross-check any macro against the network’s official documentation. AdOperator official docs →
{conversion} is the required macro, and despite the name it carries no information about whether anything converted — AdOperator uses it purely as the click identifier, filled with a unique value on every click so ValidVisit can match the arriving visit back to it. If you've wired up conversion tracking elsewhere and see a token called {conversion}, it's tempting to assume the two are related; they aren't, and treating AdOperator's {conversion} as anything other than a click ID will quietly break attribution. {campaign} identifies the campaign, and {subid} is the publisher sub-identifier — the value that names the actual traffic source behind a click and the one AdOperator lets you act on directly. All three are ordinary query-string macros that AdOperator expands automatically; the only real risk in setup is the naming, not the mechanics.
Once the naming confusion is out of the way, {subid} does the same job here it does on most publisher networks: it's what splits a single AdOperator campaign into the individual traffic sources actually running it, sources that rarely perform identically even when they share a campaign. A sub ID sending real, engaged clicks and one recycling the same traffic pattern can sit side by side in the same campaign report unless you split by {subid} and look at each one's score separately. ValidVisit's part ends at that visibility — it does not exclude a sub ID or adjust AdOperator's traffic mix for you. Cutting a bad sub ID is a decision you make and execute inside your own AdOperator account, using the per-sub scores as the evidence.
| Token | AdOperator macro | ValidVisit param | Example |
|---|---|---|---|
| Click ID *click | {conversion} | vv_click_id | abc123xyz |
| Campaign IDcampaign | {campaign} | vv_campaign_id | 123456 |
| Publisher Sub IDpublisher | {subid} | vv_publisher_id | pub_42 |
{conversion}vv_click_id{campaign}vv_campaign_id{subid}vv_publisher_id* required for AdOperator attribution.
https://yoursite.com/landing?utm_source=adoperator&utm_medium=push&vv_click_id={conversion}&vv_campaign_id={campaign}&vv_publisher_id={subid}Append these params to your landing-page URL — AdOperator fills the macros at click time, so every visit arrives attributed and ready to score. No funnel hop.
The buyer pastes/uploads the bad SubIDs as a blacklist preset (or adds them in the campaign’s SubID optimization section) so those publisher feeds stop receiving the campaign; whitelist mode is the inverse.
No, despite the name. {conversion} is AdOperator's click ID macro — it captures a unique value per click, not a sale or goal event. Treat it exactly like any other network's {click_id} token.
{subid}. It names the publisher sub-source behind a click and is the value AdOperator lets you act on directly. {campaign} only tells you which campaign spent the budget, not who sent the visit.
Attribution breaks silently — if you route conversion-event data through the same field or omit {conversion} from your destination URL, ValidVisit has no click ID to match the visit against, and the visit can't be attributed at all.
See which AdOperator publishers and placements send real buyers vs. bots.
Free trial at launch · just your email
One script · no cookies · no fingerprinting · raw IP never stored