SOP: Fallback depth — single backup vs multi-tier chain

Step 1 — Map failure modes per offer: paused, capped, geo-rejected, advertiser 5xx. Each needs a catch.
Step 2 — Start with a single house-offer backup. For low-volume campaigns, one safety net is enough — deeper chains add latency for no gain.
Step 3 — Go multi-tier only on high-volume geos:
☐ Tier 1: best EPC offer
☐ Tier 2: second-best, same geo/device
☐ Tier 3: broad house offer that accepts everything
Step 4 — Cap chain depth at 3. Each hop adds latency and a failure point; beyond 3 you're hiding a routing problem.
Step 5 — Alert on fallback rate. If Tier 1 sends >10% to fallback, that's a config or advertiser issue, not normal.

Tradeoff: deep chains maximize fill rate but add latency and obscure root causes.

Review fallback-hit rates daily; re-rank tiers weekly by EPC.

Checklist: Rotation metric — optimize on EPC vs conversion rate

Which number drives your weights? They reward different offers.

Optimize on EPC (earnings per click) when:
☐ Payouts differ across offers in the rotation
☐ You care about revenue per click, not raw conversion count
☐ A 2% CR at $40 beats a 10% CR at $5

Optimize on conversion rate when:
☐ Payouts are equal (same offer, different landers)
☐ You're testing creative/lander, not offer economics
☐ You want fast feedback — CR fires more often than revenue

Step — Use CR for lander tests, EPC for offer selection. Mixing them rewards the wrong thing.
Step — Add a minimum-clicks gate before either metric moves weight (≥100 clicks per arm).

Tradeoff: CR optimizes too early and ignores payout; EPC is correct but slower to stabilize.

Confirm which metric each rotation uses before launch; never switch mid-test.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

SOP: Conversion tracking — inline pixel vs server postback

Step 1 — Identify who confirms the conversion. If the advertiser fires it server-to-server, use postback. If only a browser pixel exists, you're stuck with inline.
Step 2 — Prefer server postback when available.
☐ Survives ad-blockers and ITP — pixels don't
☐ Carries the real payout, not a hardcoded value
☐ Can't be spoofed by the user's browser
Step 3 — Secure the postback. Validate the click_id exists and hasn't already converted (dedup conversions, not just clicks).
Step 4 — Keep inline pixel as a cross-check, not the source of truth. Discrepancy between pixel and postback >5% means tracking is leaking.
Step 5 — Match payout currency and timezone to the advertiser's, or your reconciliation drifts.

Tradeoff: pixels are universal but lossy and spoofable; postbacks are accurate but require advertiser support.

Reconcile postback vs advertiser dashboard weekly.

SOP: Cap reset logic — fixed-time reset vs rolling window

Step 1 — Read the advertiser's cap definition. '500/day' can mean midnight-reset or rolling 24h — they are not the same and over-delivery disputes start here.
Step 2 — Use fixed-time reset (resets at a set hour) when the advertiser bills by calendar day. Match their timezone exactly.
Step 3 — Use rolling window (last 24h count) when you want smooth pacing with no midnight spike — traffic doesn't dump the second the clock flips.
Step 4 — For weekly/monthly caps, always pace daily underneath, or you blow the whole cap in day one and starve the rest of the period.
Step 5 — Store cap counters in a single source (one counter store), not per-server, or a load-balanced setup over-delivers by the number of nodes.

Tradeoff: fixed reset aligns with billing; rolling window paces smoother but is harder to reconcile.

Verify counter timezone and store at every new offer setup.

Checklist: Direct-to-offer vs prelander routing

Direct link (smartlink → offer):
☐ Fastest path, highest click-to-LP rate
☐ Best for warm traffic that already knows the offer
☐ No filtering layer — bots and mismatched users hit the advertiser

Prelander (smartlink → your page → offer):
☐ Adds a filtering and warming step you control
☐ Lets you read client signals before passing the click
☐ Costs conversion rate from the extra hop

Step — Route by traffic temperature inside one smartlink:
☐ Push/pop (cold) → prelander to warm and filter
☐ Search/native (intent) → direct, don't add friction
Step — Measure click-to-conversion end-to-end, not just LP CTR, or a 'good' prelander can hide a worse final number.

Tradeoff: direct maximizes speed; prelander maximizes control and quality at the cost of a hop.

A/B direct vs prelander per traffic source quarterly.

SOP: Repeat-visitor handling — round-robin vs sticky routing

Step 1 — Decide what a returning user should see. Same offer again (sticky) or the next in rotation (round-robin)?
Step 2 — Use sticky routing when:
☐ The offer has a multi-step funnel — sending a returning user to a different offer wastes the warm-up
☐ Attribution needs consistency for the advertiser
Step 3 — Use round-robin / fresh roll when:
☐ Single-action offers where a repeat visitor likely won't convert on the same one
☐ You want to test a second offer on bounce-backs
Step 4 — Implement stickiness with a short-lived cookie or click_id map, expiry matched to the conversion window.
Step 5 — Always have a non-sticky fallback for cookie-less returns, or returning in-app users break the logic.

Tradeoff: sticky preserves funnel continuity; round-robin gives a second shot but breaks attribution.

Review repeat-visitor conversion lift per method monthly.