Click ID vs Transaction ID vs Sub ID
Compare the three identifiers that decide whether KiwiWall postbacks are clean, auditable, and reliable.
Click ID vs Transaction ID vs Sub ID in brief
In affiliate and offerwall tracking, click ID, transaction ID, and sub ID are not interchangeable names — they solve different jobs.
- click ID follows the user’s click event from source to the offerwall.
- transaction ID follows the postback event and proves which click converted.
- sub ID carries your internal context (geo, placement, campaign, creative, user segment).
If your setup is failing in postback reconciliation, do not start by changing payout rates first. Start by making every event carry a stable click ID and transaction ID, then make sub IDs a deliberate segmentation strategy rather than arbitrary metadata. KiwiWall teams usually get stable reporting when they enforce:
- one-click-id-per-click,
- one-transaction-id-per-attempt,
- immutable sub IDs per source/placement,
- strict deduplication before revenue logic.
If all three are clean, your attribution logic becomes auditable instead of guess-based.
Who this is for
This page is for teams that need attribution clarity and operational reliability:
- Publishers who need to understand why two placements with similar click volume can produce different payout quality.
- Advertisers who need to reconcile campaign results across traffic groups, especially under fraud pressure.
- Technical operators managing KiwiWall integrations, postback endpoints, and data pipelines.
- Operations leads who need one shared vocabulary when reporting with finance, support, and campaign teams.
Definition
For KiwiWall tracking, treat these as three layers in one event graph.
Click ID
A click ID is the first stable breadcrumb in the click chain. It identifies one click event generated at the moment traffic enters an offer or placement flow.
Use it for:
- joining raw click logs to offer-level events,
- anti-replay/dedup checks,
- tracing a postback to a specific click stream path.
Transaction ID
A transaction ID is the postback-layer ID that represents a conversion attempt outcome.
Use it for:
- reconciliation between KiwiWall and advertiser records,
- validating whether a conversion was accepted, rejected, retried, or duplicated,
- preventing payout inflation across retry storms.
Sub ID
A sub ID is a structured metadata payload you control.
Use it for:
- cohorting by geography, publisher segment, placement, or campaign,
- filtering traffic quality by source behavior,
- running experiments that separate setup issues from quality issues.
Decision table
Use this as the page-level control matrix.
| Decision use case | Click ID | Transaction ID | Sub ID | Why it matters |
|---|---|---|---|---|
| Publisher wants placement test diagnostics | primary | secondary | primary | Need to compare placement-level conversion path reliability |
| Advertiser wants campaign reconciliation | secondary | primary | primary | Need exact converted outcome + segmentation context |
| Fraud audit request | primary | primary | supporting | Need evidence trail from click to conversion |
| Payout dispute | secondary | primary | secondary | Transaction ledger is the evidence backbone |
| Creative or traffic experiment | primary | secondary | primary | Sub IDs expose test segment behavior fast |
| Long-tail or delayed conversions | primary | primary | primary | Prevent mixed attribution for late postbacks |
How it works in KiwiWall tracking flow
Think of KiwiWall postback plumbing as two checkpoints.
Step 1: click-time capture
- User clicks an offer in the wall.
- KiwiWall integration captures the click event.
- KiwiWall assigns or receives a click ID and forwards this ID with required fields.
- Your implementation appends sub IDs consistently (for example
sub1=subsegment,sub2=placement,sub3=campaign).
If click ID is missing or regenerated incorrectly, every downstream event is harder to prove and dedupe.
Step 2: conversion-time mapping
- Offer network sends conversion outcome to your postback endpoint.
- Conversion payload includes transaction ID (directly or in a mapped field).
- Platform validates transaction-to-click correspondence.
- If valid and unique, status transitions into accepted states; duplicates get dedupe handling.
- Payout calculation and reporting consume the finalized record.
Where people fail is not usually in the math, but in field mismatch:
- click ID captured at click time but never joined with transaction ID later,
- sub IDs omitted because teams focused on one KPI and forgot segmentation,
- retry behavior treated as new conversions because dedupe logic is absent.
At KiwiWall scale, the practical rule is: keep your IDs stable before you optimize anything else.
When this applies and when it does not
Use this page when you are fixing reconciliation accuracy, postback mismatch rates, or segment attribution quality. It is especially useful when teams report:
- a high number of "missing postbacks,"
- payouts disagreeing between platform and internal dashboard,
- strong traffic spikes but weak payout stability.
Do not use this framework for:
- creative optimization when you have no attribution pipeline (you need creative analytics first),
- pure offer selection without postback validation,
- manual campaign review where no one can modify tracking fields or retry policy.
If your immediate need is offer list optimization, build that after you can prove event-level consistency.
Example
A publisher runs two placements with different sub2 values. One placement shows duplicate clicks and transaction IDs that do not map cleanly. After the team forces unique click IDs, preserves transaction IDs through conversion, and keeps sub IDs fixed by placement, payout quality becomes easier to audit.
Common mistakes and fixes
-
Using one sub ID field for everything
- Problem: all cohorts look mixed and unreadable.
- Fix: reserve stable dimensions: geo, placement, and campaign in dedicated fields.
-
Reusing click IDs across multiple events
- Problem: retries or page refreshes appear as duplicate traffic.
- Fix: ensure click generation and storage happen once per unique click event path.
-
Ignoring transaction ID mismatches as "network noise"
- Problem: unresolved postback disputes and payout disputes.
- Fix: log raw transaction payload, transaction status, and received timestamp.
-
Treating sub IDs as optional metadata
- Problem: no operational segmentation when quality degrades.
- Fix: make sub IDs mandatory in integration contract and fail fast if missing.
-
Running payout logic before dedupe logic
- Problem: duplicate conversion bursts can over-credit campaigns.
- Fix: gate payout state changes behind dedupe outcome.
Checklist: ready-to-run postback traceability
- Each click generates exactly one stable click ID.
- Each conversion attempt includes a transaction ID.
- click ID and transaction ID are preserved through redirects and proxies.
- Sub IDs are consistently populated before first launch, not added later.
- Deduplication rejects duplicate transaction events within the expected retry window.
- Rejections and retries are tagged with reason codes and reviewed weekly.
- Parent hub and related cluster pages are linked in onboarding docs and internal runbooks.
FAQ
1) Are click ID and transaction ID the same thing?
No. A click ID is click provenance; a transaction ID is conversion event identity. If they are the same variable, you lose one layer of auditability.
2) Can sub IDs replace transaction IDs?
No. Sub IDs are context only. They are useful for segmentation and analysis, but they do not prove conversion completion by themselves.
3) Do we need both IDs if we use server-side tracking only?
Yes. Even in server-side tracking, one identifier should represent the request source while another represents the conversion event payload. That separation keeps retries recoverable.
4) Which field should support fraud detection?
All three, in different roles: click ID for replay control, transaction ID for conversion verification, sub ID for risk clustering by source quality.
5) Why are postback counts lower than click counts?
That is normal in healthy setups because not every click converts. A sustained low conversion-to-click ratio is a policy/quality signal; a sudden sharp drop is often a broken identifier chain.
6) Can we diagnose without changing payouts?
Yes. Start with logging discipline first. Fix IDs and mapping, then compare reconciliation tables before changing incentive terms.
7) Should we map every campaign to unique sub IDs?
At minimum, map by channel and placement. As traffic grows, expand to offer group and creative dimensions.
Conversion link
If your team is operating in the tracking/fraud stack and needs immediate operational alignment, review the broader framework first:
Then apply this in implementation and route to KiwiWall’s platform team for setup review:
Evidence notes
- Strategy lock source: docs/content-silo-plan.md
- Plan sync status recorded in Obsidian on 2026-06-18 (
plan_revision: 2026-06-18) with no drift detected at sync time. - Keyword evidence used for this page’s search intent:
EVID-KS-20260618-1toEVID-KS-20260618-5in the plan update log.