IOSOR ידע

היגיינת CSV של lookup המוני לפני קמפיין: לנרמל, לנקות כפילויות ולתקצב

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

שיווק רוצה רשימה. כספים רואים מטח חיובים של lookup שלא מתיישבים עם SMS שנשלחו אחר כך. Lookup המוני אינו לשפוך גיליון ל-API. היגיינה לפני ההוצאה: נירמול E.164, ניקוי כפילויות, כבוד למטמון סוג קו מיושן, תקרה על הארנק. מי שמדלג על היגיינה מתייחס למספרים מתים כתקריות מסירה, לשורות כפולות כ«כיסוי» ולתווית mobile ישנה כאמת ניתוב.

IOSOR אורז lookup ליד messaging בפנקס prepaid אחד ב־white-label. קטלוג live פירושו שהבדיקה מוכנה; in setup אינו שער ייצור שעוקפים במטמון. סביב USD 1,000+ לחודש דגימות הוצאה נמנעת ומתאם lookup→send נכנסים לסקירה מסחרית. סיור לפני שליחה: סיור מספרים לפני שליחה. Lookup בודד: בדיקת מספר לפני שליחה. מטמון מיושן: מטמון lookup מיושן וסוג קו.

עמודות CSV שכספים ו-ops צריכים

כספים ו-ops חייבים לפתוח את אותו CSV ולקרוא את אותו סיפור. עמודות מינימום: E.164 מנורמל, קלט גולמי, חותמת lookup, סוג קו, פגיעת מטמון או בדיקה טרייה, סכום חיוב, החלטת שליחה (שלח / דלג / בדוק שוב), מזהה campaign או אצווה. תווית «mobile» בלי חותמת זמן היא דעה, לא ראיה. שורת lookup בלי החלטת שליחה היא קבלה, לא בקרה.

עמודה מי משתמש אם חסרה
E.164 Ops וכספים הוצאה כפולה, שליחות שלא מתיישבות
looked-up-at Ops לא יודעים אם המטמון מיושן
החלטת שליחה כספים Lookup ופיצוץ לא מתיישבים

E.164 וניקוי כפילויות לפני הוצאת lookup

נרמלו ונקו כפילויות לפני שכסף lookup זורם. אותה קו שנכתבת +1…, 001… ופורמט מקומי מחויבת שלוש פעמים. נרמלו ל-E.164, נקו כפילויות לפי המספר, ואז קראו ל-lookup live. שורות זבל (קצרות מדי, אותיות, מחרוזות בדיקה) נזרקות בייבוא, לא נשאלות כ«לא ידוע». Ops מחזיק בכלל הנירמול; כספים מחזיק בהגדרת תקלה כששורה כפולה עדיין מחויבת.

סיכון מטמון סוג קו מיושן

סוג קו במטמון הוא אות ניתוב עם חותמת זמן, לא קעקוע. mobile של אתמול יכול להיות טווח VoIP היום. מטמון מיושן שולח OTP לטווח מת או מוסיף חיכוך למי שפורט אתמול. עדיין משלמים את שורת ה-lookup וגם את המקטע המבוזבז. TTL הוא כלל מוצר, לא טעם מסד נתונים. אל תשמרו «לא ידוע» כ-mobile. רעננו על אותות סיכון — מטמון lookup מיושן וסוג קו.

תקרות תקציב וקצב ייצוא

תקרות תקציב שייכות לאצווה, לא ל«ניישב אחר כך». שימו תקרת שורות וסכום לכל ריצת lookup; קצב הייצוא (יומי או בסגירת אצווה) קודם לפיצוץ, לא הפתעת סוף חודש. סביב USD 1,000+ הוצאה נמנעת ודליי גיל מטמון נכנסים לסקירה צפופה יותר. אל תבטיחו היגיינה לפני שליחה כל עוד lookup in setup.

דגלים אדומים

  • Lookup המוני בלי נירמול
  • אותו E.164 מחויב פעמיים בגלל וריאנטים של פורמט
  • «mobile» מיושן כאילו אמת ניתוב
  • לא ידוע שמור כ-mobile
  • CSV בלי תקרת שורות או סכום
  • Lookup מיושב עם שליחה רק בסוף החודש
  • היגיינה מובטחת כשהערוץ in setup
  • שגיאות ללקוח שמונות מותגים במעלה הזרם

התחלה עם IOSOR

קחו את CSV של הקמפיין משבוע שעבר. נרמלו כל שורה ל-E.164, זרקו זבל, הסירו כפילויות על המספר המנורמל ורק אז lookup אחד. תקרתו את האצווה במספר שורות וסכום prepaid לפני השיגור. ייצאו את אותו קובץ שכספים ותפעול יפתחו: סוג קו, פגיעת מטמון, חיוב, החלטת send או skip.

סיכום IOSOR

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

אל: אל תשפכו את הגיליון ל-API ותתאימו בסוף החודש. שורות כפולות אינן כיסוי. Unknown ששמור כ-mobile הוא דליפת prepaid.

האם המדריך הזה עזר?

מדריכים קשורים