Search syndication connects a publisher’s search experience to approved advertising demand. The useful starting point is one query from one source: identify the publisher link, the eligible provider feed, the request context and the reports that will explain the result. Nexus supplies operating software; provider access, traffic approval and commercial agreements remain separate requirements.

01

Connect supply to multiple demand feeds

Keep provider feeds and publisher links as distinct records. The provider feed holds the advertiser, search engine, feed URL, search cap, revenue share and NET reporting settings. The publisher link selects feeds and holds its own integration type, cap, backfill and commercial settings. Before connecting either, confirm the provider’s actual request and response contract and the traffic approved for it.

  • Affiliate and direct-publisher access
  • XML and JSON provider contracts
  • Feed assignment and eligibility
  • Provider-specific integration validation
02

Define publisher-link eligibility

Use the Search link Targets tab to choose which sub-IDs, domains and keywords are eligible for that link. Feed-level keyword replacement and provider settings are separate controls. Check country, browser/version and device requirements in the relevant editor rather than assuming link and feed fields are interchangeable. The adjacent configuration guide explains the relationship; it does not apply or recommend traffic settings.

Search publisher linkConfiguration guide
  1. 01 / CONTEXT

    Define eligibility for this link. Provider-feed settings remain a separate configuration.

  2. 02 / SUPPORTED CONTROLS
    • SubIDs
    • Domains
    • Keywords
  3. 03 / REVIEW

    Check link-to-feed assignments and the applicable integration before delivery.

Illustrative configuration, not a live account. Search feed and link controls differ. Provider integrations, NET import timing and metric definitions are confirmed during deployment.
03

Illustrative trace: preserve the original source

Imagine a fictional publisher, Cedar, sending the query hiking boots from its mobile-search source. In a planning record, keep the publisher link, SubID, original query, selected provider and any configured keyword transformation together. Confirm which URL macros the provider supports and test the transmitted values. These labels are explanatory; they are not a live request, a Nexus parameter schema or permission to send traffic to a search provider.

  • Original intent: hiking boots from Cedar / mobile-search.
  • Eligibility check: the configured link, domain, keyword and device rules.
  • Demand check: the assigned provider and its accepted traffic contract.
  • Outcome check: response, local searches/clicks and later partner-reported figures.
04

Make commercial policy explicit

Search feed and link editors expose revenue-share and search-cap settings. A publisher-link cap and a provider-feed cap protect different relationships; document which resource owns each value. XML feeds have separate minimum-bid, QPS, click and budget controls. Do not copy an XML limit checklist onto Search or interpret a configured traffic limit as a plan entitlement. Agree on the meaning and reset behavior of each cap during validation.

05

Diagnose an empty result in a useful order

Start with the selected link and source context, then inspect feed assignment, targeting, traffic-quality rules, caps and provider availability. Distinguish an intentionally ineligible query from an integration error or an eligible query with no demand. Test the configured backfill path independently. Increasing a cap cannot fix a malformed provider request, and changing keyword rules without preserving the original query can make later investigation harder.

  • Check one known eligible sample and one intentionally ineligible sample.
  • Exercise an empty response and a provider failure with agreed expected outcomes.
  • Record the relevant settings and report filters so another operator can repeat the investigation.
06

Reconcile technical and commercial evidence

Review the same date range, publisher/link and feed before comparing searches, monetized activity, clicks, revenue and partner NET results. Use Keyword List or Keyword Count and available domain/device breakdowns to localize a difference. NET import timing and metric definitions depend on the provider. A local search, a monetized result and a paid click are different observations; confirm the denominator of EPC, RPM and coverage with the report definition before presenting them as a business result.

07

Scope the first launch around evidence

Bring one approved provider, one publisher traffic pattern, the supported query/tracking contract and a target reporting question to the evaluation. Agree on integration tests, commercial ownership and the handover process before expansion. The goal of the first walkthrough is to show that the team can explain a traffic path and its outcome, not to infer guaranteed demand or revenue from a configured feed.

Product accuracy

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.