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

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

שינוי אינו ידיעה עד שיש לו הקשר

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

אירוע שאפשר לפעול לפיו נראה אחרת. הוא אומר: בעמוד התמחור, בשורת החבילה הבינונית, המספר עבר מ-249 ל-299, נצפה ב-14 באוגוסט בשעה 07:12, והשינוי נוגע לתמחור שלכם. אותה כמות טכנולוגיה, הבדל מוחלט בשימושיות.

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

מה בעצם מכילה רשומת אירוע שינוי?

שמונת השדות שהופכים התראה למשהו שאפשר לפעול לפיו:

• source_url - הכתובת המדויקת שנקראה, לא שם האתר.
• region - שם עסקי לאזור בעמוד: "שורת מחיר - חבילה בינונית", "רשימת לקוחות", "כותרת ראשית".
• previous_value ו-current_value - הערכים אחרי נרמול, כטקסט קצר.
• observed_at - זמן הצפייה שלכם, ב-UTC, ולא זמן הפרסום שהאתר מציג.
• previous_observed_at - מתי נצפה הערך הקודם. הפער בין השניים הוא רזולוציית אי-הוודאות שלכם.
• layer - אתר, מוצר או מסר.
• evidence_ref - הפניה לצילום הגולמי שנשמר, למקרה שמישהו יטען שהמערכת טעתה.
• confidence - האם הזיהוי היה על עוגן יציב או על ניחוש מיקום.

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

נרמול לפני השוואה: מה מוחקים כדי שלא יזעק

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

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

אחרי הנרמול משווים טקסט, ולא סימון. הדרך הפשוטה לאחסן זאת היא לשמור גיבוב לכל אזור, ולהשוות גיבובים. ארכיון האינטרנט עושה בדיוק את זה בממשק ה-CDX שלו: כל שורה מחזירה urlkey, timestamp, original, mimetype, statuscode, digest ו-length, כאשר digest הוא גיבוב של התוכן שנשמר. שתי שורות עם אותו digest הן אותו תוכן, וזו הבדיקה הזולה ביותר שקיימת.

שלוש שכבות שינוי, שלוש תגובות

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

מה מגלה שינוי ראשון - מפת אתר, הזנה או העמוד עצמו?

לפי הסדר, מהזול ליקר:

1. sitemap.xml. פרוטוקול Sitemaps מגדיר <lastmod> כתאריך השינוי האחרון של הקובץ, ומאפשר קובץ אינדקס שמפנה לקבצי משנה. הורדה אחת מגלה עמודים שנוספו, עמודים שהוסרו, ותאריכי שינוי מוצהרים. חשוב לזכור ש-lastmod מוצהר על ידי האתר ולכן אינו בהכרח מדויק.
2. הזנת RSS או Atom. אם קיימת, היא נותנת פריטים עם חותמת זמן בלי לנחש.
3. בקשה מותנית לעמוד. תקן HTTP מגדיר ETag ו-Last-Modified בתגובה, ואת If-None-Match ו-If-Modified-Since בבקשה. תגובת 304 אומרת "לא השתנה" בלי להוריד את הגוף - זה חוסך תעבורה גם לכם וגם לשרת שאינו שלכם.
4. הורדה מלאה והשוואה. רק כשאין אף אחת מהאפשרויות למעלה.

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

שלוש דרכי הכשל של ניטור שינויים

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

מהתראה לתדריך: מה עושים עם האירועים

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

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

מקורות

• Sitemaps XML protocol - הגדרת lastmod וקובץ אינדקס
• RFC 9110 - HTTP Semantics, בקשות מותנות ו-ETag
• Wayback CDX Server API - שדות התשובה כולל digest