IOSOR

IOSOR Gabay

Kalusugan ng CSV ng bulk lookup bago ang kampanya: i-normalize, i-dedupe, at magbadyet

Ang CSV ng bulk lookup ay dapat mag-normalize sa E.164, mag-dedupe, magrespeto ng stale na cache ng uri ng linya, at maglagay ng kisame ng badyet bago magpadala. Ibinabahagi ng finance at ops ang parehong mga column.

Gusto ng marketing ng listahan. Nakikita ng finance ang serye ng lookup debit na hindi tumutugma sa SMS na ipinadala pagkatapos. Ang bulk lookup ay hindi pagbuhos ng sheet sa API. Nauuna ang kalusugan sa gastos: normalize sa E.164, dedupe, respeto sa stale na cache ng uri ng linya, kisame sa wallet. Ang lumalaktaw sa kalusugan ay tinatrato ang patay na numero bilang aksidente sa paghahatid, ang dobleng row bilang «coverage», at ang lumang mobile na label bilang katotohanan ng routing.

Ipinapakete ng IOSOR ang lookup sa tabi ng messaging sa isang white-label prepaid ledger. Ang katalogo live ay nangangahulugang handa ang tseke; ang in setup ay hindi production gate na cine-cache.

Mga column ng CSV na kailangan ng finance at ops

Dapat buksan ng finance at ops ang parehong CSV at basahin ang parehong kuwento. Minimum na column: normalized E.164, hilaw na input, lookup timestamp, uri ng linya, cache hit o sariwang tseke, na-debit na halaga, desisyon sa pagpadala (send / skip / tingnan ulit), campaign o batch id. Ang «mobile» na label na walang timestamp ay opinyon, hindi ebidensya.

E.164 at dedupe bago ang gastos sa lookup

I-normalize at i-dedupe bago tumakbo ang pera ng lookup. Ang parehong linya na nakasulat +1…, 001… at lokal na format ay na-debit nang tatlong beses. I-normalize sa E.164, i-dedupe sa numerong iyon, tapos tawagin ang lookup live. Itapon ang basurang row (masyadong maikli, letra, test string) sa import, huwag itanong bilang «unknown».

Panganib ng stale na cache ng uri ng linya

Ang naka-cache na uri ng linya ay routing signal na may timestamp, hindi tattoo. Ang mobile kahapon ay maaaring VoIP range ngayon. Ang stale na cache ay nagpapadala ng OTP sa patay na range o kuskos sa customer na nag-port kahapon. Binabayaran pa rin ninyo ang lookup row at ang nasayang na segment. Ang TTL ay panuntunan ng produkto, hindi lasa ng database. Huwag i-cache ang «unknown» bilang mobile.

Mga kisame ng badyet at ritmo ng export

Ang kisame ng badyet ay sa batch, hindi sa «magre-reconcile tayo later». Maglagay ng kisame ng row at halaga bawat lookup run; ang ritmo ng export (araw-araw o sa pagsara ng batch) ay bago ang blast, hindi sorpresa sa katapusan ng buwan. Malapit sa USD 1,000+, ang maiiwasang gastos at bucket ng edad ng cache ay pumapasok sa mas siksik na review.

Mga pulang bandila

  • Bulk lookup nang walang normalize
  • Parehong E.164 na na-debit nang dalawang beses dahil sa variant ng format
  • Stale na «mobile» bilang katotohanan ng routing
  • Unknown na naka-cache bilang mobile
  • CSV na walang kisame ng row o halaga
  • Lookup na nire-reconcile sa padala sa katapusan ng buwa

Magsimula sa IOSOR

Kunin ang CSV ng kampanya noong nakaraang linggo. I-normalize ang bawat hilera sa E.164, itapon ang basura, i-dedupe sa normalisadong numero, tapos isang lookup. Takpan ang batch sa bilang ng hilera at prepaid na halaga bago ang putok. I-export ang parehong file na bubuksan ng pananalapi at ops: uri ng linya, cache hit, debit, desisyong send o skip.

Buod ng IOSOR

Gawin: kalinisan bago ang pera ng lookup. Ang mga anyo ng iisang linya ay isang debit. Ang naka-cache na uri ng linya ay may selyo ng oras; ang lumang mobile ay hindi katotohanan ng ruta.

Huwag: ibuhos ang sheet sa API at i-reconcile sa katapusan ng buwan. Ang dobleng hilera ay hindi saklaw. Ang Unknown na naka-cache bilang mobile ay prepaid na tagas.

Nakatulong ba ang gabay na ito?

Mga kaugnay na gabay