IOSOR

IOSOR Wiedza

Księgowość segmentów SMS: dlaczego jedna wiadomość to nie jedna linia kosztów

Przewodnik cenowy: GSM-7 vs UCS-2, narzut konkatenacji multipart oraz jak uzgodnić każde wysłanie z portfelem prepaid bez zgadywania.

Użytkownik wpisał jedną wiadomość. Portfel prepaid obciążył trzy jednostki. To nie bug — to księgowość segmentów, a zespoły finance, które nie rozumieją GSM-7 vs UCS-2 ani konkatenacji multipart, otwierają tickety przeciwko silnikowi billingowemu działającemu dokładnie zgodnie z projektem. Ten przewodnik jest dla liderów finance i produktu prowadzących prepaid white-label messaging, którzy potrzebują wyjaśnialnego spendu, a nie „ufaj fakturze”.

IOSOR traktuje każdą linię wydatku SMS jako odtwarzalną do liczby segmentów, kodowania i destination — nie jako nieprzezroczystą opłatę platformową. Przy około USD 1 000+ miesięcznego użycia platformy dyscyplina segmentów dzieli czystą miesięczną rekonsyliację od powtarzającej się eskalacji „dlaczego było drożej”.

Dlaczego jeden SMS to nie jedna linia kosztów

Co widzi nadawca Co widzi portfel
„Wysłałem jeden tekst” 1–3 jednostki rozliczone zależnie od kodowania i długości
Dodano emoji na końcu Cała wiadomość przechodzi na UCS-2
Zmienna szablonu o kilka znaków dłuższa Wiadomość przekracza granicę segmentu

GSM-7 vs UCS-2: dlaczego zestaw znaków zmienia matematykę

  • GSM-7 obejmuje ograniczony alfabet łaciński i mały zestaw symboli; każdy znak kosztuje mniej „budżetu” na segment
  • UCS-2 (dowolny znak poza GSM-7 — emoji, większość pism niełacińskich, część interpunkcji) wymusza całą wiadomość w szersze kodowanie z niższym limitem znaków na segment
  • Jeden „niewidzialny” znak (inteligentny cudzysłów z dokumentu, ptaszek, emoji) może po

Segmentacja multipart i narzut konkatenacji

Kodowanie Limit jednego segmentu Limit w multipart Dlaczego multipart jest mniejszy
GSM-7 160 znaków 153 znaki Nagłówek konkatenacji rezerwuje miejsce
UCS-2 70 znaków 67 znaków Ten sam nagłówek, mniejszy budżet alfabetu

Gdzie chowają się liczby segmentów

  • Podgląd composera pokazuje „1 wiadomość”, podczas gdy realne kodowanie daje 2–3 rozliczone segmenty
  • Zmienne szablonu, które wypychają długość poza granicę tylko dla części odbiorców
  • Znaki specyficzne dla locale (akcenty, pisma niełacińskie), które przechodzą QA w jednym języku i mnożą koszt w innym

Czerwone flagi

  • Composer lub odpowiedź API raportuje liczbę wiadomości zamiast segmentów
  • Brak widoczności, które kodowanie użyto dla konkretnej wysyłki
  • Support mówi „problemy z kodowaniem są rzadkie, nie martw się”
  • Linie ledgeru, których nie da się prześledzić do długości, kodowania i destination
  • Wysyłki bulk rozliczane jako płaska estymata, uzgadniane dopiero na koniec miesiąca

Zacznij z IOSOR

Przejrzyj szablony wychodzących treści w konsoli IOSOR przed uruchomieniem masowych wysyłek. Skonfiguruj bramki walidacji API, aby oznaczać każdą treść, która przekracza pojedynczy segment lub niespodziewanie zmienia kodowanie z GSM-7 na UCS-2. Upewnij się, że webhooki raportów doręczeń bezpośrednio powiązują potrącenia salda z dokładną liczbą rozliczanych segmentów, a nie z ogólną liczbą wiadomości.

Podsumowanie IOSOR

Jedna wychodząca wiadomość rzadko przekłada się na jedną pozycję kosztową. Wybór między kodowaniem GSM-7 a UCS-2, w połączeniu z narzutem nagłówków przy wiadomościach wieloczęściowych, sprawia, że niewielka zmiana w dynamicznym tekście lub pojedynczy znak specjalny mogą z łatwością podwoić rachunek za każdego odbiorcę.

Czy ten przewodnik był pomocny?

Powiązane przewodniki