Web enrichment Playwright + browser-use kombinációval
A Nortinia Sales AI legmélyebb és legkockázatosabb komponense az enrichment-svc. Egy Python FastAPI service, amely Playwright-tel és a browser-use könyvtárral szed le adatot lead URL-ekről. Ez a cikk arról szól, mit csinál pontosan, miért így csináljuk, és mit szúrtunk el márciusban.
Miért Playwright és nem requests + BeautifulSoup
A modern B2B oldalak 80%-a JavaScript-heavy. Egy egyszerű HTTP get a legtöbb esetben üres HTML shell-t ad vissza, a tényleges tartalom hydration után jelenik meg. Próbáltuk először requests-szel — minden negyedik oldalon hiányzott a hero szöveg, az About oldal teljesen üres volt, és a tech-stack-detection nem ment, mert nem futottak le a tracking scriptek.
A Playwright headless Chromium-mal lefuttatja a teljes oldalt, megvárja a network idle-t, és csak utána olvas. Lassabb (3-8x), de használható adatot ad vissza.
Mi a browser-use szerepe
A browser-use egy LLM-asszisztált browser-control könyvtár. A klasszikus Playwright-script merev selectorokra épül (.hero-text, #about-section). Ezek hetente törnek, mert minden tenant redesignol valamit.
A browser-use ehelyett kap egy magas szintű utasítást ("szedj le egy About szekciót, ha van"), és LLM-mel találja meg az oldalon. Ez 4x ellenállóbb a layout-változásokra, és új tenant onboardinghoz nem kell selector-mapet írni.
Költség-mellékhatás: minden enrichment hív 2-4 LLM completiont. Cost-monitoring kötelező.
Mit szedünk le
- Landing hero — első képernyő szöveg, fő CTA, language detect
- Navigation tree — felső menü struktúra, mélyebb oldalak felfedezésére
- About / Team — alkalmazotti létszám-jelek (csoportkép, név-felsorolás)
- Pricing / Plans — ha publikus, az árszínvonal és a target segment
- Tech stack hints — HTTP headerből (Server, X-Powered-By), HTML attribútumokból (data-react, ng-app), CDN-ből (Cloudflare, Vercel, Akamai)
- Contact — public email patterns, telefon (de csak public, nem dial)
- Recent news — Google News API a cég nevével, utolsó 90 nap
CAPTCHA stratégia: NONE
A legfontosabb design-döntés: nem oldunk meg CAPTCHA-t. Sem 2captcha-szerű szolgáltatást, sem ML-megoldó modellt nem használunk. Ha egy oldal CAPTCHA-t mutat, az signal: most ne forgalmazzunk. A scraper exponential backoff-ra megy (24h, 48h, 96h), és csak nyilvános source-okra támaszkodik (LinkedIn public profile, Google News, public domain WHOIS-jellegű info).
Ugyanígy: robots.txt-t tiszteletben tartjuk. Ha egy path Disallow-ban van, nem scraping. Ez nem szabályozási kötelezettség, hanem önként vállalt korlát — és sokszor megspórolt minket egy szolgáltatás-banoltatástól.
A márciusi rotating-IP bug
2026 márciusban két hétig fejjel a falnak mentünk. Az enrichment success rate 67%-ról 41%-re esett. Próbáltuk a Playwright timeoutot növelni, a browser-use modellt cserélni, új selector-stratégiát írni — semmi nem segített.
A root cause egy IP-rotation pool kimerülése volt. A residential proxy szolgáltatónknál egy konkrét régió (Közép-Európa) IP-poolja kifogyott, és a rendszer csendben datacenter IP-kre váltott. A datacenter IP-ket a megcélzott oldalak fingerprintelték és blokkolták.
A fix: új provider, jobb pool-monitoring, és egy belső dashboard, amely panel-szinten mutatja a success rate-et IP-osztály bontásban. Ha 6 órán át 50% alá esik, alarm. Azóta hat hónapja nem ismétlődött.
A tanulság: a scraping infrastruktúra annyira törékeny, hogy önálló observability réteg kell rá. Nem elég az alkalmazás-szintű APM.
Költségek pontosan
Egy átlag cég-enrichment:
- Playwright session (1 oldal × 3-5 path): 8-12 másodperc CPU + 80 MB RAM
- Browser-use LLM hívás (2-4 darab
gpt-4.1-mini): 0,006-0,012 USD - Struktúrált extract (1 hívás
gpt-4.1-mini): 0,008 USD - News API: 0,001 USD
- Proxy bandwidth: 0,003 USD
Összesen átlag: 0,02 USD / cég. Ez 1 420 lead / hét tenantnál havi ~120 USD enrichment költség.
Mit nem csinálunk
Nem scraping login mögötti adatot. Nem oldunk meg captchát. Nem vásárolunk leak-elt adatbázist. Nem szelekteljük az IP pool-t country-spoofingra. Az enrichment csak public source-ra épít, vagy egyáltalán nem fut.