פיתוח אגרגטור מחירים להשוואת מחירים — מפתח מלא

אתם נכנסים לאתר, מקלידים "Samsung Galaxy S24", והוא מציג מחירים מ-20 חנויות, ממיין לפי הזול ביותר, ומשרטט גרף היסטוריית מחירים. אנחנו בונים אגרגטורי מחירים כאלה—פלטפורמות שאוספות מחירים אוטומטית, מתאימות מוצרים, ומציגות למשתמשים את ההצעות הטובות ביותר. טכנית, זו משימה מורכבת: ניתוח מקורות הטרוגניים (YML, API, HTML), נורמליזציה של נתונים, התאמה עמומה (fuzzy matching), ועדכונים שוטפים. כל שלב מלא במלכודות: מהגבלת קצב בקשות (rate limiting) ועד להבדלים בשמות מוצרים. עם ניסיון של למעלה מ-10 שנים, בנינו מערכות איסוף והתאמה עמידות לתקלות שמעבדות עד מיליון מוצרים ביום. שגיאת התאמה—ומשתמשים רואים מחירים שגויים או כפילויות. גרידת אתרים (web scraping) ללא בקרה—חסימות ועונשים. אנו מבטיחים יציבות ודיוק נתונים באמצעות ארכיטקטורה מחושבת, ועוזרים ללקוחותינו לחסוך עד 40% מהתקציב על ידי ביטול בדיקות ידניות.

כיצד לארגן איסוף נתונים ממקורות שונים?

מקורות נתונים

נתוני מוצרים ומחירים מגיעים בשלוש דרכים:

• רשימות מחירים ופידים (feeds) — החנות מספקת קובץ YML, XML, או CSV עם המבחר העדכני. המקור האמין ביותר: נתונים מובנים, שותפות רשמית, ללא סיכון לחסימות. Yandex.Market YML הוא התקן דה-פקטו לשוק דובר הרוסית.
• ממשקי API של שותפים — חלק מהחנויות מספקות REST APIs. התיעוד לעיתים קרובות חלש, ומגבלות הבקשות נוקשות. לפי התיעוד הרשמי של Yandex, קישורי שותפים דורשים אישור מוקדם.
• גרידת אתרים (Web scraping) — עבור חנויות ללא פידים. סיכון גבוה: CAPTCHA, הגבלת קצב, שינויי עיצוב, חסימת IP. דורש תחזוקה מתמדת.

בתחילת דרכו של אגרגטור, עדיף לעבוד רק עם פידים ו-APIs—הם יציבים יותר. אנו מוסיפים גרידה סלקטיבית עבור מקורות מפתח.

ארכיטקטורת אוסף הנתונים

Scheduler (Celery Beat / Laravel Scheduler)
↓ каждые N часов FeedFetcher workers (по одному на источник)
↓ RawData storage (S3 или локальная FS)
↓ Parser workers (XML/CSV/JSON → нормализованные объекты)
↓ Normalizer (приведение единиц, очистка текста)
↓ Matcher (сопоставление с товарами в БД)
↓ PriceHistory (запись in timeseries)
↓ ElasticsearchIndexer (обновление индекса)

תור משימות: Celery + Redis לסטאק Python, Laravel Horizon + Redis לסטאק PHP. כל פיד מעובד באופן עצמאי; שגיאה במקור אחד לא חוסמת אחרים.

ניתוח Yandex.Market YML

YML הוא XML עם סכמה קפדנית. שדות קריטיים:

<offer id="12345" available="true">
  <url>https://shop.example.com/product/12345</url>
  <price>4990</price>
  <currencyId>RUB</currencyId>
  <categoryId>14</categoryId>
  <name>Samsung Galaxy A55 128GB</name>
  <vendor>Samsung</vendor>
  <model>Galaxy A55</model>
  <barcode>8806095076783</barcode>
  <param name="Цвет">Синий</param>
  <param name="Объём памяти">128 ГБ</param>
</offer>

הברקוד (barcode) הוא המפתח הטוב ביותר להתאמה. GTIN/EAN הוא ייחודי לכל וריאציה של מוצר. אם ברקודים קיימים עבור רוב הספקים, ההתאמה הופכת לטריוויאלית. לפי תיעוד Yandex.Market, ברקוד הוא רכיב מומלץ להתאמה מדויקת.

מדוע התאמת מוצרים היא השלב המרכזי?

זה החלק המורכב ביותר באגרגטור. המשימה: לקבוע ש-Samsung Galaxy A55 128GB Blue מחנות A ו-Smartphone Samsung Galaxy A55 (SM-A556B) 128 Gb Blue מחנות B הם אותו מוצר.

שיטות דטרמיניסטיות

• התאמת GTIN/EAN: אם לשני המוצרים יש ברקוד—התאמה חד-משמעית.
• מספר חלק של היצרן (MPN): SM-A556B הוא ייחודי בתוך המותג.
• קנוניזציה של URL: חלק מהחנויות כוללות GTIN ב-URL.

התאמה עמומה (Fuzzy Matching)

from rapidfuzz import fuzz

def match_score(title_a: str, title_b: str, brand_a: str, brand_b: str) -> float:
    if brand_a.lower() != brand_b.lower():
        return 0.0
    title_similarity = fuzz.token_sort_ratio(title_a, title_b)
    return title_similarity / 100

סף התאמה: 0.85+ נחשב להתאמה אוטומטית, 0.65–0.85 נשלח לבדיקה ידנית, מתחת—מוצר חדש.

גישת ML

ייצוגי שמות מוצרים (sentence-transformers, ruBERT) + דמיון קוסינוס. מדויק משמעותית יותר מ-fuzzy, במיוחד עבור ניסוחים שונים של אותו מוצר. המודל מאומן על התאמות שאושרו היסטורית.

מבנה אחסון:

canonical_products (id, gtin, mpn, brand, name, category_id, attrs JSONB)
source_offers (id, source_id, external_id, canonical_product_id, price, url, in_stock, updated_at)
match_candidates (offer_id, canonical_id, score, status) -- pending | approved | rejected

כיצד מתעדכנים מחירים ונשמרת היסטוריה?

היסטוריית מחירים

הערך המרכזי של אגרגטור הוא לא רק המחיר הנוכחי אלא גם היסטוריית השינויים. כל שינוי מחיר נרשם, לא מוחלף.

price_history (
    id BIGSERIAL,
    source_offer_id BIGINT,
    price NUMERIC(12,2),
    in_stock BOOLEAN,
    recorded_at TIMESTAMPTZ DEFAULT NOW()
)

לאחסון סדרות זמן אנו משתמשים ב-TimescaleDB—הרחבה של PostgreSQL שמחלקת את הטבלה לפי זמן. חלופות: InfluxDB או ClickHouse לעומסים גבוהים (עד 10,000 הכנסות בשנייה).

גרף היסטוריית מחירים הוא רכיב סטנדרטי בעמוד המוצר. אנו משתמשים ב-Chart.js או Recharts, ומצברים נתונים לפי יום: Scheduler (Celery Beat / Laravel Scheduler) ↓ каждые N часов FeedFetcher workers (по одному на источник) ↓ RawData storage (S3 или локальная FS) ↓ Parser workers (XML/CSV/JSON → нормализованные объекты) ↓ Normalizer (приведение единиц, очистка текста) ↓ Matcher (сопоставление с товарами в БД) ↓ PriceHistory (запись in timeseries) ↓ ElasticsearchIndexer (обновление индекса) .

תדירות עדכון

כשמחיר משתנה—ביטול מטמון העמוד וחישוב מחדש של המחיר המינימלי באינדקס.

כיצד להגדיר איסוף נתונים ב-4 שלבים

1. חיבור מקורות: השגת פידי YML מחנויות או הגדרת גישת API. מקור אחד = קונפיגורציה אחת.
2. הגדרת ניתוח: עבור פידים—שימוש במנתח YML/XML מוכן; עבור APIs—כתיבת מתאם לפי התיעוד.
3. הפעלת התאמה: הגדרת סט כללים—עדיפות GTIN, אחר כך fuzzy, ואז ML. התחילו עם אימות ידני.
4. ניטור ועדכון: הגדרת מתזמן Celery או Horizon, הוספת התראות לכשלי מקורות.

מה כולל פיתוח אגרגטור

כתוצאה מכך, אתם מקבלים:

• תיעוד לשילוב מקורות (תיאורי פורמטים, דוגמאות).
• תשתית פרוסה (Docker, CI/CD, ניטור).
• פאנל ניהול לעריכת התאמות וצפייה בסטטיסטיקות.
• הכשרת צוות הלקוח לתפעול המערכת.
• תמיכה טכנית למשך 3 חודשים לאחר ההשקה.
• אחריות על נכונות ההתאמות ועדכוני מחירים בזמן.

רוצים לדון בפרויקט שלכם? צרו קשר להערכת עלות. קבלו ייעוץ מהנדס ללא התחייבות.

הניסיון שלנו

למעלה מ-10 שנים בשוק, 40+ פרויקטים מיושמים. אנחנו לא רק כותבים קוד—אנחנו מתכננים ארכיטקטורה שלא קורסת תחת עומס ומתרחבת בקלות. נבחן את הפרויקט שלכם. צרו קשר—נציע ארכיטקטורה, לוחות זמנים, ותמחור סוהר.