How to Stop Getting Your CPA Shaved: Attribution and Tracking Protection

Your CPA numbers don't add up. The network dashboard shows 40 clicks from a campaign that should have converted at your usual 3-4%, but the broker's report shows one funded account. You didn't lose the traffic — you lost the attribution. Somewhere between the click and the deposit, a cookie expired, a browser blocked a script, or a network's tracking link quietly dropped your sub-ID. This is commonly called getting your CPA shaved — commissions you earned but never get credited for, whether through technical attribution failure or, less often, deliberate reporting manipulation on the other side of the deal.

For a performance affiliate, attribution accuracy is the entire business model. A rebate IB or Master IB can survive imperfect tracking because volume-based revenue share smooths out individual misses. A CPA marketer cannot: every unattributed conversion is 100% lost revenue on that lead, not a smaller share of it. This article explains why shaving happens, how to build a tracking setup that resists it, and how to tell an honest tracking gap from an actual dispute worth escalating.

Why CPA Attribution Breaks in the First Place

Attribution is the process of connecting a conversion (a funded trading account, in most broker deals) back to the click, ad, or sub-ID that produced it. It fails for three broad reasons, and only one of them is misconduct.

Browser-side tracking prevention. Safari's Intelligent Tracking Prevention (ITP) and Firefox's Enhanced Tracking Protection restrict how long first-party cookies set via JavaScript persist — Safari has enforced a 7-day cap on JS-set cookies for years, meaning a prospect who clicks your link and opens a live account nine days later shows up as "direct" traffic to the broker, not yours. This is not a broker plot. It is browser vendor policy that affects every affiliate program, forex or otherwise.

Multi-device and multi-session journeys. A trader researches a broker on mobile, closes the tab, and signs up on desktop two days later from a bookmark or a Google search for the broker's name. A pure cookie system with no persistent identifier has nothing to attribute that account to, even though your content originated the interest.

Network or broker-side shaving. Less common, more serious: a network or broker deliberately mis-reports conversions, delays sending postbacks past your cookie duration window, or applies undisclosed "quality" adjustments that quietly zero out a share of your leads. This is the scenario the term "shaved" describes most precisely, and it is a due-diligence problem, not a tracking-configuration problem.

Cookie Tracking vs Server-to-Server: Know What You're Running

The single highest-leverage fix is moving your primary attribution model off client-side cookies and onto server-to-server tracking (S2S), also called postback tracking.

S2S works because the conversion report never depends on the visitor's browser at all. When the broker's server confirms a funded account, it calls your postback URL directly with the sub-ID you passed at click time. There is no cookie to expire and no ad blocker in the path.

Building an Attribution Setup That Survives Shaving

A resilient setup has three layers, and each one closes a different failure mode.

1. Own your tracking platform. Run clicks through your own tracker (or your network's) so you generate the sub-ID and can independently log every click before it ever reaches the broker. This gives you a source-of-truth click log the broker cannot dispute.
2. Insist on S2S postbacks, not pixels. Ask explicitly during onboarding whether the program supports server-to-server postbacks with a pass-through parameter for your sub-ID. If a Master IB or network sits between you and the broker, confirm the sub-ID survives that hop unmodified — this is the single most common place tracking silently breaks in multi-tier setups.
3. Extend your cookie window as a backstop, not a primary method. A longer cookie duration (30-90 days is common in broker programs) still helps catch same-device, same-browser conversions that happen before S2S is confirmed working, but it should never be your only mechanism.

Reconciling Your Numbers: The Weekly Habit That Catches Shaving Early

Set a standing weekly reconciliation between three numbers: your own click log, the network's reported conversions, and (where available) the broker's own dashboard if you have direct access. A gap between your click log and the network's numbers, with no corresponding gap between the network and the broker, usually points to a tracking configuration issue on your end. A gap between the network's numbers and what the broker itself confirms is the pattern worth escalating.

Before you assume you're being shaved, rule out the ordinary causes:

• Click-to-conversion lag. Forex account funding can take days after initial signup (KYC, deposit method, first-time wire delays). Don't compare this week's clicks to this week's conversions — compare a cohort of clicks against conversions over the following 30-45 days.
• Sub-ID truncation or overwrite. Some tracking platforms truncate long sub-IDs or strip special characters; test your exact sub-ID format end-to-end before scaling any campaign to it, a step covered in more depth in how to test a broker offer before you scale traffic to it.
• Traffic quality rejection. A broker's compliance team can legitimately reject accounts that fail KYC, use VPNs to fake a geo, or show bot-like signup patterns. This is not shaving — it's a quality filter, and a program with zero rejected leads is itself a red flag worth questioning.

What Real Shaving Looks Like — and How to Respond

Genuine, deliberate under-reporting has a recognizable signature: it is consistent (the same rough percentage disappears every cycle), it correlates with your best-performing sub-IDs specifically, and it survives you fixing every technical variable on your end. If you've confirmed S2S is firing correctly, your sub-IDs pass through cleanly, and the gap between your click log and the broker's confirmed conversions is still consistent month over month, escalate methodically:

1. Document before you accuse. Export your independent click log with timestamps and sub-IDs for the disputed period.
2. Request the broker's raw conversion log, not a summary dashboard, for the same window.
3. Escalate through your account manager first, in writing, with the discrepancy quantified in numbers, not accusations.
4. If unresolved, treat it as a due-diligence finding and weigh it against the rest of the relationship — the same way you'd evaluate any other item on an IB due-diligence checklist.

Where Tracking Fits Into Your Broader Partner Evaluation

Attribution reliability should be a scored criterion the same way payout terms and EPC are, not an afterthought you discover after you've already scaled a campaign. When you're evaluating a new broker offer, check for S2S support, ask how sub-IDs pass through any intermediary network, and confirm cookie duration in writing before committing meaningful spend — the fuller framework for weighing a broker's offer end-to-end is in the performance affiliate's guide to picking a converting broker offer.

If you're comparing multiple CPA network relationships against direct broker deals, tracking control is one of the clearest differentiators — a direct integration typically gives you cleaner S2S access than a multi-tier network pass-through, a tradeoff explored further in affiliate networks vs direct broker deals.

To research a broker's or network's tracking reputation before you commit, Revenika's partner glossary is a good starting point for understanding the terminology and mechanics you'll be evaluating — from conversion tracking basics to how marketing attribution models differ across programs.

Frequently Asked Questions

Is "CPA shaving" always intentional fraud?

No. Most attribution loss traces back to browser cookie restrictions (Safari ITP, Firefox ETP), cross-device journeys, or misconfigured sub-IDs — technical gaps, not malice. Genuine deliberate under-reporting is real but less common, and it has a recognizable pattern: consistent, unexplained, and unresolved after you've fixed everything on your end. The Federal Trade Commission and equivalent bodies elsewhere treat deceptive affiliate reporting as a consumer-protection issue when it's proven, but proving it requires the reconciliation process above, not assumption.

How long should I keep my tracking cookie active?

Broker programs commonly run 30-90 day cookie windows, which is reasonable for forex given signup-to-funding lag. Cookie duration should be treated as a backstop alongside S2S, not your primary mechanism, since browser-side restrictions cap how long a JavaScript-set cookie actually survives regardless of what the program advertises.

Does server-to-server tracking cost anything extra to set up?

Most tracking platforms (Voluum, Binom, RedTrack, and similar) support postback URLs at no extra cost beyond your existing subscription. The setup cost is mainly time: correctly mapping the broker's or network's postback parameters to your platform's sub-ID field, and testing end-to-end with a real conversion before you scale.

What if the network insists the broker's numbers are correct and mine are wrong?

Ask for the raw event-level log from the broker directly, not a summary. A summary dashboard can mask individual dropped conversions; a raw log with timestamps and sub-IDs lets you match record-for-record against your own click log and identify exactly where the discrepancy occurs.

Should I stop sending traffic while a dispute is unresolved?

Pause new spend to that specific offer, but don't necessarily end the relationship on a first discrepancy — cookie-related gaps are common enough that a single unreconciled cycle isn't proof of anything. Resume once you've confirmed the technical cause, or treat a second unresolved cycle as a serious warning sign.

Conclusion

Getting shaved feels like a broker or network problem, but in most cases it's a tracking-architecture problem you can fix yourself: move to server-to-server postbacks as your primary attribution method, keep an independent click log, and reconcile the numbers weekly rather than after you've already scaled. When you've closed every technical gap and a discrepancy still persists — consistent, unexplained, and concentrated in your best-performing traffic — you have the documentation to escalate it as what it actually is, and to walk away from a partner who won't reconcile in good faith.