Lead review: statuses, deadlines and disputed decisions
Build an advertiser lead-review process with owners, deadlines, evidence, rejection reasons and appeals. Worked examples and a practical readiness checklist.
A lead can arrive on time and still spend weeks without an understandable decision. The publisher sees a waiting status, the advertiser sees a queue, and the operator searches conversations instead of checking an event. Start by agreeing who reviews each lead, against which conditions, by what deadline and with what explanation.
This guide helps advertisers and operations teams organise the review of leads already received. Apply it to permitted products after checking relevant regional requirements. All deadlines, codes and figures below are educational examples, not AffiliateCore terms. The example concerns an ordinary digital service and does not establish that such an offer is available in the marketplace.
1. Define what the decision means
Separate whether an event happened, whether it meets agreed conditions and whether financial settlement is complete. Receiving a postback establishes receipt of a message; it does not by itself establish lead quality. A confirmed conversion does not necessarily mean money is available for withdrawal: holds and financial operations are separate.
Before launch, document the event, required attributes, permitted sources, repeat-enquiry rules, observation window and terms version. For an illustrative software demonstration request, the event could be a submitted form specifying a product. A purchase within a month cannot silently become an additional acceptance condition after traffic has arrived. If payment depends on a different event, define that in advance.
Produce a one-page rule sheet with an effective date and retain its previous version. A disputed lead must be reviewed under the conditions that applied to it. Agree changes for future events rather than using them to reduce previously accepted results.
2. Assign responsibility at every stage
Someone receives the queue, a technical owner checks evidence when needed, and an authorised operator records the outcome. A small team may combine roles, but a dispute should ideally go to someone other than the original decision maker. Name a holiday replacement and an escalation contact.
Educational workflow: received → identified → conditions checked → reasoned decision → notification → reconsideration when new evidence arrives. Missing information creates an evidence request with an owner and deadline. This is a team workflow, not a diagram of built-in AffiliateCore automation.
After preparing the rules, register as an AffiliateCore advertiser, provide required information and use the rules when preparing your own offer. Registration alone does not establish product eligibility or launch readiness.
3. Map working stages to visible statuses
The verified AffiliateCore advertiser conversion list provides viewing, a status filter, event type, external identifier, event amount and currency, advertiser charge, rejection reason, offer and event time. It does not give advertisers unrestricted editing or deletion through this list.
| Listed status | Operational question |
|---|---|
| pending | Who owns the review and when is a decision expected? |
| confirmed | Which condition was confirmed? Check holds and settlement separately. |
| rejected | Which rule failed, and where is the evidence? |
| reversed | Why was an earlier result reversed? Distinguish this from an initial rejection. |
| disputed | What is disputed and who is reviewing it? |
A disputed label does not establish an automated appeal submission, countdown or dedicated dispute workspace. A complete participant-facing appeals workflow was not confirmed during verification. Keep the proposed case register and deadlines in your agreed work tool, and let the authorised party change system statuses. Do not promise a partner a button that is unavailable.
4. Give deadlines a starting point
“Reviewed quickly” is vague. “Initial triage by the next working day after receipt; missing information triggers a specific request and a new date” is actionable. An educational pilot could allow two working days for an ordinary decision and another day to escalate an overdue item. Agree actual values against workload, holidays, region and when the target event can be observed.
Record event time, receipt time and decision deadline separately. State the time zone in the process and include its offset when exchanging timestamps. A delayed event is not automatically a publisher breach: first establish why delivery was late and which rule applies.
Waiting for evidence must not silently reset the lead’s age. Keep the original deadline, extension reason, owner and revised date. Expiry means escalation, not automatic rejection or credit unless that mechanism has actually been agreed and implemented.
5. Keep sufficient, limited evidence
A review needs the source event ID, platform conversion ID where available, click association, offer, time, applicable rule version and a reference to supporting evidence. A user ID cannot replace an event ID: one person may perform several permissible actions.
In the decision register, record previous and new status, reviewer, date, reason and link to the earlier decision. Repeated delivery of one message is not a new lead. A shared IP or similar address alone also does not prove duplication or fraud. Check event identity against the agreed conditions.
Do not send partners passwords, postback secrets, full identity documents or unnecessary visitor contact details. Use restricted access or a redacted extract sufficient to understand the reason. OWASP Logging Cheat Sheet provides general logging and protection guidance; the lead-review process here is our practical editorial template.
6. Separate rejection reasons from evidence requests
These educational codes replace an unexplained “poor traffic” label. They are not a built-in AffiliateCore dictionary.
EVENT_DUPLICATE — The same event was recorded again. Supporting material: Original event reference and matching criterion.
TERMS_MISMATCH — A specific applicable condition was not met. Supporting material: Terms clause, version and verifiable fact.
EVENT_NOT_MET — The agreed target action was not completed. Supporting material: Source state at the end of the observation window.
NEEDS_EVIDENCE — Information is insufficient for a decision. Supporting material: Exact request, recipient and response deadline.
The last row is a work item, not a final rejection reason. Fraud signals also need interpretation. If your own system outage makes evidence unavailable, record an incident and a review date. Do not turn uncertainty into an accusation against a partner.
7. Worked example: an honest queue report
An illustrative digital service received 100 unique leads in a week after repeated deliveries were removed. At the reporting time, 60 are confirmed, 20 rejected on verified grounds and 20 awaiting a decision. There are 80 completed reviews. Confirmation among decided leads is 60 / 80 = 75%; confirmation among all received leads is 60 / 100 = 60%. Label the denominator because these measure different things.
Eight of the 20 pending leads are overdue. The overdue share of the open queue is 8 / 20 = 40%. Do not relabel pending items as rejections to close a report. Assign owners to the eight overdue records, then inspect the age and waiting reasons of the others.
If 12 of the 20 rejections are described as repeated messages, revisit the cohort definition. Our starting count already excluded repeated deliveries, so that explanation would require correcting the input data. Arithmetic must match the unit being counted, not merely add up to 100.
Exercise: prepare this table for your offer without personal data. In the advertiser account, compare it with available conversion statuses and send a separate discrepancy list to the responsible operator. Never create fictitious payable events to test a spreadsheet.
8. Worked example: reconsider a disputed decision
Lead L-041 was rejected as a duplicate of L-019. The partner supplies two different event IDs. The reviewer retrieves the applicable terms: a repeat enquiry is permitted only for a different product. They then compare product and time in the source. A different identifier alone does not prove the partner right; the same IP does not prove the rejection right.
If a distinct eligible event is verified, the authorised party corrects the outcome through the supported process. Preserve the original decision, new evidence, reconsideration time and reason. Verify the financial effect separately. Replaying a postback must not be used to “add the missing credit”.
If the decision stands, answer with the actual rule and fact rather than just “rejected”. If evidence is still missing, state the next action and date. Closing a case solely because an internal deadline expired is no substitute for a reasoned decision.
9. Measure review operations
Weekly, inspect the open queue at a stated snapshot time, overdue count, median and 90th percentile time to first decision, share of decisions with reasons and reconsideration outcomes. Calculate decision time for completed records and separately show the age of open items. Otherwise long unresolved cases disappear from the speed metric.
Calculate overturned decisions among resolved appeals, not among every lead. Three reconsiderations are too little evidence for a strong conclusion about a source. Compare consistent periods, terms versions and sufficiently mature cohorts. More rejections may reflect an event-definition change or processing error; investigate before judging traffic.
10. Readiness and next action
Before the pilot, check the event definition and terms version; queue owner and backup; deadline starting point; evidence for reasons; distinction between clarification and rejection; dispute owner; preserved decision history; and separate reporting of open and decided leads.
Run a tabletop review of three educational records: an ordinary lead, a repeated message and a dispute with new evidence. Readiness means a reviewer can identify the rule, next step, owner and deadline for each. If not, clarify the process before launch instead of adding arbitrary statuses.
Use our guides to packaging an understandable offer and report discrepancies. The outcome here is a reproducible decision for each lead, not attribution setup or a promised acceptance rate.
Register as an AffiliateCore advertiser, complete required information and prepare your own offer with agreed review conditions. Eligibility, required checks and moderation remain separate steps; creating an offer does not guarantee launch or traffic. Retain the process with your team and confirm the available platform communication procedure before the first test.