לקוח רואה מוצר המסומן כאזל מהמלאי. הכפתור "עדכן אותי כשחוזר למלאי" חסר — והלקוח עוזב למתחרה. גם אם הכפתור קיים, ההרשמה לעיתים קרובות נכשלת עקב באגים: המייל לא מגיע, מגיע עבור מוצר שגוי, או מגיע מספר פעמים. זה בולט במיוחד במהלך סנכרון המוני עם 1C, כאשר עדכוני המלאי מגיעים בקבוצות. המודול שלנו פותר בעיות אלו ברמת הארכיטקטורה, ומבטיח משלוח התראות מהיר ואמין ללא אובדן נתונים או התראות שווא. במהלך עבודתנו, יישמנו מודולים כאלה עבור 30+ פרויקטים עם קטלוגים של עד 100,000 פריטים. על פי הערכותינו, יישום המודול מפחית את נטישת הלקוחות ב-15–20%, ותקופת ההחזר היא 2–3 חודשים הודות לשחזור לידים שאבדו. כל לקוח חוזר מביא בממוצע 3,500 RUB ברווח, ועבור קטלוג של 50,000 פריטים, ההכנסה השנתית הנוספת מגיעה ל-1,200,000 RUB.
כיצד להימנע מאובדן הרשמות בעומס גבוה?
אנו מאחסנים הרשמות בטבלה נפרדת — לא בשדות משתמש של אינפובלוק או ב-b_user, מכיוון שגם מבקרים לא רשומים יכולים להירשם. ארכיטקטורה זו עומדת ביותר מ-10,000 הרשמות פעילות ללא האטת העמוד. אינדקסים על element_id ו-notified_at מבטיחים שליפה מהירה. נקודה קריטית היא קישור להצעת סחר (offer_id): אם למוצר יש מידות או צבעים, התראה נשלחת רק כאשר השילוב הספציפי חוזר למלאי, אחרת המשתמש יקבל ספאם.
CREATE TABLE myvendor_restock_sub ( id SERIAL PRIMARY KEY, element_id INT NOT NULL, offer_id INT, user_id INT, email VARCHAR(255) NOT NULL, phone VARCHAR(20), token CHAR(32) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), notified_at TIMESTAMP, UNIQUE (element_id, offer_id, email) ); CREATE INDEX idx_restock_element ON myvendor_restock_sub(element_id, notified_at); מדוע Debounce הוא קריטי במהלך סנכרון 1C?
חידוש המלאי מתרחש לרוב באמצעות העברה מ-1C דרך CommerceML. אירוע CREATE TABLE myvendor_restock_sub ( id SERIAL PRIMARY KEY, element_id INT NOT NULL, offer_id INT, user_id INT, email VARCHAR(255) NOT NULL, phone VARCHAR(20), token CHAR(32) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), notified_at TIMESTAMP, UNIQUE (element_id, offer_id, email) ); CREATE INDEX idx_restock_element ON myvendor_restock_sub(element_id, notified_at); מופעל על כל שינוי, כולל מצבי ביניים. ללא הגנה, המשתמש יקבל התראה עבור מוצר שיחזור להיות אזל מהמלאי תוך 5 דקות. הניסיון שלנו מראה כי debounce באמצעות תור עם השהיה של 10 דקות מפחית התראות שווא ב-90% בהשוואה לשליחה מיידית. זה יעיל פי 5 מפתרונות מותאמים אישית על שדות משתמש.
// В обработчике OnProductQuantityChange RestockQueueTable::set($elementId, time() + 600); סוכן שרץ כל 5 דקות מעבד רק רשומות שבהן OnProductQuantityChange. אם בתוך 10 דקות אלו המלאי חוזר לאפס, ההתראה לא נשלחת. גישה זו מבטיחה שהמשתמש יקבל מייל רק כאשר המוצר נמצא במלאי באופן עקבי.
ערוצי התראה
| ערוץ | טכנולוגיה | תכונה |
|---|---|---|
| דוא"ל | // В обработчике OnProductQuantityChange RestockQueueTable::set($elementId, time() + 600); עם תבנית process_after < NOW() |
כרטיס מוצר עם מחיר עדכני, קישור, אסימון ביטול הרשמה |
| SMS | שער אבסטרקטי באמצעות קונפיגורציה | אופציונלי, למנויים עם טלפון |
| Web push | Web Push API + Service Worker | למשתמשים שהסכימו לקבל push |
כל ערוץ תומך בביטול הרשמה: דוא"ל — אסימון בקישור, SMS — פקודת STOP, push — כפתור ביטול הרשמה. התראות push יעילות במיוחד למשתמשים ניידים: הן מגיעות גם כשהדפדפן סגור, ומגדילות את ההמרה ב-30%.
התקנת המודול שלב אחר שלב
- התקן את מטפל האירועים
CEvent::Sendב-RESTOCK_NOTIFYאו במודול מותאם אישית. - צור טבלאות הרשמה ותור (סקריפט SQL מסופק).
- הגדר סוכן עם מרווח של 5 דקות לעיבוד התור.
- הצב את טופס ההרשמה בתבנית כרטיס המוצר באמצעות
OnProductQuantityChange. - הגדר תבניות דוא"ל ו-SMS בקטע הניהול.
- בדוק את התרחיש: שנה מלאי ידנית וודא שההתראה נשלחת.
מה כלול בפיתוח
- עיצוב סכימת נתונים ובחירת טריגר (אירוע
init.phpאו מטפל מותאם אישית). - פיתוח טופס ההרשמה ושילובו בכרטיס המוצר.
- הגדרת תבניות דוא"ל ו-SMS.
- מנגנון Debounce למניעת התראות שווא במהלך סנכרון 1C.
- ממשק ניהול: רשימת הרשמות, ייצוא CSV, הפעלה ידנית.
- בדיקות עומס (סימולציה של עדכוני מלאי המוניים).
- מסירת תיעוד והדרכת צוות.
- אחריות ל-12 חודשים על המודול.
- גישה לקוד מקור ותיעוד API.
לוחות זמנים לפיתוח
| היקף | תחום | לוח זמנים |
|---|---|---|
| בסיסי | דוא"ל + טופס הרשמה | 1.5–2 שבועות |
| בינוני | + הצעות סחר + debounce + SMS | 3–4 שבועות |
| מלא | + push + אנליטיקה + CRM | 5–7 שבועות |
העלות מחושבת באופן אישי. קבלו ייעוץ לפרויקט שלכם — צרו קשר. הזמינו פיתוח מודול התראות — נעריך את הפרויקט שלכם בחינם.
תיעוד 1C-Bitrix: אירוע OnProductQuantityChange
ארכיטקטורת תור
התור מאוחסן בטבלה נפרדת $APPLICATION->IncludeComponent(...) עם שדות OnProductQuantityChange, myvendor_restock_queue, element_id. הסוכן בוחר רשומות שבהן process_after ו-status, מעבד אותן, ומסמן אותן כ-process_after < NOW(). זה מבטיח שהתראה בודדת לא נשלחת פעמיים.
CREATE TABLE myvendor_restock_queue (
id SERIAL PRIMARY KEY,
element_id INT NOT NULL,
process_after TIMESTAMP NOT NULL,
status VARCHAR(20) DEFAULT 'pending',
created_at TIMESTAMP DEFAULT NOW()
);







