IOSOR

IOSOR Kunskap

SMS-segmentredovisning: därför är ett meddelande inte en kostnadspost

Prisguide: GSM-7 vs UCS-2, overhead för multipart-konkatenering och hur du stämmer av varje sändning mot prepaid-plånboken utan gissningar.

Användaren skrev ett meddelande. Prepaid-plånboken debiterade tre enheter. Det är inte en bugg — det är segmentredovisning, och finance-team som inte förstår GSM-7 vs UCS-2 och multipart-konkatenering öppnar ärenden mot en faktureringsmotor som fungerar precis som den är designad.

IOSOR behandlar varje SMS-kostnadspost som rekonstruerbar till segmentantal, encoding och destination — inte som en ogenomskinlig plattformsavgift. Nära USD 1 000+ månatlig plattformsanvändning är segmentdisciplin skillnaden mellan en ren månadsavstämning och en återkommande eskalering “varför kostade det mer”.

Därför är ett SMS inte en kostnadspost

Vad avsändaren ser Vad plånboken ser
“Jag skickade en text” 1–3 fakturerade enheter beroende på encoding och längd
En emoji tillagd i slutet Hela meddelandet växlar till UCS-2
En mallvariabel några tecken längre Meddelandet korsar en segmentgräns

GSM-7 vs UCS-2: därför ändrar teckenuppsättningen matematiken

  • GSM-7 täcker ett begränsat latinskt alfabet och en liten symboluppsättning; varje tecken kostar mindre “budget” per segment
  • UCS-2 (vilket tecken som helst utanför GSM-7 — emoji, de flesta icke-latinska skriftsystem, viss skiljetecken) tvingar hela meddelandet till en bredare encoding med lägre teckengräns per segment
  • Ett “osynligt” tecken (smart citattecken från ett dokument, en bock, en emoji) kan tyst vända hela meddelandet från GSM-7 till UCS-2

Multipart-segmentering och konkatenerings-overhead

Encoding Gräns för ett segment Gräns i multipart Därför är multipart mindre
GSM-7 160 tecken 153 tecken Konkateneringshuvudet reserverar plats
UCS-2 70 tecken 67 tecken Samma huvud, mindre alfabetbudget

Att passera gränsen för ett segment “rundar” inte snyggt — meddelandet delas i flera segment, var och en med konkatenerings-overhead, och omfaktureras därefter.

Var segmentantal gömmer sig

  • En förhandsvisning i composern visar “1 meddelande” medan verklig encoding ger 2–3 fakturerade segment
  • Mallvariabler som skjuter längden över en gräns bara för vissa mottagare
  • Lokalspecifika tecken (accenter, icke-latinska skriftsystem) som klarar QA på ett språk och multiplicerar kostnad på ett annat

Varje debetpost ska visa: destination, meddelandelängd, upptäckt encoding, segmentantal och enhetstaxa — inte en blandad “SMS-avgift”. Om finance inte kan mappa en plånboksdebet till de fem fälten är legret inte avstämningsbart — man litar på det i tro.

  1. Uppskatta encoding och segmentantal före sändning med samma regler som plånboken kommer att fakturera
  2. Varna — tillåt inte tyst — när en mallredigering korsar en segmentgräns
  3. Visa encoding i composern, inte bara teckenräkning
  4. Testa med riktiga mottagarlocales, inte bara författarspråket

Röda flaggor

  • Composer eller API-svar rapporterar meddelandeantal i stället för segmentantal
  • Ingen synlighet för vilken encoding en specifik sändning använde
  • Support säger “encodingproblem är sällsynta, oroa dig inte”
  • Ledger-rader som inte kan spåras till längd, encoding och destination
  • Bulk-sändningar fakturerade som platt uppskattning, avstämda först i månadsskiftet

Börja med IOSOR

Granska dina utgående mallfiler i IOSOR-konsolen innan du skickar ut stora volymer. Konfigurera API-validering för att fånga upp meddelanden som överskrider ett enskilt segment eller oväntat växlar från GSM-7 till UCS-2.

IOSOR sammanfattning

Ett enda utgående textmeddelande motsvarar sällan en enda kostnadsrad.

Var den här guiden till hjälp?

Relaterade guider