אירועי פלטפורמה - מדריך

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

הודעות

אירוע	תיאור	אות
`message.sent`	Joryio שלחה הודעה למשתמש הזה, בערוץ כלשהו.	-
`message.delivered`	הספק אישר את מסירת ההודעה.	-
`message.opened`	הנמען פתח אימייל.	מעורבות
`message.clicked`	הנמען לחץ על קישור במעקב.	מעורבות חזקה
`message.bounced`	המסירה הוחזרה, באופן קבוע או זמני.	בעיה באיכות הרשימה
`message.auto_replied`	תיבת הדואר של הנמען שלחה מענה אוטומטי (מחוץ למשרד). המייל נמסר: זו אינה החזרה.	-
`message.unsubscribed`	הנמען ביטל הרשמה דרך קישור או כותרת של Joryio, שמירה בדף ההעדפות או תשובת STOP. `scope` מציין ממה יצא: `channel` (רק הערוץ שבו הגיעה ההודעה), `list`, או `global` (הכול - בחירה מפורשת). נושא `campaignId`, `canvasId`, `nodeId`, `variantId`. `unsubscribeSource` מציין איך ההסרה הגיעה (`header_one_click` = הכפתור של אפליקציית המייל, `page_button` = הכפתור בדף המתארח, `preferences_page`, `page_everything`, `keyword`; מאז 2026-10-15), יחד עם `userAgent` ו-`sinceSendMs` (מילישניות אחרי השליחה). מאז 2026-11-02 הוא נכתב גם כשחבר צוות (`admin`) או מפתח API (`api`) מבטלים הרשמה לערוץ, בביטול הרשמה מה-SDK (`sdk`) ובביטול שמגיע מחנות (`store_sync`, כולל תיבה לא מסומנת כשההגדרה האופציונלית של החנות פעילה); לאלה אין קמפיין.	ביטול הרשמה
`message.subscribed`	אדם נרשם - המקבילה של `message.unsubscribed` (מאז 2026-10-25). פעם אחת לכל שינוי אמיתי (מללא סטטוס, `unsubscribed` או `pending` לרשום), אף פעם לא כשהאדם כבר היה רשום. `scope`: `channel` (הערוץ עצמו) או `list` (רשימה, עם `listId`). נושא `channel`, `source` (איך זה קרה - ראו אירוע ההרשמה), `platform` בהרשמה מחנות, `optInSource`, `status`, `previousStatus`, `resubscribe`. מסע יכול להתחיל ממנו. לא נרשם בייבוא, בסנכרון ממחסן נתונים, בהוספה גורפת לרשימה או בסנכרון הראשוני של חנות.	הרשמה
`Unsubscribe Page Viewed`	הנמען פתח את דף ביטול ההרשמה או את דף ההעדפות מקישור בהודעה. זה לא ביטול הרשמה. מאפיינים: `campaignId`, `canvasId`, `nodeId`, `variantId`, `channel`, `page` (`unsubscribe` או `preferences`), `position` (איזה קישור ביטול הרשמה באימייל). ללא בוטים; פעם אחת לכל קישור ב-24 שעות.	כוונת הסרה
`message.failed`	השליחה נכשלה אצל הספק.	-
`message.spam_complaint`	לא שם של אירוע שנשלח בפועל: תלונות ספאם מגיעות כ־`message.spamreport`. לא מוצע בבוררי אירועים.	סיכון ליכולת המסירה
`message.queued`	הספק קיבל את ההודעה והעביר אותה לתור.	-
`message.deferred`	הספק דחה את המסירה זמנית וינסה שוב.	-
`message.skipped`	השליחה דולגה בגלל אחד משערי Joryio, כגון חסימה, הגבלת תדירות, שעות שקט או הסכמה.	-
`message.held`	מושהה על ידי Joryio: שער המעורבות השהה הודעת מסע לזמן מה כי האדם קיבל זה עתה הודעה אחרת, או ויתר עליה כשהתיישנה; `reason` אומר למה ומציין את ההודעה המתחרה כשהייתה כזו.	`outcome`, `reason`, `nodeId`
`message.complained`	כינוי מקובל של `message.spamreport` בספירת תלונות (שורות היסטוריות); אף מקור לא שולח אותו היום. לא מוצע בבוררי אירועים.	סיכון ליכולת המסירה
`message.spamreport`	הספק דיווח על תלונת ספאם; אצל ספקים מסוימים זהו שם חלופי ל־`spam_complaint`.	סיכון ליכולת המסירה

כרטיסי ארנק

אירוע	תיאור	אות
`pass.issued`	כרטיס ארנק של Joryio הונפק למשתמש.	-
`pass.installed`	המשתמש הוסיף את הכרטיס ל-Apple Wallet או ל-Google Wallet.	הצטרפות לערוץ הארנק
`pass.updated`	עדכון תוכן נשלח לכרטיסים שהותקנו.	-
`pass.removed`	המשתמש הסיר את הכרטיס מהארנק שלו.	כוונת נטישה - טריגר חזק למסע חידוש מעורבות
`pass.downloaded`	קובץ הכרטיס הורד, לפני שלב ההתקנה.	-
`pass.scanned`	הברקוד או קוד ה-QR של הכרטיס נסרק, למשל בעת מימוש בדלפק.	מעורבות חזקה - שימוש בעולם האמיתי
`pass.expired`	הכרטיס הגיע לתאריך התפוגה שלו.	הזדמנות לחידוש
`pass.update_pushed`	עדכון תוכן נשלח במפורש לכרטיסים שהותקנו בעקבות עריכה.	-
`pass.voided`	העסק ביטל או השבית את הכרטיס.	-

מסחר אלקטרוני

אירוע	תיאור	אות
`purchase`	לא אירוע ש־Joryio שולחת: רכישה שהושלמה מגיעה כ־`Order Completed`. לא מוצע בבוררי אירועים.	-
`Order Completed`	הזמנה שהושלמה בחנות מחוברת, דרך Orders API או דרך ה-SDK; זהו אירוע המסחר התקני. האירוע נושא גם את העגלה שממנה הגיעה ההזמנה והאם היא שחזרה אותה: `cartRef`, `recoveredCart` (`true` כשההזמנה שחזרה עגלה נטושה - אותה החלטה כמו תג "עגלה משוחזרת" בדף ההזמנות), `recoveredVia` (`recovery_link`, `same_cart`, `contact_cart`, `reported`), ואת ייחוס הכניסה שהחנות דיווחה: `utm_source`, `utm_medium`, `utm_campaign`, `utm_term`, `utm_content`, `campaign_id`, `canvas_id`. ראו מאפייני Order Completed.	רכישה - עגלה משוחזרת היא ההמרה של מסע השחזור
`Order Refunded`	חנות מחוברת (Shopify, WooCommerce, Magento) או ה-API של ההזמנות דיווחו על החזר חדש בהזמנה - אירוע אחד לכל החזר, מלא או חלקי. `total` הוא הסכום שההחזר הזה החזיר (`total_base` במטבע הבסיס), ולא סכום ההזמנה. בנוסף: `order_id`, `currency`, `refund_type` (`full` או `partial`), `refund_amount`, `refund_id`, `reason`, `products`, `coupon_codes`. ההכנסות כבר נטו מהחזרים, ולכן האירוע הזה אף פעם לא מקטין אותן פעם שנייה. ראו אירועי החזר וביטול.	חוסר שביעות רצון אחרי רכישה
`Order Cancelled`	חנות מחוברת או ה-API של ההזמנות ביטלו הזמנה - פעם אחת לכל הזמנה. מאפיינים: `order_id`, `total`, `currency`, `reason`, `cancelled_at`, `coupon_codes`.	מכירה שאבדה
`Coupon Issued`	תוכנית קופונים הנפיקה קוד לאדם (מאפיינים: program, program_id, campaign_id, canvas_id, node_id, source, expires_at). הקוד עצמו לעולם לא נמצא על אירוע.	-
`Coupon Redeemed`	הזמנה השתמשה בקוד ש-Joryio הנפיקה (נוספים order_id, revenue, redeemed_by_someone_else). נשלח על האדם שקיבל את הקוד.	המרה מהודעה
`Coupon Expired`	קוד פג בלי שימוש (program, program_id, campaign_id, canvas_id, expires_at).	הזדמנות להחזרת לקוח
`Checkout Started`	תהליך התשלום התחיל אך טרם הושלם.	-
`cart_abandoned`	לא אירוע: זהו מצב העגלה הנטושה שתנאי סגמנט או Branch בודק (E-commerce: עגלה נטושה). כדי להתחיל מסע כשעגלה ננטשת, השתמשו ב־`Cart Abandoned`. לא מוצע בבוררי אירועים, ולא ניתן לפרסם מסע שמופעל עליו.	-
`Cart Abandoned`	נשלח על ידי חנויות מחוברות (Shopify, WooCommerce, Magento, PrestaShop) כשעגלה נשארה בלי הזמנה למשך זמן הנטישה שהוגדר בסביבת העבודה. `checkoutUrl` הוא קישור השחזור של החנות לעגלה הזו - קשרו אותו כ־`{{ cart.checkoutUrl }}`. מוצג בבוררי אירועים עם הכיתוב "נשלח מחנויות מחוברות". `cartId` מזהה את העגלה הזו: העגלה הבאה של איש הקשר מקבלת מזהה חדש (לפני 2026-10-27 הוא חזר על עצמו בין העגלות של אותו איש קשר). `cartRef` הוא מספר העגלה בחנות עצמה (`quote_33` של Magento, סשן WooCommerce, מזהה עגלת PrestaShop, טוקן קופה של Shopify). לא נשלח לעגלה שאין דרך להגיע לבעליה (בלי אימייל, טלפון, מזהה לקוח או זהות באפליקציה) - נשלח פעם אחת אם אפשר להגיע אליו מאוחר יותר - ופעם אחת לכל נטישה: עגלה שהפריטים בה השתנו אחרי שננטשה (רוקנה ומולאה מחדש, נוספו או הוסרו פריטים), או שחזרה בלי שינוי יום או יותר אחר כך, וננטשה שוב - היא נטישה חדשה עם `cartId` חדש (אותה עגלה ננטשה שוב); חזרה על אותה נטישה לא נשלחת שוב. `value` הוא סכום העגלה שהחנות שלחה (יכול לכלול משלוח); `subtotal` הוא סכום הפריטים, לפני משלוח ומס. ‏`recoveryLink` הוא `true` כש־`checkoutUrl` הוא קישור השחזור של החנות ו־`false` כשזה רק עמוד התשלום או העגלה (מ־2026-11-01). ‏`source` הוא `plugin_event` כשהחנות דיווחה על הנטישה ו־`cart_abandonment_scan` כש־Joryio סימנה את העגלה בעצמה (כשהחנות לא מדווחת על הנטישה).	הטריגר הקלאסי למסע שחזור
`Cart Updated`	פריטים נוספו לעגלה או הוסרו ממנה.	-
`Product Added`	מוצר נוסף לעגלה.	כוונת רכישה
`back_in_stock`	מוצר שהמשתמש צפה בו לאחרונה או הוסיף לעגלה, אך לא קנה, חזר למלאי. האירוע נוצר לכל משתמש כשהמוצר עובר ממצב שאזל מהמלאי למצב זמין ב-Shopify או ב-WooCommerce.	טריגר קמעונאי בעל שיעור המרה גבוה
`price_drop`	מחירו של מוצר שהמשתמש צפה בו לאחרונה או הוסיף לעגלה, אך לא קנה, ירד מעבר לסף שהוגדר. האירוע נוצר לכל משתמש בעת ירידת מחיר בקטלוג.	טריגר קמעונאי בעל שיעור המרה גבוה
`entity_back_in_stock`	אירוע ברירת המחדל של התראת קשר בין ישויות, למשל חידוש מלאי בקטלוג מותאם או פרק חדש. האירוע נוצר לכל משתמש כאשר שדה במעקב ברשומה של ישות מותאמת משתנה. אפשר להגדיר להתראה שם אירוע מותאם במקום זאת.	טריגר מקטלוג מותאם
`Product Viewed`	המשתמש צפה בעמוד מוצר.	עניין בגלישה

SDK / ווב

אירוע	תיאור	אות
`session_start`	לא השם שה־SDK שולחים: תחילת סשן מגיעה כ־`Session Start`. לא מוצע בבוררי אירועים.	-
`Page Viewed`	המשתמש צפה בעמוד דרך ה-Web SDK.	-
`Screen Viewed`	צפייה במסך (SDK של iOS ו-Android). המקבילה המוביילית של Page Viewed; ה-SDK-ים המובייליים לעולם לא שולחים Page Viewed.	`screen_name`
`signup`	לא אירוע ש־Joryio שולחת: האפליקציה עוקבת אחר אירוע הרשמה משלה (למשל `Signed Up`). לא מוצע בבוררי אירועים.	-

In-app

אירוע	תיאור	אות
`in_app.served`	סימון בצד השרת שהודעת in-app נמסרה למכשיר לצורך הצגה. נוצר אירוע אחד לכל מסירה. הוא שומר מקום במגבלת התדירות למשך שתי דקות עד שהמכשיר מאשר את ההצגה; רק `in_app.displayed`, שמאשר בצד הלקוח שההודעה הוצגה, נספר במגבלה.	-
`in_app.viewed`	לא השם שה־SDK שולחים: הצגת הודעת in-app מגיעה כ־`in_app.displayed`. לא מוצע בבוררי אירועים.	-
`in_app.clicked`	המשתמש לחץ על קריאה לפעולה בתוך הודעת in-app.	מעורבות
`in_app.displayed`	הודעת in-app הוצגה ונרשמה חשיפה.	-
`in_app.dismissed`	המשתמש סגר את הודעת ה-in-app בלי לבצע פעולה.	-
`in_app.converted`	המשתמש ביצע את פעולת היעד של הודעת ה-in-app.	המרה
`In-App Form Submitted`	טופס בתוך הודעה באפליקציה נשלח ונכתב לאדם הזה: מאפיינים, הרשמות לרשימות, תגיות (מאפיינים: `campaignId`, `campaignName`, `variantId`, `fields`, `listsSubscribed`, וה-`email`, ה-`phone` וה-`phoneUpdated` של הטופס - ראו `Form Submitted`).	המרה

מסעות

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

אירוע	תיאור	אות
`canvas.step.entered`	האדם הגיע לשלב במסע (טריגר, השהיה, פיצול, ניסוי, הודעה - כל צומת). אחד לכל ביקור; הודעה שנדחתה בגלל שעות שקטות או מגבלת קצב ונוסתה שוב היא אותו ביקור. מאפיינים: `canvasId`, `canvasVersion`, `nodeId`, `nodeType`, `executionId`.	-
`canvas.step.left`	האדם יצא משלב במסע. `outcome` הוא מה שהשלב החליט - שם הענף, מזהה המסלול בניסוי (או `no_winner` כשהניסוי הסתיים בלי מנצח ושחרר את קבוצת ההמתנה שלו - המסע מסתיים אז כ-`completed`), `success` / `on_error` ל-webhook, `did` / `timed_out` / שם קבוצה לפיצול התנהגותי, `issued` / `not_issued`, `sent` / `skipped`, `elapsed` להשהיה, ואחרת `next`. `nextNodeId` הוא לאן המשיך; הוא ריק כשהמסע הסתיים בשלב הזה, ואז `exitReason` מסביר למה (`completed`, `exited`, `exit_criteria`, `restart`, `error`). `durationMs` הוא הזמן שהאדם שהה בשלב.	-

המלצות

אירוע	משמעות	אות
`recommendation.served`	מודל ההמלצות בחר פריטים עבור המשתמש בהודעה שנשלחה (מאפיינים: `modelId`, `itemIds`).	חשיפה להתאמה אישית

דפי נחיתה

אירוע	משמעות	אות
`Landing Page Viewed`	אדם מזוהה (הגיע דרך קישור של Joryio הנושא את הטוקן שלו) פתח דף נחיתה שפורסם (מאפיינים: `pageId`, `pageSlug`, `pageName`, `referrer`, ערכי UTM).	עניין
`Landing Page Form Submitted`	טופס בדף נחיתה נשלח ונכתב לאדם הזה: מאפיינים, הרשמות לרשימות, תגיות (מאפיינים: `pageId`, `pageSlug`, `pageName`, `fields`, `listsSubscribed`, `referrer`, ערכי UTM, וה-`email`, ה-`phone` וה-`phoneUpdated` של הטופס - ראו `Form Submitted`).	המרה

טפסים באתר

אירוע	משמעות	אות
`Form Submitted`	טופס באתר שלכם נשלח ונכתב לאדם הזה: טופס Contact Form 7 או Elementor Pro בוורדפרס (דרך התוסף של Joryio), או טופס יצירת הקשר או טופס ממופה אחר ב-PrestaShop (דרך המודול של Joryio). נרשם בין אם האדם הסכים לדיוור ובין אם לא (מאפיינים: `source` - `cf7`, `elementor`, `prestashop_contact` או `prestashop_form`, `formId`, `formName`, `pageUrl`, `consentGiven`, `consentText` (הנוסח של תיבת ההסכמה שהאדם סימן, כשהטופס שולח אותו), `listsSubscribed`, `listsPending` לרשימות עם אישור כפול שממתינות לאישור, וה-`email` וה-`phone` של הטופס עצמו, בפורמט שבו איש הקשר שומר אותם, עם `phoneUpdated` כשהטלפון בטופס שונה מזה של איש הקשר: `true` כשאיש הקשר מחזיק בו עכשיו, `false` כשאיש הקשר שמר את שלו). טופס של מבקר רק ממלא אימייל או טלפון ריקים; טופס של לקוח מחובר בחנות יכול לעדכן את הטלפון שלו. `email` ו-`phone` הם מידע אישי: מוסתרים מחברי צוות שאינם מורשים לראות מידע אישי ונמחקים יחד עם האדם. שאר הערכים שהוזנו בטופס אינם נשמרים באירוע.	המרה

הודעות​

כרטיסי ארנק​

מסחר אלקטרוני​

SDK / ווב​

In-app​

מסעות​

המלצות​

דפי נחיתה​

טפסים באתר​