למה קרפור ישראל הוא לא עוד אתר e-commerce פשוט
הטעות הראשונה היא להתייחס לאתר של קרפור ישראל כמו אל אתר תוכן סטנדרטי. המורכבות כאן נובעת משלושה גורמים מרכזיים: קנה מידה, דינמיות והטכנולוגיה בצד הלקוח. הקטלוג כולל עשרות אלפי פריטים, אולי 40,000-50,000 SKUs אם סופרים וריאציות וסניפים. זה אומר שאיסוף קטלוג מלא דורש סריקה של אלפי דפי קטגוריה ומוצר. הדינמיות היא האתגר האמיתי. אנחנו מדברים על מבצעים שמתחילים ונגמרים בשעות ספציפיות ועל מלאי לפי מוצר שמשתנה בזמן אמת. סריקה חד-פעמית ביום לא תספיק למי שעוסק בתחום של מודיעין מתחרים או ניטור מחירים תחרותי. הדרישה היא לסריקות תכופות, מה שמגביר את העומס ומעלה את הסיכוי להיחסם.
בצד הטכני, האתר הוא SPA, ככל הנראה מבוסס React או Vue. התוכן לא קיים ב-HTML הראשוני שמגיע מהשרת. הוא נטען ומוצג על ידי JavaScript שרץ בדפדפן. כל ניסיון להשתמש בספרייה פשוטה כמו requests יחזיר מעט מאוד מידע שימושי. כאן נכנסת הדרישה לשימוש בכלים שיודעים להריץ JS, מה שמוביל אותנו ישירות לעולם ה-headless browsers. כל ניסיון לחסוך פה במשאבים ולהישאר עם HTTP clients פשוטים נידון לכישלון מהיר או לתחזוקה אינסופית כשה-frontend ישתנה.
ארכיטקטורת ה-Scraper: Headless Browser הוא ברירת המחדל
תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 כמעט בכל מטריקה רלוונטית, במיוחד במהירות, יציבות ויכולות רשת מתקדמות. כשניגשים ל-scraping של קרפור ישראל, הגישה הנכונה היא להתחיל עם Playwright. למה? כי הוא מאפשר לנו גם לרנדר את הדף המלא וגם ליירט את קריאות ה-API הפנימיות שהדפדפן מבצע. זו נקודת מפתח. במקום לגרד את ה-HTML הסופי, אנחנו יכולים להאזין לתעבורת הרשת של הדף, לזהות את ה-endpoints שמחזירים את נתוני המוצרים כ-JSON, ולכוון את ה-scraper שלנו ישירות אליהם בהמשך.
התהליך נראה כך: בשלב המחקר הראשוני, מריצים Playwright במצב headful (עם חלון דפדפן גלוי) ועוברים על תהליך רכישה סטנדרטי עם כלי המפתחים פתוחים בלשונית 'Network'. מנטרים את קריאות ה-XHR/Fetch. מהר מאוד תזהו את הקריאות שמביאות את רשימות המוצרים בקטגוריה או את פרטי המוצר הספציפי. זיהיתם את ה-endpoint? מעולה. עכשיו אפשר לבנות scraper היברידי: הוא משתמש ב-Playwright כדי לנהל סשנים, לקבל עוגיות וטוקנים נחוצים, אבל את איסוף הנתונים המאסיבי הוא מבצע באמצעות קריאות HTTP ישירות לאותו API שגיליתם. זה חוסך 90% ממשאבי ה-CPU והזיכרון שהיו נדרשים לרינדור מלא של כל דף ודף. השילוב הזה הוא ה-sweet spot בין אמינות ליעילות.
נקודת הכשל הצפויה: ניהול סשנים ו-Fingerprinting
כאן רוב המערכות נופלות, במיוחד אחרי כמה ימים של ריצה רציפה. אתרים כמו קרפור ישראל לא מסתמכים רק על חסימת IP. הם משתמשים בטכניקות fingerprinting מתקדמות כדי לזהות דפדפנים אוטומטיים. אם תריצו Playwright בגרסת ברירת המחדל שלו, אתם למעשה שולחים "שלט ניאון" שמכריז "אני בוט". משתני JavaScript כמו navigator.webdriver, היעדר תוספים מסוימים, והתנהגות עכבר לא אנושית הם דגלים אדומים. הפתרון הוא להשתמש בספריות stealth. המדריך ל-Playwright stealth מכסה את היסודות של איך להסוות את האוטומציה שלכם.
אבל זה לא רק ה-fingerprint של הדפדפן. זה גם ניהול הסשן. אם תנסו לסרוק 5,000 דפים עם אותו IP ואותן עוגיות תוך 10 דקות, אתם תיחסמו. המערכת צריכה להיות מתוכננת לרוטציית זהויות. זה אומר שכל worker בתור צריך לקבל פרופיל דפדפן נקי, IP חדש (רצוי ממגוון של residential proxies), ועוגיות משלו. בנינו מערכות שמחזיקות מאגר של אלפי זהויות כאלה, כל אחת עם היסטוריית גלישה מינימלית כדי להיראות לגיטימית. קצב הבקשות הוא קריטי. אל תנסו להפציץ את השרת. קצב של 20-30 דפים בדקה פר IP הוא סביר, אבל דורש ניטור מתמיד. אם אחוז השגיאות עולה מעל 5%, המערכת צריכה להאט אוטומטית ולבצע רוטציה של פרוקסי וזהויות.
מעבר מאיסוף נתונים גולמי ל-API מוכן לשימוש
איסוף הנתונים הוא רק חצי מהעבודה. השלב הבא, והחשוב לא פחות, הוא הפיכת בליל ה-JSON וה-HTML שקיבלתם למידע נקי, מובנה וזמין. זה מה שהופך פרויקט scraping סתמי למוצר נתונים אמיתי, כמו API / קובץ נתונים קרפור ישראל שהלקוחות יכולים לצרוך. השלב הראשון הוא נורמליזציה. צריך לוודא ששדה המחיר תמיד יהיה מספר, שהקטגוריות ממופות למבנה היררכי אחיד, ושהמפרטים הטכניים של המוצר מפורקים לשדות נפרדים. זה דורש כתיבת parsers חכמים שיודעים להתמודד עם שוני במבנה הנתונים בין קטגוריות שונות.
לאחר מכן, יש את נושא שמירת הנתונים. חשוב לשמור גרסאות היסטוריות של כל פריט. זה מאפשר ניטור מחירים לאורך זמן ומעקב אחר שינויים במלאי. בסיס נתונים כמו PostgreSQL עם טבלת products וטבלת price_history הוא התחלה טובה. לבסוף, צריך לחשוף את הנתונים. זה יכול להיות ייצוא CSV יומי שמועלה ל-S3, או בניית API פנימי פשוט מעל בסיס הנתונים. ה-API מאפשר למערכות אחרות לשלוף מידע על מוצר ספציפי, לבדוק מעקב מלאי/זמינות קרפור ישראל בזמן אמת, או לקבל את כל המוצרים בקטגוריה מסוימת. בניית התשתית הזו היא מה שמבדיל בין scraper שמריצים פעם אחת לבין מערכת מודיעין שוק אמינה.
מתי הגישה הזו היא Overkill
למרות כל מה שאמרתי, לא תמיד צריך להוציא את התותחים הכבדים. אם כל מה שאתם צריכים זה לבדוק מחיר של עשרה מוצרים פעם ביום, בניית מערכת מבוזרת עם רוטציית פרוקסי ו-Playwright היא בזבוז מוחלט של זמן ומאמץ. במקרה כזה, סקריפט פשוט, אולי אפילו כזה שרץ לוקאלית על המחשב שלכם, יעשה את העבודה. אין טעם לבנות מערכת שיודעת להתמודד עם 100,000 בקשות בשעה אם ה-use case שלכם דורש 100 בקשות ביום. המורכבות שאנחנו מתכננים כאן נועדה לפתור בעיות של קנה מידה ועמידות.
תרחיש נוסף שבו הגישה הזו מיותרת הוא כשיש API ציבורי או דרך קלה יותר להשיג את המידע. תמיד כדאי לבדוק אם לאתר יש אפליקציית מובייל. לעיתים קרובות, ה-API של האפליקציה פחות מוגן וקל יותר לעבוד מולו מאשר מול אתר הדסקטופ. אם אפשר לבצע reverse engineering ל-API של האפליקציה ולהשתמש בו ישירות, זה יכול לחסוך את כל המורכבות של התמודדות עם דפדפנים ו-JavaScript. עם זאת, במקרה של אתרי סופרמרקט גדולים כמו קרפור ישראל, הסיכוי למצוא API פתוח ופשוט הוא נמוך. הם משקיעים מאמצים רבים בהגנה על הנתונים שלהם. לכן, חשוב להעריך את המטרה הסופית לפני שמתחייבים לארכיטקטורה מורכבת.