چک لیست برای کاهش ریسک OTP برای شرکت هایی که از ایمیل موقت در QA/UAT استفاده می کنند
یک چک لیست در سطح سازمانی برای کاهش خطر OTP زمانی که تیم ها از ایمیل موقت در طول QA و UAT استفاده می کنند - که تعاریف، حالت های شکست، خط مشی چرخش، ارسال مجدد پنجره ها، معیارها، کنترل های حریم خصوصی و حاکمیت را پوشش می دهد تا محصول، QA و امنیت هماهنگ بمانند.
دسترسی سریع
Tl; دكتر
1) تعریف ریسک OTP در QA/UAT
2) حالت های خرابی رایج را مدل کنید
3) محیط های جداگانه، سیگنال های جداگانه
4) استراتژی صندوق ورودی مناسب را انتخاب کنید
5) پنجره هایی را که کار می کنند دوباره ارسال کنید
6) سیاست چرخش دامنه را بهینه کنید
7) معیارهای مناسب را ابزار کنید
8) یک کتاب بازی QA برای قله ها بسازید
9) مدیریت ایمن و کنترل حریم خصوصی
10) حکومت: چه کسی مالک چک لیست است
جدول مقایسه - چرخش در مقابل بدون چرخش (QA/UAT)
چگونه
سوالات متداول
Tl; دكتر
- قابلیت اطمینان OTP را به عنوان یک SLO قابل اندازه گیری، از جمله میزان موفقیت و TTFOM در نظر بگیرید (p50/p90، p95).
- ترافیک QA/UAT و دامنه ها را از تولید جدا کنید تا از مسموم شدن شهرت و تجزیه و تحلیل جلوگیری کنید.
- پنجره های ارسال مجدد و چرخش کلاهک را استاندارد کنید. فقط پس از تکرار منظم بچرخید.
- استراتژی های صندوق ورودی را بر اساس نوع آزمون انتخاب کنید: قابل استفاده مجدد برای رگرسیون. عمر کوتاه برای انفجار.
- معیارهای فرستنده ×دامنه ابزار با کدهای خرابی و اجرای بررسی های کنترل سه ماهه.
چک لیست برای کاهش ریسک OTP برای شرکت هایی که از ایمیل موقت در QA/UAT استفاده می کنند
پیچ و تاب اینجاست: قابلیت اطمینان OTP در محیط های آزمایشی فقط یک "چیز ایمیل" نیست. این یک تعامل بین عادات زمان بندی، شهرت فرستنده، لیست خاکستری، انتخاب دامنه و نحوه رفتار تیم های شما تحت استرس است. این چک لیست این درهم تنیدگی را به تعاریف، نرده های محافظ و شواهد مشترک تبدیل می کند. برای خوانندگانی که تازه با مفهوم صندوق های ورودی موقت آشنا شده اند، می توانید ابتدا ملزومات Temp Mail را مرور کنید تا با اصطلاحات و رفتارهای اساسی آشنا شوید.
1) تعریف ریسک OTP در QA/UAT
اصطلاحات مشترک را طوری تنظیم کنید که QA، امنیت و محصول در مورد قابلیت اطمینان OTP به یک زبان صحبت کنند.
"نرخ موفقیت OTP" به چه معناست
نرخ موفقیت OTP درصدی از درخواست های OTP است که منجر به دریافت و استفاده از یک کد معتبر در پنجره خط مشی شما می شود (به عنوان مثال، ده دقیقه برای جریان های آزمایشی). آن را توسط فرستنده (برنامه/سایتی که کد را صادر می کند) و توسط استخر دامنه دریافت کننده ردیابی کنید. موارد رها کردن کاربر را به طور جداگانه حذف کنید تا از رقیق شدن تجزیه و تحلیل حادثه جلوگیری شود.
TTFOM p50/p90 برای تیم ها
از زمان ارسال اولین پیام OTP (TTFOM) استفاده کنید - ثانیه هایی از «ارسال کد» تا اولین ورود صندوق ورودی. نمودار p50 و p90 (و p95 برای تست های استرس). این توزیع ها بدون تکیه بر حکایات صف بندی، دریچه گاز و لیست خاکستری را نشان می دهند.
منفی های کاذب در مقابل شکست های واقعی
"منفی کاذب" زمانی اتفاق می افتد که کدی دریافت می شود اما جریان آزمایش کننده آن را رد می کند - اغلب به دلیل موارد زیر وضعیت برنامه , سوئیچینگ برگه یا تایمرهای منقضی شده . یک "شکست واقعی" عدم ورود به پنجره است. آنها را در طبقه بندی خود جدا کنید. فقط خرابی های واقعی چرخش را توجیه می کند.
هنگام مرحله بندی، قابلیت تحویل را کج می کند
مرحله بندی نقاط پایانی و الگوهای ترافیک مصنوعی اغلب باعث لیست خاکستری یا اولویت زدایی می شود. اگر خط پایه شما بدتر از تولید است، انتظار می رود: ترافیک غیر انسانی به طور متفاوتی توزیع می شود. یک جهت گیری مختصر در مورد رفتارهای مدرن مفید خواهد بود. لطفا نگاهی به مرور مختصر Temp Mail در سال 2025 بیندازید تا توضیحی در مورد چگونگی تأثیر الگوهای صندوق ورودی یکبار مصرف بر قابلیت تحویل در طول آزمایشات داشته باشید.
2) حالت های خرابی رایج را مدل کنید
مشکلات تحویل با بیشترین تأثیر را ترسیم کنید تا بتوانید با خط مشی و ابزار از آنها جلوگیری کنید.
فهرست خاکستری و شهرت فرستنده
لیست خاکستری از فرستندگان می خواهد که بعدا دوباره امتحان کنند. اولین تلاش ها ممکن است به تأخیر بیفتد. استخرهای فرستنده جدید یا "سرد" نیز تا زمانی که شهرت آنها گرم شود آسیب می بینند. انتظار جهش p90 را در اولین ساعات سرویس اعلان ساخت جدید داشته باشید.
فیلترهای اسپم ISP و استخرهای سرد
برخی از ارائه دهندگان بررسی های شدیدتری را برای IP ها یا دامنه های سرد اعمال می کنند. اجرای QA که OTP ها را از یک استخر تازه منفجر می کند، شبیه کمپین ها است و می تواند پیام های غیر حیاتی را کند کند. توالی های گرم کردن (کم و حجم منظم) این را کاهش می دهد.
محدودیت نرخ و اوج ازدحام
درخواست های ارسال مجدد پشت سر هم می تواند محدودیت های نرخ را کاهش دهد. تحت بار (به عنوان مثال، رویدادهای فروش، راه اندازی بازی)، صف های فرستنده کشیده می شوند و TTFOM p90 را گسترش می دهند. چک لیست شما باید پنجره های ارسال مجدد و کلاه های دوباره را تعریف کند تا از کاهش سرعت خود جلوگیری شود.
رفتارهای کاربر که جریان ها را می شکند
تغییر برگه، پس زمینه کردن یک برنامه تلفن همراه و کپی کردن نام مستعار اشتباه همگی می توانند باعث رد یا انقضا شوند، حتی زمانی که پیام ها تحویل داده می شوند. کپی "در صفحه بمانید، صبر کنید، یک بار ارسال مجدد" را در میکرومتن رابط کاربری برای آزمایش ها بپزید.
3) محیط های جداگانه، سیگنال های جداگانه
QA/UAT را از تولید جدا کنید تا از مسمومیت شهرت و تجزیه و تحلیل فرستنده جلوگیری کنید.
مرحله بندی در مقابل حوزه های تولید
دامنه های فرستنده متمایز و هویت های پاسخ به آنها را برای اهداف مرحله بندی حفظ کنید. اگر OTP های آزمایشی به استخرهای تولید نشت کنند، درس های اشتباهی یاد خواهید گرفت و ممکن است دقیقا در لحظه ای که فشار تولید به آن نیاز دارد، شهرت را کاهش دهید.
حساب ها و سهمیه های تست
حساب های آزمایشی نامگذاری شده را تهیه کنید و به آنها سهمیه اختصاص دهید. تعداد انگشت شماری از هویت های آزمون منظم صدها هویت موقت را که اکتشافات فرکانس را طی می کنند، شکست می دهند.
پنجره های ترافیک مصنوعی
ترافیک OTP مصنوعی را در پنجره های خارج از پیک هدایت کنید. از انفجارهای کوتاه برای تأخیر پروفایل استفاده کنید، نه سیل های بی پایان که شبیه سوء استفاده هستند.
حسابرسی ردپای ایمیل
موجودی دامنه ها، IP ها و ارائه دهندگانی که تست های شما لمس می کنند. تأیید کنید که SPF/DKIM/DMARC برای مرحله بندی هویت ها سازگار است تا از اشتباه گرفتن شکست های احراز هویت با مشکلات قابلیت تحویل جلوگیری شود.
4) استراتژی صندوق ورودی مناسب را انتخاب کنید
آیا می توانید تصمیم بگیرید که چه زمانی از آدرس ها در مقابل صندوق های ورودی با عمر کوتاه برای تثبیت سیگنال های آزمایشی استفاده مجدد کنید؟
آدرس های قابل استفاده مجدد برای رگرسیون
برای تست های طولی (مجموعه های رگرسیون، حلقه های بازنشانی رمز عبور)، یک آدرس قابل استفاده مجدد تداوم و ثبات را حفظ می کند. بازگشایی مبتنی بر توکن نویز را در روزها و دستگاه ها کاهش می دهد و آن را برای مقایسه نتایج مشابه در چندین ساخت ایده آل می کند. لطفا به جزئیات عملیاتی در «استفاده مجدد از آدرس ایمیل موقت» نگاهی بیندازید تا دستورالعمل هایی در مورد نحوه بازگشایی ایمن صندوق ورودی دقیق داشته باشید.
عمر کوتاه برای تست پشت سر هم
برای سنبله های یکبار مصرف و QA اکتشافی، صندوق های ورودی با عمر کوتاه باقی مانده را به حداقل می رسانند و آلودگی لیست را کاهش می دهند. آنها همچنین بازنشانی تمیز بین سناریوها را تشویق می کنند. اگر یک تست فقط به یک OTP نیاز داشته باشد، یک مدل کوتاه مدت مانند 10 Minute Mail به خوبی مناسب است.
نظم و انضباط بازیابی مبتنی بر توکن
اگر صندوق ورودی آزمایشی قابل استفاده مجدد مهم است، با توکن مانند یک اعتبار رفتار کنید. می توانید آن را در یک مدیر رمز عبور در زیر برچسب مجموعه آزمایشی با دسترسی مبتنی بر نقش ذخیره کنید.
جلوگیری از برخورد آدرس
تصادفی سازی نام مستعار، ASCII پایه و بررسی منحصر به فرد بودن سریع از برخورد با آدرس های تست قدیمی جلوگیری می کند. نحوه نامگذاری یا ذخیره نام مستعار در هر مجموعه را استاندارد کنید.
5) پنجره هایی را که کار می کنند دوباره ارسال کنید
کاهش "خشم مجدد" و دریچه گاز کاذب با استاندارد کردن رفتارهای زمان بندی.
حداقل انتظار قبل از ارسال مجدد
پس از اولین درخواست، 60 تا 90 ثانیه صبر کنید تا یک تلاش مجدد ساختاریافته انجام شود. این کار از شکست دادن اولین پاس لیست خاکستری جلوگیری می کند و صف های فرستنده را تمیز نگه می دارد.
تلاش مجدد تک ساختاریافته
اجازه یک تلاش مجدد رسمی در اسکریپت آزمایشی را بدهید، سپس مکث کنید. اگر p90 در یک روز معین کشیده به نظر می رسد، به جای ارسال هرزنامه که نتایج همه را کاهش می دهد، انتظارات را تنظیم کنید.
مدیریت سوئیچینگ تب اپلیکیشن
کدها اغلب زمانی که کاربران برنامه را پس زمینه می کنند یا دور می شوند، باطل می شوند. در اسکریپت های QA، "روی صفحه بمانید" را به عنوان یک مرحله صریح اضافه کنید. رفتارهای سیستم عامل/پس زمینه را در گزارش ها ضبط کنید.
ضبط تله متری تایمر
مهرهای زمانی دقیق را ثبت کنید: درخواست، ارسال مجدد، ورود صندوق ورودی، ورود کد، وضعیت پذیرش/رد. رویدادها را بر اساس فرستنده برچسب گذاری کنید و Domainorensics بعدا امکان پذیر است.
6) سیاست چرخش دامنه را بهینه کنید
هوشمندانه بچرخانید تا لیست خاکستری را دور بزنید بدون اینکه قابلیت مشاهده تست را تکه تکه کنید.
کلاه های چرخش به ازای هر فرستنده
چرخش خودکار نباید در اولین اشتباه شلیک کند. آستانه ها را بر اساس فرستنده تعریف کنید: به عنوان مثال، فقط پس از شکست دو پنجره برای یک جفت فرستنده×دامنه بچرخانید - برای محافظت از شهرت، جلسات را در ≤2 چرخش محدود کنید.
بهداشت استخر و TTL ها
استخرهای دامنه را با ترکیبی از دامنه های قدیمی و تازه مدیریت کنید. وقتی p90 رانش می شود یا موفقیت کاهش می یابد، دامنه های "خسته" را استراحت دهید. پس از بهبودی دوباره بستری شوید. TTL ها را با آهنگ تست تراز کنید تا قابلیت مشاهده صندوق ورودی با پنجره بررسی شما هماهنگ شود.
مسیریابی چسبنده برای A/B
هنگام مقایسه ساخت ها، مسیریابی چسبنده را حفظ کنید: همان فرستنده به یک خانواده دامنه در همه انواع مسیرها می رود. این از آلودگی متقابل معیارها جلوگیری می کند.
اندازه گیری کارایی چرخش
چرخش یک قوز نیست. انواع را با و بدون چرخش در پنجره های ارسال مجدد یکسان مقایسه کنید. برای منطق عمیق تر و گاردریل ها، چرخش دامنه برای OTP را در این توضیح ببینید: چرخش دامنه برای OTP.
7) معیارهای مناسب را ابزار کنید
موفقیت OTP را با تجزیه و تحلیل توزیع های تأخیر و اختصاص برچسب های علت ریشه ای قابل اندازه گیری کنید.
موفقیت OTP توسط دامنه فرستنده × SLO خط بالا باید توسط ماتریس فرستنده × دامنه تجزیه شود، که نشان می دهد آیا مشکل در یک سایت/برنامه است یا در دامنه مورد استفاده.
TTFOM p50 / p90 ، p95
تأخیر متوسط و دم داستان های متفاوتی را روایت می کند. p50 نشان دهنده سلامت روزمره است. P90/P95 استرس، دریچه گاز و صف را نشان می دهد.
ارسال مجدد نظم و انضباط ٪
سهم جلساتی را که به طرح رسمی ارسال مجدد پایبند بودند پیگیری کنید. اگر خیلی زود ناراحت شوید، آن کارآزمایی ها را از نتیجه گیری های قابلیت تحویل حذف کنید.
کدهای طبقه بندی شکست
کدهایی مانند GL (لیست خاکستری)، RT (محدودیت سرعت)، BL (دامنه مسدود شده (تعامل کاربر/سوئیچ برگه) و OT (سایر) را بپذیرید. نیاز به کدهایی در یادداشت های حادثه
8) یک کتاب بازی QA برای قله ها بسازید
انفجارهای ترافیک را در راه اندازی های بازی یا برش های فین تک بدون از دست دادن کد مدیریت کنید.
گرم کردن قبل از رویدادها اجرا می شود
OTP با نرخ پایین و منظم از فرستنده های شناخته شده 24 تا 72 ساعت قبل از اوج به شهرت گرم ارسال می شود. خطوط روند p90 را در سراسر گرم کردن اندازه گیری کنید.
پروفایل های عقب نشینی بر اساس ریسک
منحنی های عقب نشینی را به دسته های ریسک متصل کنید. برای سایت های معمولی، دو بار در عرض چند دقیقه تلاش مجدد انجام دهید. برای فین تک پرخطر، پنجره های طولانی تر و تلاش های مجدد کمتر منجر به برافراشته شدن پرچم های کمتر می شود.
چرخش قناری و هشدارها
در طول یک رویداد، اجازه دهید 5 تا 10 درصد از OTP ها از طریق یک زیر مجموعه دامنه قناری مسیر پیدا کنند. اگر قناری ها افزایش p90 یا موفقیت در حال سقوط را نشان دادند، استخر اولیه را زودتر بچرخانید.
تریگرهای پیجر و Rollback
محرک های عددی را تعریف کنید - به عنوان مثال، OTP Success به مدت 10 دقیقه به زیر 92٪ کاهش می یابد، یا TTFOM p90 بیش از 180 ثانیه است - برای صفحه پرسنل در حال کشش، گشاد کردن پنجره ها یا بریدن به یک استخر استراحت.
9) مدیریت ایمن و کنترل حریم خصوصی
حفظ حریم خصوصی کاربر و در عین حال اطمینان از قابلیت اطمینان تست در صنایع تنظیم شده.
صندوق های پستی آزمایشی فقط دریافت
از یک آدرس ایمیل موقت فقط دریافتی برای حاوی بردارهای سوءاستفاده و محدود کردن خطر خروجی استفاده کنید. پیوست ها را خارج از محدوده صندوق ورودی QA/UAT در نظر بگیرید.
پنجره های دید 24 ساعته
پیام های آزمایشی باید ~ 24 ساعت پس از ورود قابل مشاهده باشند، سپس به طور خودکار پاک شوند. این پنجره برای بررسی به اندازه کافی طولانی و برای حفظ حریم خصوصی به اندازه کافی کوتاه است. برای بررسی اجمالی خط مشی و نکات استفاده، راهنمای ایمیل موقت اصول اولیه همیشه سبز را برای تیم ها جمع آوری می کند.
ملاحظات GDPR / CCPA
می توانید از داده های شخصی در ایمیل های آزمایشی استفاده کنید. از جاسازی PII در بدنه های پیام خودداری کنید. نگهداری کوتاه، HTML ضدعفونی شده و پراکسی تصویر نوردهی را کاهش می دهد.
ویرایش و دسترسی به لاگ
سیاهههای مربوط به توکن ها و کدها را اسکراب کنید. دسترسی مبتنی بر نقش به توکن های صندوق ورودی را ترجیح دهید. آیا می توانید مسیرهای حسابرسی را برای اینکه چه کسی و چه زمانی صندوق پستی آزمایشی را بازگشایی کرده است، نگه دارید؟
10) حکومت: چه کسی مالک چک لیست است
مالکیت، آهنگ و شواهد را برای هر کنترل در این سند اختصاص دهید.
RACI برای قابلیت اطمینان OTP
مالک مسئول (اغلب QA)، حامی پاسخگو (امنیت یا محصول)، مشاوره (زیر/ایمیل) و آگاه (پشتیبانی) را نام ببرید. این RACI را در مخزن منتشر کنید.
بررسی های سه ماهه کنترل
هر سه ماهه، اجرای نمونه در برابر چک لیست انجام می شود تا تأیید شود که پنجره های ارسال مجدد، آستانه های چرخش و برچسب های متریک همچنان اجرا می شوند.
شواهد و مصنوعات آزمایشی
اسکرین شات ها، توزیع های TTFOM و جداول فرستنده×دامنه را به هر کنترل پیوست کنید - توکن ها را به طور ایمن با ارجاعات به مجموعه آزمایشی که ارائه می دهند ذخیره کنید.
حلقه های بهبود مستمر
هنگامی که حوادثی رخ می دهد، یک بازی/ضد الگو به دفترچه اجرا اضافه کنید. آستانه ها را تنظیم کنید، استخرهای دامنه را بازخوانی کنید و کپی را که آزمایش کنندگان می بینند به روز کنید.
جدول مقایسه - چرخش در مقابل بدون چرخش (QA/UAT)
| خط مشی کنترل | با چرخش | بدون چرخش | TTFOM p50 / p90 | درصد موفقیت OTP | یادداشت های ریسک |
|---|---|---|---|---|---|
| مظنون به لیست خاکستری | بعد از دو بار انتظار بچرخانید | domaiDomain را نگه دارید | / دهه 95 | 92% | چرخش زودهنگام 4xx عقب نشینی را پاک می کند |
| صف های فرستنده اوج | بچرخانید اگر p90 | انتظار را تمدید کنید | دهه 40 / 120 ثانیه | 94% | Backoff + تغییر دامنه کار می کند |
| استخر فرستنده سرد | قناری گرم + چرخش | فقط گرم | دهه 45 / 160 ثانیه | 90% | چرخش در هنگام گرم کردن کمک می کند |
| فرستنده پایدار | چرخش های کلاهک در 0-1 | بدون چرخش | 25 ثانیه / 60 ثانیه | 96% | از ریزش بی مورد خودداری کنید |
| دامنه پرچم گذاری شده است | تغییر خانواده | همان را دوباره امتحان کنید | دهه 50 / دهه 170 | 88% | سوئیچینگ از بلوک های تکراری جلوگیری می کند |
چگونه
یک فرآیند ساختاریافته برای تست OTP، نظم فرستنده و جداسازی محیط - مفید برای QA، UAT و جداسازی تولید.
مرحله 1: محیط ها را جدا کنید
هویت فرستنده QA/UAT و استخرهای دامنه جداگانه ایجاد کنید. هرگز با تولید به اشتراک نگذارید.
مرحله 2: زمان بندی ارسال مجدد را استاندارد کنید
قبل از یک بار تلاش مجدد، 60 تا 90 ثانیه صبر کنید. تعداد کل ارسال مجدد در هر جلسه را محدود کنید.
مرحله 3: درپوش های چرخشی را پیکربندی کنید
فقط پس از نقض آستانه برای همان فرستنده×دامنه بچرخانید. ≤2 چرخش/جلسه.
مرحله 4: استفاده مجدد مبتنی بر توکن را بپذیرید
از توکن ها برای باز کردن مجدد همان آدرس برای رگرسیون و بازنشانی استفاده کنید. توکن ها را در یک مدیر رمز عبور ذخیره کنید.
مرحله 5: معیارهای ابزار
Log OTP Success، TTFOM p50/p90 (و p95)، ارسال مجدد انضباط، و کدهای شکست.
مرحله 6: تمرینات اوج را اجرا کنید
فرستنده ها را گرم کنید؛ از چرخش قناری با هشدار برای گرفتن زودهنگام رانش استفاده کنید.
مرحله 7: بررسی و تأیید
من می خواهم شما هر کنترل را با شواهد پیوست شده بررسی کنید و امضا کنید.
سوالات متداول
چرا کدهای OTP در طول QA دیر می رسند اما در تولید نیستند؟
صحنه سازی ترافیک برای گیرنده ها پر سر و صداتر و سردتر به نظر می رسد. لیست خاکستری و دریچه گاز P90 را تا زمانی که استخرها گرم شوند، گسترش می دهد.
قبل از ضربه زدن روی «ارسال مجدد کد» چقدر باید صبر کنم؟
حدود 60-90 ثانیه. سپس یک تلاش مجدد ساختاریافته. ارسال مجدد بیشتر اغلب صف ها را بدتر می کند.
آیا چرخش دامنه همیشه بهتر از یک دامنه واحد است؟
نه. فقط پس از قطع آستانه ها بچرخید. چرخش بیش از حد به شهرت آسیب می رساند و معیارها را گل آلود می کند.
تفاوت بین TTFOM و زمان تحویل چیست؟
TTFOM تا زمانی که اولین پیام در نمای صندوق ورودی ظاهر شود، اندازه گیری می کند. زمان تحویل می تواند شامل تلاش های مجدد فراتر از پنجره آزمایشی شما باشد.
آیا آدرس های قابل استفاده مجدد به قابلیت تحویل در آزمایش آسیب می رسانند؟
نه ذاتا. آنها مقایسه ها را تثبیت می کنند، توکن ها را با خیال راحت ذخیره می کنند و از تکرار دیوانه وار جلوگیری می کنند.
چگونه موفقیت OTP را در فرستنده های مختلف ردیابی کنم؟
معیارهای خود را بر اساس فرستنده × دامنه ماتریس کنید تا مشخص شود که آیا مشکلات مربوط به یک سایت/برنامه یا یک خانواده دامنه است یا خیر.
آیا آدرس های ایمیل موقت می توانند در طول QA با GDPR/CCPA مطابقت داشته باشند؟
بله - فقط دریافت، پنجره های دید کوتاه، HTML پاک شده و پراکسی تصویر از تست حریم خصوصی اول پشتیبانی می کنند.
لیست خاکستری و گرم کردن چگونه بر قابلیت اطمینان OTP تأثیر می گذارد؟
فهرست خاکستری تلاش های اولیه را به تأخیر می اندازد. استخرهای سرد نیاز به گرم کردن مداوم دارند. هر دو بیشتر به p90 رسیدند، نه p50.
آیا باید صندوق های پستی QA و UAT را جدا از تولید نگه دارم؟
بله. جداسازی استخر از کاهش شهرت تولید و تجزیه و تحلیل جلوگیری می کند.
چه تله متری برای ممیزی های موفقیت OTP بیشترین اهمیت را دارد؟
موفقیت OTP، TTFOM p50/p90 (p95 برای استرس)، Resend Discipline ٪ و کدهای شکست با شواهد مهر زمانی. برای مرجع سریع، لطفا به سوالات متداول Temp Mail مراجعه کنید.
