למה Requests פשוט לא יספיק לדלתא
בואו נשים את זה על השולחן: אם תנסו לשלוח בקשת GET פשוטה לדף קטגוריה בדלתא, תקבלו בחזרה שלד HTML כמעט ריק מתוכן. המוצרים? המחירים? המבצעים? כל אלה נטענים דינמית באמצעות JavaScript לאחר שהדף הראשוני נטען בדפדפן. זהו client-side rendering (CSR) קלאסי, וזה הופך ספריות פשוטות ללא רלוונטיות.
הפיתוי הראשון הוא לקפוץ ישר לפתרון כוחני כמו Selenium או Playwright. זה יעבוד, בערך. תוכלו להריץ דפדפן מלא, לחכות שה-JavaScript ירוץ, ואז לגרד את ה-HTML הסופי. אבל זו גישה בזבזנית להחריד במשאבים ובזמן. כל בקשה דורשת הרמת תהליך דפדפן שלם, מה שמוביל ל-latency של 3-5 שניות לדף, במקרה הטוב. כשאתם צריכים לסרוק קטלוג של 8,000 מוצרים, זה פשוט לא סקיילבילי.
הגישה הנכונה מתחילה בבחינה של תעבורת הרשת. פתחו את ה-DevTools, רעננו דף קטגוריה, וסננו לפי בקשות XHR/Fetch. מהר מאוד תגלו שהדפדפן לא קורא HTML, הוא קורא ל-API פנימי שמחזיר JSON נקי ומסודר עם כל המידע שאתם צריכים. זה היעד האמיתי שלנו. ניתוח ה-API הזה הוא המפתח ל-scraper יעיל. זה ההבדל בין מערכת שמקרטעת עם 50% הצלחה לבין מערכת שמביאה 99% מהנתונים בפחות מעשירית מהזמן.
פיצוח ה-API הפנימי לאיסוף קטלוג מלא
אחרי שזיהינו שהמפתח הוא ה-API, השלב הבא הוא למפות אותו. זהו תהליך של בלשות דיגיטלית. התחילו מניווט באתר כמו משתמש רגיל, עם חלון ה-Network פתוח. שימו לב לאילו נקודות קצה (endpoints) הדפדפן פונה כשאתם עוברים בין קטגוריות, משתמשים בפילטרים או טוענים את הדף הבא ברשימת המוצרים.
באתר כמו Delta, סביר שתמצאו נקודת קצה מרכזית לקטלוג, משהו שנראה כמו api.delta.co.il/v2/products/list עם פרמטרים כמו categoryId, page, ו-pageSize. המטרה היא להבין את כל הפרמטרים האפשריים כדי שתוכלו לבצע איסוף קטלוג Delta מלא באופן שיטתי. ברגע שיש לכם את נקודת הקצה והפרמטרים, אתם יכולים לכתוב סקריפט פשוט ב-Python עם httpx (שהיא אסינכרונית, חובה לפרויקטים כאלה) שמבצע איטרציה על כל הקטגוריות והעמודים ומוריד את כל המידע. כך אפשר לאסוף את כל שמות המוצרים והקטגוריות תוך דקות, במקום שעות של גירוד דפדפן.
כמובן, זה לא תמיד פשוט. לפעמים ה-API דורש headers ספציפיים, כמו x-api-key או טוקן Authorization שמתקבל בבקשה ראשונית. חשוב לחקות את ה-headers שהדפדפן שולח בצורה מדויקת. השקעת הזמן בפיצוח ה-API מחזירה את עצמה פי כמה וכמה במהירות, באמינות ובעלות התחזוקה של ה-scraper.
מעקב מלאי וזמינות בזמן אמת
בתחום האופנה, מידע על מוצר ללא פירוט מלאי הוא כמעט חסר ערך. מעקב מלאי/זמינות Delta הוא אחד ה-use cases המורכבים ביותר, כי המידע הזה הוא הנדיף ביותר. מלאי של פריט במידה מסוימת יכול להשתנות מעשרות יחידות לאפס תוך שעה במהלך מבצע.
כאן נכנס לפעולה תרחיש כשל נפוץ: ניסיון להבין זמינות על ידי ניתוח כפתור "הוסף לסל". מפתחים רבים בונים לוגיקה שמחפשת אם הכפתור פעיל או אפור. זו טעות. לעיתים קרובות, הלוגיקה הזו מנוהלת בצד הלקוח ויכולה להיות מטעה. הדרך הנכונה היא למצוא את קריאת ה-API הספציפית שמתרחשת כשמשתמש בוחר מידה או צבע. לרוב, זו תהיה קריאת API נפרדת שמחזירה אובייקט JSON עם המלאי המדויק לכל וריאציה (SKU), למשל: {"sku": "DL123-S-BLUE", "stock": 15}.
האתגר הוא שביצוע בקשה כזו עבור כל מידה של כל מוצר בקטלוג יכול לייצר עומס אדיר ולהפעיל מנגנוני הגנה. לכן, יש צורך בגישה מתוחכמת: סריקה ראשונית רחבה של הקטלוג פעם ביום, וסריקות תכופות וממוקדות יותר, כל 15-30 דקות, רק על פריטים פופולריים או כאלה שנמצאים במבצע. זה דורש מערכת שיודעת לתעדף משימות ומערך פרוקסים איכותי. קראו עוד על איך לבחור פרוקסי residential כדי להבין איך לגשת למשימה כזו מבלי להיחסם.
מודיעין מתחרים ואיך להפוך נתונים ל-API
איסוף הנתונים הוא רק חצי מהסיפור. הערך האמיתי נוצר כשמנתחים אותם. עבור מודיעין מתחרים Delta, אנחנו לא מסתכלים רק על המחיר הנוכחי. אנחנו עוקבים אחרי שינויי מחיר לאורך זמן, מזהים מתי קטגוריות שלמות נכנסות למבצע, ומנתחים אילו מוצרים חדשים מתווספים לקטלוג. לדוגמה, זיהוי של הוספת קו מוצרים חדש או שינוי אסטרטגיית התמחור בקטגוריית בגדי הילדים יכול להיות מידע קריטי.
בסופו של דבר, הנתונים הגולמיים צריכים להפוך למוצר שמיש. בין אם זה עבור צוותי שיווק, מנהלי מוצר או אנליסטים, הם צריכים גישה נוחה למידע. זו הסיבה שבפרויקטים רבים המטרה הסופית היא לספק API / קובץ נתונים מסודר. במקום לתת להם גישה ישירה לבסיס הנתונים המבולגן של ה-scraper, אנחנו בונים שכבת API פשוטה מעליו. נקודת קצה כמו /products/{sku}/price-history או יצירת ייצוא CSV יומי שמועלה ל-S3 הם פתרונות נפוצים. זה הופך את הפרויקט מכלי טכני חד-פעמי לנכס דאטה מתמשך בארגון. חשוב לזכור שהנתונים צריכים להיות נקיים ומנורמלים. אף אחד לא רוצה להתעסק עם שדות מחיר שמכילים "₪" או סימני מטבע אחרים.
מתי הגישה הזו לא תעבוד (ומה עושים אז)
למרות כל היתרונות, גישת ה-API-first אינה תרופת פלא. ישנם תרחישים שבהם היא נכשלת או הופכת למורכבת מדי. האתגר הגדול ביותר הוא כאשר האתר משתמש במנגנוני הגנה מתקדמים שמכוונים ספציפית לבקשות API. אם כל בקשת API דורשת טוקן שנוצר על ידי אתגר JavaScript מורכב (מה שחברות כמו Cloudflare או Akamai עושות), מלאכת ההנדסה לאחור הופכת לקשה משמעותית. במצב כזה, אתם עלולים לבזבז שבועות בניסיון לפענח קוד JavaScript שעבר מיניפיקציה ואובפוסקציה.
במקרים כאלה, ולפעמים רק במקרים כאלה, חזרה לפתרון מבוסס דפדפן מלא היא הדרך הפרגמטית. אבל גם כאן, יש לעשות זאת בחוכמה. במקום Selenium הגנרי, עדיף להשתמש בכלים מודרניים יותר כמו Playwright עם תוספים כמו playwright-stealth. כלים אלו טובים יותר בהסוואת טביעת האצבע של הדפדפן האוטומטי. הם מטפלים בפרטים קטנים כמו תכונות של האובייקט navigator, רזולוציית מסך, ושליחת בקשות מעקב שהדפדפן האמיתי היה שולח. זה לא פתרון מושלם, ועדיין תצטרכו להתמודד עם טיפול בשגיאות 429 וניהול פרוקסים, אבל זה יכול להיות המוצא האחרון כשה-API נעול הרמטית. המפתח הוא להבין את ה-trade-off: אתם מחליפים מהירות ופשטות תמורת היכולת לעקוף הגנות מורכבות.