IOSOR

IOSOR База знаний

Segment accounting: почему «одно SMS» ≠ одна строка spend

Pricing-гайд по segment accounting в SMS — GSM-7 vs UCS-2 encoding, overhead multipart-конкатенации и сверка каждой отправки с prepaid-кошельком без догадок.

Пользователь напечатал одно сообщение. Prepaid-кошелёк списал три unit. Это не баг — это segment accounting, и финансовые команды, которые не понимают GSM-7 vs UCS-2 и multipart-конкатенацию, заводят тикеты на billing-движок, который работает ровно так, как задуман. Этот гайд для finance и product leads, которые ведут prepaid white-label messaging и хотят, чтобы spend был объясним, а не «доверьтесь инвойсу».

IOSOR относится к каждой строке SMS-spend как к реконструируемой до segment count, encoding и destination — а не как к непрозрачной platform fee. Около USD 1 000+ месячного platform usage дисциплина segment — разница между чистой месячной сверкой и повторяющейся эскалацией «почему это стоило дороже».

Почему «одно SMS» — не одна строка spend

Что видит отправитель Что видит кошелёк
«Я отправил один текст» 1–3 billed unit в зависимости от encoding и длины
Один emoji добавлен в конец Всё сообщение переключилось в UCS-2
Шаблон с переменной чуть длиннее Сообщение перешло границу segment

GSM-7 vs UCS-2: почему character set меняет математику

  • GSM-7 покрывает ограниченный латинский алфавит и небольшой набор символов; каждый символ стоит меньше «бюджета» на segment
  • UCS-2 (любой символ вне GSM-7 — emoji, большинство нелатинских письменностей, часть пунктуации) переводит всё сообщение на более широкий encoding с меньшим лимитом символов на segment
  • Один «невидимый» символ (умная кавычка, вставленная из документа, галочка, emoji) может тихо переключить всё сообщение с GSM-7 на UCS-2

Multipart segmentation и overhead конкатенации

Encoding Лимит одного segment Лимит segment в multipart Почему multipart меньше
GSM-7 160 симв. 153 симв. Заголовок конкатенации резервирует место
UCS-2 70 симв. 67 симв. Тот же заголовок, меньший алфавитный бюджет

Переход через лимит одного segment не «округляется» аккуратно — сообщение делится на несколько segment, каждый с overhead конкатенации, и billится соответственно.

Где скрываются segment count

  • Превью в композере показывает «1 сообщение», хотя реальный encoding даёт 2–3 billed segment
  • Переменные шаблона, которые толкают длину за границу только для части получателей
  • Locale-специфичные символы (диакритика, нелатинские письменности), которые проходят QA на одном языке и множат стоимость на другом

Каждая строка списания должна показывать: destination, длину сообщения, определённый encoding, segment count и unit rate — а не единую смешанную «SMS fee». Если finance не может свести списание кошелька к этим пяти полям, ledger не сверяем, ему просто доверяют на веру.

  1. Оценивайте encoding и segment count до отправки, по тем же правилам, по которым billится кошелёк
  2. Предупреждайте (а не тихо пропускайте), когда правка шаблона пересекает границу segment
  3. Показывайте encoding в композере, а не только счётчик символов
  4. Тестируйте на реальных locale получателей, а не только на языке авторинга

Красные флаги

  • Композер или API-ответ показывает message count вместо segment count
  • Нет видимости, какой encoding использовался для конкретной отправки
  • Support говорит «проблемы с encoding редки, не переживайте»
  • Строки ledger нельзя проследить до длины, encoding и destination
  • Bulk-отправки billятся плоской оценкой, сверяемой только в конце месяца

Начните с IOSOR

Проверьте настройки API-шлюза в консоли IOSOR и зафиксируйте лимит сегментов на одно исходящее сообщение.

Как работает резервирование баланса при предоплате? · Что делать при смене кодировки в середине рассылки? · Чем отличается предварительный расчет от итогового счета?

Итог IOSOR

Данное руководство подтверждает: расхождение между количеством отправленных SMS и итоговым расходом депозита всегда вызвано правилами сегментации GSM-7 и UCS-2.

Был ли материал полезен?

Связанные гайды