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

Перевірте розрахунок білінгових сегментів у консолі IOSOR перед запуском масових розсилок з динамічними змінними.

Як розраховується резерв гаманця для передплати · Чому змінюється кодування посеред розсилки · Різниця між ціною в квоті та фінальним рахунком

Підсумок IOSOR

Одне відправлене повідомлення не завжди дорівнює одній білінговій одиниці, оскільки кодування та довжина тексту безпосередньо визначають кількість сегментів.

Чи був матеріал корисним?

Пов’язані гіди