שליחת SMS מהקוד בישראל: ה-API של InforU ומלכודת העלות של העברית

InforU היא פלטפורמת מסרים ישראלית, והיא חושפת שליחת SMS דרך HTTP - גם בממשק REST וגם בממשקי Web Service, עם דוגמאות קוד בשפות הנפוצות. החיבור הראשון הוא עניין של שעה. מה שמפתיע אנשים מגיע אחר כך, בחשבונית.

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

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

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

הודעת SMS נשלחת במקטעים, ואורך המקטע תלוי בקידוד:

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

הפרט שתופס אנשים לא מוכנים

תו אחד לא-לטיני מכריח את כל ההודעה לקידוד הרחב.

הדוגמה שממחישה: הודעה באנגלית באורך 150 תווים היא מקטע אחד. מוסיפים לה אימוג'י אחד - וכעת היא בקידוד UCS-2, כלומר 70 תווים למקטע, כלומר שלושה מקטעים במקום אחד. פי שלושה בעלות, בגלל תו אחד.

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

מה לעשות

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

הודעה שהתקבלה אינה הודעה שנמסרה

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

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

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

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

מספרי טלפון - לנרמל לפני שליחה

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

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

שם השולח

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

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

הסרה - לבנות לפני הדיוור הראשון

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

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

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

מה שחייב להיות

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

צ'קליסט

1. לפתוח את התיעוד הרשמי ולקחת ממנו את מבנה הבקשה.
2. לכתוב פונקציית ספירת מקטעים לפני שכותבים את השליחה.
3. לבדוק כל תבנית עם ערכים ארוכים אמיתיים.
4. להחליט אם צריך דוחות מסירה - ולטפל בהם אם כן.
5. לברר רישום שם שולח לפני שמבטיחים ללקוח.
6. לבנות הסרה ורשימת חסימה לפני הדיוור הראשון.
7. לוודא שהטוקן לא נמצא בשום קוד לקוח.