IOSOR

IOSOR Знания

Счетоводство на SMS сегменти: защо едно съобщение не е един разходен ред

Ценови гид: GSM-7 срещу UCS-2, overhead на multipart конкатенация и как да съгласувате всяко изпращане с предплатения портфейл без гадаене.

Потребителят написа едно съобщение. Предплатеният портфейл дебитира три единици. Това не е бъг — това е счетоводство на сегменти, и финансови екипи, които не разбират GSM-7 срещу UCS-2 и multipart конкатенация, отварят тикети срещу билингов двигател, който работи точно както е проектиран. Този гид е за финансови и продуктови лидери, които управляват prepaid white-label messaging и имат нужда от обясним разход — не „вервайте на фактурата“.

IOSOR третира всеки SMS разходен ред като реконструируем до брой сегменти, кодиране и дестинация — не като непрозрачна платформена такса. Около USD 1 000+ месечна употреба на платформата дисциплината на сегментите е разликата между чиста месечна сверка и повтаряща се ескалация „защо струваше повече“.

Защо едно SMS не е един разходен ред

Какво вижда подателят Какво вижда портфейлът
„Изпратих един текст“ 1–3 таксувани единици според кодиране и дължина
Добавено е emoji в края Цялото съобщение преминава към UCS-2
Променлива в шаблон с няколко символа по-дълга Съобщението пресича граница на сегмент

GSM-7 срещу UCS-2: защо наборът от символи променя математиката

  • GSM-7 покрива ограничена латиница и малък набор символи; всеки символ струва по-малко „бюджет“ на сегмент
  • UCS-2 (всеки символ извън GSM-7 — emoji, повечето нелатински писмености, част от пунктуацията) принуждава цялото съобщение към по-широко кодиране с по-нисък лимит на сегмент
  • Един „невидим“ символ (умни кавички от документ, отметка, emoji) може тихо да превключи

Multipart сегментация и overhead на конкатенация

Кодиране Лимит на един сегмент Лимит в multipart Защо multipart е по-малък
GSM-7 160 символа 153 символа Заглавката на конкатенация резервира място
UCS-2 70 символа 67 символа Същата заглавка, по-малък азбучен бюджет

Къде се крият броевете на сегменти

  • Прегледът в composer показва „1 съобщение“, докато реалното кодиране дава 2–3 таксувани сегмента
  • Променливи в шаблон, които бутат дължината над граница само за част от получателите
  • Locale-специфични символи (ударения, нелатински писмености), които минават QA на един език и умножават разхода на друг

Съгласуване на сегменти с предплатения портфейл

Всеки дебитен ред трябва да показва: дестинация, дължина на съобщението, засечено кодиране, брой сегменти и единична ставка — не смесена „SMS такса“. Ако финансите не могат да съпоставят дебит от портфейла към тези пет полета, ledger-ът не е съгласуем — доверяват му се с вяра.

Започнете с IOSOR

Прегледайте шаблоните за изходящи съобщения в конзолата на IOSOR, преди да пуснете мащабни кампании. Настройте API проверки за валидация, които да сигнализират при всяко съобщение, надвишаващо един сегмент или преминаващо неочаквано от GSM-7 към UCS-2 кодиране. Уверете се, че уебхукувете за отчети за доставка обвързват спада в баланса директно с точния брой таксувани сегменти, а не с общия брой съобщения.

Обобщение IOSOR

Едно изходящо текстово съобщение рядко се равнява на един разходен ред. Изборът между GSM-7 и UCS-2 кодиране, съчетан със системните изисквания при разделяне на дълги съобщения, означава, че дори малка промяна в динамичния текст или един специален символ могат лесно да удвоят таксуването на получател.

Полезно ли беше ръководството?

Свързани ръководства