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

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

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

קודם כל - על מה מנטרים

בעיות שונות דורשות תדירויות בדיקה שונות ותגובות שונות. היו מפורשים:

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

קודם כל APIs רשמיים

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

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

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

להתריע על מעברים, לא על ערכים

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

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

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

זה הופך את נפח ההתראות ליחסי למספר הדברים שבאמת משתבשים, וזה הנפח היחיד שאדם ימשיך לשים אליו לב.

השהיית רגישות, או למה ההתראות שלכם מושתקות

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

שני מנגנונים מתקנים את זה:

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

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

לאן ההתראות צריכות להגיע

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

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

קנה מידה ועלות

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

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

לכבד את היעד

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

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