Cash on delivery makes a familiar marketing funnel harder to read. A submitted order may still need to be confirmed, shipped, delivered, collected, approved, and made payable. Each event belongs to a different part of the journey, and the affiliate may not receive every status update. If a dashboard labels all submitted forms as conversions, it can reward activity that never becomes commission. If a late or missing postback looks like a failed order, it can make a working campaign appear broken.
The solution is a measurement system built around explicit handoffs. Define the customer journey separately from the network’s commission statuses, preserve the event details you are allowed to receive, and judge comparable groups only after they have had time to mature.
One campaign, two connected funnels
Start by drawing two lists of states. The first tracks the customer and parcel: order submitted, contacted, confirmed, dispatched, delivery attempted, delivered, collected, refused, returned, or rescheduled. The exact states depend on the offer’s actual process. The second tracks the affiliate’s relationship with the network: click recorded, lead received, status confirmed or rejected, commission approved, payable, and paid. A contract or account dashboard may use different words or collapse several steps into one.
These lists overlap, but they are not interchangeable. “Delivered” describes a logistics event. “Approved” describes a network or advertiser decision. “Payable” describes a financial state under the current terms. An affiliate should not infer one from another unless the system explicitly maps and reports it.
Define the event before choosing the metric
For each event, record the name used by the source system, what it means, who records it, when it becomes final, and how it can later change. Add the identifier that connects it to the original click or order, the reporting time zone, and the source of truth. If a field is unavailable, say so. Do not silently substitute an earlier event.
A compact event contract can include:
- Event: exact status name from the current offer, network, or tracker.
- Meaning: the action or decision that has actually occurred.
- Owner and source: advertiser, carrier, call center, network, or tracker.
- Identifier: approved click or order key used to reconcile the event.
- Timing: event timestamp, time zone, and expected delay.
- Revision rule: whether the event can be rejected, reversed, corrected, or duplicated.
- Payable rule: the status that qualifies for commission under current terms.
The public DR.CASH terms document describes remuneration according to offer parameters, account statistics, and confirmed applications; it also assigns the network statistics system a role in recording performance. The accessible PDF is labeled version 22.06, so it is a dated reference. Verify the current account and offer terms, and use the live status definitions instead of assuming that the public document describes every present workflow. (DR.CASH Terms of Service).
Calculate transition rates from a comparable cohort
Choose a denominator that matches the question. Order-to-confirmation is confirmed orders divided by submitted orders. Delivery-to-collection is collected orders divided by delivered orders, if both events are reported reliably. Click-to-order is submitted orders divided by tracked clicks. Label each rate with its numerator, denominator, date range, and cohort rule. A percentage without those details cannot tell a reader which handoff it describes.
Consider this entirely hypothetical, fully matured group: 1,000 tracked clicks, 100 submitted orders, 72 confirmed, 50 dispatched, 32 delivered, 27 collected, 23 approved, and 20 payable. The 10% click-to-order rate does not reveal whether the remaining loss occurs during confirmation, delivery, collection, or approval. Counts by status help locate the question, but they do not prove its cause. The small example is a teaching illustration, not a benchmark or DR.CASH result.
Maturity matters. If the click cohort began yesterday, many orders may still be awaiting contact or delivery. Comparing those orders with a month-old cohort confuses delay with loss. Use the same cohort definition and comparable time to outcome; keep unresolved statuses visible rather than treating them as zero or as confirmed failures.
Diagnose the handoff before changing the ad
A weak transition can come from tracking, operations, the offer, or the message. Check the event path in that order before assuming the creative caused it.
- From a click to an order: check landing-page availability, redirects, order-form errors, click-ID preservation, and offer fit. The rate cannot prove that the audience is inherently low quality.
- From an order to confirmation: check contact coverage, valid details, order expectations, call timing, and duplicate submissions. The rate cannot show that the ad promise caused every unconfirmed order.
- From confirmation to delivery: check GEO coverage, stock, carrier handoff, address quality, and delivery-attempt timing. The rate cannot show whether the customer changed their mind.
- From delivery to collection: check amount due, delivery communication, rescheduling, refusal or return codes, and cash-collection reporting. The rate cannot isolate product or creative as the cause.
- Reconciling the network record with the tracker: check identifier and status mapping, postback logs, timing, retries, and duplicates. Missing tracker data does not prove the network has no record.
- From approval to an amount available for payment: check payout threshold, reversals, account terms, reconciliation, and settlement dates. Approval alone cannot tell you when funds reach the affiliate’s bank.
This sequence avoids a costly reflex: replacing a headline when the actual defect is a dropped identifier, a delayed status update, an unavailable delivery route, or a mismatch in the order process. When a message or page may be responsible, compare its exact version with the customer’s expectation and the downstream outcome. Record operational and creative changes separately.

Make the postback a traceable event, not a magic fix
A postback can carry a later status from a network into a tracker or another permitted system. DR.CASH’s public advertiser description says it uses API lead transfer and postback technology to update CRM statuses. Its public publisher tutorial on API lead submission is dated June 9, 2023. These sources show examples of the integration pattern, not a guaranteed current endpoint or field schema for every affiliate offer. Confirm the current setup, required parameters, and status meanings in the account or with the network before configuring a live flow. (DR.CASH advertiser integration overview; DR.CASH API lead guide, dated June 9, 2023.)
Test the whole chain with a permitted test event: click identifier captured, order or lead accepted by the right endpoint, later status mapped to the same identifier, event visible in the tracker, and duplicate or corrected messages handled as intended. Keep a reconciliation log with sent time, response, event ID, mapped status, and any retry. A successful HTTP response only shows that a receiver acknowledged a request; it does not prove that the event has the right campaign attribution or final commission value.
Keep identifiers stable across redirects, and verify that a later status does not create a new click or a second conversion. Do not send customer details that are not required and authorized for that integration. Follow the network’s terms, the ad platform’s current requirements, and the applicable privacy rules for the data you handle.
Google Ads illustrates why integrations need platform-specific checks. Its documentation for offline conversions requires a connected data source for the setup to function and provides separate diagnostics for import errors and data quality. Those are Google Ads requirements; affiliate postbacks use the event definitions agreed by the network and tracker. If Google Ads is one of your traffic sources, follow its current import route and diagnostic guidance; do not assume a tracker’s generic “conversion sent” status means Google recorded or attributed it. (Google Ads offline conversion setup; offline data diagnostics).

Feed decisions with evidence the system can support
A tracker can only optimize toward the events it receives correctly and is allowed to use. Label early events, such as clicks or submitted orders, as early indicators. Label confirmed, collected, approved, or payable events according to the real source and offer rules. If those later events cannot be forwarded to an ad platform, use them in reporting and decisions where permitted, but do not imply that the platform’s automated bidding used them.
In the weekly review, show raw counts beside rates, cohort start and end dates, age since click, unresolved share, status lag, and total spend. Report the payout event and any reversals separately. If sample sizes are small, say so and avoid treating a small percentage movement as a stable diagnosis. A mature cohort with transparent limits can guide the next test; an immature dashboard snapshot cannot establish profitability.
Set pause conditions in advance. Stop or investigate if click identifiers disappear, status mapping changes, the offer’s traffic conditions no longer match the campaign, or customer-facing delivery promises cannot be met. Scale only after the payable event, cost, and pending exposure are understood well enough for the decision. The point is not to collect the largest possible status list. It is to know what each status proves and what it leaves unanswered.


