IOSOR

IOSOR Gabay

SMS segment accounting: bakit ang isang mensahe ay hindi isang linya ng gastos

Gabay sa pricing: GSM-7 vs UCS-2, overhead ng multipart concatenation, at paano i-reconcile ang bawat send sa prepaid wallet nang hindi humuhula.

Nag-type ang user ng isang mensahe. Nag-debit ang prepaid wallet ng tatlong unit. Hindi ito bug — ito ay segment accounting, at ang mga finance team na hindi naiintindihan ang GSM-7 vs UCS-2 at multipart concatenation ay nagbubukas ng ticket laban sa billing engine na gumagana nang eksakto ayon sa disenyo. Ang gabay na ito ay para sa finance at product lead na nagpapatakbo ng prepaid white-label messaging at kailangan ng maipapaliwanag na spend — hindi “magtiwala sa invoice”.

Tinatrato ng IOSOR ang bawat SMS spend line bilang maaaring i-reconstruct hanggang segment count, encoding, at destination — hindi opaque platform fee.

Bakit ang isang SMS ay hindi isang linya ng gastos

Ano ang nakikita ng sender Ano ang nakikita ng wallet
“Nagpadala ako ng isang text” 1–3 billed unit depende sa encoding at haba
Idinagdag ang isang emoji sa dulo Buong mensahe ay lumipat sa UCS-2
Template variable na mas mahaba ng ilang character Lumampas ang mensahe sa segment boundary

GSM-7 vs UCS-2: bakit binabago ng character set ang matematika

  • Sinasaklaw ng GSM-7 ang limitadong Latin alphabet at maliit na symbol set; mas mababang “budget” per segment ang bawat character
  • Pinipilit ng UCS-2 (anumang character sa labas ng GSM-7 — emoji, karamihan ng non-Latin script, ilang punctuation) ang buong mensahe sa mas malawak na encoding na may mas mababang character limit per segment
  • Isang “invisible” character (smart quote mula sa

Multipart segmentation at concatenation overhead

Encoding Limit ng single segment Limit sa multipart Bakit mas maliit ang multipart
GSM-7 160 char 153 char Nagrereserba ang concatenation header ng espasyo
UCS-2 70 char 67 char Parehong header, mas maliit ang alphabet budget

Saan nagtatago ang segment counts

  • Nagpapakita ang composer preview ng “1 message” habang ang totoong encoding ay nagbubunga ng 2–3 billed segment
  • Template variables na nagtutulak ng haba lampas sa boundary para lang sa ilang recipient
  • Locale-specific characters (accents, non-Latin scripts) na pumapasa sa QA sa isang wika at nagpaparami ng gastos sa iba

Mga red flag

  • Composer o API response na nagre-report ng message count imbes na segment count
  • Walang visibility kung aling encoding ang ginamit sa partikular na send
  • Sinasabi ng support na “bihirang encoding issues, huwag mag-alala”
  • Ledger rows na hindi masusubaybayan hanggang haba, encoding, at destination
  • Bulk sends na sinisingil bilang flat estimate, na-reconcile sa hulihan ng buwan lang

Magsimula sa IOSOR

Suriin ang iyong mga labas na template payload sa IOSOR console bago maglunsad ng malawakang pagpapadala. Mag-set up ng mga API validation gate para matukoy ang anumang payload na lalampas sa isang segment o biglang lumipat mula sa GSM-7 patungo sa UCS-2 encoding.

Buod ng IOSOR

Ang isang labas na text message ay bihirang mangahulugan ng iisang linya ng gastusin. Ang pagpili sa pagitan ng GSM-7 at UCS-2 encoding, kasama ang overhead ng header para sa multipart concatenation, ay nangangahulugang ang kaunting pagbabago sa dynamic na text o isang espesyal na karakter ay madaling magdoble ng iyong bayarin sa bawat tatanggap.

Nakatulong ba ang gabay na ito?

Mga kaugnay na gabay