レポートは送信数ではなく DLR 配達確認に一致させる必要があります

送信数は安しん感を与えます。API がメッセージを受理したため、その週の処理が順調に進んだように見えます。しかし、その安心感は請求週に崩壊します。送信数を成功として集計するレポートは、DLR 受領書、マルチセグメント トラフィックのウォレット引き落とし、Webhook 監査と相違が生じます。

IOSOR は厳格なルールを適用します。レポートのエクスポートは配達確認に従います。送信済み、キュー投入済み、送信受付済みは運用上のプロセス指標に過ぎません。財務および製品チームが議論すべき核心的な列は、配達完了、失敗、不明の 3 つです。

送信数はプロセスの痕跡であり締め指標ではない

送信受付はシステムがジョブを受理したことを証明するだけであり、端末が SMS を受信したことを証明するものではありません。レポートの主要 KPI が送信数になっている場合、失敗や不明の割合が増加した際に成功率を過大評価することになります。送信数はスループットの確認用として保持し、配達完了の代替指標として使用しないでください。

締め処理のルールを定着させます。まず DLR の列(不明、失敗、配達完了)を確認し、その後に全体のボリュームとして送信数を参照します。製品ローンのレビューでも同じ順序を採用し、マーケティングの資料が週の途中で成功の定義を勝手に変更できないようにします。

エクスポート列は受領書に従う

エクスポート スキーマは受領書の状態を明示的に定義します。配達完了には DLR が必須です。失敗には最終的な失敗シグナルが必要です。不明状態は受領書が届くまで不明のまま保持され、みなし配達として処理してはなりません。成功の中に不明を隠す請求週は、未配達問題の典型的な原因となります。

セグメント計算と実際の請求額が一致しない場合は、送信数に推定セグメント数を掛けるのではなく、受領書に基づく行データとセグメント数から調査を開始します。請求週のセグメント パスを正確に維持し、送信数を配達完了とみなすレポート設計を排除します。

Webhook と元帳を同じ受領書で照合する

Webhook 監査とプリペイド元帳のエクスポートを照合することは、レポートの正確性を証明する最善の方法です。日次 Webhook ログ、DLR 状態、プリペイド元帳の明細は一致している必要があります。Webhook が失敗を示しているにもかかわらずレポートが成功を示している場合は、レポート側が誤っています。ウォレットを調整するのではなく、エクスポートを修正してください。

監査の手順を定形化します。1 日分の Webhook 受領書、元帳エクスポート、レポート パックを準備し、メッセージ ID を照合します。ギャップは運用チームへ送付し、不正確な成功データはスキーマ担当者へ差し戻します。

送信数に基づく請求週の拒否

送信数のみに基づいて請求や成果報告を行う締め処理はブロックされるべきです。財務チームが配達完了と不明のシェアを軸に分析できるよう、レポート パックを再構築してください。パートナー契約に「成功した API 送信」と記載されている場合でも、それを DLR 補足情報として扱い、列の定義を不適切な表記に合わせないでください。

関連する運用パス

• DLR請求週：不明なシェアが未配達になる理由
• プリペイド残高に対する日次Webhookログの照合
• SMS請求週：セグメント計算と実際の請求額が一致しない時

IOSORで始める

IOSOR コンソールで今週のレポートパックを開き、見出し KPI が DLR レシート（delivered / failed / unknown）基準で、submit や API accept ではないことを確認する。submit を成功扱いしているチャートがあれば、財務クローズ前に改名か削除する。エクスポートは一度だけ、製品と財務で同じレシート列を共有する。

IOSORの要点

レポートは DLR レシート（delivered / failed / unknown）で閉じる。submit はスループット用であり、到達の真実でも請求の根拠でもない。

やる：レシート項目の単一エクスポートを固定する。やらない：製品が accept を祝い、財務が failed DLR で揉める状態。