URLTO GUIDE
Clicks but no revenue? Reconcile traffic, orders and settlement
Establish which records exist before estimating earnings from clicks. Every campaign, count and commission in this guide is invented. Adapt the worksheet to the actual partner’s status names and settlement terms.
URLTO editorial · Updated
1. Align four dimensions first
Do not attribute an order to this campaign when the order report provides no campaign evidence. Label it as total orders in the same period instead. Confirm attribution windows and timestamps with the program, and do not compare immature cohorts as finalized outcomes.
| Dimension | Example entry | Problem if missing |
|---|---|---|
| Observation interval | 2026-10-01 00:00 ≤ t < 2026-10-08 00:00 Asia/Seoul | Different day boundaries make comparison misleading |
| Traffic cohort | campaign=event_tools_202610 / placement=top_button | Acquisition and order-date groups get mixed |
| Report extraction date | 2026-10-16 | Later approvals and refunds change the results |
| Metric definition | Requests / sessions / action events / transaction status | Unlike units become a misleading conversion rate |
2. A worked campaign ledger
The difference 1,200 − 800 is not 400 people lost. Requests and sessions use different definitions without a shared identity. Likewise, 120 button events need not mean 120 people. Do not invent a request-to-purchase conversion rate without a defensible connection between the populations.
| Ledger | Invented value | Meaning |
|---|---|---|
| URLTO redirect requests | 1,200 | Can include repeats, previews and tests |
| Destination analytics sessions | 800 | Under the destination system’s definition |
| Seller-button events | 120 | Repeatable events, not necessarily people |
| Settlement-report transactions | 10 | Only campaign-attributed records in this example |
| Approved / pending / rejected | 7 / 2 / 1 | Mutually exclusive extraction-date states total 10 |
3. Separate approved commission from cash received
Assume KRW 3,000 per approved transaction and seven approvals: approved commission is KRW 21,000. Do not add the two pending transactions. If KRW 15,000 has been received, KRW 6,000 of approved commission remains unpaid. Keep differing currencies, exchange rates and deductions separate.
Compare it yourself · Illustrative example
Illustrative state equations 10 transactions = 7 approved + 2 pending + 1 rejected Approved commission = 7 × KRW 3,000 = KRW 21,000 Approved but unpaid = 21,000 − 15,000 = KRW 6,000 Do not add pending, approved and paid as separate revenue
4. Reconcile the same example with costs
The cash example assumes acquisition and tool costs were paid and no other cash moved; time cost is not a cash payment. These are internal comparisons before tax and other costs, not a determination of accounting profit or taxable amounts. Document allocation of shared tools and avoid charging the same cost in full to several campaigns.
| Item | Invented amount |
|---|---|
| Approved commission | 21,000 KRW |
| Acquisition cost | 12,000 KRW |
| Allocated tool cost | 3,000 KRW |
| Assumed time cost | 6,000 KRW |
| Contribution before time cost | 21,000 − 12,000 − 3,000 = 6,000 KRW |
| After assumed time cost | 6,000 − 6,000 = 0 KRW |
| Simplified cash movement | 15,000 − 12,000 − 3,000 = 0 KRW |
5. Diagnose the last observed stage
A difference alone does not establish a broken link or missing partner credit. These are investigation steps. URLTO does not automatically collect or prove purchases, partner approvals or settlement. Mark missing evidence as unobserved and establish collection for that stage first.
| Observation | First check | Next action |
|---|---|---|
| Requests, no sessions | Final URL, analytics collection, labels and interval | Reproduce arrival from the published button |
| Sessions, no actions | Button behavior, event collection and offer fit | Verify behavior, then review the explanation |
| Actions, no transactions | Official identifiers, permitted source, attribution and reporting lag | Check the program’s own records and conditions |
| Transactions, no approvals | Pending period, cancellations and exclusions | Record immature and rejected states separately |
| Approvals, no receipts | Payment date, threshold, deductions and receipts | Reconcile due dates with actual receipts |
6. A weekly reconciliation template
A public distribution register needs campaign, placement, public code and page version only. Keep order identifiers, personal information and private statistics or management keys out of public documents. Reconcile transaction details in an access-controlled ledger using only necessary fields.
Compare it yourself · Illustrative example
Interval / time zone / extraction date / attribution conditions Campaign / placement / public code / page version Requests R / sessions V / actions O / transactions N Approved / pending / rejected / unobserved fields Approved amount / cash received / approved but unpaid Acquisition / allocated tools / time / other costs Revisions, refunds and payment adjustments / evidence / next check date
7. Choose one change for the next review
Verify collection before judging a conversion experiment. Then change one of placement, explanation or offer and record the change time, cost cap and review date. Compare cohorts at similar maturity when approvals are pending. Small-sample differences do not establish cause or guarantee earnings.
For later refunds or approval reversals, revise transaction states and amounts with dated adjustments. Check that an order has not been duplicated as both new revenue and a cancellation. Retain earlier extracts as comparison evidence.