← ClaudeAtlas

lead-delivery-reconciliationlisted

Use when leads are delivered to an affiliate network, lead buyer or CRM and you need to know what was actually accepted and paid rather than what was sent - reconciling a delivery log against a network register, computing acceptance rate and effective payout, normalising or deduplicating leads before delivery, handling rejects and resale, or debugging why a daily cap overshot or a delivered lead never appeared in the buyer's system.
Hiberius/lead-delivery-reconciliation · ★ 0 · DevOps & Infrastructure · score 72
Install: claude install-skill Hiberius/lead-delivery-reconciliation
# Lead Delivery Reconciliation ## Overview A lead buyer answering *received* or *waiting to validate* is telling you the payload was well formed. It is not an economic outcome. The outcome arrives hours later, nobody sends it to you, and until you pull their register and match it against what you sent, the day's revenue is a guess. **Core principle: a lead is worth the effective payout, not the contract payout.** ``` effective payout per delivered lead = total revenue / delivered leads ``` At a contract payout of 17 with 62% acceptance, a delivered lead is worth 10.54. Every CPL target built on 17 is wrong by 38%. ## When to use - Reconciling what you delivered against what a network says it did with it - Computing acceptance rate, effective payout, or the real revenue of a day - Normalising or deduplicating leads before delivery - A daily cap overshot and the daily report says it did not - A delivered lead never appeared in the buyer's system, or appeared twice - Deciding what to do with rejects For the campaign economics built on top of these numbers (profit per country, break-even CPL, account triage), use `cpa-profit-ops`. ## The pipeline ``` Meta Lead Ads ──► normalise ──► deduplicate ──► qualify ──► cap ──► deliver │ │ rejects ──► resale queue store your delivery id │