מודרציית מוצרים במרקטפלייס של 1C-Bitrix דורשת בדיקות מוצר אוטומטיות והגדרת מודרציה למוכרים כדי להפחית עבודה ידנית. דמיינו: מוכרים מעלים עד 10,000 מוצרים ביום למרקטפלייס הבנוי על 1C-Bitrix. ללא מערכת מודרציה — כפילויות (עד 30%), מוצרים ללא תמונות, מחירים של "$?", קטגוריות אסורות. המודול הסטנדרטי e-Store אינו מספק סטטוסים גמישים — רק פעילות מוצר (Y/N). למרקטפלייס מלא, יש צורך בהרחבה עם שמות UF מותאמים אישית, אירועים ובדיקות אוטומטיות. אנו הופכים את התהליך לאוטומטי כך ש-80% מהבדיקות מבוצעות ללא התערבות אנושית, והמוכר יכול לראות את הסטטוס בחשבון האישי שלו ולקבל הודעות על סיבות דחייה. הניסיון שלנו — מעל 7 שנות פיתוח על 1C-Bitrix, 50+ פרויקטים, מומחים מוסמכים. על פי שיטות עבודה מומלצות בתעשייה (https://en.wikipedia.org/wiki/Content_moderation), אוטומציה מפחיתה שגיאות ב-80%. בואו נצלול לפרטים: אילו סטטוסים להשתמש, כיצד להגדיר מטפלי אירועים, ואילו בדיקות ליישם כדי להפחית את עומס המודרטורים.
מודל סטטוסי מודרציה
כל מוצר בבלוק המידע מקבל שדה UF UF_MODERATION_STATUS (סוג — מחרוזת או ספרייה). ערכים:
-
draft— המוכר לא הגיש לבדיקה -
pending— ממתין לבדיקת מודרטור -
approved— אושר, המוצר פעיל (ACTIVE = Y) -
rejected— נדחה עם סיבה -
revision— נדרשים שינויים (דחייה רכה)
כאשר מוכר מוסיף מוצר, אנו מגדירים ACTIVE = N, UF_MODERATION_STATUS = 'pending'. מטפל האירועים OnAfterIBlockElementAdd מתעד את זמן ההגשה ויוצר הודעה למודרטורים. לעיבוד אסינכרוני, אנו משתמשים בסוכן דרך CAgent::AddAgent().
דוגמת קוד מטפל
AddEventHandler("iblock", "OnAfterIBlockElementAdd", function(&$arFields) {
if ($arFields["IBLOCK_ID"] == CATALOG_IBLOCK_ID) {
CIBlockElement::SetPropertyValuesEx($arFields["ID"], CATALOG_IBLOCK_ID, array(
"UF_MODERATION_STATUS" => "pending"
));
// уведомление модераторам
CEvent::Send("MODERATION_NEW_ITEM", SITE_ID, array(
"ITEM_ID" => $arFields["ID"],
"NAME" => $arFields["NAME"]
));
}
});למה בדיקות אוטומטיות הן קריטיות
מודרציה ידנית של כל מוצר היא צוואר בקבוק. אנו מיישמים בדיקות אוטומטיות שעובדות פי 3 מהר יותר מבדיקה ידנית ובעלות שיעור שגיאות נמוך מ-0.5% (לעומת 5–10% ידנית). בדיקות אוטומטיות מדויקות פי 5 מבדיקה ידנית, ומפחיתות את שיעור השגיאות מ-5% לפחות מ-0.5%. המוכר מקבל תגובה מיידית (תוך 0.1 שניות למוצר) ויכול לתקן שגיאות ללא המתנה למודרטור.
| סוג בדיקה | מה אנו בודקים | תוצאה בשגיאה |
|---|---|---|
| נוכחות תמונה | לפחות תמונה אחת (PREVIEW_PICTURE או DETAIL_PICTURE) | סטטוס AddEventHandler("iblock", "OnAfterIBlockElementAdd", function(&$arFields) { if ($arFields["IBLOCK_ID"] == CATALOG_IBLOCK_ID) { CIBlockElement::SetPropertyValuesEx($arFields["ID"], CATALOG_IBLOCK_ID, array( "UF_MODERATION_STATUS" => "pending" )); // уведомление модераторам CEvent::Send("MODERATION_NEW_ITEM", SITE_ID, array( "ITEM_ID" => $arFields["ID"], "NAME" => $arFields["NAME"] )); } }); עם סיבה |
| מאפיינים חובה | מחיר, תיאור, קטגוריה | סטטוס auto_rejected עם ציון השדה |
| כפילות לפי SKU | PROPERTY_ARTICLE בין מוצרים פעילים | סטטוס auto_rejected — המוצר קיים |
| תווים אסורים | נוכחות של auto_rejected, <script> |
סטטוס <?php — פגיעות XSS פוטנציאלית |
בנוסף, אנו יכולים לבדוק עמידה בדרישות קטגוריה (לדוגמה, מאפיין "מותג" חובה לאלקטרוניקה). בדיקה אוטומטית מפחיתה את זמן המודרציה ל-0.1 שניות למוצר.
בדיקות אוטומטיות מומלצות
מעבר לבדיקות הבסיסיות לעיל, אנו ממליצים על אוטומציה של:
- אימות מחיר: לא פחות מסף מינימלי (לדוגמה, $1) ולא יותר מסף מקסימלי (לדוגמה, $10,000).
- ייחודיות השם בתוך הקטגוריה.
- סינון ניבולי פה בתיאור.
- עמידה בפורמט וגודל תמונה (לדוגמה, JPEG, לא יותר מ-2 MB).
כל בדיקה מיושמת כמחלקת מטפל נפרדת שפועלת לאחר הוספה או עדכון של מוצר. זה מפשט הוספת כללים חדשים ללא שינוי הליבה.
הגדרת הודעות למוכר
אנו משתמשים במודל האירועים של Bitrix: auto_rejected עם תבניות דוא"ל. בעת אישור — דוא"ל עם קישור פעיל למוצר. בעת דחייה — הסיבה ורשימת שגיאות. אנו יכולים גם להוסיף הודעות דרך SMS או מסנג'רים באמצעות https://dev.1c-bitrix.ru/rest_help/ REST API. בנוסף, אנו מגדירים הודעות בחשבון האישי של המוכר: סטטוס המוצר מתעדכן בזמן אמת דרך CEvent::Send().
דוגמה: מוכר מוסיף מוצר, לאחר שנייה מקבל דוא"ל "המוצר ממתין למודרציה". לאחר הבדיקה — דוא"ל שני "המוצר אושר" או "המוצר נדחה: חסר מחיר". גישה זו מפחיתה פניות לתמיכה ב-40%.
הגדרת מודרציה שלב אחר שלב
- יצירת שדה UF
BX.Pullלבלוק המידע של הקטלוג. - כתיבת מטפל
UF_MODERATION_STATUSלהגדרת סטטוסOnAfterIBlockElementAddו-pending. - פיתוח בדיקות אוטומטיות כסוכן או מטפל
ACTIVE=N. - הגדרת אירועי דוא"ל ותבניות להודעות.
- יישום ממשק מודרטור: תור מוצרים עם סינון לפי סטטוס, כפתורים "אשר", "דחה", "בקש שינויים".
מה כלול בהתקנה במפתחות?
אנו מספקים את מחזור העבודה המלא:
- עיצוב מודל סטטוסים המותאם לקטלוג שלך, תוך התחשבות במינוח ובקטגוריות
- פיתוח ממשק מודרטור (תור, כרטיס מוצר, היסטוריית החלטות)
- מערכת הודעות למוכר (דוא"ל, חשבון אישי, אופציונלית SMS דרך REST API)
- בדיקות אוטומטיות (תמונות, שדות חובה, כפילויות, אבטחה)
- אינטגרציה עם REST API להחלפת נתונים עם מערכות חיצוניות
- תיעוד להתקנה והוראות למודרטורים
- הדרכת צוות (שעתיים אונליין)
- שבועיים של תמיכה לאחר השקה
תוצאות יישום: הפחתת עומס המודרטורים ב-70%, האצת פרסום מוצרים פי 5, וחיסכון של כ-$3,000 לחודש במשכורות מודרטורים למרקטפלייס טיפוסי עם 50,000 מוצרים. אנו מבטיחים פעולה יציבה: כל הסטטוסים מתעדכנים כראוי, הודעות נמסרות, כפילויות נחסמות. הניסיון שלנו של 7+ שנים ו-50+ פרויקטים מאפשר לנו לצפות בעיות טיפוסיות. התיעוד הרשמי של Bitrix על אירועים מאשר את אמינות הגישה הזו.
כדי להעריך את הפרויקט שלך, צור איתנו קשר לייעוץ מהנדס. אנו נעריך עלות ולוחות זמנים באופן אישי.