DLR پیامک چیست؟ تفاوت Sent، Delivered و Failed در گزارش تحویل
DLR پیامک یا Delivery Receipt، گزارشی دربارهٔ نتیجهٔ تحویل پیام پس از واگذاری آن به مسیر ارسال است. این گزارش کمک می‌کند بفهمیم پیام در چه وضعیتی قرار گرفته؛ اما «درخواست پذیرفته شد»، «به مسیر بالادستی ارسال شد» و «تحویل گزارش شد» سه رویداد متفاوت‌اند. تفسیر درست DLR به مرحلهٔ پیام، قرارداد ارائه‌دهنده و منبع گزارش بستگی دارد.
برای تیمی که رمز یک‌بارمصرف، اعلان تراکنش یا پیام خدماتی می‌فرستد، دیدن واژهٔ «ارسال شد» در داشبورد کافی نیست. اگر مشتری بگوید پیام را دریافت نکرده، باید بتوان مسیر پیام را از ثبت درخواست تا گزارش نهایی دنبال کرد. DLR همین شکاف اطلاعاتی را تا حدی پر می‌کند. این راهنما معنای وضعیت‌های رایج، مسیر دریافت گزارش، محدودیت‌های آن و روش پایش عملی را توضیح میدهد. برای دیدن تصویر بزرگ‌تر مسیر پیام، ابتدا معماری SMS Gateway سازمانی را ببینید.
DLR پیامک چیست و در کدام مرحله ایجاد می‌شود؟
DLR مخفف Delivery Receipt و به معنی رسید یا گزارش تحویل است. سامانهٔ فرستنده پیام را به درگاه پیامک میدهد؛ درگاه از طریق صف و مسیریابی پیامک آن را به اتصال بالادستی می‌فرستد. پس از ثبت رویدادهای مسیر، نتیجهٔ تحویل یا شکست میتواند به شکل گزارش به سامانهٔ مبدأ برگردد. در SMPP، رسید تحویل معمولاً با پیام deliver_sm و شناسهٔ پیام مرتبط می‌شود؛ در APIهای وب، همین رویداد ممکن است با callback یا webhook منتقل شود.
گزارش تحویل همان پاسخ اولیهٔ درخواست ارسال نیست. پاسخ اولیه معمولاً نشان میدهد درگاه درخواست را پذیرفته یا رد کرده است. DLR رویداد بعدی است و ممکن است چند ثانیه یا بیشتر پس از آن برسد. زمان دقیق و جزئیات گزارش به مسیر، اپراتور، نوع اتصال و سیاست نگهداری پیام بستگی دارد. در بعضی مسیرها وضعیت نهایی ناقص یا با تأخیر می‌رسد؛ بنابراین طراحی سامانه باید وضعیت «هنوز نامعلوم» را نیز تحمل کند.
پاسخ کوتاه: برای هر پیام یک شناسهٔ پایدار نگه دارید، پاسخ ثبت درخواست را از DLR جدا کنید و وضعیت را به‌صورت یک تاریخچهٔ رویداد ذخیره کنید. «Sent» بهتنهایی تحویل به مخاطب را ثابت نمیکند و نبود DLR نیز بهتنهایی شکست قطعی نیست.
تفاوت Sent، Delivered و Failed در گزارش پیامک چیست؟
نام وضعیت‌ها در سرویس‌های مختلف یکسان نیست و حتی یک نام ممکن است در لایه‌های متفاوت معنای عملیاتی متفاوتی داشته باشد. با این حال، می‌توان یک مدل عمومی برای خواندن داشبورد و طراحی پایش به کار برد. برای نمونه، مستندات رسمی Twilio، sent را پذیرش توسط نزدیک‌ترین مسیر بالادستی و delivered را دریافت تأیید تحویل از مسیر بالادستی و در صورت دسترس، گوشی مقصد توصیف می‌کند. این تعریف را نباید بدون بررسی قرارداد به همهٔ ارائه‌دهندگان تعمیم داد.
| وضعیت عمومی | چه چیزی را نشان میدهد؟ | چه چیزی را ثابت نمیکند؟ | اقدام بعدی |
|---|---|---|---|
| Accepted | درخواست ارسال در لایهٔ دریافت پذیرفته شده است. | عبور پیام از صف یا تحویل به مخاطب. | شناسهٔ پیام و وضعیت‌های بعدی را دنبال کنید. |
| Queued | پیام برای پردازش یا ارسال در صف قرار دارد. | واگذاری موفق به اپراتور. | عمق و عمر صف را بررسی کنید. |
| Sent / Submitted | پیام به مسیر بالادستی سپرده یا در آن پذیرفته شده است. | تحویل نهایی به گوشی و خواندهشدن. | منتظر وضعیت نهایی و DLR بمانید. |
| Delivered | گزارش تحویل موفق از مسیر دریافت شده است. | باز شدن یا خواندهشدن پیام توسط انسان. | زمان و منبع گزارش را ثبت کنید. |
| Failed / Undelivered | ارسال یا تحویل در یک مرحله ناموفق گزارش شده است. | یک علت مشترک برای همهٔ شکست‌ها. | مرحله، کد خطا و قابلیت Retry را تفکیک کنید. |
| Unknown / Pending | هنوز نتیجهٔ قابل اتکا یا نهایی در دست نیست. | موفقیت یا شکست قطعی. | مهلت انتظار، استعلام و آشتی رویدادها را اجرا کنید. |
آیا Delivered یعنی پیام خوانده شده است؟
خیر. DLR دربارهٔ وضعیت تحویل در شبکه یا مسیر پیام است، نه رفتار انسانی مخاطب. حتی وقتی گزارش Delivered ثبت شده، نمی‌توان نتیجه گرفت کاربر پیام را باز کرده یا متن را خوانده است. وضعیت Read مربوط به کانال‌هایی است که رسید خواندن دارند و نباید آن را با SMS معمولی یکی دانست. برای اندازه‌گیری تعامل، باید به رویداد مستقل و مجاز دیگری مانند اقدام کاربر در سرویس مراجعه کرد.
Failed و Undelivered یکسان‌اند؟
در مدل برخی سرویس‌ها، Failed یعنی خود فرایند ارسال پیش از واگذاری موفق شکست خورده و Undelivered یعنی پیام واگذار شده اما گزارش عدم تحویل برگشته است. این تفاوت برای تصمیم دربارهٔ Retry Policy پیامک مهم است: خطای ورودی نامعتبر معمولاً با تلاش دوباره حل نمی‌شود، اما اختلال موقت مسیر ممکن است به بررسی یا تلاش کنترل‌شده نیاز داشته باشد. کدهای خطا را بر اساس مستندات همان ارائه‌دهنده تفسیر کنید.
چرا DLR ممکن است دیر برسد یا اصلاً دیده نشود؟
در مسیر پیامک، رویدادها هم‌زمان رخ نمی‌دهند. پیام ممکن است مدتی در صف بماند، به مسیر بالادستی واگذار شود و سپس منتظر گزارش نهایی باشد. اگر گوشی خاموش باشد یا مسیر گزارش با تأخیر کار کند، وضعیت نهایی دیرتر ثبت می‌شود. در برخی اتصال‌ها نیز گزارش ممکن است کامل به سامانهٔ شما نرسد. بنابراین «هنوز DLR نیامده» یک وضعیت مستقل است و نباید بلافاصله به «ناموفق» یا «موفق» تبدیل شود.
در SMPP، دریافت رسید به درخواست DLR در زمان ارسال و قابلیت مرکز پیام وابسته است. قالب رایج رسید شامل شناسهٔ پیام، زمان ثبت، زمان نهایی، وضعیت و کد خطاست؛ با این حال برخی خطاها وابسته به شبکه یا SMSC هستند. نگاشت یک کد عمومی به علت قطعی بدون قرارداد مسیر میتواند گزارش‌های عملیاتی را گمراه کند. مستندات رسمی پروتکل نیز حالت‌های میانی مانند ENROUTE را از حالت‌های نهایی مانند DELIVERED و EXPIRED جدا می‌کند.
گزارش تحویل را چگونه به سامانهٔ سازمانی وصل کنیم؟
اولین نیاز، پیوند قابل ردیابی میان شناسهٔ درخواست کسب‌وکار، شناسهٔ داخلی درگاه و شناسه‌ای است که اتصال بالادستی برمی‌گرداند. اگر این رابطه در زمان ارسال ثبت نشود، هنگام ورود DLR نمی‌دانید گزارش به کدام سفارش، اعلان یا کاربر مربوط است. شناسهٔ پیام را به‌جای متن و شمارهٔ مقصد مبنای تطبیق بگذارید؛ دو پیام معتبر ممکن است متن و مقصد یکسان داشته باشند.
در یک جریان مبتنی بر webhook یا callback، endpoint دریافت‌کننده باید هویت فرستنده را طبق روش مورد توافق اعتبارسنجی کند، پاسخ مناسب بدهد و پردازش رویداد را از پاسخ سریع شبکه جدا نگه دارد. رویداد تکراری یا خارج از ترتیب نباید تاریخچه را خراب کند. برای مثال، اگر یک وضعیت دیررس بعد از گزارش نهایی رسید، آن را به‌عنوان رویداد ثبت کنید اما وضعیت نهایی را بدون قاعدهٔ مشخص برنگردانید. زمان رویداد، زمان دریافت، مسیر و شناسهٔ تطبیق را جدا ثبت کنید.
اگر رابط شما به‌جای callback امکان استعلام دارد، بازه و سقف استعلام را مشخص کنید. استعلام بی‌وقفه برای همهٔ پیام‌ها میتواند بار غیرضروری ایجاد کند. در هر دو مدل، یک مهلت برای تبدیل «Pending» به «نیازمند بررسی» تعریف کنید. این مهلت باید با نوع پیام و شرایط مسیر سازگار باشد؛ یک عدد ثابت برای همهٔ پیام‌های تراکنشی و تبلیغاتی مناسب نیست.
کدام شاخص‌ها برای پایش DLR مهم‌اند؟
نرخ تحویل را بهتنهایی نبینید. نسبت پیام‌های Sent که DLR نهایی دریافت کرده‌اند، تأخیر از واگذاری تا گزارش نهایی، سهم وضعیت‌های نامعلوم، نرخ خطا به تفکیک مسیر و نوع پیام و تعداد رویدادهای ناسازگار را کنار هم بسنجید. این شاخص‌ها به تیم عملیات کمک می‌کنند مشکل تحویل را از مشکل دریافت گزارش جدا کند. برای نمونه، افزایش ناگهانی پیام‌های Sent بدون DLR میتواند از اختلال مسیر گزارش یا تأخیر بالادستی باشد؛ صرفاً با افزایش Retry حل نمی‌شود.
تحلیل را در بازه‌های زمانی مناسب و به تفکیک اپراتور، مسیر، مشتری و کاربرد انجام دهید؛ در غیر این صورت میانگین کل ممکن است یک اختلال محلی را پنهان کند. اگر زمان ماندن پیام در صف بالا رفته، راهنمای Queue پیامک را کنار گزارش تحویل بخوانید. اگر شکست‌ها تنها در یک مسیر متمرکزند، وضعیت Failover در SMS Gateway و سلامت مسیر را بررسی کنید. برای سازمانی که چند سامانه پیام می‌فرستند، داشبورد باید امکان دنبال کردن یک شناسهٔ مشخص از API تا وضعیت نهایی را بدهد.
چک‌لیست عیب‌یابی وقتی کاربر پیام را نگرفته است
- شناسهٔ درخواست و زمان ایجاد آن را پیدا کنید؛ از ارسال دوبارهٔ فوری همان رویداد خودداری کنید.
- ببینید درخواست در API پذیرفته شد یا همان‌جا رد شد.
- زمان ورود و خروج از صف و مسیر انتخاب‌شده را بررسی کنید.
- شناسهٔ بالادستی و وضعیت Sent را با گزارش نهایی تطبیق دهید.
- اگر DLR ناموفق است، مرحله و کد خطا را طبق مستندات همان مسیر بخوانید.
- اگر DLR موجود نیست، مهلت انتظار، callback، استعلام و رویدادهای دیررس را بررسی کنید.
- تنها پس از روشن شدن وضعیت و اعتبار پیام، دربارهٔ Retry یا مسیر جایگزین تصمیم بگیرید.
پرسش‌های رایج دربارهٔ DLR پیامک
DLR مخفف چیست؟
DLR مخفف Delivery Receipt است؛ گزارشی که وضعیت تحویل یا نتیجهٔ نهایی پیام را پس از مراحل ارسال نشان میدهد. شکل دقیق آن به پروتکل و ارائه‌دهنده بستگی دارد.
فرق Sent و Delivered چیست؟
Sent معمولاً به واگذاری یا پذیرش پیام در مسیر بالادستی اشاره دارد؛ Delivered نشان میدهد گزارش تحویل موفق برگشته است. Sent بهتنهایی تحویل به گوشی را ثابت نمیکند.
اگر DLR نرسد، پیام ناموفق بوده است؟
خیر. نبود گزارش میتواند از تأخیر، محدودیت مسیر گزارش یا مشکل دریافت callback باشد. وضعیت را «نامعلوم» نگه دارید و با شناسه و زمان‌بندی مناسب بررسی کنید.
آیا DLR زمان خواندهشدن SMS را نشان میدهد؟
خیر. رسید تحویل SMS، خواندهشدن توسط مخاطب را اثبات نمیکند. رسید خواندن ویژگی جداگانهٔ برخی کانال‌های دیگر است.
آیا برای هر وضعیت ناموفق باید پیام را دوباره فرستاد؟
خیر. ابتدا مشخص کنید شکست در کدام مرحله و به چه علت رخ داده است. پیام منقضی یا دادهٔ نامعتبر با ارسال دوبارهٔ همان درخواست اصلاح نمی‌شود.
وضعیت پیام را در تمام مسیر ببینید
برای بررسی تحویل، باید رویدادهای API، صف، مسیر اپراتوری و DLR به یک شناسهٔ قابل ردیابی وصل باشند. اگر تیم شما در تشخیص تأخیر گزارش یا علت پیام‌های ناموفق مشکل دارد، راهکار SMS Gateway تلیرکو را ببینید و معماری فعلی خود را برای بررسی فنی مطرح کنید.
منابع فنی: مشخصات SMPP v3.4، راهنمای Delivery Receipt در SMPP، تعریف وضعیت پیام در مستندات Twilio، راهنمای Status Callback. این منابع برای توضیح مفاهیم عمومی‌اند و به معنی استفادهٔ تلیرکو از ارائه‌دهندهٔ مشخص نیستند.