למה Requests לבד לא יספיק לכם בסטימצקי
בואו נשים את זה על השולחן: אם הגישה שלכם היא requests.get() ופארסינג של ה-HTML הסטטי, אתם הולכים לבזבז המון זמן. אתר כמו סטימצקי, כמו רוב אתרי האיקומרס המודרניים, לא שולח את כל המידע בטעינה הראשונית. חלק גדול מהתוכן, במיוחד נתונים דינמיים כמו זמינות בסניפים או מבצעים שמופעלים על ידי אינטראקציית משתמש, נטען אסינכרונית דרך קריאות API פנימיות (XHR/Fetch).
הגישה הנכונה מתחילה בשימוש בכלי שיכול לרנדר JavaScript. תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, ממהירות ועד יציבות. אבל גם שימוש ב-Headless Browser לא מבטיח הצלחה. השלב הראשון הוא לפתוח את ה-DevTools, ללכת ללשונית Network ולסנן לפי Fetch/XHR. תראו בדיוק אילו endpoints מספקים את המידע על מחירים, מלאי ותיאורי מוצר. במקרים רבים, אפשר לדלג לחלוטין על רינדור הדף ולגשת ישירות ל-API הפנימי הזה. זה מהיר יותר, צורך פחות משאבים, והרבה פחות שביר. הבעיה היא שה-endpoints האלה דורשים לרוב headers ספציפיים, cookies, או טוקנים שנוצרים בצד הלקוח. כאן נכנסת לתמונה גישה היברידית: שימוש ב-Playwright כדי לייצר סשן חוקי, לחלץ את הטוקנים הנדרשים, ואז להשתמש בספריית HTTP מהירה כמו httpx כדי לתקוף את ה-API ישירות בקצב גבוה.
איך להפוך דאטה גולמי למודיעין מתחרים
אז יש לכם גישה לנתונים. מה עכשיו? איסוף קטלוג סטימצקי הוא רק הצעד הראשון. הערך האמיתי מגיע מהיכולת להפוך את המידע הגולמי הזה לתובנות. זה המקום שבו רוב הפרויקטים הטכניים נופלים — הם מצליחים לאסוף את הדאטה, אבל לא בונים את התשתית לעבד אותו.
נתחיל עם ניטור מחירים סטימצקי. זה לא רק לאסוף את המחיר הנוכחי. זה לתעד כל שינוי, לזהות מבצעים ('2+1', 'ספר שני ב-50% הנחה') ולנרמל אותם למבנה נתונים אחיד. ה-DOM של מבצעים משתנה לעיתים קרובות יותר מה-DOM של מחיר רגיל, וזה מקור קבוע לשבירת הפארסרים שלכם. מעבר למחירים, מעקב מלאי/זמינות סטימצקי הוא קריטי. האם ספר מסוים זמין רק אונליין? האם הוא במלאי בסניף ספציפי? המידע הזה יכול להיות אינדיקטור לביקוש או לבעיות לוגיסטיות. כשאוספים את כל המידע הזה לאורך זמן — שינויי מחיר, מבצעים, זמינות, הופעת מוצרים חדשים — מתחילים לראות תמונה רחבה. זה כבר לא סתם דאטה, זה מודיעין מתחרים. השלב הבא הוא כמובן לספק את המידע הזה בצורה נגישה, בין אם זה API / קובץ נתונים סטימצקי בפורמט CSV או JSON שמתעדכן מדי יום. המפתח הוא לחשוב על ה-end product מהיום הראשון, לא רק על איך לעבור את העמוד הראשון.
תרחיש הכישלון הקלאסי: מבצעים ו-Proxy Rotation
ראיתי את זה קורה עשרות פעמים. בונים סקרייפר שעובד נהדר על 100 עמודים. מריצים אותו על כל הקטלוג של סטימצקי, 100,000+ מוצרים, והכל מתרסק. ה-failure mode הכי נפוץ באתרי איקומרס הוא לא חסימה מיידית, אלא degradation שקט של איכות הנתונים.
דמיינו את התרחיש: אתם מריצים את הסקרייפר עם מאגר של פרוקסיז. חלקם מהירים, חלקם איטיים. חלקם ממוקמים בישראל, חלקם בגרמניה. האתר של סטימצקי, כמו רבים אחרים, מציג מחירים או מבצעים שונים בהתבסס על ה-IP של המשתמש. פתאום, אתם מתחילים לקבל מחירים ללא מע"מ, או שמבצעים מסוימים פשוט לא מופיעים. למה? כי הבקשה שלכם הגיעה מ-IP אירופאי. הסקרייפר לא נכשל, הוא לא קיבל שגיאת 403. הוא פשוט החזיר נתונים שגויים. הנתונים האלה מזהמים את הדאטהבייס שלכם ומובילים למסקנות עסקיות שגויות. הלקח פה הוא קריטי: כשעושים scraping לאתר ישראלי, חייבים להשתמש בפרוקסיז ישראליים. זה לא nice-to-have, זו דרישת בסיס. בנוסף, חשוב לבנות מנגנוני ולידציה אוטומטיים. למשל, סקריפט שרץ אחרי כל סריקה ובודק ש-99% מהמוצרים מכילים מחיר בפורמט שקלי, או ששדה ה'מבצע' לא ריק עבור קטגוריות שלמות. בלי בדיקות שפיות כאלה, אתם תגלו את הבעיה רק שבועות אחרי שהיא התחילה.
סוגיית קצב הבקשות והטביעה הדיגיטלית
כולם רוצים לאסוף את הדאטה מהר. אבל מהירות היא האויב של התגנבות. אם תתחילו לשלוח 300 בקשות בדקה מ-IP בודד, אתם תחסמו תוך פחות משעה. המערכות המודרניות לא מסתכלות רק על קצב הבקשות, אלא על טביעת הרגל הדיגיטלית הכוללת. זה כולל את ה-User-Agent, סדר ה-headers, התנהגות ה-JavaScript (אם אתם משתמשים ב-headless browser), וקצב הניווט. אם אתם קופצים ישירות לעמודי מוצר בלי לעבור דרך קטגוריות, זה דגל אדום.
המטרה היא לא להיות הכי מהירים, אלא הכי יעילים. בפרויקט סקייל כזה, אני מכוון לקצב של 5-10 בקשות בשנייה, מפוזרות על פני מאגר של לפחות 50-100 פרוקסיז. זה נותן קצב כולל של כמה אלפי דפים בדקה, מספיק כדי לכסות את כל הקטלוג תוך כמה שעות, ועדיין להישאר מתחת לרדאר. כדי לנהל את זה נכון, אתם צריכים מערכת תורים (Queue) כמו RabbitMQ או Redis. המערכת הזו מנהלת את ה-URLs שצריך לסרוק, וה-workers שלכם (הסקרייפרים) שולפים ממנה משימות. זה מאפשר לכם לשלוט בקצב הגלובלי, לעצור ולהמשיך את הסריקה, ולטפל בשגיאות בצורה אלגנטית. אם אתם נתקלים בהרבה שגיאות 429 (Too Many Requests), זה סימן שהמערכת שלכם לא מכבדת את האתר. במקום להילחם בזה, עדיף להאט. טיפול נכון בשגיאות 429 הוא סימן למקצועיות.
מתי Scraping הוא לא הפתרון הנכון
אני בונה מערכות scraping למחייתי, אבל חשוב להגיד את האמת: לפעמים זה פשוט overkill. אם כל מה שאתם צריכים זה לעקוב אחרי המחירים של 20 ספרים ספציפיים, בניית תשתית מורכבת עם Playwright, proxy rotation ומערכת תורים היא בזבוז אדיר של זמן ומאמץ. במקרה כזה, סקריפט פשוט שירוץ פעם ביום יכול להספיק. גם אם הוא ייחסם, הנזק מינימלי.
המורכבות נכנסת לתמונה כשאתם צריכים לעמוד בשלושה תנאים: סקייל (עשרות אלפי פריטים ומעלה), תדירות (איסוף יומי או שעתי), ואמינות (נתונים מדויקים ב-99.5% מהזמן). אם אתם לא עומדים בכל השלושה, כנראה שאתם יכולים להסתפק בפתרון פשוט יותר. לדוגמה, אם אתם צריכים רק תמונה כללית של הקטלוג פעם בחודש לצורך מחקר שוק, סריקה איטית וידנית כמעט תמיד תעבוד. הבעיה היא שאנשים נוטים להעריך בחסר את המאמץ הנדרש לתחזוקה. סקרייפר הוא לא מוצר של 'שגר ושכח'. האתר של סטימצקי ישנה את המבנה שלו, יוסיף הגנות חדשות, וישנה את ה-API הפנימי. מערכת שלא בנויה לגמישות ולניטור תפסיק לעבוד בשקט, ולרוב תגלו את זה מאוחר מדי. לפני שצוללים לפרויקט כזה, תשאלו את עצמכם אם יש לכם את המשאבים לתחזק אותו לחצי שנה קדימה, לא רק לבנות אותו השבוע.