IOSOR

IOSOR Kunnskap

SMS-segmentregnskap: derfor er én melding ikke én kostnadspost

Prisveiledning: GSM-7 vs UCS-2, multipart-konkatenasjonsoverhead og hvordan du avstemmer hver sending mot den forhåndsbetalte lommeboken uten gjetting.

Brukeren skrev én melding. Den forhåndsbetalte lommeboken debiterte tre enheter. Det er ikke en feil — det er segmentregnskap, og finance-team som ikke forstår GSM-7 vs UCS-2 og multipart-konkatenering åpner saker mot en billingmotor som fungerer nøyaktig som designet.

IOSOR behandler hver SMS-kostnadspost som rekonstruerbar til segmentantall, encoding og destinasjon — ikke som et ugjennomsiktig plattformgebyr. Nær USD 1 000+ månedlig plattformbruk er segmentdisiplin forskjellen mellom en ren månedsavstemming og en gjentatt eskalering “hvorfor kostet dette mer”.

Derfor er én SMS ikke én kostnadspost

Det avsenderen ser Det lommeboken ser
“Jeg sendte én tekst” 1–3 fakturerte enheter avhengig av encoding og lengde
Én emoji lagt til på slutten Hele meldingen bytter til UCS-2
En malvariabel noen tegn lengre Meldingen krysser en segmentgrense

GSM-7 vs UCS-2: derfor endrer tegnsettet matematikken

  • GSM-7 dekker et begrenset latinsk alfabet og et lite symbolsett; hvert tegn koster mindre “budsjett” per segment
  • UCS-2 (ethvert tegn utenfor GSM-7 — emoji, de fleste ikke-latinske skrifter, noe tegnsetting) tvinger hele meldingen inn i en bredere encoding med lavere tegngrense per segment
  • Ett “usynlig” tegn (smart anførselstegn fra et dokument, et hakemerke, en emoji) kan stille snu hele meldingen fra GSM-7 til UCS-2

Multipart-segmentering og konkatenasjonsoverhead

Encoding Grense for ett segment Grense i multipart Hvorfor multipart er mindre
GSM-7 160 tegn 153 tegn Konkatenasjonshodet reserverer plass
UCS-2 70 tegn 67 tegn Samme hode, mindre alfabetbudsjett

Å krysse grensen for ett segment “avrunder” ikke elegant — meldingen deles i flere segmenter, hver med konkatenasjonsoverhead, og faktureres på nytt tilsvarende.

Hvor segmentantall gjemmer seg

  • En composer-forhåndsvisning viser “1 melding” mens den reelle encodingen gir 2–3 fakturerte segmenter
  • Malvariabler som skyver lengden over en grense bare for noen mottakere
  • Locale-spesifikke tegn (aksenter, ikke-latinske skrifter) som klarer QA på ett språk og multipliserer kostnad på et annet

Hver debetlinje bør vise: destinasjon, meldingslengde, oppdaget encoding, segmentantall og enhetstakst — ikke et blandet “SMS-gebyr”. Hvis finance ikke kan mappe en lommebokdebet til de fem feltene, er ledgeret ikke avstemmelig — man stoler på det i tro.

  1. Estimer encoding og segmentantall før sending med de samme reglene som lommeboken vil fakturere etter
  2. Advar — tillat ikke stille — når en malredigering krysser en segmentgrense
  3. Vis encoding i composeren, ikke bare tegnantall
  4. Test med ekte mottakerlocales, ikke bare forfatterspråket

Røde flagg

  • Composer eller API-svar rapporterer meldingsantall i stedet for segmentantall
  • Ingen synlighet for hvilken encoding en spesifikk sending brukte
  • Support sier “encodingproblemer er sjeldne, ikke bekymre deg”
  • Ledgerlinjer som ikke kan spores tilbake til lengde, encoding og destinasjon
  • Bulk-sendinger fakturert som flat estimering, først avstemt ved månedsavslutning

Start med IOSOR

Gå gjennom malane for utgåande meldingar i IOSOR-konsollet før de set i gong store utsendingar. Konfigurer API-valideringsfilter for å markere meldingar som overstig eit enkelt segment eller uventa byter frå GSM-7- til UCS-2-koding. Sørg for at leveringsrapportane knyt saldofrådraga direkte til nøyaktige tal på fakturerte segment i staden for generelle meldingsantall.

IOSOR-lærdom

Ei enkel utgåande tekstmelding svarer sjeldan til éin enkel kostnadspost.

Var denne guiden nyttig?

Relaterte veiledninger