התראות על קשרים בין ישויות

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

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

מגדירים ישות הורה - הקטלוג שהרשומות שלו משתנות (למשל concert_tickets או series) - ובוחרים איך למצוא את הקהל: רשימת הצטרפות קשורה (ישות המתנה / מעקב) או אנשים שעבורם נרשם אירוע רלוונטי (צפו / התעניינו). ראו שתי דרכים להגדיר את הקהל למטה.

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

למה שתי ישויות?

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

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

שתי דרכים להגדיר את הקהל

לפני ההגדרה - הבחירה המרכזית: מי יקבל התראה:

• התנהגותי (audienceSource: "event") - האנשים שעבורם נרשם אירוע שמביע כוונה (למשל Watched Episode, Viewed Flight) ומפנה לרשומה בתוך חלון מבט לאחור. אין רשומות מעקב/המתנה לתחזק - הקהל הוא ההתנהגות. זה משקף איך חזרה‑למלאי של מוצרים בונה את הקהל מאירועי גלישה. מתאים ל"להודיע לכל מי שצפה / התעניין".
• מפורש (audienceSource: "child_entity", ברירת מחדל) - השורות של ישות הצטרפות קשורה (רשימת "Notify me", רשימת "Follow this show"). מתאים כשאנשים נרשמים במכוון, בנפרד מכל התנהגות.

לא צריך ישות מעקב עבור מקרה ה‑VOD - ראו דוגמה 2.

"Notify me" כאירוע מול ישות המתנה

שאלה נפוצה: אם לחיצה על "Notify me" פולטת אירוע (Notify Me עם product_id), האם עדיין צריך ישות המתנה? בדרך כלל לא - הגדירו אותו כאירוע הכוונה במצב event (intentEvent: "Notify Me", intentRefProperty: "product_id") וזהו.

הדבר היחיד שמחזיר אתכם לישות ילד הוא עמידוּת. קהל מבוסס אירוע מוגבל על ידי שני גורמים:

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

תזמון חזרה‑למלאי פתוח - פריט עשוי לחזור בשבוע הבא או בעוד שמונה חודשים. אם אירוע "Notify me" כבר נמחק בשל מדיניות השמירה עד שהפריט חוזר למלאי, קהל האירוע לא יכלול את האדם הזה; שורת המתנה נשמרת עד שתנקו אותה. לכן:

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

הגדרה

הגדירו relationshipAlert בהגדרות ישות ההורה:

שדה	משמעות	דוגמה
enabled	הפעלת ההתראה	true
triggerMode	איזה שינוי ב־field מפעיל את ההתראה (ראו למטה)	"restock"
field	שדה ההורה ששינוי הערך שלו מפעיל את ההתראה	"available"
eventName	האירוע שייפלט לכל משתמש	"back_in_stock"
cooldownDays	תקופת צינון לכל צמד של אדם ורשומה (ברירת מחדל 7)	7
audienceSource	"child_entity" (ברירת מחדל) או "event"	"event"
childEntity	(מצב child) השם הפנימי של ישות ההמתנה/המעקב	"ticket_waitlist"
childRefField	(מצב child) השדה ברשומת הילד שמכיל את מזהה רשומת ההורה	"ticketId"
intentEvent	(מצב event) אירוע הכוונה שלפיו ייבנה הקהל	"Watched Episode"
intentRefProperty	(מצב event) מאפיין האירוע המחזיק את מזהה רשומת ההורה	"series_id"
intentLookbackDays	(מצב event) כמה רחוק אחורה לחפש (ברירת מחדל 90)	90

מצבי טריגר

• restock - מספר עובר מ־≤ 0 ל־> 0 (חזרה למלאי). ברירת מחדל.
• increase - מספר עולה (למשל מספר פרקים 8 → 9).
• changed - ערך משתנה לערך חדש ולא ריק (למשל "מזהה הפרק האחרון").

במצב child_entity חייב להיות מוגדר בישות הילד User Link (איזה שדה ממופה לאיש קשר - לפי user id / external id / email / phone / attribute) - כך כל שורה מקושרת לאדם. במצב event ה‑user_id של אירוע הכוונה הוא איש הקשר. שינוי מערך קודם לא ידוע אינו מפעיל התראה (במצבים המספריים), כך שהזנה ראשונית אינה יוצרת התראת שווא.

---

דוגמה 1 - כרטיסי הופעה חוזרים למלאי

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

1. ישות הורה concert_tickets עם שדה מספרי available.

2. ישות ילד ticket_waitlist עם השדות ticketId (הרשומה/הופעה שאליה היא מפנה) ו‑email. הגדירו את User Link שלה ל‑email.

3. על concert_tickets, הגדירו:

   {
     "relationshipAlert": {
       "enabled": true,
       "triggerMode": "restock",
       "field": "available",
       "childEntity": "ticket_waitlist",
       "childRefField": "ticketId",
       "eventName": "back_in_stock",
       "cooldownDays": 30
     }
   }

4. כשמישהו לוחץ "Notify me", האפליקציה/האתר מוסיפים שורה ל‑ticket_waitlist: { ticketId: "SHOW-A", email: "fan@example.com" }.

5. כאשר concert_tickets/SHOW-A available עובר 0 → 50, Joryio פולטת אירוע back_in_stock לכל איש קשר ברשימת ההמתנה.

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

{{ event.name }} tickets are back! Grab yours before they sell out again.

האירוע נושא גם את event.record_id, event.new_value (המלאי החדש), וכל שדה סקלרי של הרשומה.

---

דוגמה 2 - פרק חדש בסדרה שמישהו צופה בה (VOD / בסגנון Netflix)

מטרה: כשיוצא פרק חדש בסדרה, להודיע לכל מי שצפה בה.

האם צריך ישות "מעקב", או שאפשר פשוט להשתמש באירוע צפייה? אפשר להשתמש באירוע הצפייה - ולמקרה ה‑VOD זו הבחירה הטבעית. אתם כבר פולטים אירוע Watched Episode (או watch_series) כשמישהו צופה בפרק; הפנו את ההתראה לאירוע הזה ו‑Joryio מודיעה לכל מי שצפה בסדרה לאחרונה. אין רשומות מעקב ליצור או לתחזק. השתמשו בישות מעקב רק אם אתם רוצים רשימת "Follow this show" מפורשת ונפרדת מהצפייה.

האם המנגנון זהה לחזרה למלאי? הקהל כאן מבוסס על התנהגות במקום על רשימת המתנה (זו האפשרות audienceSource: "event"), וגם הטריגר שונה: פרק חדש אינו שינוי מלאי 0 → >0, אלא מספר פרקים שעולה (או "מזהה פרק אחרון" שמשתנה). אותו מנוע, שתי הגדרות שונות.

מה צריך - ישות אחת בלבד:

1. ישות הורה series עם:

   • שדה תצוגה כמו title,
   • שדה מספרי episodeCount (או מחרוזת latestEpisodeId).
   • ללא ישות ילד.

2. על series, הגדירו:

   {
     "relationshipAlert": {
       "enabled": true,
       "triggerMode": "increase",
       "field": "episodeCount",
       "audienceSource": "event",
       "intentEvent": "Watched Episode",
       "intentRefProperty": "series_id",
       "intentLookbackDays": 90,
       "eventName": "new_episode",
       "cooldownDays": 1
     }
   }

   (העדיפו "triggerMode": "changed" עם "field": "latestEpisodeId" אם אתם עוקבים אחר הפרק החדש ביותר לפי מזהה ולא לפי מונה רץ.)

3. החיבור הוא מאפיין האירוע. הנגן שלכם כבר שולח, בכל ניגון, משהו כמו:

   { "event": "Watched Episode", "series_id": "S-42", "episode": 12 }

   intentRefProperty: "series_id" הוא מה שמקשר צפייה לרשומת ה‑series - הוא חייב להתאים למזהה הרשומה או לערך המפתח הראשי שלה (S-42).

4. איך מפעילים: כאשר תהליך קליטת הקטלוג מעדכן ברשומה series/S-42 את episodeCount מ־8 → 9 (עדכון רשומה רגיל), Joryio מאתרת את כל המשתמשים שעבורם נרשם Watched Episode עם series_id = S-42 ב־90 הימים האחרונים ופולטת אירוע new_episode לכל אחד מהם.

5. בנו מסע/קמפיין שנכנס בעקבות new_episode:

   New episode of {{ event.name }} is out now. Pick up where you left off →

אם אתם מעדיפים רשימת מעקב מפורשת במקום התנהגות צפייה, השאירו triggerMode: "increase" אך השתמשו בקהל המבוסס על ישות הילד: הוסיפו ישות series_follows (seriesId, userId, User Link → userId), הגדירו audienceSource: "child_entity", childEntity: "series_follows", childRefField: "seriesId", והוסיפו שורת מעקב כשמישהו לוחץ Follow.

חזרה‑למלאי מול פרק‑חדש במבט מהיר

	חזרת כרטיסים למלאי	פרק חדש (VOD)
ישויות נדרשות	הורה + ילד המתנה	רק ההורה
קהל	שורות ticket_waitlist (הצטרפות)	אירוע Watched Episode (התנהגות)
audienceSource	child_entity	event
שדה מנוטר	available (מלאי)	episodeCount / latestEpisodeId
triggerMode	restock (0 → >0)	increase / changed
אירוע שנפלט	back_in_stock	new_episode

---

החרגת אנשים שכבר פעלו

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

1. דילוג עליהם בזמן ההפעלה - excludeEvent

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

{
  "excludeEvent": "Watched Episode",
  "excludeRefProperty": "series_id",
  "excludeValueProperty": "episode",
  "excludeLookbackDays": 30
}

כעת, כשפרק 9 יוצא, Joryio מודיעה לאנשים שצפו בסדרה אך מחריגה כל מי שכבר צפה בפרק 9 (series_id = הסדרה הזו וגם episode = הערך החדש). excludeValueProperty הוא מה שמצמיד זאת לפרק הספציפי החדש - כדי שההשוואה תפעל, הערך החדש של השדה צריך להתאים למזהה שאירוע הצפייה נושא (הפתרון הנקי ביותר הוא triggerMode: "changed" עם latestEpisodeId, או כשמספרי הפרקים שווים למונה). המנגנון עובד גם לחזרה למלאי - הגדירו את excludeEvent לאירוע הרכישה שלכם כדי לדלג על קונים אחרונים.

2. בדיקה מחדש בזמן השליחה - הפתרון המדויק לשליחות מושהות

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

1. טריגר כניסה: new_episode.
2. המתנה של יומיים.
3. תנאי / פיצול לפי התנהגות: לא ביצע Watched Episode עם episode = {{ trigger.new_value }} ביומיים האחרונים → רק ענף זה ממשיך לשליחה.

התנאי מעריך מחדש את מצבו של כל אדם רגע לפני השליחה, כך שכל מי שהתעדכן במהלך ההמתנה מוחרג. השתמשו ב‑excludeEvent (שכבה 1) כדי לשמור על קהל התחלתי מצומצם, ובתנאי המסע (שכבה 2) כדי להפוך שליחה מושהית למדויקת.

שימוש באירוע ההתראה

לא משנה איך תקראו לו, eventName מתנהג ככל אירוע אחר ב‑Joryio:

• הוא מופיע בבורר האירועים כטריגר כניסה למסע/קמפיין.
• המאפיינים שלו (record_id, new_value, field, וכן שדות סקלריים של הרשומה ותווית name) זמינים כ‑event.* ב‑Liquid.
• שליחות עדיין מכבדות הסכמה, רשימות חסימה ושעות שקט כמו כל שליחה אחרת בערוץ.

איך זה מופעל (מאחורי הקלעים)

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

ייבוא מרוכז (bulk)

ייבוא מרוכז של רשומות אינו מפעיל התראות כברירת מחדל - כך טעינה ראשונית אינה מתריעה לכולם. הפעילו התראות בכל ייבוא בנפרד באמצעות שליחת triggerAlerts: true לנקודת הקצה של הייבוא. כשהאפשרות מופעלת וגם לישות יש מפתח ראשי עסקי, הייבוא מבצע upsert-and-diff: רשומות שכבר קיימות מתעדכנות והשינויים בהן מפעילים התראות (למשל עדכון לילי של מלאי או של episodeCount), בעוד שרשומות חדשות לגמרי מפעילות רק התראות במצב changed (למצבים המספריים דרוש ערך קודם כדי לעבור ממנו).

התחלה

אפשר להגדיר ידנית את שתי הישויות ואת relationshipAlert כבר היום. עוזר ה‑AI יוכל גם לבנות את הכול - ליצור את ישות המעקב/רשימת ההמתנה, להחיל את ההגדרה ולבנות את מסע ההתראה - מבקשה אחת.