הגבלת תדירות (Touching Rules)

Touching Rules הם מנגנון הגבלת התדירות (frequency capping) של Joryio: מגבלות ברמת סביבת העבודה על כמה פעמים מותר "לגעת" בכל משתמש בודד - לפי ערוץ, לפי חלון זמן. משתמש שהגיע לתקרה - שליחות נוספות אליו מדולגות עד שהחלון מתחלף, לא משנה איזה קמפיין או מסע מנסה להגיע אליו.

פתחו Settings → Touching Rules בלוח הבקרה כדי להגדיר. (צפייה דורשת את ההרשאה touching_rules:read.)

מבנה של כלל

כל כרטיס ערוץ מכיל מתג הפעלה ו־1 עד 4 כללים. כל כלל קובע:

מקסימום N הודעות לכל Day / Week / Month, וחל על כל ההודעות או רק על הודעות הנושאות תגיות מסוימות.

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

תיחום לפי תגיות

• כלל ללא תגיות חל על כל הודעה בערוץ.
• כלל עם תגיות סופר ומגביל רק הודעות שנושאות לפחות אחת מהתגיות שלו (OR בתוך הכלל). התגיות מגיעות מאותו מאגר תגיות של סביבת העבודה שמשמש קמפיינים, מסעות ותבניות - ראו תגיות.

כך אפשר לבנות מדיניות בשכבות, כפי שמסך ההגדרות עצמו מציין: "3 push/day for #promo AND 10 push/day overall" הן שתי תקרות בעלות משמעות, לא כפילות. אם שני כללים באותו כרטיס חולקים גם את החלון וגם את היקף התגיות, הדף מסמן אותם כ־Redundant - המחמיר מביניהם גובר, לכן הוסיפו תגית שתבדיל ביניהם או הסירו אחד.

ערוצים

ערוץ	ההמלצה במוצר
Push Notifications	מומלץ: 5–10 ביום למעורבות מיטבית.
Email Messages	מומלץ: 3–7 בשבוע כדי להימנע מתלונות ספאם.
SMS Messages	מומלץ: 1–3 בשבוע - SMS הוא הערוץ היקר ביותר.
In-App Messages	מומלץ: 10–20 ביום - הערוץ הכי פחות פולשני.
WhatsApp Messages	מומלץ: 3–5 ביום בהתאם למדיניות WhatsApp.
Viber Messages	מומלץ: 3–5 ביום בהתאם למדיניות Viber.
Webhook Calls	מומלץ: 30–50 ביום, תלוי באינטגרציה.

כל הערוצים מגיעים כבויים כברירת מחדל - שום הגבלה אינה פועלת עד שתפעילו ערוץ (או את המגבלה חוצת הערוצים) ותשמרו.

המגבלה חוצת הערוצים (כלל־על)

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

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

מה נחשב "נגיעה"

התקרות נספרות מול היסטוריית ההודעות האמיתית של המשתמש - לא לפי קמפיין:

• אימייל, SMS, פוש, WhatsApp, Viber, webhook - כל הודעה שנשלחה בהצלחה (אירוע message.sent).
• In-app - הודעות in-app נמשכות על-ידי האפליקציה ולא נדחפות, ולכן מה שנספר הוא החשיפה (אירוע in_app.displayed).
• Count failed deliveries (תחת Additional settings, כבוי כברירת מחדל) - כשהוא פעיל, גם ניסיונות משלוח שנכשלו (message.failed) צורכים מהתקציב בערוצי הדחיפה. ל-in-app אין אירוע כישלון, ולכן זה לא חל עליו.

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

חלונות זמן

"ליום / לשבוע / לחודש" נמדד מול אזור הזמן של סביבת העבודה (מוגדר בהגדרות סביבת העבודה), לא מול שעון השרת:

• Day - מחצות, שעון סביבת העבודה.
• Week - מיום שני 00:00, שעון סביבת העבודה (שבוע ISO).
• Month - מה-1 בחודש, שעון סביבת העבודה.

החלונות מעוגנים ללוח השנה ואינם "מתגלגלים": בגבול החלון הספירה של כולם מתחילה שוב מאפס.

מה קורה לשליחה שנחסמה

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

• קמפיינים - המשתמש שמעבר לתקרה מדולג בזמן השליחה, ונרשם אירוע פלטפורמה message.skipped עם הסיבה frequency_cap, כך שתוכלו לראות בדיוק מי נחסם ולמה. ראו אירועי פלטפורמה.
• מסעות - צומת ההודעה מדולג עבור אותו משתמש והמסע ממשיך במסלולו; הדילוג נרשם באותו אופן. הודעה שדולגה לעולם לא חוסמת את המשך המסע.
• צומתי Webhook - מוגבלים כברירת מחדל כמו כל הודעה (webhook לרוב מפעיל נקודת מגע עם המשתמש במערכת אחרת). האפשרות System call - skip quiet hours & frequency caps על הצומת מוציאה קריאת מערכת-למערכת טהורה מהמגבלה; ראו צומתי מסע.
• In-app - למשתמש שהגיע לתקרת ההודעות בתוך האפליקציה פשוט לא יוצגו הודעות זמינות בתוך האפליקציה עד שהחלון יתחלף.

סדר ההערכה

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

בתוך התקרות עצמן:

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

בקרות קשורות שהן לא הגבלת תדירות:

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

עקיפת תקרות להודעה מסוימת

לקמפיינים בודדים ולצומתי הודעה במסע יש אפשרות Ignore Touching Rules (Frequency Limits) שעוקפת את ההגבלה ברמת סביבת העבודה עבור אותה שליחה בלבד. ההנחיה של מסך ההגדרות עצמו: להשתמש להתראות אבטחה, קבלות טרנזקציוניות, הודעות משפטיות ושינויי סטטוס חשבון - לא למבצעים. בקמפיינים היא בשלב המשלוח לצד עקיפת שעות השקט; בבונה המסעות היא באפשרויות המשלוח המתקדמות של כל צומת הודעה.

שני דברים שכדאי לדעת על העקיפה:

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

עריכה ושמירה

השינויים נכנסים לתוקף בלחיצה על Save Settings - כללים חדשים חלים על שליחות בתוך כדקה (ההגדרות נשמרות לזמן קצר במטמון של מערך השליחה). Reset טוען מחדש את המצב האחרון שנשמר ומבטל עריכות שלא נשמרו.

הערות אמינות

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