Wykrywanie oszustw w formularzach leadów: od blokad do inteligentnego filtra
Formularze leadów są atakowane na wielu poziomach — od prostych botów po zlecone zgłoszenia wykonane przez ludzi. Na początku bota parsowały statyczne strony i wypełniały pola. Przejście na dynamiczną generację formularzy w Vue.js tymczasowo przerwało ten przepływ, ukrywając elementy przed parserami.
Spamery dostosowały się, analizując punkty końcowe API i podmieniając nagłówki: User-Agent, rozdzielczość ekranu, ciasteczka. Klasyczne CAPTCHA straciły skuteczność — bota generowały dane w czasie rzeczywistym.
Wdrożenie tokenów JWT powiązanych z sesją użytkownika w połączeniu z weryfikacją serwerową przywróciło kontrolę. Jednak w konkurencyjnych branżach (np. nieruchomość) pojawiły się usługi zleconego wypełniania: za stałą opłatę człowiek przechodzi kwestionariusz i wysyła formularz, co zakłóca metryki konwersji.
Analiza zachowania dla pierwotnej filtracji
Czasowe znaczniki na etapach kwestionariusza pozwalają wykrywać automatyczne przejścia. Jeśli czas odpowiedzi jest poniżej progu (np. <2 sekundy na pytanie), zgłoszenie oznaczane jest jako podejrzane.
Monitorowanie cyfrowego śladu obejmuje:
- sprawdzanie IP pod kątem gwałtownych wzrostów z centrów danych;
- analizę ciasteczek i fingerprintingu (canvas, WebGL, czcionki);
- wykrywanie powtarzających się kontaktów w bazie (próg >3 na sesję).
Te środki odrzucają 80–90% automatycznego spamu, ale zlecenie oszustw obchodzi je poprzez czyszczenie śladów i ręczne przejście.
Nowa paradigma: zarządzanie zamiast blokady
Ścisłe blokowanie prowadzi do adaptacji: spamery zmieniają proxy, czyścić localStorage. Przejście do "miękkiego" filtra zmienia zasady gry.
Zgłoszenie zawsze zostaje potwierdzone, ale kierowane do różnych scenariuszy:
- Pełne ignorowanie: Dane nie są zapisywane ani w CRM, ani w powiadomieniach — zgłoszenie 'wyparowuje'.
- Czarna metka: Zapis w izolowanej bazie do analizy, bez przekazywania do integracji roboczych.
- Przyzwoita konwersja: Przesyłanie do CRM z flagą 'spam', ale bez zdarzeń w analityce (GA4, Yandex Metrika).
Ten podejście dezmotywuje wykonawców: brak odmowy maskuje niską skuteczność, obniżając ROI zleconych ataków.
Realizacja techniczna filtra
Middleware serwerowy w Node.js/Express sprawdza wektor cech:
const fraudScore = calculateFraudScore(req.body, req.headers, sessionData);
if (fraudScore > 0.8) {
routeToBlackhole(req.body); // Scenariusz 1
} else if (fraudScore > 0.5) {
markAsSpamAndLog(req.body); // Scenariusz 2
} else if (fraudScore > 0.3) {
sendToCrmWithFlag(req.body); // Scenariusz 3, bez analityki
} else {
processNormally(req.body);
}
function calculateFraudScore(data, headers, session) {
let score = 0;
score += data.quizTime < 30 ? 0.4 : 0; // Czas kwestionariusza
score += isProxyIP(headers['x-forwarded-for']) ? 0.3 : 0;
score += session.repeatContacts > 2 ? 0.2 : 0;
return score;
}Fingerprinting przez skrypt klienta zbiera entropię: pamięć urządzenia, przesunięcie strefy czasowej, kontekst dźwiękowy. Serwer agreguje dane w Redis do real-time wykrywania klastrów.
Skalowanie i monitorowanie
Dla systemów o wysokim obciążeniu zintegruj modele ML (XGBoost na historii leadów). Szkolenie na zestawie danych z etykietami (spam/legitymne) daje precyzję >95% przy recallu 90%.
Monitorowanie przez Grafana: pulpit z wskaźnikami fraudu i fałszywych pozytywów. Testy A/B na podzbiorze ruchu minimalizują ryzyko.
Co ważne
- Zlecone oszustwa kosztują 10–50 zł/lead, ale zakłócają CPC w reklamach o 20–30%.
- "Miękki" filtr obniża motywację ataków bez szkody dla UX.
- Łącz analizę zachowania z ML dla trwałości.
- Loguj wszystko do analizy po fakcie i doszkolenia modeli.
- Testuj na rzeczywistym ruchu przed wdrożeniem.
— Editorial Team
Brak komentarzy.