למה Good Pharm הוא לא עוד אתר Shopify סטנדרטי
במבט ראשון, האתר מרגיש פשוט. אבל כשפותחים את ה-DevTools, התמונה משתנה. אנחנו לא מדברים פה על HTML סטטי שמוגש מהשרת. חלק ניכר מהמידע הקריטי — מחיר, זמינות, מבצעים — נטען דינמית באמצעות קריאות JavaScript לאחר טעינת הדף הראשונית. המשמעות היא שספרייה כמו requests תחזיר לך HTML חלקי, בלי המידע שאתה באמת צריך. זהו כישלון ודאי עוד לפני שהתחלת.
הקטלוג עצמו מכיל אלפי מוצרים, כשלפי הערכה מהירה מדובר על טווח של 10,000-15,000 דפי מוצר פעילים, לא כולל וריאציות. הניווט בין הקטגוריות והעמודים מתבצע לרוב דרך אינטראקציות JS, מה שמסבך עוד יותר איסוף קטלוג מלא. ה-sitemap.xml יכול לתת נקודת פתיחה, אבל הוא לא תמיד מעודכן במאת האחוזים, במיוחד לגבי מוצרים חדשים או כאלה שיצאו מהמלאי. כדי לבנות scraper אמין לאתר כזה, נקודת המוצא חייבת להיות כלי שיודע להריץ JS. תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים וב-API הנקי שלו. זה הכלי הנכון לעבודה הזאת, לפחות לשלב גילוי המבנה והאינטראקציות.
איסוף קטלוג וניטור מחירים: הגישה הנכונה
המשימה הראשונה בדרך כלל היא איסוף קטלוג Good Pharm מלא. זה הבסיס לכל דבר אחר. הדרך לעשות את זה נכון היא להתחיל מדף הקטגוריות הראשי ולבצע זחילה רקורסיבית. באמצעות Playwright, אתה יכול לנווט בין עמודי הקטגוריה, לאסוף את כל הקישורים למוצרים, וללחוץ על כפתור "הבא" עד שהוא נעלם. חשוב לשמור על state כדי לדעת איפה עצרת אם הסקריפט נופל באמצע. צפו ל-latency של בין 800ms ל-2.5 שניות לטעינת דף מלא, כולל כל קריאות ה-API הפנימיות שלו.
ברגע שיש לך רשימת URLs של מוצרים, מתחיל השלב של ניטור מחירים Good Pharm. כאן הדיוק חשוב. אתה צריך לחלץ לא רק את המחיר הרגיל, אלא גם מבנה של מבצעים. האם יש הנחת כמות? מבצע 1+1? מחיר לחברי מועדון? כל אלה הם אלמנטים נפרדים ב-DOM, ולפעמים נטענים מקריאת API שונה. גישה חכמה היא להשתמש ביכולות של Playwright לנטר קריאות רשת. אפשר להגדיר listener שמחכה לקריאת ה-API הספציפית שמחזירה את נתוני המחיר כ-JSON. זה הרבה יותר יציב מלחפש סלקטורים של CSS שיכולים להשתנות ברידיזיין הבא. גישה זו מבטיחה שהנתונים שלך מדויקים ומונעת את הצורך לעדכן את הסקריפט כל שני וחמישי.
המשחק האמיתי: מעקב מלאי וזמינות בסניפים
כאן רוב ה-scrapers החובבניים נכשלים. מעקב מלאי/זמינות Good Pharm הוא לא פיצ'ר, הוא המהות של איסוף נתונים בעולם הפארם והקמעונאות. זה המידע שבאמת מניע החלטות עסקיות. הבעיה היא שנתוני מלאי כמעט תמיד נטענים מקריאת API נפרדת, שמתבצעת לאחר שהמשתמש מבצע אינטראקציה כלשהי (למשל, בוחר סניף לאיסוף). לנסות לחלץ את המידע הזה מה-HTML הראשוני זה מתכון לאסון ולקבלת נתונים שגויים.
תרחיש כשל קלאסי שראיתי קורה שוב ושוב: ה-scraper טוען את דף המוצר, רואה את הכיתוב "זמין במלאי" הדיפולטי, ושומר את המוצר כזמין. בפועל, קריאת ה-API שרצה ברקע אחרי חצי שנייה מחזירה {"stock": 0}. הנתונים שלך פשוט לא נכונים. הפתרון הוא לדמות את התנהגות המשתמש במלואה או, טוב יותר, לבודד את קריאת ה-API שבודקת מלאי לפי מוצר. לאחר זיהוי ה-endpoint הזה, אפשר לנסות לשלוח אליו בקשות ישירות. זה דורש ניתוח של ה-headers, ה-cookies, ואולי token שצריך לחלץ מהדף. אם תצליח, תוכל להריץ בדיקות מלאי בקצב גבוה בהרבה ובעלות משאבים נמוכה משמעותית. אבל היזהר, קריאות תכופות מדי ל-API הזה הן דרך בטוחה לקבל חסימת IP. שמור על קצב סביר, מתחת ל-3-4 בקשות לשנייה מאותו IP, והשתמש ב-proxy rotation איכותי. אם אתה מקבל שגיאות 429, זה סימן שאתה צריך להאט. המדריך שלנו לטיפול בשגיאות 429 יכול לעזור כאן.
מתי לא צריך Headless Browser לכל בקשה
אחרי כל מה שאמרתי על Playwright, יש נקודה שבה הוא הופך ל-overkill. שימוש ב-headless browser לכל בקשה הוא בזבוז משאבים אדיר, במיוחד כשמדובר על מודיעין מתחרים Good Pharm שדורש סריקות תכופות. אחרי שביצעת את שלב הגילוי הראשוני עם Playwright, מיפית את ה-endpoints של ה-API הפנימי, והבנת את מבנה הבקשות, המטרה הבאה היא לזרוק את ה-browser.
אם הצלחת לבודד את קריאות ה-API למחירים, מבצעים ומלאי, אתה יכול לעבור למודל היברידי. השתמש ב-Playwright פעם ביום כדי לוודא שה-endpoints לא השתנו וכדי לאסוף cookies או טוקנים חדשים במידת הצורך. אבל את 99% מהבקשות השוטפות — בדיקות המחיר והמלאי כל כמה דקות — תריץ עם ספריית HTTP קלת משקל כמו httpx ב-Python. המעבר הזה יכול להקטין את צריכת ה-CPU וה-RAM שלך בסדר גודל, ולאפשר לך להגדיל את תדירות הדגימה פי 10 או יותר באותה תשתית. זהו המפתח ליצירת API / קובץ נתונים Good Pharm אמין ועדכני. זה דורש יותר מאמץ הנדסי בהתחלה, אבל התמורה ביעילות ובסקייל היא עצומה. זו הגישה שמפרידה בין פרויקט חובבני למערכת דאטה מקצועית.
הגנות, חסימות, ואיך לשמור על פרופיל נמוך
ל-Good Pharm אין חומת הגנה אגרסיבית כמו של אתרים פיננסיים, אבל זה לא אומר שהם לא יחסמו אותך. המערכות שלהם כנראה מנטרות דפוסי התנהגות חריגים. אם תנסה לסרוק את כל 15,000 המוצרים תוך 10 דקות מ-IP בודד של דאטה סנטר, אתה תחטוף חסימה. זה כמעט מובטח. הסוד הוא לא להיראות כמו בוט.
הצעד הראשון הוא להשתמש בכתובות IP איכותיות. פרוקסי של דאטה סנטר זה טוב להתחלה, אבל אם אתה נתקל בחסימות, הגיע הזמן לשדרג. איך לבחור פרוקסי residential זה נושא שלם, אבל הרעיון הוא שהתעבורה שלך תיראה כאילו היא מגיעה ממשתמשים ביתיים אמיתיים. בנוסף, חובה לבצע רוטציה של ה-IPs ושל ה-User-Agent. אל תשתמש באותו User-Agent לכל הבקשות. גוון ביניהם. שלב מתקדם יותר הוא שימוש בטכניקות התחמקות. מדריך Playwright stealth מכסה איך להסתיר את העובדה שאתה מריץ דפדפן אוטומטי. זה כולל הסתרת מאפייני navigator.webdriver, שינוי מאפייני WebGL, ועוד טריקים שגורמים לאוטומציה שלך להיראות אנושית יותר. בסופו של דבר, המטרה היא לשמור על אחוז הצלחה של מעל 98%. אם אתה יורד מזה, סימן שאחת ההגנות שלהם תפסה אותך וצריך לחזור לשולחן השרטוטים.