Q: I'm getting paid for conversions I don't think I drove. Should I worry?

A: Yes — quietly. If a traffic source is stuffing your click logs, you may be receiving conversions stolen from other channels through click flooding (firing huge volumes of low-quality clicks so the last one wins last-click attribution). When the advertiser audits, the clawback lands on you.

The tells you're missing:

— Your click-to-install or click-to-conversion time is implausibly short OR suspiciously long-tail, suggesting clicks were sprayed to catch organic conversions.
— One sub-source sends enormous click volume with a near-zero conversion rate, then suddenly 'converts' on big actions.
— Your conversions cluster right after app-store or organic spikes you didn't cause.

Fix: segment by sub-source and look at the click-to-conversion time distribution. Healthy traffic has a sane curve; flooding shows a spike at the very short end. Cut the sub-source before the advertiser does it for you and reverses your payouts.

Short version: free conversions can be hijacked attribution. Watch click-to-conversion timing per sub-source.

Still stuck? Drop your case in the comments.

Q: My quality is fine but the offer keeps rejecting me. The reason just says 'low quality'. What does that actually mean?

A: 'Low quality' is a bucket, and the mistake is treating it as one problem. Ask for the breakdown — networks usually have sub-reasons behind that label.

What hides under 'low quality':

— Incentivized traffic on a non-incent offer. You rewarded users to sign up, they have no intent, and post-conversion metrics (deposit, retention, second action) collapse.
— Short session time or one-page bounces after the conversion event.
— A geo or device split that technically passes but underperforms the offer's KPI.
— High refund or chargeback rate downstream, which the advertiser feeds back as quality.

Fix: ask the advertiser for the actual KPI behind the offer — is it deposit rate, day-7 retention, approved sales? Then measure YOUR traffic against that exact metric, not against raw conversions. Optimize the downstream number, not the click.

Short version: 'low quality' is a downstream KPI you're not measuring. Get the real metric, optimize for it.

Still stuck? Drop your case in the comments.

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

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

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

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

Q: I set my fraud-score block at the recommended level and now I'm killing good traffic. What's the mistake?

A: Treating a fraud score as a hard yes/no instead of a probability. A score of, say, 75 doesn't mean 'fraud' — it means 'riskier than average for this provider's model'. Block everything above an arbitrary line and you cut honest users who happen to share risk signals.

Where people overcut:

— You block the whole high range instead of routing it. Mobile, prepaid-card, and traveling users often score high without being fraudulent.
— You use the provider's default threshold without calibrating it against YOUR own conversion data.
— You block on a single score instead of combining it with behavior (did they actually convert and stick?).

Fix: pull a month of traffic, sort by fraud score, and look at real downstream value per score band. You'll usually find the line where value drops off — and it's rarely the default. Route the gray middle to extra verification instead of an outright block.

Short version: a fraud score is a dial, not a switch. Calibrate the threshold against your own outcomes.

Still stuck? Drop your case in the comments.

Q: A huge chunk of my call-center leads come back as 'no answer' and get rejected. Is that fraud on my end?

A: Usually not fraud — usually a timing and data-quality mistake. 'No answer' (the lead never picked up for verification) eats your approval rate, and most of it is fixable upstream.

The common causes:

— Your phone field accepts garbage — wrong length, missing country code, obvious filler like 1234567890. Validate format at the form.
— You're sending leads in a timezone where the call center rings them at 3 a.m. local. Match send time to the lead's local daylight hours.
— Long delay between sign-up and the verification call, so user intent has gone cold by the time the phone rings.
— You promised something on the landing page the call agent can't deliver, so users dodge the call.

Fix: validate phone format and country code at capture, pass the lead's timezone, and shorten the gap between opt-in and call. Cold leads don't answer.

Short version: 'no answer' is mostly bad numbers, bad timing, and cold leads. Validate, localize, and call fast.

Still stuck? Drop your case in the comments.

Q: We keep every lead's full data forever 'just in case'. Our DPO is panicking. Why?

A: Because GDPR has a storage-limitation principle: you may keep personal data only as long as you need it for the stated purpose. 'Forever, just in case' is the exact thing it forbids, and it turns every old record into liability.

The mistakes hiding here:

— No retention schedule, so rejected and expired leads pile up with names, emails, and IPs indefinitely.
— You keep raw IP and device data long after the fraud-check window that justified collecting it.
— You can't honor a deletion request because the same record is copied across five tools with no map.

Fix: set a retention period per data type tied to its purpose (a fraud-check IP might live 90 days; an active customer record longer). Auto-delete or anonymize past that. Keep a data map so a deletion request actually reaches every copy.

Short version: keeping everything forever violates storage limitation. Set per-purpose retention and delete on schedule.

Still stuck? Drop your case in the comments.