Skip to main content

​
10DLC reddetmeleri, yeniden denetim ve onay sonrası yaşam döngüsü

10DLC kayıt kılavuzu, “gönderime başla” noktasında biter. Bu kılavuz bundan sonra ne olduğunu kapsar — şifreli gizli bir kodla bir reddetme, kapasitenizi sınırlayan bir denetim puanı veya günlük sınırı artık hacminize uymayan onaylanmış bir kampanya. Buradaki her şey kendi kayıtlarınız üzerinde bir kontroldür; operatör ve kayıt kurumu kararları onların kalır.

​
Reddetmeler nereden gelir

Bir reddetme iki şeyden biridir ve fark, sonrasında yaptığınız her şeyi belirler:
  • Kayıt kurumu reddetmeleri (TCR ve ona vekilenen CSP’ler) kayıt incelemesi sırasında veya sonrasında ateşlenir — dosyalama kendisi reddedilir. Bunlar, üç yerde bir rejectionReason dizgisiyle FAILED / REJECTED durumu kayıtları olarak yüzeyene çıkar: Ayarlar > Uyum > 10DLC sihirbash, terminal geçişinde bir dashboard bildirimi ve GET /api/v1/compliance/10dlc/campaigns/:id/status üzerindeki rejectionReason alanı.
  • Operatör reddetmeleri (AT&T, T-Mobile) TCR onayından sonra, operatör başına mnoStatuses haritası içinde inebilir — marka üzerinde doğrudan bir operatör denetimi veya bir operatörün CSP düzeyi kararla anlaşmazlığı.
Bazı kodlar, TCR herhangi bir karar vermeden önce yayınlanır: DUPLICATE-BRAND ve küçük harfli-usecase başarısızlığı gönderim-zamanı işaretleridir, inceleme-aşaması çıktıları değil. Gönderiminizin hemen ardından sihirbashın gösterdiği bir reddetme genellikle bu sınıfa girer. İki reddetme, düzeltme istemek yerine kaydı kilitler — BRAND-DCA-FAIL ve DUPLICATE-BRAND, resubmit_allowed: false ile bir düzeltme kartı döndürür, bu da marka kimliğinin yakıldığı ve düzeltmenin bir düzenleme değil, yeni bir kayıt olduğu anlamına gelir.

​
Ham bir reddetme kodunu düzeltme kartına çözün

TCR ve CSP’ler, 30883, 40016 ve EIN-MISMATCH gibi kodları tek satır serbest-metin nedeniyle ve alan başına düzeltme olmadan döndürür. Sorun Giderme: 10DLC kampanyası reddedildi konusundaki düzeltme tablosu yaygın durumları statik olarak kapsar; kod çözücü uç noktası aynı kataloğu herhangi bir koda uygular — tablo listesinde yer almayan ifadeler ve kodlar dahil. POST /api/v1/compliance/10dlc/decode-rejection Ham code’u ve sahip olduğunuzda serbest-metin rejectionReason’u geçirin — serbest metin, birden fazla nedene eşlenen kodları netleştirir:
Yanıt (200 OK):
Karttan dört alanı okuyun:
  • fix — sihirbash reddetme şeridiyle aynı dilde, tek en yüksek olasılıklı düzeltme adımı.
  • resubmit_allowed — sonraki çağrınızı belirleyen karar. true: yükü düzeltip aynı markayı veya kampanyayı yeniden gönderin. false: kayıt kilitlidir; yeni bir kayıt başlatın.
  • category — kendi UI’nızda gruplamak için kararlı bir küme (eligibility, content, identity, throughput, format, dca, unknown).
  • field — düzeltmenin uygulandığı sihirbash adımı (campaign.sample_message, brand.ein, …), böylece operatörü doğru forma derin bağlayabilirsiniz.
Kod çözücü saf bir kural motorudur — hiçbir şey saklamaz, hiçbir şey oluşturmaz ve kodu sizin için normalleştirir: TCR-30883, Twilio Error 30883 ve ein_mismatch’ın tümü kanonik girişlerine çözülür. Tanımlanamayan bir kod, unknown-kategorili bir kart döndürür ve bu kartın fix’i sizi Devotel uyuma yönlendirir, böylece kartı işleyen bir UI asla boş bir panel göstermez.
Düzeltmeyi çalıştırmadan önce kod çözücüyü çalıştırın. Kartın fix alanı bir örnek mesajı veya açıklamayı yeniden yazdığında, düzeltilmiş yükü yeniden göndermeden önce preflight linter’ı üzerinden geçirin — düzeltmenin sık sık tanıttığı ikinci derece reddetmeyi yakalar.

​
Çalışılmış örnek: ‘kullanım durumu uyumsuzluğu’

Bir kampanya durumu yoklaması şunu döndürür:
Neden dizgisi nedeni adlandırır ama bir TCR kodu değil. Kod çözücü biriyle veya diğeriyle çalışır, bu yüzden sahip olduğunuzu geçirin — yalnızca serbest metin:
Yanıt — 30898 kartı:
resubmit_allowed: true, düzelt-ve-yeniden-gönder demektir. Şimdi düzeltilmiş kampanyayı aynı markaya karşı yeniden gönderin — ilk dosyalama ile aynı çağrı, aynı gibi yeniden dosyalanır:
İlk dosyalama ile aynı 1–5 iş gününü bekleyin; durum uç noktasını yoklayın veya dashboard bildirimini izleyin.

​
İkinci bir çalışılmış örnek: ‘SHAFT örneği’

Bu, içerik sınıfı bir kartla aynı döngüdür. "Sample 2 flagged: SHAFT sample" gibi bir neden, 30883 — içerik ihlali — koduna çözülür ve resubmit_allowed: true ile field: "campaign.sample_message" taşır. İşaretlenen örneği, bildirilen dikeyi belirtecek şekilde yeniden yazın ve yasaklı ifadeyi bırakın, ardından kampanyayı aynı gibi yeniden dosyalayın. Döngünün amacı: bir kod çözücü çağrısı, bir düzeltilmiş gönderim ve bunun hiçbiri TCR’nin hangi ifadeyi döndürdüğüne bağlı değildir.

​
Yeniden denetim mi, yeniden gönderim mi

Reddedilen içerik düzeltmeleri yeniden gönderim demektir. Bir düşük denetim puanı farklı bir engelleyicidir — bir kampanya yükünde hiçbir düzeltme miktarı bunu onarmaz ve sadece incelemede olan kampanyayı değil, markadaki her kampanyayı sınırlar. Puan sınırı belirler, bu yüzden çözüm bir yeniden gönderim değil, bir yeniden denetimdir. POST /api/v1/compliance/10dlc/brands/:id/revet
Yanıt (200 OK):
provider, markayı taşıyan kayıtçıyı adlandırır; status, yeniden denetim başladığında yenilenen marka durumudur. Yeniden denetimden önce marka kaydını tamamlayın — EIN, IRS kayıtlarıyla eşleşen yasal ad, web sitesi, kendi etki alanınızda destek e-postası — yeniden denetim aynı bilgileri yeniden puanlar ve değişmemiş bir kayıt değişmemiş bir puan döndürür. Kayıtçı yeniden denetimleri oran sınırlar (kayıttan hemen sonra bir kez, ardından kabaca üç ayda bir kez), bu yüzden oran sınırlı bir çağrı, kayıtçının bekleyin metniyle 422 döndürür — onu okuyun, bir döngüde yeniden denemeyin.

​
Kapasite planlama: puanın verdiği

İki uç nokta, denetim puanını işlediğiniz sınırlara çevirir. GET /api/v1/compliance/10dlc/brands/:id/vetting ham sonucu döndürür:
vettingScore: null, EVP’nin hâlâ işlediği anlamına gelir — 0 değil, “Beklemede” olarak işleyin. GET /api/v1/compliance/10dlc/brands/:id/throughput, operatör tarafından atanan sınırları o puandan türetir:
Yanıt (200 OK):
  • att.class — AT&T, kampanya başına bir kapasite sınıfı atar, D→C→B→A (dakikada 15 → 75 → 240 → 600 mesaj), güven puanı katları 0/25/50/75’te.
  • tmobile.tier — T-Mobile, markadaki her kampanyayı ve numarayı kapsayan marka başına günlük-sınır katmanı atar (2k / 10k / 40k / 200k / sınırsız).
  • entity_type (isteğe bağlı sorgu parametresi) — sole-proprietor markaları puana bakılmaksızın 2k katmanı ve Sınıf D ile sınırlıdır; türetionun özel durumu görmesi için kayıtlı varlık türünü geçirin.
  • sent_today (isteğe bağlı sorgu parametresi) — geçerli kayan 24 saatlik pencerede zaten gönderilmiş mesaj parçaları. Geçirdiğinizde, consumption sessiz-filtreleme bölgesinden önce kapasite kalanını raporlar: ok sınırın %80’inin altında, warning %80’de, critical %95’de, exceeded %100’ünde.
Her iki sorgu parametresi de isteğe bağlıdır; sent_today sağlayana kadar consumption null durumundadır.

​
Yeniden denetim mi, yoksa katmanı kabul mü

warning / critical eşiklerini işaret olarak kullanın. Önplan hacminiz sürekli olarak uyarı bandına indiğinde bir yeniden denetim planlayın — oran sınırlıdır, bu yüzden bunu yalnızca gerçek bir yörünge değişikliğinde yakın. Tavan sınıf değil de günlük sınır olduğunda, kısıt marka başınadır: kampanyaya daha fazla numara atamak onu yükseltmez ve bir SOLE_PROPRIETOR’ün tam marka kaydına yükseliş yükseltir — bu bir varlık türü değişikliğidir, bir yeniden denetim değil.

​
Yeniden gönderim mi, yeniden denetim mi: her birinin maliyeti

TCR yeniden gönderim başına ve yeniden denetim başına yeni bir denetim ücreti alır (genellikle birkaç USD) ve operatörler her yeniden gönderimi yeni bir inceleme olarak değerlendirir — önceki denemelerinizden bağımsız zamanlama.

​
Ayrıca bakınız