IOSOR

IOSOR Tudás

SMS-szegmenskönyvelés: miért nem egy üzenet egy költségsor

Árazási útmutató: GSM-7 vs UCS-2, multipart összefűzési overhead, és hogyan egyeztesse minden küldést az előre fizetett tárcával találgatás nélkül.

A felhasználó egy üzenetet írt. Az előre fizetett tárca három egységet terhelt. Ez nem hiba — ez szegmenskönyvelés, és a pénzügyes csapatok, amelyek nem értik a GSM-7 vs UCS-2-t és a multipart összefűzést, ticketet nyitnak olyan számlázómotor ellen, amely pontosan a tervezés szerint működik. Ez az útmutató olyan pénzügyi és termékvezetőknek szól, akik előre fizetett white-label üzenetküldést futnak, és magyarázható költést akarnak — nem „bízzon a számlában”.

Az IOSOR minden SMS-költségsort szegmensszámig, kódolásig és célállomásig rekonstruálhatónak kezel — nem átlátszatlan platformdíjként. Havonta kb. USD 1 000+ platformhasználat mellett a szegmensfegyelem a tiszta havi egyeztetés és az ismétlődő „miért került többe” eszkaláció különbsége.

Miért nem egy SMS egy költségsor

Mit lát a küldő Mit lát a tárca
„Egy szöveget küldtem” 1–3 számlázott egység kódolás és hossz szerint
Egy emoji a végére került Az egész üzenet UCS-2-re vált
A sablonváltozó néhány karakterrel hosszabb Az üzenet átlépi a szegmenshatárt

GSM-7 vs UCS-2: miért változtatja a karakterkészlet a matematikát

  • A GSM-7 korlátozott latin ábécét és kis szimbólumkészletet fed; minden karakter kevesebb „keretet” fogyaszt szegmensenként
  • Az UCS-2 (bármely GSM-7-en kívüli karakter — emoji, a legtöbb nem latin írás, bizonyos írásjelek) az egész üzenetet szélesebb kódolásba kényszeríti alacsonyabb karakterlimittel szegmensenként
  • Egy „láthatatlan” karakter (dokumentumból

Multipart szegmentálás és összefűzési overhead

Kódolás Egy szegmens határa Multipart határ Miért kisebb a multipart
GSM-7 160 karakter 153 karakter Az összefűzési fej helyet foglal
UCS-2 70 karakter 67 karakter Ugyanaz a fej, kisebb ábécé-keret

Hol bújnak a szegmensszámok

  • A composer előnézet „1 üzenetet” mutat, miközben a valódi kódolás 2–3 számlázott szegmenst ad
  • Sablonváltozók, amelyek csak egyes címzetteknél tolják a hosszt a határ fölé
  • Locale-specifikus karakterek (ékezetek, nem latin írások), amelyek egy nyelven átmennek a QA-n, máson pedig megsokszorozzák a költséget

Piros zászlók

  • A composer vagy az API-válasz üzenetszámot jelent szegmensszám helyett
  • Nincs rálátás, melyik kódolást használta egy konkrét küldés
  • A support azt mondja: „a kódolási problémák ritkák, ne aggódjon”
  • Ledger-sorok, amelyek nem vezethetők vissza hosszra, kódolásra és célállomásra
  • Bulk küldések sík becslésként számlázva, csak hónap végén egyeztetve

Kezdje az IOSOR-ral

Tekintsd át a kimenő sablonok tartalmakat az IOSOR konzolon, mielőtt nagy mennyiségű üzenetet indítanál. Állíts be API-ellenőrzési pontokat, amelyek kiszűrik az egy szegmensnél hosszabb, vagy váratlanul GSM-7-ről UCS-2 kódolásúra váltó adatokat. Biztosítsd, hogy a kézbesítési jelentések webhookjai az egyenleglevonást pontosan a kiszámlázott szegmensek számához kössék, ne pedig az általános üzenetszámhoz.

IOSOR összegzés

Egyetlen kimenő szöveges üzenet ritkán jelent egyetlen költségsort. A GSM-7 és az UCS-2 kódolás közötti választás, valamint a többrészes összefűzés fejlécköltsége azt jelenti, hogy a dinamikus szöveg apró változása vagy egyetlen speciális karakter is könnyen megkétszerezheti a címzettenkénti számlázást.

Hasznos volt ez az útmutató?

Kapcsolódó útmutatók