פורטל נדל"ן עם חיפוש גיאוגרפי ומחשבון משכנתא

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

פיתוח ותחזוקה של כל סוגי האתרים:

אתרי מידע או יישומי אינטרנט
אתרי תדמית, דפי נחיתה, אתרי חברה, קטלוגים מקוונים, חידונים, אתרי קידום, בלוגים, מקורות חדשות, פורטלי מידע, פורומים, אגרגטורים
אתרי מסחר אלקטרוני או יישומי אינטרנט
חנויות מקוונות, פורטלי B2B, שווקים, בורסות מקוונות, אתרי קאשבק, בורסות, פלטפורמות דרופשיפינג, מנתחי מוצרים
יישומי אינטרנט לניהול תהליכים עסקיים
מערכות CRM, מערכות ERP, פורטלים ארגוניים, מערכות ניהול ייצור, מנתחי מידע
אתרי שירות אלקטרוני או יישומי אינטרנט
פלטפורמות מודעות, בתי ספר מקוונים, בתי קולנוע מקוונים, בוני אתרים, פורטלים לשירותים אלקטרוניים, פלטפורמות אירוח וידאו, פורטלים נושאיים

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
פורטל נדל"ן עם חיפוש גיאוגרפי ומחשבון משכנתא
בינוני
מ- 1 שבוע עד 3 חודשים
שאלות נפוצות

פיתוח פורטל נדל"ן: היכן נשבר חיפוש הנכסים

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

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

זמן התגובה עולה עם כל אלף מודעות, והמסננים לא מוצאים נכסים רק потому, что הערכים מנורמלים באופן שונה — "2-חדרים" ו-"2 חדרים" מאוחסנים במסד כשתי ישויות שונות.

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

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

מה נותן חיפוש מחודש: מהירות, דיוק, עמידות

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

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

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

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

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

אפשרויות מימוש הפורטל: ליבה מוכנה, התאמה, הרכבה

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

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

השוואת גישות

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

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

שלבי עבודה: מניתוח הקטלוג ועד מסירה לתפעול

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

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

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

מה מוסרים לידיים: סכמות, נהלים, תיעוד

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

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

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

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

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

מה שינינו בחיפוש הגאוגרפי

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

שכבת המפות Яндекс Карты, בחירות כבדות מחושבות מראש לפי רשת ומוחזרות מתוך סט מוכן — המסנן מגיב מיד גם לעשרות אלפי נכסים.

כרטיס הנכס

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

חודשיים לאחר ההשקה ההמרה מצפייה בכרטיס לבקשה עלתה מ-1.2% ל-3.4%, שיעור הפניות עם שכונה נבחרת — מ-18% ל-61%. הנשירה בשלב ההתאמה קטנה כמעט פי שניים, והמנהלים החלו לקבל בקשות עם בקשה מגובשת: שכונה, תקציב ופרמטרי משכנתא ידועים לפני השיחה.

במה שונה חיפוש גאוגרפי לפי גבולות שכונות מחיפוש לפי רדיוס?

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

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

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

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

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

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

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

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

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

ספקות טכניים: אינטגרציות, עומס, איכות נתונים

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

איך הפורטל יעמוד בעומס שיא?

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

מה לעשות עם שגיאות במודעות מייצואים?

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

איך מועבר מסד נכסים קיים?

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

מי מלווה את האינטגרציות לאחר ההשקה?

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

נדון במשימה ונחזור עם תוכנית עבודה והערכה

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

מה עוזר לחזור עם תוכנית עבודה, ולא עם מילים כלליות:

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

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

הכישורים שלנו:

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1393
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1368
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1139
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1152
  • פיתוח אתר עבור SBH Partners
    פיתוח אתר עבור SBH Partners
    1231
  • פיתוח אתר עבור Red Pear
    פיתוח אתר עבור Red Pear
    641