אינטגרציה של 1С-Битрикс עם Dynamic Yield: מדריך שלב אחר שלב

אינטגרציה של 1С-Битрикс עם Dynamic Yield: היכן הפרסונליזציה נשברת

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

כל עוד הכול נמצא בבקשה אחת, הסכימה עובדת; ברגע שנוצר עיכוב בהחלפה בין המערכות, המשתמש רואה מוצר שאינו במלאי, או המלצה על פריט שכבר רכש. אינטגרציה של 1С-Битрикс עם Dynamic Yield היא בראש ובראשונה משמעת של סנכרון אירועים, ולא חיבור סקריפט לעמוד.

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

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

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

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

מה נותן החיבור: מהירות, המרה, יציבות הוויטרינה

מהירות מתן ההמלצות

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

המרת הוויטרינה

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

יציבות הוויטרינה

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

ניהול ומדידת האפקט

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

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

הפרופיל נבנה משני מקורות, לא מאחד

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

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

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

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

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

כללי תצוגה נשענים על עדיפות ותדירות

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

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

מדוע זה משפיע על דיוק ההמלצות

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

דרכי חיבור: השוואה בין אפשרויות אינטגרציה

ישנן בדיוק שלוש דרכים לחבר את הקטלוג וההזמנות בצד 1С-Битрикс עם מנוע הפרסונליזציה, והבחירה ביניהן נעשית לא לפי טעם אישי, אלא לפי היכן נמצא מקור האמת על המוצר ומי אחראי על מהירות התצוגה.

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

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

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

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

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

הכנה וסכימה

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

בדיקה ומסירה

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

תארו את המשימה — נחזור עם הערכה ותוכנית לכל שלב.

מה הלקוח מקבל לידיו: קונפיגורציות, תרשימים, נהלים

אינטגרציה של 1С-Битрикс עם Dynamic Yield היא לא "התקנו תוסף ושכחנו", אלא סט של ארטיפקטים שלפיהם המערכת חיה ומתפתחת ללא מחבר ההטמעה. אנו מעבירים אותם לריפוזיטורי של הלקוח: קונפיגורציות, מפות אירועים, מדיניות גישה, תיעוד ונהלי עדכון.

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

• קונפיגורציות האינטגרציה — קבצי הגדרות חיבור ל-Dynamic Yield, פרמטרים של סנכרון הקטלוג וכללי מיפוי שדות בין 1С-Битрикс לפלטפורמת הפרסונליזציה.
• מפת אירועים — טבלה של "אירוע באתר → אות ב-Dynamic Yield → סגמנט/כלל", עם ציון אילו נתונים נשלחים, באיזה פורמט ובאיזה שלב במשפך הם מופעלים.
• מדיניות גישה — הפרדת הרשאות על מפתחות API, הפרדה בין סביבות (production / staging), רוטציה של סודות וכללים שקובעים מי בצוות יכול לשנות מה ללא אישור.
• תיעוד האינטגרציה — תרשים זרימות נתונים, נקודות הרחבה, תיאור פתרונות לא סטנדרטיים ומגבלות ידועות, כדי שמפתח חדש ייכנס לפרויקט תוך ימים ולא שבועות.
• נהלי עדכון — סדר הוצאת שינויים, בדיקת תאימות בעת עדכון הליבה של 1С-Битрикс והמודולים, תוכנית rollback וקריטריונים שבהם הריליס נעצר.
• צ'ק-ליסט קבלה — תרחישים שלפיהם נבדק שאירועים מגיעים, שסגמנטים נאספים, ושהמלצות מוחזרות כראוי לאחר כל עדכון.
• יומן שינויים — תיעוד של עריכות בקונפיגורציות ובמפות אירועים עם תאריכים ומחברים, כדי להבין מה ומתי השפיע על התנהגות הפרסונליזציה.

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

במה שונה העברת אירועים בזרימה מהעברה בקבוצות?

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

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

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

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

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

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

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

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

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

הלקוח — חנות מקוונת עם קטלוג של כמה עשרות אלפי פריטים על 1С-Битрикс — פנה בתלונה שבלוקי ההמלצות מציגים את אותו הדבר: המשתמש רואה מוצר בכרטיס המוצר, מסך אחד לאחר מכן — בבלוק "דומים", ועוד מסך אחד לאחר מכן — ב"צפית לאחרונה". תצוגות חוזרות ונשנות אכלו מקום בעמוד, ושיעור המעברים הממוקדים מבלוקי ההמלצות עמד על כ-4%.

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

מה שינו

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

מדדים לפני ואחרי

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

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

ספקות טכניים נפוצים בעת אינטגרציה

אינטגרציה של 1С-Битрикс עם Dynamic Yield לעתים רחוקות נשברת בשלב "חיבור הסקריפט". הספקות הטכניים העיקריים מתעוררים מאוחר יותר: האם חלון הראווה יעמוד בעומס נוסף, האם הקטלוג לא יתפצל בין המערכות, מה יקרה בעת עדכון הפלטפורמה. להלן — תשובות למה שנשאל לרוב לפני ההתחלה.

כיצד עדכוני הקטלוג ב-1С מגיעים להמלצות?

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

מה יקרה בעת עדכון Битрикс או החלפת תבנית?

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

האם ניתן לבטל את האינטגרציה ללא השבתת חלון הראווה?

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

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

אינטגרציה של 1С-Битрикс עם Dynamic Yield לעיתים רחוקות היא "להתקין סקריפט ולשכוח": יש לתאם אילו אירועים נשלחים למערכת, כיצד הם מקושרים לקטלוג ולהזמנות, היכן נשמרים מזהי המשתמש וכיצד כל זה שורד עדכוני פלטפורמה.

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

מה תקבלו בסופו של דבר:

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

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

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