למה מכבי הוא אתגר שונה מרוב האתרים
רובנו התחלנו ב-scraping של אתרי תוכן או חנויות. המודל פשוט: מקבלים רשימת לינקים, עוברים אחד-אחד, מחלצים HTML, מנתחים, שומרים. קל. כשניגשים ל-scraping של מכבי, המודל הזה נשבר מהר מאוד. הנתונים המעניינים ביותר — כמו זמינות תורים או רשימת סניפים שמבצעים בדיקה מסוימת — לא יושבים בדפי HTML סטטיים. הם נטענים דינמית, לרוב אחרי אינטראקציה של המשתמש. למשל, בחירת התמחות ואיזור גיאוגרפי כדי לראות רשימת רופאים.
זה אומר שספריית requests לבדה פשוט לא מספיקה. אתה תמצא את עצמך מנסה לעשות reverse engineering לבקשות XHR פנימיות, מנחש איזה headers צריך לשלוח, ומדבג tokens של API פנימי. זו דרך ארוכה ומלאת תסכול. הפתרון הנכון ב-2025 הוא להשתמש ב-headless browser כמו Playwright. הוא מריץ דפדפן אמיתי, מנהל את כל ה-JavaScript, ה-cookies וה-session storage בשבילך. במקום להילחם עם ה-API הפנימי, אתה פשוט נותן לדפדפן לעשות את העבודה ומחכה שהמידע יופיע ב-DOM. זה אולי נשמע איטי יותר, אבל הזמן שתחסוך על דיבאג והנדסה לאחור יהיה משמעותי. העבודה כאן היא לא לחלץ טקסט, אלא לדמות משתמש אמיתי כדי לחשוף את הנתונים שאתה צריך.
אסטרטגיית ה-Scraping הנכונה: מעקב זמינות בזמן אמת
ה-use case המרכזי והחזק ביותר עבור מכבי הוא מעקב מלאי/זמינות מכבי. 'מלאי' במקרה הזה הוא תורים פנויים. לחברות בתחום הבריאות הדיגיטלית, או אפילו למערכות פנימיות, היכולת לדעת מתי רופא מומחה ספציפי פנוי היא קריטית. המטרה היא לא להציף את האתר, אלא לבנות תהליך סריקה חכם ומכבד.
האסטרטגיה מורכבת מכמה שלבים. ראשית, בונים רשימה בסיסית של כל הרופאים והשירותים. זהו איסוף קטלוג מכבי הראשוני. אנחנו מדברים על אלפי ישויות, אולי 10,000-15,000 דפים ייחודיים של רופאים ושירותים. לאחר מכן, מתחיל התהליך המחזורי. אי אפשר להכות בשרתים עם 50 בקשות בשנייה. זה יסתיים בחסימה תוך דקות. קצב סביר הוא סביב 1-2 בקשות בשנייה פר IP, תוך שימוש ברוטציה של פרוקסי איכותיים. הצלחה של 98% ומעלה היא יעד ריאלי עם הגישה הזו. השתמשו ב-Playwright כדי לנווט לדף הרופא, לבצע את הפעולות הנדרשות לחשיפת לוח השנה, ולחלץ את התאריכים והשעות הפנויים. המידע הזה צריך להישמר במסד נתונים מובנה, עם חותמת זמן. כך, לאורך זמן, אפשר לנתח מגמות, לזהות מתי תורים חדשים נפתחים, ואפילו לחזות זמינות עתידית. אם אתם לא בטוחים איך להתחיל עם פרוקסי, יש מדריך מצוין לבחירת פרוקסי residential שיכול לעזור.
תרחיש הכישלון הקלאסי: נפילה על State ו-Sessions
ראיתי את זה קורה עשרות פעמים. מהנדס מנסה לחסוך במשאבים ובונה scraper מבוסס requests לאתר כמו מכבי. הוא מצליח לשלוף את עמוד החיפוש הראשי, ואז מנסה לשלוח בקשת POST כדי לקבל את תוצאות החיפוש. לפעמים זה אפילו עובד. אבל אז מגיע השלב הבא: הוא מקבל רשימת רופאים, ומנסה לגשת לכל פרופיל בנפרד עם בקשת GET פשוטה. ובום. כלום לא עובד. הוא מקבל דף שגיאה, דף כניסה, או פשוט דף ריק.
מה קרה? הוא איבד את ה-state. האתר מצפה שהבקשה לפרופיל הרופא תגיע מאותו session שהריץ את החיפוש. ישנם טוקנים ב-cookies, ב-session storage, או אפילו ב-local storage שהדפדפן מנהל אוטומטית. ה-scraper ה'טיפש' שלו לא מודע לכל זה. הוא שולח בקשה 'עיוורת' בלי ההקשר הנכון, והשרת, בצדק, דוחה אותה. זו לא בהכרח הגנה אקטיבית נגד בוטים, אלא פשוט איך ש-web applications מודרניים עובדים. הניסיון לחקות את כל ההתנהגות הזו ידנית הוא סיוט תחזוקתי. כל שינוי קטן ב-frontend של מכבי ישבור לכם את ה-scraper. תפסיקו להילחם בזה. השתמשו ב-Playwright עם stealth ותנו לו לנהל את ה-session. זה הפתרון הנכון, לא פריצה זמנית.
מתי הגישה הזו לא תעבוד: אזורים מאחורי Login
חשוב להבין את הגבולות. כל מה שדיברנו עליו עד עכשיו מתייחס למידע הציבורי באתר מכבי – רשימות רופאים, שירותים, מרפאות, וזמינות תורים כללית. כל זה נגיש למשתמש אנונימי. אבל יש עולם שלם של מידע שקיים רק לאחר הזדהות משתמש. תוצאות בדיקות אישיות, היסטוריית טיפולים, הפניות – כל אלה נמצאים מאחורי חומת ה-login.
הגישה של scraping שאנחנו דנים בה לא מיועדת ולא מתאימה לגישה לנתונים אישיים. זה לא רק אתגר טכני גדול יותר (שדורש ניהול credentials, התמודדות עם אימות דו-שלבי וכו'), אלא זו גם חצייה של גבולות אתיים ומשפטיים ברורים. המטרה שלנו היא לאסוף מידע ציבורי זמין בקנה מידה גדול, לא לפלוש לפרטיות של אף אחד. אם הפרויקט שלכם דורש גישה למידע אישי, web scraping הוא לא הכלי הנכון. אתם צריכים לחפש פתרונות מבוססי API רשמי עם הסכמת משתמש, אם קיימים כאלה. הניסיון לעקוף מערכות הזדהות הוא מתכון לצרות, והוא מפספס את המטרה של איסוף מידע אגרגטיבי ובלתי-אישי.
בניית API נתונים ומודיעין תחרותי
אז אספנו את כל המידע: קטלוג שירותים, רשימת רופאים עם התמחויות, מיקומי מרפאות וזמינות תורים מתעדכנת. מה עכשיו? הערך האמיתי מגיע כשהופכים את הדאטה הגולמי הזה לנכס שמיש. הצעד הבא הוא לבנות API / קובץ נתונים מכבי פנימי. במקום שכל צוות יצטרך להתמודד עם ה-scraper, הם פונים ל-endpoint פנימי יציב שמחזיר להם JSON נקי. דמיינו endpoint של /doctors?specialty=cardiology&city=tel-aviv שמחזיר רשימה מעודכנת. זה משנה את כללי המשחק.
בנוסף, הנתונים האלה הם בסיס למודיעין מתחרים מכבי. כמובן, בהקשר של שירותי בריאות, 'תחרות' היא מילה מורכבת, אבל המידע עדיין בעל ערך אסטרטגי. אפשר לנתח את פריסת הרופאים המומחים גיאוגרפית, לזהות פערים בשירותים באזורים מסוימים, או לעקוב אחר הוספה של שירותים רפואיים חדשים. לדוגמה, אם מכבי מוסיפה 3 מרכזי רפואה דחופה חדשים בצפון, זהו סיגנל משמעותי. הפקת דוח CSV יומי של כ-50MB עם כלל השינויים בקטלוג מאפשרת ניתוח מגמות ארוך טווח. כשנתקלים בשגיאות רשת או חסימות, חשוב לדעת איך לטפל נכון בשגיאות 429 ו-503 כדי לשמור על יציבות התהליך.