Opracowanie zautomatyzowanego mostu: FB Instant Forms → CRM → Kameleo API → Broker API

Istota zadania:

Konieczne jest wdrożenie systemu „żywej” rejestracji leadów. Skrypt powinien przechwytywać leady z Facebooka (Lead Ads), tworzyć je w naszym CRM i przeprowadzać pełną symulację rejestracji na stronie docelowej za pomocą przeglądarki antydetekcyjnej Kameleo (Playwright) lub analogicznej, aby stworzyć unikalny i spójny cyfrowy ślad, który przejdzie weryfikację zaawansowanych systemów antyfraudowych.

Proces techniczny:

1. FB Lead Ads API

• Odbieranie leada z różnych Form_ID przez Webhooks / Graph API.
• Dla każdego ID formularza w konfiguracji skryptu powinien być przypisany odpowiedni oferta i GEO.

2. Zarządzanie proxy i tworzenie unikalnej sesji

• Przydzielanie IP: Skrypt powinien zwrócić się do API dostawcy proxy w celu zarezerwowania unikalnego adresu IP rezydencyjnego lub mobilnego w odpowiednim GEO dla bieżącego leada.
• Sesja Kameleo & Unikalny odcisk palca: Używając tego zarezerwowanego IP, skrypt uruchamia profil iOS przez API Kameleo.
• Krytyczna randomizacja: Każdy profil powinien używać realistycznych i unikalnych parametrów urządzenia (CPU, pamięć, rozdzielczość ekranu, pamięć urządzenia), odpowiadających rzeczywiście istniejącym modelom iPhone'a. Powtarzanie wzorców jest niedopuszczalne.
• Aktywacja spoofingu: Należy wymusić aktywację funkcji inteligentnego spoofingu (Intelligent Canvas/WebGL Spoofing) przez API Kameleo, aby zapewnić spójny i realistyczny cyfrowy odcisk przez całą sesję.
• Aktualne modele: Parametry urządzenia (CPU, pamięć, rozdzielczość ekranu, pamięć urządzenia) powinny odpowiadać rzeczywiście istniejącym modelom iPhone'a nie starszym niż seria iPhone 14 (iPhone 14, 14 Plus, 14 Pro, 14 Pro Max i nowsze). Użycie powtarzających się wzorców jest niedopuszczalne.
• iOS: Tylko wersje 17.x i 18.x (wydane do 2026 roku). Użycie iOS 15/16 na nowych modelach iPhone'a wygląda jak manipulacja.
• Przeglądarki: Wersja Chrome/Safari nie powinna być starsza niż dwa ostatnie wydania od bieżącej daty (sprawdzać przez Chromium Dash).

3. Walidacja sesji

• Sprawdzenie utworzonej sesji na Pixelscan lub analogicznym (np. browserleaks.com).
• Status powinien być Consistent (Spójny).
• Krytycznie ważne jest, aby upewnić się, że dwa kolejno przyjęte leady mają różne, a jednocześnie spójne odciski Canvas i WebGL i wyglądają jak natywny odcisk zgłoszonego urządzenia iOS.

4. Rejestracja (Emulacja dotykowa)

• Skrypt przez Playwright emuluje „rozgrzewanie” i wejście na stronę docelową w ramach już uruchomionej sesji z przydzielonym IP.
• Emulacja działań: Skrypt wprowadza dane do formularza strony docelowej, klika „Zarejestruj się” (wyłącznie przez touchscreen.tap w celu symulacji dotykowego wprowadzenia na iOS).
• Ważne wymaganie dotyczące User-Agent i Fingerprintingu: Ponieważ nasz CRM analizuje parametry dokładnie w momencie przejścia przez link autologowania (a nie w momencie przesyłania leada przez API), niezwykle ważne jest, aby:
• Przejście przez maskującą link CRM odbywało się wyłącznie w ramach tej samej sesji Kameleo, w której emulowano wejście na stronę docelową.
• Skrypt Playwright powinien zapewnić pełną tożsamość User-Agent, IP (przez to samo proxy) i parametry WebRTC podczas przejścia przez link.
• System antyfraudowy CRM powinien widzieć „czysty” cyfrowy odcisk urządzenia iOS, wygenerowany przez Kameleo, aby weryfikacja przejścia przebiegła pomyślnie.

5. Integracja z API Brokera i CRM

• W momencie naciśnięcia przycisku na stronie docelowej skrypt powinien zainicjować zapytanie API do brokera (zgodnie z dokumentacją brokera), używając TEGO SAMEGO zarezerwowanego adresu IP, który jest przypisany do bieżącej sesji Kameleo.
• Odbieranie danych autologowania (token/link) od brokera.
• Zarządzanie nagłówkami: Przy wykonywaniu zapytań API do brokera i przejściach w przeglądarce zabrania się przesyłania zbędnych lub domyślnych nagłówków (np. Referer lub Origin), aby zminimalizować cyfrowy ślad.
• Ostateczne przejście w przeglądarce Kameleo przez link autologowania, aby sesja została przypisana do urządzenia.

6. Cechy pracy z systemem przekierowań CRM i Antyfraudem

• Logika przekierowania: Otrzymany od brokera link autologowania najpierw jest zapisywany w naszym CRM. Skrypt otrzymuje od CRM wewnętrzny maskujący link, a nie bezpośredni link brokera.
• Krytyczne wymaganie dotyczące User-Agent i Fingerprintingu: Przejście przez ten maskujący link CRM powinno odbywać się wyłącznie w ramach tej samej sesji Kameleo/Playwright.
• Synchronizacja: System antyfraudowy CRM analizuje parametry dokładnie w momencie przejścia przez link autologowania. Skrypt powinien zapewnić pełną tożsamość User-Agent, jeden IP i wszystkie odciski (Canvas/WebGL) między momentem rejestracji a momentem przejścia przez link.
• Raportowanie: Aktualizacja statusu w naszym wynajmowanym CRM (ID leada, status u brokera, link do logu).

Wymagania techniczne

1. Parametry Urządzenia (Hardware Fingerprints)

Wymaganie: Każdy profil Kameleo powinien używać realistycznych i unikalnych parametrów urządzenia (CPU, pamięć, rozdzielczość ekranu, pamięć urządzenia), które odpowiadają rzeczywiście istniejącym modelom iPhone'a (np. iPhone 13 Pro z konkretnymi, nietypowymi cechami). Nie można używać typowych wzorców.

• Działanie dewelopera: Wykonawca powinien opracować mechanizm, który generuje lub wybiera z bazy danych unikalny zestaw parametrów dla każdej sesji, wykluczając powtarzanie powiązań WebGL/Canvas i rozdzielczości ekranu między różnymi leadami.

2. Zarządzanie Odciskami (Canvas & WebGL Spoofing)

Wymaganie: Należy upewnić się, że Kameleo nie tylko spoufa odciski, ale czyni je unikalnymi dla każdej sesji.

• Działanie dewelopera: W ramach punktu 3 („Walidacja”), skrypt powinien potwierdzić, że dwa kolejno przyjęte leady mają różne, a jednocześnie spójne (przeszłe Pixelscan/Browserleaks) odciski Canvas i WebGL. Powtarzanie hashy jest niedopuszczalne.

3. Randomizacja User-Agent

Wymaganie: Wykluczyć użycie wzorcowych lub powtarzających się User-Agent.

• Działanie dewelopera: Wykonawca powinien używać dynamicznej generacji User-Agent lub bazy danych rzeczywistych UA, odpowiadających wybranemu modelowi iPhone'a i wersji iOS, z minimalnymi, realistycznymi wariacjami (np. różne numery kompilacji przeglądarki), aby uniknąć wzorca generatora.

4. Jakość Proxy i Adresów IP

Wymaganie: Rozwiązać problem niezgodności IP/Geo i podejrzanych IPv6.

• Działanie dewelopera: Wykonawca powinien używać wysokiej jakości mobilnych lub rezydencyjnych proxy, które gwarantują dokładne geograficzne dopasowanie GEO oferty i nie mają oznak proxy dla systemów antyfraudowych (czyste IP).

5. Wymagania dotyczące serwerów proxy i adresów IP

Krytycznie ważne jest używanie wysokiej jakości proxy, aby uniknąć wykrycia farmy botów.

Dlaczego to ważne:

Systemy antyfraudowe brokera są bardzo wrażliwe na jakość adresów IP. Szukają niezgodności Geo/IP (gdy adres IP nie odpowiada zadeklarowanemu GEO leada) i podejrzanych IPv6.

Kluczowa zasada: Adres IP, który jest używany do rejestracji leada przez API (Sending IP), powinien zgadzać się z adresem IP, który jest używany do przejścia przez link autologowania (IP of following the link).

Wymagania dotyczące proxy:

• Typ proxy: Należy używać rezydencyjnych lub mobilnych proxy. Użycie serwerowych (data-centerowych) proxy jest kategorycznie zabronione, ponieważ są one łatwo wykrywane jako narzędzia automatyzacji.
• Spójność IP: Wykonawca powinien zapewnić mechanizm, w którym ten sam adres IP jest używany przez cały proces:
  1. Dla zapytania API rejestracji do brokera.
  2. Dla tworzenia profilu w Kameleo.
  3. Dla przejścia przez link autologowania w ramach sesji Playwright.
• Dokładne GEO: Adres IP powinien dokładnie odpowiadać geograficznemu regionowi oferty i danym leada (np. Szwajcaria dla CH). Przypadki „Ashburn↔Yonkers” lub „Pittsburgh↔Lititz” są niedopuszczalne i doprowadzą do odrzucenia leada.

Суть задачи:

Необходимо реализовать систему «живой» регистрации лидов. Скрипт должен перехватывать лиды из Facebook (Lead Ads), создавать их в нашей CRM и проводить полную имитацию регистрации на лендинге через антидетект-браузер Kameleo (Playwright) или аналог для создания уникального и консистентного цифрового следа, который пройдет проверку продвинутых антифрод-систем

Технический процесс:

1. FB Lead Ads API

• Прием лида из разных Form_ID через Webhooks / Graph API.
• Под каждый ID формы в конфигурации скрипта должен быть закреплен свой оффер и ГЕО.

2. Управление прокси и создание уникальной сессии

• Выделение IP: Скрипт должен обратиться к API прокси-провайдера для резервирования уникального резидентного или мобильного IP-адреса в нужном ГЕО для текущего лида.
• Kameleo Session & Уникальный фингерпринт: Используя этот зарезервированный IP, скрипт запускает профиль iOS через Kameleo API.
• Критическая рандомизация: Каждый профиль должен использовать реалистичные и уникальные параметры устройства (CPU, память, разрешение экрана, Device Memory), соответствующие реально существующим моделям iPhone. Повторение шаблонов недопустимо.
• Активация спуфинга: Необходимо принудительно активировать функцию интеллектуального спуфинга (Intelligent Canvas/WebGL Spoofing) через API Kameleo для обеспечения консистентного и реалистичного цифрового отпечатка на протяжении всей сессии
• Актуальные модели: Параметры устройства (CPU, память, разрешение экрана, Device Memory) должны соответствовать реально существующим моделям iPhone не старше iPhone 14-й серии (iPhone 14, 14 Plus, 14 Pro, 14 Pro Max и новее). Использование повторяющихся шаблонов недопустимо.
• iOS: Только версии 17.x и 18.x (вышедшие к 2026 году). Использование iOS 15/16 на новых моделях iPhone выглядит как манипуляция.
• Браузеры: Версия Chrome/Safari должна быть не старше двух последних релизов от текущей даты (проверять через Chromium Dash).

3. Валидация сессии

• Проверка созданной сессии на Pixelscan или аналоге (например, browserleaks.com).
• Статус должен быть Consistent (Согласованный).
• Критически важно убедиться, что два последовательных лида имеют разные и при этом консистентные отпечатки Canvas и WebGL и выглядят как нативный отпечаток заявленного iOS-устройства.

4. Регистрация (Сенсорная эмуляция)

• Скрипт через Playwright имитирует «прогревание» и заход на лендинг в рамках уже запущенной сессии с выделенным IP.
• Эмуляция действий: Скрипт вводит данные в форму лендинга, нажимает «Зарегистрироваться» (строго через touchscreen.tap для имитации сенсорного ввода на iOS).
• Важное требование по User-Agent и Fingerprinting:Поскольку наша CRM анализирует параметры именно в момент перехода по ссылке автологина (а не в момент передачи лида по API), крайне важно, чтобы:
• Переход по маскировочной ссылке CRM осуществлялся строго внутри той же сессии Kameleo, в которой имитировался заход на лендинг.
• Скрипт Playwright должен обеспечить полную идентичность User-Agent, IP(через тот же прокси) и WebRTC параметров при переходе по ссылке.
• Система антифрода CRM должна видеть «чистый» цифровой отпечаток iOS-устройства, сгенерированный Kameleo, чтобы верификация перехода прошла успешно

5. Интеграция с API Брокера и CRM

• В момент нажатия кнопки на лендинге скрипт должен инициировать API-запрос к брокеру (согласно документации брокера), используя ТОТ ЖЕ САМЫЙ зарезервированный IP-адрес, который привязан к текущей сессии Kameleo.
• Получение данных автологина (token/link) от брокера.
• Управление заголовками: При выполнении API-запросов к брокеру и переходов в браузере запрещается передавать лишние или дефолтные заголовки (например, Referer или Origin), чтобы минимизировать цифровой след.
• Финальный переход в браузере Kameleo по ссылке автологина, чтобы сессия закрепилась за устройством.

6. Особенности работы с Redirect-системой CRM и Антифродом

• Логика редиректа: Полученная от брокера ссылка автологина  сначала сохраняется в нашей CRM. Скрипт получает от CRM внутреннюю маскировочное ссылку, а не прямую ссылку брокера.
• Критическое требование по User-Agent и Fingerprinting: Переход по этой маскировочной ссылке CRM должен осуществляться строго внутри той же сессии Kameleo/Playwright.
• Синхронизация: Система антифрода CRM анализирует параметры именно в момент перехода по ссылке автологина. Скрипт должен обеспечить полную идентичность User-Agent, единый IP и всех отпечатков (Canvas/WebGL) между моментом регистрации и моментом перехода по ссылке.
• Отчетность: Обновление статуса в нашей арендной CRM (ID лида, статус у брокера, ссылка на лог).

Технические Требования

1. Параметры Устройства (Hardware Fingerprints)

Требование: Каждый профиль Kameleo должен использовать реалистичные и уникальныепараметры устройства (CPU, память, разрешение экрана, Device Memory), которые соответствуют реально существующим моделям iPhone (например, iPhone 13 Pro с конкретными, нешаблонными характеристиками). Нельзя использовать типовые шаблоны.

• Действие разработчика:Исполнитель должен разработать механизм, который генерирует или выбирает из базы данных уникальный набор параметров для каждой сессии, исключая повторение связок WebGL/Canvas и разрешений экрана между разными лидами.

2. Управление Отпечатками (Canvas & WebGL Spoofing)

Требование: Необходимо убедиться, что Kameleo не просто спуфит отпечатки, а делает их уникальными для каждой сессии.

• Действие разработчика: В рамках пункта 3 («Валидация»), скрипт должен подтверждать, что у двух последовательных лидов разные и при этом консистентные (прошедшие Pixelscan/Browserleaks) отпечатки Canvas и WebGL. Повторение хешей недопустимо.

3. Рандомизация User-Agent

Требование: Исключить использование шаблонных или повторяющихся User-Agent.

• Действие разработчика:Исполнитель должен использовать динамическую генерацию User-Agent или базу данных реальных UA, соответствующих выбранной модели iPhone и версии iOS, с минимальными, реалистичными вариациями (например, разные номера сборки браузера), чтобы избежать паттерна генератора.

4. Качество Прокси и IP-Адресов

Требование: Решить проблему IP/Geo несостыковок и подозрительных IPv6.

• Действие разработчика:Исполнитель должен использовать качественные мобильные или резидентные прокси, которые гарантируют точное географическое соответствие ГЕО оффера и не имеют признаков проксирования для антифрод-систем (чистые IP).

5. Требования к прокси-серверам и IP-адресам

Критически важно использовать высококачественные прокси, чтобы избежать обнаружения фермы ботов.

Почему это важно :

Антифрод-системы брокера очень чувствительны к качеству IP-адресов. Они ищут Geo/IP несостыковки (когда IP-адрес не соответствует заявленному ГЕО лида) и подозрительные IPv6.

Ключевое правило: IP-адрес, который используется для регистрации лида через API (Sending IP), должен совпадать с IP-адресом, который используется для перехода по ссылке автологина (IP of following the link).

Требования к прокси:

• Тип прокси: Необходимо использовать резидентные или мобильные прокси. Использование серверных (дата-центровых) прокси категорически запрещено, так как они легко детектируются как инструменты автоматизации.
• Консистентность IP: Исполнитель должен обеспечить механизм, при котором один и тот же IP-адрес используется на протяжении всей цепочки:
  1. Для API-запроса регистрации к брокеру.
  2. Для создания профиля в Kameleo.
  3. Для перехода по ссылке автологина внутри сессии Playwright.
• Точное ГЕО: IP-адрес должен точно соответствовать географическому региону оффера и данным лида (например, Швейцария для CH). Кейсы "Ashburn↔Yonkers" или "Pittsburgh↔Lititz" недопустимы и приведут к отклонению лида.