פיתוח אפליקציה לנייד להשוואת מחירים

למה השוואת מחירים נשברת בקטלוגים אמיתיים

חנויות ומרקטפלייסים מוסרים קטלוגים בפורמטים שונים: ייצוא CSV, מחירוני XML, JSON דרך ממשק, וחלק מהמקורות צריך לפרסר ישירות מתוך סימון העמודים. לאותו מוצר בשני קטלוגים שונים סדר המילים בשם שונה, המפרידים במק"טים שונים, יחידות המידה שונות וקבוצת המאפיינים שונה.

השוואה לפי התאמה מדויקת של מחרוזת בקטלוגים הטרוגניים מפספסת בעשרות אחוזים מהמקרים, וזאת עוד לפני שמביאים בחשבון את הגורם האנושי בנתונים עצמם.

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

סיפור בפני עצמו — ייצואים מיושנים. מקורות מתעדכנים בתדירות שונה: אחד מוסר נתונים כל שעה, אחר פעם ביום, שלישי רק לפי דרישה.

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

וגומרת את העניין איכות הנתונים על המוצרים: מאפיינים ריקים, סימונים שונים של צבע ונפח, מותג שלפעמים בשם ולפעמים בשדה נפרד.

לכן את ההתאמה בונים לא על מחרוזת אחת, אלא על קבוצת סימנים — מק"ט ומזהה גלובלי, מותג, מאפיינים מרכזיים, קרבה בין השמות — וכללי הנרמול וספי ההתאמה מכווננים לקטלוג המסוים. בהמשך נפרט כיצד זה נסגר: מקבלת הייצואים ועד לכללי ההדבקה ובקרת הטריות.

מה נותנת השוואת מחירים מדויקת: כיסוי, טריות, אמון

השוואת מחירים עובדת לא כשבקטלוג יש הרבה חנויות, אלא כשעבור כל פריט אפשר לבדוק שלושה גדלים: שיעור המוצרים עם מחיר תקין, הזמן משינוי המחיר אצל המקור ועד להופעתו באפליקציה, ומספר הפניות לתמיכה בנושא «המחיר לא תאם».

את שלושת המדדים האלה אנחנו מכניסים לתהליך הקבלה — אחרת ה«השוואה» נשענת על תחושה, ולא על נתונים בדיקים.

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

קטגוריות פופולריות נבדקות לעתים קרובות יותר, והזנב הארוך פחות: המאמץ מופנה לשם, היכן שהמחיר באמת משפיע על הבחירה.

טריות המחירים נשענת על לוח הזמנים של העדכונים. קטגוריות מהירות נסרקות לעתים קרובות ובמנות קטנות, איטיות — פחות, לפי לוח זמנים; במקום טעינה מחדש של כל הקטלוג, מתעדכנים רק הפריטים שהשתנו, ולכן המחיר מגיע לאפליקציה בתוך דקות ולא בתוך יממה. בנפרד מוגדרת ההתנהגות כשהמקור אינו זמין: המחיר המאומת האחרון נשמר עם חתימת זמן, ולא מוחלף בניחוש.

פניות לתמיכה הן המדד הכי כן: הקונה כותב כשראה באפליקציה דבר אחד, ובקופה — אחר. הירידה נובעת לא רק מדיוק הנתונים, אלא גם מהתנהגות המסך בעת אי-התאמה: סימון «המחיר אומת לתאריך», הסבר קצר של הסיבה ומשוב בנגיעה אחת. זה הופך תלונה לאות להצלבה, ושיעור אי-ההתאמות הופך לגודל נשלט, ולא לרעש רקע.

אפשרויות לקבלת נתונים: ייצואים תקופתיים ואיסוף מחזיתות

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

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

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

שלבי העבודה: מפרסור הנתונים ועד הרצה ומסירה

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

1. פרסור המקורות. בוחנים כיצד החנויות מוסרות קטלוגים: ייצואים, ממשקים פתוחים, סימון עמודים. מתעדים את תדירות העדכון, קיומם של מק"ט וברקוד, ומגבלות העומס על המקור.
2. סכמת ההתאמה. מתכננים כללים לאיחוד המוצר לכרטיס אחד: מזהים מדויקים, אחר כך צירוף «מותג + דגם», ואז פירוק השם. בנפרד מתארים קטגוריות ויחידות מידה — אחרת השוואת המחירים מייצרת זוגות שגויים.
3. הגדרת העדכונים. המחירים מחושבים מחדש לעתים קרובות יותר, הקטלוג פחות. מגדירים תור בקשות, חזרות כשהמקור אינו זמין, וצבירת היסטוריית מחירים — בלעדיה אי אפשר להציג דינמיקה.
4. בדיקה על נתונים אמיתיים. מריצים את הזרימה על פני תקופה ומצליבים: שיעור הכרטיסים שאוחדו, הדבקות שגויות, פריטים שהוחמצו. הקבלה נעשית על קטגוריות חיות, ולא על מדגם מוכן.
5. הרצה. מוציאים את העדכונים למסלול העבודה, מפעילים התראות על נפילת מקור ותגובות איטיות, ובודקים את התנהגות האפליקציה כשהנתונים חלקיים.
6. מסירת הפרויקט. מוסרים תיעוד של המקורות והכללים, תקנון עדכונים, הרשאות גישה, ומלמדים את צוות הלקוח לעבוד עם הסימון.

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

הרכב האספקה: סכמות נתונים, תקנוני עדכון, הרשאות גישה

האספקה נסגרת לא בתאריך השחרור, אלא בחבילת ארטיפקטים שלפיה אפשר לפתח ולתחזק את האפליקציה בלעדינו. להלן מה שנשאר בידי הצוות שלכם יחד עם קוד המקור.

• סכמת הנתונים. יישויות של מוצר, חנות, הצעה והיסטוריית מחיר, הקשרים והמפתחות שלהן — מהסכמה מיד רואים היכן נשמר מקור האמת לכל כרטיס וכיצד נבנית התוצאה בעת ההשוואה.
• תיאור המקורות. רשימת ערוצי הגעת המחירים (ייצוא לפי לוח זמנים, קובץ, ממשק פתוח של החנות), הפורמט שלהם, התדירות והמגבלות על מספר הפניות.
• כללי ההתאמה. נרמול שמות, דגמים ומאפיינים, ספי התאמה ותור לבדיקה ידנית של זוגות שנויים במחלוקת — כדי שאותו מוצר לא יתפצל לכמה כרטיסים.
• תקנון העדכון. לוח זמנים לבנייה מחדש של המחירים, סדר הפעולות כשהמקור אינו זמין, והכלל שלפיו הצעה מיושנת מוסתרת ולא מוצגת עם המחיר הקודם.
• מסירת הרשאות גישה. חשבונות של שירותים ופאנלים, מפתחות אינטגרציות, הרשאות לפרסום גרסאות (builds), אנשי קשר אחראיים בצד החנויות.
• תיעוד פנימי. מפת השירותים, סכמת הפריסה, סדר החזרה לאחור של מהדורה ופעולות תמיכה שגרתיות עם תיאור התוצאה הצפויה.
• מדדי האיסוף. פאנל עם שיעור המקורות שנקלטו בהצלחה, אחוז הפריטים שהותאמו, והשהיה בין שינוי המחיר להצגתו למשתמש.

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

מקרה בוחן: צמצמנו את אי-ההתאמות בנתונים ואת זמן העדכון

היכן זה נשבר קודם

שירות השוואת מחירים אסף הצעות מכמה מאות חנויות: ייצואי מחירונים הגיעו בפורמטים שונים, והתאמת הפריטים נעשתה לפי מחרוזת השם. «סמארטפון X 128GB שחור» ו«סמארטפון X, 128GB, Black» נשארו מוצרים שונים, ואילו דורות סמוכים של אותה סדרה הודבקו זה לזה.

שיעור הפריטים השגויים בתוצאות עמד על 12–14%, המחיר בחזית פיגר אחרי אתר החנות בעשרות דקות, והתמיכה טיפלה בזרם של פניות אחידות «יש לכם מחיר שגוי».

מה שינינו ומה יצא

העברנו את ההתאמה למפתח יציב: מק"ט יצרן וברקוד, היכן שהם קיימים, ובנוסף נרמול של השם והמאפיינים לשאר הכרטיסים.

את ההצלבה עם קטלוג הייחוס Google Merchant Center הפכנו לתקופתית, ואת אי-ההתאמות — לגלויות: הזוג מקבל ציון ביטחון, והתאמות שנויות במחלוקת עוברות לבדיקה ידנית, ולא לתוצאות.

את עדכון המחירים העברנו לעיבוד זרימת שינויים — מחושבים מחדש רק הפריטים שנגעו בהם והשכנים שלהם בהשוואה, ולא כל הקטלוג כולו.

שיעור הפריטים השגויים ירד ל-0.6–0.9%, זמן התגובה לשינוי מחיר התקצר מעשרות דקות ל-1–3 דקות בזרימה החמה. העומס על התמיכה ירד בערך פי שישה: תיקונים ידניים בקטלוג הצטמצמו לטיפול בכרטיסים דו-משמעיים, ופניות שגרתיות נסגרו מעצמן.

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

מה לעשות אם המקורות כבר מחוברים, אבל הנתונים לא מתכנסים?

אי-ההתאמות כמעט לעולם לא נמצאות באפליקציה — הן נמצאות בכללי ההתאמה של מוצרים בין המקורות. אם הקטלוגים מחוברים, והמחירים על אותו מוצר מתפצלים, כנראה שלא תאמו הנרמול של השם, יחידת המידה, המק"ט או המטבע. אין смысл לכתוב מחדש את האפליקציה — הקוד החדש יירש את אותן שגיאות.

הביקורת מתחילה במדגם, ולא בקוד. מייצאים את אי-ההתאמות על פני תקופה ומחלקים אותן למחלקות: מוצר שלא מצא זוג, שמצא זוג שגוי, שהתאים בשם אך לא במאפיינים. השיעור של כל מחלקה קובע את סדר העבודה — בדרך כלל את עיקר הרעש מייצרות מחלקה או שתיים.

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

יחידות מידה ומשקל מתועדים בנפרד: מחיר לקילוגרם או לליטר מתפצל לעתים קרובות ביותר — כך קורה גם בייצואים כמו Google Shopping.

שדרוג מדורג זול יותר מבנייה מחדש מלאה. שכבת הנרמול משתנה צעד אחר צעד, והחוזה של התוצאות נשאר כשהיה, ולכן יציבות האפליקציה לא נפגעת: השוואת מחירים, המועדפים וההתראות עובדים על אותם נתונים. האפקט מדיד אחרי כל שלב — שיעור הפריטים המותאמים עולה, והזוגות השגויים מתמעטים.

קריטריון המוכנות אינו «אין אי-התאמות», אלא שיעור נשלט וחזרה לאחור מובנת: כלל שהרע את התוצאות מוסר בהגדרה בלי מהדורה חדשה. תארו אילו מקורות מחוברים והיכן הם מתפצלים — נחזור עם תוכנית ביקורת.

ספקות טכניים נפוצים: התאמה וטריות נתונים

התאמת מוצרים היא המקום שבו האמון בתוצאות נשבר לעתים קרובות ביותר: אותו מוצר מגיע ממקורות עם שמות, מק"טים ויחידות מידה שונים. לכן אנחנו משווים לא מחרוזות, אלא קבוצת סימנים — דגם, מאפיינים, קטגוריה — ומאחדים אותם לכרטיס קנוני.

להלן שאלות שבדרך כלל נשאלות בקבלה: מגבלות המקור, התנהגות בלי חיבור לרשת, והוספת ספקי נתונים חדשים.

מה רואה אדם בלי חיבור לרשת?

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

איך מחברים ספק נתונים חדש?

המקור מתווסף כמודול נפרד: מתארים את מבנה התוצאות שלו, ממירים את השדות לסכמה אחודה ומשלבים בזרימה המשותפת. שאר המקורות נשארים ללא שינוי. אם הספק משנה את מבנה התוצאות, התיקונים נשארים בתוך המודול שלו, והאפליקציה ממשיכה לעבוד.

מי אחראי לאמינות המחירים?

אנחנו אחראים על קבלת הנתונים, ההתאמה וההצגה, והמקור — על מה שהוא מוסר. לצד המחיר רואים מתי הוא התעדכן ומאין הגיע, ואי-ההתאמות נרשמות ביומן. זה מסיר את המחלוקת «האפליקציה הציגה מחיר שגוי» עוד לפני הפנייה לתמיכה.

נדון במשימה: מה נדרש להערכה ולתוכנית עבודה

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

• מקורות מחירים: ממשקי שותפים של חנויות, ייצואי קטלוגים, עמודים פתוחים — מה זמין ובאילו תנאים.
• גאוגרפיה ורשתות: מדינות וערים, האם נדרשים מחירים אזוריים ובאיזה מטבע מוצגת העלות.
• התאמת מוצרים: האם קיימים ברקודים ומק"טים של ספקים, ולפי אילו סימנים אנחנו רואים בשתי הצעות מוצר אחד.
• תרחישי משתמש: חיפוש, רשימת השוואה, היסטוריית מחיר, התראה על ירידת מחיר, מועדפים, כניסה לחשבון.
• עומס: כמה מוצרים וחנויות, באיזו תדירות מחושבים המחירים מחדש, וכמה טריים הנתונים צריכים להיות.
• הרשאות וכללים: הסכמים עם החנויות, מגבלות על שימוש בנתונים שלהן, דרישות לנתונים אישיים.
• אנליטיקה ופרסום: מה נחשב לפעולה ממוקדת, באילו חנויות אפליקציות מפרסמים, ומי מחזיק בחשבונות.

לפי נתוני הפתיחה הללו אנחנו חוזרים עם תוכנית עבודה: שלבים, הרכב הצוות — פיתוח מובייל, צד שרת, נרמול נתונים, בדיקות — והערכת לוחות זמנים עם סדר השחרורים. תארו את המשימה ושלחו את מה שכבר קיים: נחזור עם הערכה ותוכנית.