שאלות נפוצות בנושא חיוב על RCS לעסקים

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

קטגוריות חיוב

מהן קטגוריות חיוב של נציגים?

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

בטבלה הבאה מפורטות שתי קטגוריות החיוב העיקריות.

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

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

איך יודעים איזו קטגוריית חיוב לבחור לסוכן?

יש שתי קטגוריות עיקריות לחיוב: שיחות ואינטראקציות שאינן שיחות.

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

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

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

קטגוריית חיוב לא קשורה לשיחה

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

ב-20 בנובמבר 2025, פישטנו את מבנה החיוב על ידי שילוב של שתי קטגוריות חיוב מדור קודם, Basic Message ו-Single Message, לקטגוריית חיוב אחת – Non-conversational. מכיוון שהלוגיקה של החיוב בקטגוריות הקודמות הייתה זהה, השינוי הזה פשוט מפשט את הגדרת הסוכן.

מעכשיו, כל נציג יסווג כנציג שיכול לנהל שיחות או כנציג שלא יכול לנהל שיחות.

השינוי הזה משפיע על RcsBusinessMessagingAgentBillingConfig והוא חל על כל המפתחים שמשתמשים ב-Developer Console או ב-Management API, ועל כל הספקים שמשתמשים ב-Operations API.

למשתמשי API יש תקופת מעבר של 90 יום (עד 18 בפברואר 2026) לשילוב הקטגוריה החדשה במערכות שלהם. לפרטים מלאים על תוכנית המעבר, כולל תאימות לדורות קודמים של API ושינויים מומלצים בקוד, אפשר לעיין בקטעים הבאים.

העברה של סוכנים קיימים (לא נדרשת פעולה)

צוות התמיכה יטפל בהעברה באופן אוטומטי:

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

‫Developer Console (מפתחים)

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

Management API (Developers)

  • תאימות לאחור: במהלך תקופת המעבר של 90 יום, Management API יתמוך באופן זמני בערכים הקודמים BASIC_MESSAGE ו-SINGLE_MESSAGE וגם בערך החדש NON_CONVERSATIONAL, ויחזיר את כולם.
  • נדרשת פעולה: צריך לעדכן את הלוגיקה של הסוכן כדי להשתמש בערך החדש NON_CONVERSATIONAL לפני 18 בפברואר 2026.

תבנית קוד מומלצת

כדי לוודא שהקוד שלכם עמיד בפני שינויים עתידיים, מומלץ לעדכן את הלוגיקה כך שתשתמש בבדיקה בינארית בשדה billingCategory:

if (billingCategory == CONVERSATIONAL) {
  // Logic for conversational messages
} else {
  // Logic for non-conversational messages
}

הגישה הזו מונעת מהמערכת שלכם להיות תלויה בשמות או בערכים ספציפיים של enum, שעשויים להשתנות.

Operations API (Carriers)

  • תאימות לאחור: כדי למנוע שיבושים, Operations API יחזיר את הערך הקודם SINGLE_MESSAGE עבור סוכנים שמסומנים כ-NON_CONVERSATIONAL במהלך תקופת המעבר של 90 יום.
  • נדרשת פעולה: צריך לעדכן את המערכות כדי שיוכלו לטפל בערך החדש NON_CONVERSATIONAL לפני 18 בפברואר 2026.
  • אימוץ מוקדם: ספקים יכולים לפנות לתמיכה כדי להצטרף לקבלת ספירת הערכים החדשה NON_CONVERSATIONAL לפני 18 בפברואר 2026. אם תפעילו את ההגדרה הזו, סוכנים שהוגדרו כ-NON_CONVERSATIONAL (ב-Developer Console או באמצעות Management API) יחזירו NON_CONVERSATIONAL ב-Operations API.

אירועים לחיוב

מהם אירועים לחיוב?

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

‫Google עוקבת אחרי האירועים האלה ומדווחת עליהם כדי לעזור לחברות הסלולר לחייב שותפים על הודעות שנשלחו על ידי הסוכנים שלהם.

אילו אירועים ניתנים לחיוב חלים על כל סוג הודעה?

חמישה סוגים של אירועים שניתן לחייב עליהם נרשמים בדוחות החיוב. האירועים האלה כוללים אירועי MT ו-MO, שנקראים אירועי A2P ו-P2A.

  • A2P (Application-to-Person)‎ הוא MT (Mobile Terminated)‎: הודעה שנשלחת על ידי העסק.
  • ‫P2A (Person-to-Application) הוא MO (Mobile Originated): הודעה או פעולה שהמשתמש יזם.

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

סוג האירוע תיאור סוכנים בממשק שאינו שיחה סוכנים בממשק שיחה
basic_message הודעת A2P שכוללת רק טקסט באורך של עד 160 תווים.
דוגמה		 תמיד נספר כאירוע נפרד לחיוב, בלי קשר לשאלה אם המשתמש משיב. היא נחשבת לאירוע נפרד לחיוב, אלא אם המשתמש משיב תוך 24 שעות. במקרה כזה, ההודעה הופכת לחלק מa2p_conversation.
single_message הודעת A2P שמכילה תוכן עשיר או הודעת טקסט בלבד באורך של יותר מ-160 תווים.
דוגמה		 תמיד נספר כאירוע נפרד לחיוב, בלי קשר לשאלה אם המשתמש משיב. היא נחשבת לאירוע נפרד לחיוב, אלא אם המשתמש משיב תוך 24 שעות. במקרה כזה, ההודעה הופכת לחלק מa2p_conversation.
a2p_conversation (התשלום בוצע על ידי העסק) האירוע מתרחש כשמשתמש משיב להודעת A2P תוך 24 שעות מרגע קבלתה, מחוץ לשיחה קיימת.
דוגמה		 לא רלוונטית. סוכנים לא שיחתיים אף פעם לא יוצרים את סוג האירוע הזה. אם הודעת P2A נמסרת תוך 24 שעות ממסירת כמה הודעות A2P, רק הודעת ה-A2P שקדמה להודעת ה-P2A תשמש לפתיחת השיחה. ההודעה הזו מסוג A2P, וכל ההודעות שיישלחו ב-24 השעות הקרובות, הן חלק מa2p_conversation.
p2a_conversation (בהפעלת המשתמש) התגובה הראשונית מתקבלת תוך 24 שעות ממועד קבלת ההודעה, מחוץ לשיחה קיימת.
דוגמה		 לא רלוונטית. סוכנים לא שיחתיים אף פעם לא יוצרים את סוג האירוע הזה. אם הודעת A2P נמסרת תוך 24 שעות מכמה הודעות P2A, רק הודעת ה-P2A שקדמה להודעת ה-A2P תשמש לפתיחת השיחה. ההודעה הזו מסוג P2A, וכל ההודעות שיישלחו ב-24 השעות הקרובות, הן חלק מp2a_conversation.
p2a_message הודעת P2A מכל סוג.
דוגמה		 תמיד נחשב כאירוע נפרד לחיוב, גם אם הסוכן לא משיב. היא תיחשב כאירוע נפרד לחיוב, אלא אם הנציג ישיב תוך 24 שעות.

מהן דוגמאות להודעות שמפעילות כל אירוע חיוב?

הודעה בסיסית

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

basic_message_example

הודעה בודדת

single_message_example

שיחה מסוג A2P

a2p_conversation_example

הודעה מסוג P2A

p2a_message_example

שיחה מסוג P2A

p2a_conversation_example

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

הודעה בסיסית

היתרונות העיקריים של הודעה בסיסית:

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

basic_message_benefits

הודעה בודדת

היתרונות המרכזיים של הודעה בודדת:

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

single_message_benefits

שיחה

היתרונות העיקריים של שיחות מסוג A2P ו-P2A:

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

conversational_message_benefits

מה הקשר בין קטגוריות חיוב של נציגים לבין אירועי חיוב?

חשוב לא להתבלבל בין אירועי החיוב basic_message ו-single_message לבין קטגוריות החיוב 'הודעה בסיסית' ו'הודעה יחידה'.

  • כל סוכן (לא משנה קטגוריית החיוב שלו) יכול ליצור אירועי חיוב מסוג basic_message ו-single_message.
  • קטגוריות החיוב 'הודעה בסיסית' ו'הודעה יחידה' משמשות לסיווג של סוכנים שאינם מנהלים שיחות. סוכנים בקטגוריות החיוב האלה לא יוצרים אירועי חיוב של שיחות (a2p_conversations או p2a_conversations). במקום זאת, הם יוצרים אירועי חיוב נפרדים מסוג basic_message, single_message ו-p2a_message.

מהי שיחה?

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

  • A2P (Application-to-Person): נשלחת על ידי העסק.
  • P2A (Person-to-Application): נשלחת על ידי המשתמש.

איך השיחות עובדות

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

בתרשים הבא מוצגת דוגמה לסשן לחיוב של A2P עבור סוכנים וירטואליים:

תרשים חיוב

חשוב

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

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

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

לסוכנים שאינם מבוססים על שיחה: כל הודעה יוצרת אירוע משלה

  • הודעה מסוכן יוצרת אירוע מסוג basic_message או single_message.
  • הודעה של משתמש יוצרת אירוע p2a_message.

לנציגים וירטואליים: התוצאה תלויה במועד שבו המשתמש משיב להודעה האחרונה של הנציג

  • אם המשתמש משיב תוך 24 שעות:
    • אירוע a2p_conversation מתחיל. האירוע הזה כולל את ההודעה האחרונה של הנציג, את התשובה של המשתמש ואת כל ההודעות שהוחלפו במסגרת חלון של 24 שעות אחרי התשובה של המשתמש.
    • הודעות של נציג/ת התמיכה שנשלחו לפני ההודעה האחרונה של הנציג/ה לא נכללות בשיחה, וכל אחת מהן יוצרת אירוע basic_message או single_message משלה.
  • אם המשתמש ישיב אחרי 24 שעות:
    • כל הודעה של הסוכן יוצרת אירוע מסוג basic_message או single_message.
    • התגובה של המשתמש יוצרת אירוע p2a_conversation אם הנציג מגיב תוך 24 שעות. אם הסוכן לא מגיב בפרק הזמן הזה, נוצר אירוע p2a_message במקום זאת.

אילו תגובות של משתמשים נכללות באירועי חיוב?

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

סיכום הקווים המנחים:

תגובת משתמש תורם לאירועי חיוב הערות
שליחת קובץ כן מטופלת כהודעה שמקורה בנייד (MO).
שליחת הודעת טקסט כן מטופלת כהודעת MO.
מקישים על הצעה לתשובה כן מטופלת כהודעת MO.
הקשה על הצעה לפעולה לא נתוני הדיווח החוזר על המרה מהקשה עצמה לא נכללים באירוע חיוב.
שיתף/ה מיקום כן הודעת ה-MO שמכילה את מיקום המשתמש תורמת לאירוע חיוב. זה תקף גם אם המיקום משותף באופן ידני וגם אם הוא משותף באמצעות הצעה לפעולה.
מקישים על ביטול ההרשמה או על הרשמה כן אירוע ה-webhook שמתקבל לא נחשב לאירוע לחיוב, אבל ההודעה האוטומטית STOP או START שנשלחת כשמשתמש מקיש על האפשרות לביטול ההרשמה או להרשמה נחשבת להודעת MO.

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

לסוכנים שאינם בממשק שיחה:

  • אירוע החיוב שנוצר מתגובה של משתמש הוא תמיד p2a_message.

לסוכנים בממשק שיחה:

סוג האירוע נקבע גם לפי התזמון של ההודעות בחלון של 24 שעות.

  • כשמשתמש מגיב להודעה של הנציג:
    • תוך 24 שעות: התשובה של המשתמש תורמת לאירוע a2p_conversation קיים.
    • אחרי 24 שעות: התשובה של המשתמש יוצרת אירוע חדש מסוג p2a_message.
  • כשהנציג מגיב להודעה של משתמש:
    • תוך 24 שעות: התשובה של הנציג יוצרת p2a_conversation, החל מההודעה הראשונית של המשתמש.
    • אחרי 24 שעות: ההודעה של המשתמש יוצרת אירוע p2a_message.

דוחות חיוב

מהו דוח חיוב?

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

מידע נוסף על דוחות חיוב זמין במאמר בנושא דוחות על אירועי חיוב ויומני פעילות.

האם אפשר לקבל דוח חיוב?

רק ספקי סלולר שמפעילים באופן פעיל את RCS לעסקים מקבלים דוחות חיוב. שותפים לא מקבלים דוחות חיוב.

במאמר אחסון קבצים וגישה אליהם מוסבר איך מקבלים דוחות חיוב. אלה הוראות לאחזור דוחות חיוב באמצעות Secure File Transfer Protocol (פרוטוקול מאובטח להעברת קבצים, SFTP) עבור ספקי תקשורת שיש להם גישה לדוחות חיוב.

מה קורה אם חסר מידע בדוח החיוב?

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

למה מופיעים חיובים בחשבון שלי בחודש שבו לא שלחתי הודעות?

אירועי חיוב של RCS for Business מתועדים על סמך הזמן שבו ההודעה נמסרה, ולא על סמך הזמן שבו ההודעה נשלחה.

דוגמה:

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

מודלים לחיוב

מה ההבדלים העיקריים בין מודל החיוב הרגיל לבין מודל החיוב בארה"ב?

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

מודל חיוב רגיל (תנועה מחוץ לארה"ב)

המודל הזה חל על כל התנועה מחוץ לארה"ב.

  • הסיווג מבוסס על קטגוריית החיוב של הנציג ועל תוכן ההודעה.
    • נציגים שאינם מנהלים שיחות: החיוב הוא לפי הודעה. תוכן ההודעה קובע את סוג האירוע: הודעה בסיסית או הודעה יחידה.
    • סוכנים בממשק שיחה: החיוב הוא לפי שיחה. שיחה היא חלון של 24 שעות שבהן המשתמש והנציג יכולים להחליף הודעות ללא הגבלה, והחיוב הוא לפי תעריף קבוע. אם המשתמש לא משיב תוך 24 שעות, ההודעה של הסוכן מחויבת בנפרד כהודעה בסיסית או כהודעה בודדת.
  • אירועים לחיוב:
    • basic_message
    • single_message
    • a2p_conversation
    • p2a_conversation
    • p2a_message
  • לוגיקת החיוב: החיוב הסופי נקבע לפי קטגוריית החיוב של הסוכן, והוא יכול להיות שיעור קבוע לכל הודעה (לא שיחה) או שיעור קבוע לכל חלון שיחה של 24 שעות (שיחה).

מודל החיוב בארה"ב

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

  • הסיווג של הודעות ספציפיות ופעולות משתמשים הוא אוטומטי ומבוסס על התוכן. בלי קשר לקטגוריית החיוב של הסוכן, כל אירוע שניתן לחיוב מסווג כאחד מהבאים:
    • הודעה עשירה (MT/MO)
    • הודעת מדיה עשירה (MT/MO)
    • קליק על הצעה לפעולה (רק בניידים)
  • אירועים לחיוב:
    • a2p_rich_message
    • a2p_rich_media_message
    • p2a_rich_message
    • p2a_rich_media_message
    • suggested_action_click
  • לוגיקת החיוב: החיוב הסופי נקבע לפי סיווג החיוב של הנציג, באמצעות סיווגים של אירועים שניתנים לחיוב כדי להחיל את מבנה התעריפים הנכון.

הבדלים טכניים והבדלים בדיווח

  • ‫RBM API: משאבי ה-API‏ AgentMessage ו-UserMessage כוללים אובייקט richMessageClassification להגדרת סוג ההודעה לתנועה בארה"ב בלבד. המידע הזה מסופק בזמן אמת אחרי קריאה ל-API, והוא נפרד מדוח חיוב שיופק בשלב מאוחר יותר.
  • דוחות חיוב: דוחות החיוב מותאמים לכל מודל וכוללים עמודה type שבה מפורטים האירועים שניתנים לחיוב וספציפיים למודל הזה. דוח החיוב בארה"ב כולל גם עמודה של segment_count, שרלוונטית רק להודעות עשירות.
הקודם
תרחישים לדוגמה לשימוש בנציג וכללים עסקיים