Integración S2S de Singular para seguimiento de afiliados: guía de configuración

Singular sits at the analytics-heavy end of the MMP spectrum, and its partner integration reflects that: flat postback payloads, a full timestamp trail from click to install to event, an explicit attribution window on every postback, and a first-class fraud verdict. It is one of the cleaner integrations in this series — with exactly two field-naming traps worth knowing in advance. For the tracker–MMP architecture generally, start with the mobile attribution guide.

What Makes Singular Clean to Integrate

Three properties simplify the work. Postbacks are flat key-value payloads — no nested objects to unpack, unlike Branch or Kochava. Every postback can carry the click, install, and event timestamps plus the click lookback window that governed attribution, which makes window disputes with advertisers resolvable from data rather than assertion. And Singular stamps each postback with its own fraud evaluation, giving your pipeline a verdict to enforce before your own screening even runs.

Step 1 — Build the Tracking Link

Singular's click endpoint takes your affiliate context in short, fixed parameter names:

https://tracking.singular.net/click
   ?aid={affiliate_id}          // publisher
   &sid={sub_aff1}              // sub-affiliate
   &click_id={click_id}         // your click ID — the round-trip key
   &campaign_id={campaign_id}
   &campaign_name={campaign_name}
   &source={source}
   &sub_aff_id2={sub_aff2}
   &sub_aff_id3={sub_aff3}

The naming is terse — aid for the publisher, sid for the first sub-affiliate slot — and easy to transpose when configuring by hand. The mapping table:

Step 2 — Configure the Postbacks

The advertiser registers your tracker's endpoints against your partner source in Singular — install postback plus event postbacks for every action behind a CPA rule:

// Install
https://track.yourdomain.com/postback?click_id={clickid}

// In-app event
https://track.yourdomain.com/postback
   ?click_id={clickid}
   &event={partner_event_identifier}
   &payout={revenue_amount}

Event names must match the Singular dashboard configuration exactly, and — series rule by now — configure event postbacks even on pure CPI campaigns, because post-install activity is your install-farm detector.

Step 3 — The Fields That Matter (and Two Traps)

Beyond the click ID, four payload fields do the analytical work: click_timestamp / install_timestamp / event_timestamp give you the full timing trail for click-to-install analysis; click_lookback_window tells you which attribution window applied; is_reengagement separates re-engagement from fresh installs (route it to its own payout rules, as with Adjust's reattributions); and source=organic marks unattributed traffic that must never convert.

Step 4 — Honour the Fraud Verdict, Then Add Your Own

Every Singular postback carries a fraud_status: traffic its rules rejected arrives marked blocked, usually with a reason attached. Enforce it as a hard gate — a blocked event must never become a payable conversion, whatever your own scoring says. Then run the survivors through tracker-side screening anyway: the MMP sees device and install patterns, but only your tracker sees publisher concentration, sub-ID anomalies, and cross-campaign behaviour. The two layers catch different fraud, which is the point of the layered model in our fraud prevention guide. Postbacks are signed with HMAC-SHA256 over the raw body when a postback secret is configured — verify constant-time, reject mismatches, and treat unsigned production integrations as a finding, not a default.

Step 5 — Reconcile via the Reporting API

Singular's reporting API serves aggregate rows by app, source, campaign, and adset with install and revenue metrics. Schedule a daily pull and compare against your postback-derived counts at source level: matching aggregates confirm the postback stream is complete; a Singular-side surplus points to postback delivery gaps or over-aggressive filtering; a tracker-side surplus points to deduplication problems. Keep both systems reporting in UTC and reconcile whole days, not rolling windows.

Troubleshooting

• Android IDs missing — read aifa, not just gaid. This is the single most common Singular ingestion bug.
• Conversions with empty click IDs — the tracking link omitted click_id, or the join is falling back to singular_click_id. Fix the link template.
• Re-engagement paid as installs — is_reengagement unhandled. Split the conversion class before it becomes an invoice dispute.
• Window disputes with the advertiser — use click_lookback_window from the payloads as the shared source of truth; it states which window Singular actually applied.

Affclix's Singular integration emits the tracking link pre-mapped, normalises aifa/gaid automatically, enforces fraud_status before payout, separates re-engagement, verifies signatures, and runs the daily reporting-API reconciliation.

Preguntas frecuentes

How do I integrate Singular with an affiliate tracker?

Your network is set up as a partner source in Singular, your seguimiento link carries the aid (publisher), sid (sub-affiliate), and clic_id parameters into Singular's clic endpoint, and Singular forwards attributed installs and mapped in-app events to your tracker's postback URL with the clic ID returned.

What does Singular's fraude_status field mean?

Singular evaluates each attribution against its fraude reglas and stamps the postback with a status — a blocked status means Singular itself rejected the traffic, and your tracker should never convert it. Treat the field as a first-pass verdict and still run your own tracker-side screening behind it.

Por qué are Android advertising IDs missing from my Singular postbacks?

Most likely a field-name mismatch: Singular sends the Android advertising ID as aifa, not gaid. Map both names on the ingestion side. On iOS, idfa is only present where ATT consent was granted.