ວິທີທີ່ການຫມູນວຽນ Domain ປັບປຸງຄວາມເຊື່ອຖື OTP ສໍາລັບ Temp Mail (ອີເມວຊົ່ວຄາວ)
ເມື່ອລະຫັດຜ່ານພຽງເທື່ອດຽວບໍ່ມາເຖິງ, ຜູ້ຄົນຈະທໍາລາຍປຸ່ມສົ່ງຄືນ, ປ່ຽນແປງແລະຕໍາຫນິການຮັບໃຊ້ຂອງເຈົ້າ. ໃນ ການ ປະຕິບັດ, ຄວາມ ລົ້ມ ເຫ ລວ ສ່ວນ ຫລາຍ ບໍ່ ໄດ້ ເປັນ ເລື່ອງ ບັງເອີນ; ເຂົາ ເຈົ້າ ເຕົ້າ ໂຮມ ກັນ ຢູ່ ອ້ອມ ຮອບ ອັດຕາ ຈໍາກັດ, ລາຍ ຊື່ ສີ ຂີ້ ເທົ່າ ແລະ ເວລາ ທີ່ ບໍ່ ດີ. ບົດ ຄວາມ ນີ້ ສະ ແດງ ໃຫ້ ເຫັນ ວິ ທີ ທີ່ ຈະ ວິ ໄຈ, ລໍ ຖ້າ ຢ່າງ ສະ ຫລາດ, ແລະ ຫມູນ ວຽນ ຈົດ ຫມາຍ ຊົ່ວ ຄາວ ຂອງ ທ່ານ (domain switch) ໂດຍ ເຈດ ຕະ ນາ - ບໍ່ ແມ່ນ ເພາະ ຄວາມ ຢ້ານ ກົວ. ສໍາລັບທັດສະນະຂອງລະບົບທີ່ເລິກເຊິ່ງຂອງລະບົບ, ໃຫ້ເບິ່ງຄໍາອະທິບາຍທໍາອິດຂອງອີເມວຊົ່ວຄາວ (A-Z).
ເຂົ້າ ເຖິງ ໄວ
TL; DR / ຈຸດ ສໍາຄັນ
Spot Delivery Bottle Neck
ນັບຖື Resend Windows
ຫມູນວຽນທີ່ຢູ່ຈົດຫມາຍຊົ່ວຄາວຂອງເຈົ້າ
ອອກແບບສະນ້ໍາຫມູນວຽນຂອງເຈົ້າ
ວັດ ແທກ ທີ່ ພິສູດ ວ່າ ການ ຫມູນ ວຽນ ໄດ້ ທໍາ ງານ
ກໍລະນີສຶກສາ (Mini)
ຫຼີກລ່ຽງຄວາມເສຍຫາຍທາງດ້ານຄໍ້າປະກັນ
ອະນາຄົດ: ນະໂຍບາຍທີ່ສະຫຼາດກວ່າ, ຕໍ່ຜູ້ສົ່ງ
ເທື່ອ ລະ ຂັ້ນ ຕອນ - ຂັ້ນ ໄດ ຫມູນວຽນ (HowTo)
ຕາຕະລາງປຽບທຽບ - ການຫມູນວຽນ vs. ບໍ່ມີການຫມູນວຽນ
ຄຳຖາມທີ່ຖືກຖາມເລື້ອຍໆ
ສະຫລຸບ
TL; DR / ຈຸດ ສໍາຄັນ
- OTP misses ມັກເກີດຈາກການສົ່ງຄືນກ່ອນໄວ, greylist ແລະ sender throttles.
- ທ່ານ ສາມາດ ໃຊ້ ຂັ້ນ ໄດ ຫມູນ ວຽນ ສັ້ນໆ; ຫມູນ ຫລັງ ຈາກ ໄດ້ ສົ່ງ ປ່ອງຢ້ຽມ ຄືນ ໃຫມ່ ເທົ່າ ນັ້ນ.
- ກໍານົດຂອບເຂດທີ່ຊັດເຈນ (ຄວາມລົ້ມເຫລວຕໍ່ຜູ້ສົ່ງ, TTFOM) ແລະບັນທຶກມັນຢ່າງເຄັ່ງຄັດ.
- ຕິດຕາມອັດຕາຄວາມສໍາເລັດ OTP, TTFOM p50/p90, ຈໍານວນການລອງຄືນໃຫມ່ ແລະ ອັດຕາການຫມູນວຽນ.
- ຫຼີກລ່ຽງການຫມູນວຽນຫຼາຍເກີນໄປ; ມັນກໍ່ຄວາມເສຍຫາຍຕໍ່ຊື່ສຽງແລະເຮັດໃຫ້ຜູ້ໃຊ້ສັບສົນ.
Spot Delivery Bottle Neck
ໃຫ້ລະບຸບ່ອນທີ່ OTP ຕິດຢູ່—ຄວາມຜິດພາດທາງດ້ານລູກຄ້າ, ຂໍ້ຈໍາກັດຂອງອັດຕາ ຫຼື greylisting—ກ່ອນທີ່ທ່ານຈະແຕະຕ້ອງ domains.
ເບິ່ງ ຂ້າງ ນອກ, ເບິ່ງ ຄື ວ່າ ບໍ່ ສໍາຄັນ. ຕາມ ຈິງ ແລ້ວ, ການ ສູນ ເສຍ OTP ມີ ເຄື່ອງຫມາຍ ທີ່ ແຕກ ຕ່າງ ກັນ. ເລີ່ມຕົ້ນດ້ວຍແຜນທີ່ຜິດພາດໄວໆ:
- Client/UI: ຕິດທີ່ຢູ່ຜິດ, inbox ບໍ່ຟື້ນຟູ ຫຼື view ຖືກຕອງເປັນຂໍ້ຄວາມເທົ່ານັ້ນ ໂດຍມີຮູບພາບຖືກປິດກັ້ນ.
- SMTP / ຜູ້ໃຫ້ບໍລິການ: greylisting ຢູ່ຝ່າຍຜູ້ສົ່ງ, IP ຫຼື sender throttling, ຫຼື ຄວາມກົດດັນຄືນຂອງແຖວຊົ່ວຄາວ.
- ເວລາເຄືອຂ່າຍ *: ປ່ອງຢ້ຽມ ສູງ ສຸດ ສໍາລັບ ຜູ້ ສົ່ງ ໃຫຍ່, ເສັ້ນທາງ ທີ່ ບໍ່ ສະ ເຫມີ ພາບ ແລະ ການ ໂຄສະນາ ທີ່ ຊັກ ຊ້າ ໃນ ຈົດຫມາຍ ທີ່ ບໍ່ ສໍາຄັນ.
ໃຊ້ການວິນິໄສໄວ:
- TTFOM (ຂ່າວສານ OTP ເວລາທໍາອິດ). track p50 ແລະ p90.
- ອັດຕາຄວາມສໍາເລັດ OTP ຕໍ່ຜູ້ສົ່ງ (ເວັບໄຊ/ແອັບທີ່ອອກລະຫັດ).
- Resend Window Adherence: ເລື້ອຍປານໃດທີ່ຜູ້ໃຊ້ຕີ resend ໄວເກີນໄປ?
ຜົນ ທີ່ ຕາມ ມາ ກໍ ງ່າຍໆ: ຢ່າ ຫມູນ ວຽນ domain ຈົນ ກວ່າ ທ່ານ ຮູ້ ວ່າ ມີ ຫຍັງ ລົ້ມ ເຫລວ. ການກວດ ສອບ ຫນຶ່ງ ນາທີ ຢູ່ ທີ່ ນີ້ ຈະ ປ້ອງ ກັນ ບໍ່ ໃຫ້ ມີ ການ ຟ້າວ ຟັ່ງ ຫລາຍ ຊົ່ວ ໂມງ ຕໍ່ ມາ.
ນັບຖື Resend Windows
ການ ກະ ໂດດ ປືນ ມັກ ຈະ ເຮັດ ໃຫ້ ການ ຂົນ ສົ່ງ ລໍາ ລຽງ ບໍ່ ດີ ຂຶ້ນ - ໃຫ້ ເວ ລາ ພະ ຍາ ຍາມ ຕໍ່ ໄປ.
ຕາມ ຄວາມ ຈິງ ແລ້ວ, ລະບົບ OTP ຫລາຍ ຢ່າງ ໄດ້ ເຈດ ຕະນາ ຊັກ ຊ້າ ການ ສົ່ງ ຊ້ໍາ ອີກ. ຖ້າຜູ້ໃຊ້ພະຍາຍາມອີກໄວເກີນໄປ, ການປ້ອງກັນການຈໍາກັດອັດຕາຈະເລີ່ມຕົ້ນແລະຂ່າວສານຕໍ່ໄປນີ້ຈະບໍ່ຈັດລໍາດັບຄວາມສໍາຄັນຫຼືຖືກຍົກເລີກ. ໃຊ້ປ່ອງຢ້ຽມທີ່ໃຊ້ການໄດ້:
- ລອງ 2 ພຽງ ແຕ່ ຫລັງ ຈາກ 30-90 ວິນາທີ ຈາກ ການ ພະຍາຍາມ ເທື່ອ ທໍາ ອິດ.
- ລອງ 3 ຫລັງ ຈາກ 2-3 ນາທີ ຕື່ມ ອີກ.
- fintech ທີ່ ມີ ຄວາມ ສ່ຽງ ສູງ * ບາງ ເທື່ອ ການ ຫລັ່ງ ໄຫລ ຈະ ໄດ້ ຮັບ ຜົນ ປະ ໂຫຍດ ຈາກ ການ ລໍຖ້າ ຈົນ ເຖິງ ຫ້າ ນາທີ ກ່ອນ ຈະ ເພີ່ມ ທະວີ ຂຶ້ນ.
ແບບແຜນທີ່ເຮັດໃຫ້ສະຫງົບໃຈ, ບໍ່ເຮັດໃຫ້ຕື່ນເຕັ້ນ: "ພວກເຮົາບໍ່ພໍໃຈກັບລະຫັດ. ໃຫ້ ກວດ ເບິ່ງ ອີກ ປະມານ 60 ວິນາທີ." ບັນທຶກການສົ່ງຄືນທຸກຄັ້ງດ້ວຍເວລາ, ຜູ້ສົ່ງ, ເຂດທີ່ເຮັດວຽກ ແລະ ຜົນ. ພຽງ ແຕ່ ສິ່ງ ນີ້ ເທົ່າ ນັ້ນ ທີ່ ຈະ ແກ້ ໄຂ ບັນຫາ "ການ ຂົນ ສົ່ງ" ທີ່ ຫນ້າ ປະຫລາດ ໃຈ.
ຫມູນວຽນທີ່ຢູ່ຈົດຫມາຍຊົ່ວຄາວຂອງເຈົ້າ
ໃຊ້ ຂັ້ນ ໄດ ຕັດສິນ ໃຈ ເລັກ ນ້ອຍ; ຫມູນວຽນເມື່ອສັນຍານບອກເທົ່ານັ້ນ.
ການ ຫມູນ ວຽນ ຄວນ ຮູ້ສຶກ ເບື່ອ ຫນ່າຍ ແລະ ຄາດ ການ ໄດ້. ນີ້ ຄື ຂັ້ນ ໄດ ນ້ອຍໆ ທີ່ ທ່ານ ສາມາດ ສອນ ທີມ ຂອງ ທ່ານ:
- ໃຫ້ ກວດ ເບິ່ງ ວ່າ UI ຂອງ inbox ມີ ຢູ່ ແລະ address ຖືກຕ້ອງ.
- ລໍຖ້າ ປ່ອງຢ້ຽມ ເທື່ອ ທໍາ ອິດ; ແລ້ວ ສົ່ງ ຄືນ ອີກ ເທື່ອ ຫນຶ່ງ.
- ໃຫ້ກວດເບິ່ງທັດສະນະອື່ນ (spam / plain-text) ເພື່ອເບິ່ງວ່າ UI ຂອງເຈົ້າມີໃຫ້ຫຼືບໍ່.
- ສົ່ງຄືນອີກເປັນເທື່ອທີສອງຫຼັງຈາກປ່ອງຢ້ຽມທີ່ຍາວນານ.
- ຫມູນວຽນທີ່ຢູ່/ໂດເມນຊົ່ວຄາວເທົ່ານັ້ນເມື່ອກໍານົດວ່າຄວນ.
ຂອບເຂດທີ່ເຫມາະສົມສໍາລັບການຫມູນວຽນຂອງທີ່ຢູ່ໄປສະນີຊົ່ວຄາວ
- ຄວາມ ລົ້ມ ເຫ ລວ ຕໍ່ ຜູ້ ສົ່ງ ≥ N ພາຍ ໃນ M ນາທີ (ເລືອກ N / M ສໍາລັບ ຄວາມ ສ່ຽງ ຂອງ ທ່ານ).
- TTFOM ເກີນ ຂອບ ເຂດ ຂອງ ທ່ານ ຊ້ໍາ ແລ້ວ ຊ້ໍາ ອີກ (ຍົກ ຕົວຢ່າງ,
- ສັນຍານ ຈະ ຖືກ ຕິດຕາມ ຕໍ່ ຜູ້ ສົ່ງ × domain, ບໍ່ ເຄີຍ "rotate blind".
ຮາວ ເຫລັກ ສໍາຄັນ - ການ ຫມູນ ວຽນ ຂອງ cap ເປັນ ≤2 ຕໍ່ ພາກ. ຮັກສາສ່ວນທ້ອງຖິ່ນ (prefix) ເມື່ອເປັນໄປໄດ້ເພື່ອຜູ້ໃຊ້ຈະບໍ່ສູນເສຍເນື້ອໃນ.
ອອກແບບສະນ້ໍາຫມູນວຽນຂອງເຈົ້າ
ຄຸນ ນະ ພາບ ຂອງ ກຸ່ມ domain ຂອງ ທ່ານ ສໍາ ຄັນ ຫລາຍ ກວ່າ ຂະ ຫນາດ.
ຫນ້າ ປະຫລາດ ໃຈ ທີ່ domain ອີກ ສິບ ປາຍ ຈະ ບໍ່ ຊ່ວຍ ຖ້າ ຫາກ ມັນ "ມີ ສຽງ ດັງ." ສ້າງ ສະ ນ້ໍາ ທີ່ ຄວບ ຄຸມ:
- TLD ທີ່ຫຼາກຫຼາຍທີ່ມີປະຫວັດສາດທີ່ສະອາດ; ຫລີກ ເວັ້ນຈາກ ສິ່ງ ທີ່ ຖືກ ຂົ່ມ ເຫັງ ຢ່າງ ຫນັກ.
- ຄວາມ ສົມ ດຸນ ຂອງ ຄວາມ ສົດ ຊື່ນ ແລະ ຄວາມ ໄວ້ ວາງ ໃຈ: ໃຫມ່ ສາມາດ ຜ່ານ ພົ້ນ ໄປ, ແຕ່ ອາຍຸ ເປັນ ສັນຍານ ເຖິງ ຄວາມ ໄວ້ ວາງ ໃຈ ໄດ້; ທ່ານ ຕ້ອງ ການ ທັງ ສອງ.
- Bucket by use-case *: e-commerce, gaming, QA / staging—ແຕ່ລະຢ່າງສາມາດມີຜູ້ສົ່ງແລະແບບແຜນການโหลดທີ່ແຕກຕ່າງກັນ.
- ນະໂຍບາຍການພັກຜ່ອນ: ປ່ອຍໃຫ້ໂດເມນເຢັນລົງເມື່ອວັດແທກຂອງມັນຫລຸດລົງ; ໃຫ້ ເບິ່ງ ການ ພັກ ຟື້ນ ກ່ອນ ຈະ ຍອມຮັບ ມັນ ອີກ.
- Metadata ໃນ ແຕ່ ລະ domain: ອາຍຸ, ຄະແນນ ສຸຂະພາບ ພາຍ ໃນ ແລະ ຄວາມ ສໍາ ເລັດ ຜົນ ສຸດ ທ້າຍ ຂອງ ຜູ້ ສົ່ງ.
ວັດ ແທກ ທີ່ ພິສູດ ວ່າ ການ ຫມູນ ວຽນ ໄດ້ ທໍາ ງານ
ຖ້າ ຫາກ ທ່ານ ບໍ່ ວັດ ແທກ, ການ ຫມູນ ວຽນ ກໍ ເປັນ ພຽງ ສັນ ຍາ ລັກ ເທົ່າ ນັ້ນ.
ເລືອກ ຊຸດ ນ້ອຍໆ ທີ່ ສາມາດ ເຮັດ ຊ້ໍາ ໄດ້:
- ອັດຕາຄວາມສໍາເລັດ OTP ໂດຍຜູ້ສົ່ງ.
- TTFOM p50 / p90 ໃນ ວິນາທີ.
- Retry Count median ກ່ອນປະສົບຜົນສໍາເລັດ.
- ອັດຕາການຫມູນວຽນ: ສ່ວນປະກອບຂອງພາກທີ່ຕ້ອງມີການປ່ຽນໂດເມນ.
ວິເຄາະຕາມຜູ້ສົ່ງ, domain, ປະເທດ/ISP (ຖ້າມີ) ແລະ ເວລາຂອງມື້. ໃນ ການ ປະຕິບັດ, ໃຫ້ ປຽບທຽບ ກຸ່ມ ຄວບ ຄຸມ ທີ່ ລໍຖ້າ ຜ່ານ ປ່ອງຢ້ຽມ ສອງ ປ່ອງຢ້ຽມ ກ່ອນ ຈະ ຫມູນ ກັບ ກຸ່ມ ທີ່ ຫມູນ ວຽນ ຫລັງ ຈາກ ຄວາມ ລົ້ມ ເຫລວ ເທື່ອ ທໍາ ອິດ. ໃນ ຄວາມ ສົມ ດຸນ, ການ ຄວບ ຄຸມ ຈະ ປ້ອງ ກັນ ການ ປ່ຽນ ແປງ ທີ່ ບໍ່ ຈໍາ ເປັນ; variant ຊ່ວຍ ກູ້ ກໍລະນີ edge ໃນ ໄລຍະ ທີ່ ຜູ້ ສົ່ງ ຊ້າ ລົງ. ຈໍານວນ ຂອງ ທ່ານ ຈະ ຕັດສິນ ໃຈ.
ກໍລະນີສຶກສາ (Mini)
ເລື່ອງສັ້ນຊະນະທິດສະດີ—ສະແດງໃຫ້ເຫັນສິ່ງທີ່ປ່ຽນແປງຫຼັງຈາກຫມູນວຽນ.
- ລະບົບ ໃຫຍ່ A: TTFOM p90 ໄດ້ ຫລຸດ ລົງ ຈາກ 180 → 70 ຫລັງ ຈາກ ໄດ້ ບັງຄັບ ໃຫ້ ສົ່ງ ປ່ອງຢ້ຽມ ແລະ ຫມູນ ວຽນ ຕາມ ຂອບ ເຂດ, ບໍ່ ແມ່ນ ອາລົມ.
- E-commerce B: ຄວາມ ສໍາ ເລັດ ຜົນ ຂອງ OTP ໄດ້ ປີນ ຂຶ້ນ 86% → 96% ໂດຍ ການ ນໍາ ໃຊ້ ມາດຕະຖານ ຕໍ່ ຜູ້ ສົ່ງ ແລະ ເຮັດ ໃຫ້ domain ທີ່ ມີ ສຽງ ດັງ ເຢັນ ລົງ ເປັນ ເວລາ ຫນຶ່ງ ມື້.
- ຊຸດ QA: ການ ທົດ ສອບ ທີ່ ບໍ່ ແຈ່ມ ແຈ້ງ ໄດ້ ຫລຸດ ຈໍານວນ ລົງ ຫລັງ ຈາກ ການ ແບ່ງ ແຍກ ກຸ່ມ: ການ ຈັດ ລະບຽບ ບໍ່ ໄດ້ ເປັນ ພິດ ຕໍ່ ເຂດ ຜະລິດຕະພັນ ອີກ ຕໍ່ ໄປ.
ຫຼີກລ່ຽງຄວາມເສຍຫາຍທາງດ້ານຄໍ້າປະກັນ
ປົກປ້ອງຊື່ສຽງໃນຂະນະທີ່ແກ້ໄຂ OTP ແລະຢ່າເຮັດໃຫ້ຜູ້ໃຊ້ສັບສົນ.
ມີ ບັນຫາ. ການ ຫມູນ ວຽນ ຫລາຍ ເກີນ ໄປ ເບິ່ງ ຄື ວ່າ ເປັນ ການ ຂົ່ມ ເຫັງ ຈາກ ພາຍ ນອກ. ຫລຸດຜ່ອນດ້ວຍ:
- ສຸຂະອະນາໄມຊື່ສຽງ: ຈໍາກັດການຫມູນວຽນ, ໄລຍະພັກຜ່ອນ ແລະ ການເຕືອນກ່ຽວກັບການທໍາຮ້າຍທີ່ເພີ່ມຂຶ້ນ.
- ຄວາມຫມັ້ນຄົງຂອງ UX: ຮັກສາຄໍານໍາຫນ້າ/ຊື່ຫລິ້ນ; ຜູ້ໃຊ້ຂໍ້ຄວາມເບົາໆເມື່ອມີການປ່ຽນແປງ.
- ລະ ບຽບ ວິ ໄນ ເລື່ອງ ຄວາມ ປອດ ໄພ: ຢ່າ ເປີດ ເຜີຍ ກົດ ການ ຫມູນ ວຽນ ຢ່າງ ເປີດ ເຜີຍ; ໃຫ້ ມັນ ຢູ່ ທາງ server.
- ອັດຕາການຈໍາກັດໃນທ້ອງຖິ່ນ *: ຄວບ ຄຸມ ລູກ ຄ້າ ທີ່ ມີ ຄວາມ ສຸກ ເພື່ອ ຢຸດ ສົ່ງ ລົມ ພະຍຸ.
ອະນາຄົດ: ນະໂຍບາຍທີ່ສະຫຼາດກວ່າ, ຕໍ່ຜູ້ສົ່ງ
ການຫມູນວຽນຈະເປັນສ່ວນຕົວຕາມຜູ້ສົ່ງ, ພາກພື້ນ ແລະ ເວລາຂອງມື້.
Profiles per sender ຈະກາຍເປັນມາດຕະຖານ: ປ່ອງຢ້ຽມ, ຂອບເຂດທີ່ແຕກຕ່າງກັນ, ແລະແມ່ນແຕ່ຊຸດຍ່ອຍຂອງໂດເມນໂດຍອີງຕາມພຶດຕິກໍາທາງປະຫວັດສາດຂອງເຂົາເຈົ້າ. ໃຫ້ ຄາດ ຫວັງ ວ່າ ນະ ໂຍບາຍ ທີ່ ຮູ້ຈັກ ເວລາ ຈະ ພັກຜ່ອນ ໃນ ຕອນ ກາງຄືນ ແລະ ເຄັ່ງ ຄັດ ໃນ ຊົ່ວ ໂມງ ທີ່ ສູງ ສຸດ. ອັດຕະໂນມັດຂອງແສງສະຫວ່າງເຕືອນເມື່ອວັດແທກເຄື່ອນເຫນັງ, ແນະນໍາການຫມູນວຽນດ້ວຍເຫດຜົນ ແລະ ຮັກສາມະນຸດໃຫ້ຢູ່ໃນວົງຈອນໃນຂະນະທີ່ກໍາຈັດການຄາດຄະເນ.
ເທື່ອ ລະ ຂັ້ນ ຕອນ - ຂັ້ນ ໄດ ຫມູນວຽນ (HowTo)
ຂັ້ນ ໄດ ທີ່ ສາມາດ copy pasteable ສໍາລັບ ທີມ ຂອງ ທ່ານ.
ຂັ້ນຕອນທີ 1: ກວດສອບ UI ຂອງ Inbox - ຢືນຢັນທີ່ຢູ່, ແລະ ໃຫ້ແນ່ໃຈວ່າ inbox view update ໃນເວລາຈິງ.
ຂັ້ນຕອນທີ 2: ລອງສົ່ງຄືນເທື່ອດຽວ (ລໍຖ້າປ່ອງຢ້ຽມ) - ສົ່ງອີກເທື່ອຫນຶ່ງແລະລໍຖ້າ 60-90 ວິນາທີ; ຟື້ນຟູ inbox.
ຂັ້ນຕອນທີ 3: ລອງສົ່ງຄືນສອງເທື່ອ (ປ່ອງຢ້ຽມຂະຫຍາຍ) - ສົ່ງເທື່ອທີສອງ; ລໍຖ້າອີກ 2-3 ນາທີກ່ອນຈະກວດຄືນອີກ.
ຂັ້ນຕອນ 4: Rotate Temp Mail Address/Domain (Threshold Met) — Switch only after threshold fire; ຖ້າເປັນໄປໄດ້ໃຫ້ໃຊ້ຄໍານໍາຫນ້າແບບດຽວກັນ.
ຂັ້ນຕອນທີ 5: Escalate or Switch Inbox - ຖ້າຍັງມີຄວາມຮີບດ່ວນ, ໃຫ້ສໍາເລັດການສົ່ງຄືນດ້ວຍຫີບເຂົ້າທີ່ທົນທານ; ກັບຄືນໄປໃຊ້ຄືນໂດຍອາໄສ token ໃນພາຍຫຼັງ.
ສໍາລັບສະພາບການທີ່ຕໍ່ເນື່ອງ, ໃຫ້ເບິ່ງວິທີໃຊ້ທີ່ຢູ່ອີເມວຊົ່ວຄາວກັບການຟື້ນຟູໂດຍອາໄສ token ຢ່າງປອດໄພ.
ຕາຕະລາງປຽບທຽບ - ການຫມູນວຽນ vs. ບໍ່ມີການຫມູນວຽນ
ການ ຫມູນ ວຽນ ຈະ ຊະ ນະ ເມື່ອ ໃດ?
| ກໍລະນີ | ສົ່ງ ລະ ບຽບ ວິ ໄນ ຄືນ ໃຫມ່ | ການຫມູນວຽນ? | TTFOM p50/p90 (ກ່ອນ → ຫຼັງ) | OTP Success % (ກ່ອນ → ຫຼັງ) | ບັນທຶກ |
|---|---|---|---|---|---|
| ສະຫມັກ ສໍາລັບ ຊົ່ວໂມງ ທີ່ ສູງ ສຸດ | ດີ | ແມ່ນ ແລ້ວ | 40 / 120 → 25 / 70 | 89% → 96% | ການຈໍາກັດຜູ້ສົ່ງທີ່ p90 |
| ການລົງທະບຽນ off-peak | ດີ | ບໍ່ | 25 / 60 → 25 / 60 | 95% → 95% | ບໍ່ ຈໍາ ເປັນ ຕ້ອງ ຫມູນ ວຽນ; ຮັກສາ ຊື່ ສຽງ ໃຫ້ ຫມັ້ນຄົງ |
| ການເຂົ້າເກມດ້ວຍ greylisting | ກາງ | ແມ່ນ ແລ້ວ | 55 / 160 → 35 / 85 | 82% → 92% | ຫມູນວຽນຫຼັງຈາກລໍຖ້າສອງເທື່ອ; Greylisting ຫລຸດລົງ |
| ການຕັ້ງລະຫັດຜ່ານ Fintech | ກາງ | ແມ່ນ ແລ້ວ | 60 / 180 → 45 / 95 | 84% → 93% | ຂອບເຂດທີ່ເຄັ່ງຄັດກວ່າ; ຮັກສາ prefix |
| ຄວາມອັດສະຈັນຂອງ ISP ພາກພື້ນ | ດີ | ບາງທີ | 45 / 140 → 40 / 110 | 91% → 93% | ການຫມູນວຽນຊ່ວຍໄດ້ຫນ້ອຍຫນຶ່ງ; ເອົາ ໃຈ ໃສ່ ກັບ ເວລາ |
| ອຸບັດຕິເຫດຜູ້ສົ່ງຈໍານວນຫຼາຍ (campaign burst) | ດີ | ແມ່ນ ແລ້ວ | 70 / 220 → 40 / 120 | 78% → 90% | ຄວາມ ເສື່ອມ ໂຊມ ຊົ່ວຄາວ; Cool Anoisy Domains |
| QA/Staging ແຍກອອກຈາກການຜະລິດ | ດີ | ແມ່ນ (ແບ່ງ ສະ ນ້ໍາ) | 35 / 90 → 28 / 70 | 92% → 97% | ການແຍກຕົວຈະກໍາຈັດສຽງຂ້າມສຽງ |
| ຜູ້ສົ່ງທີ່ໄວ້ວາງໃຈສູງ, ການຫລັ່ງໄຫລທີ່ຫມັ້ນຄົງ | ດີ | ບໍ່ | 20 / 45 → 20 / 45 | 97% → 97% | ຫມວກຫມູນວຽນປ້ອງກັນການປ່ຽນແປງທີ່ບໍ່ຈໍາເປັນ |
ຄຳຖາມທີ່ຖືກຖາມເລື້ອຍໆ
ຂ້ອຍຄວນຫມູນວຽນເມື່ອໃດແທນທີ່ຈະສົ່ງຄືນໃຫມ່?
ຫລັງ ຈາກ ຫນຶ່ງ ຫລື ສອງ ເທື່ອ ທີ່ ຍັງ ລົ້ມ ເຫລວ, ຈໍາ ນວນ ຂອງ ທ່ານ ຈະ ເລີ່ມ ຕົ້ນ.
ການຫມູນວຽນທໍາລາຍຊື່ສຽງບໍ?
ມັນ ສາມາດ ເຮັດ ໄດ້, ຖ້າ ຫາກ ຖືກ ຂົ່ມ ເຫັງ. ໃຊ້ caps, rest domain ແລະ per-sender tracking.
ຂ້ອຍຈໍາເປັນຕ້ອງມີຈັກໂດເມນ?
ພຽງພໍທີ່ຈະປົກປ້ອງພາລະຫນັກແລະຄວາມຫຼາກຫຼາຍຂອງຜູ້ສົ່ງ; ຄຸນ ນະ ພາບ ແລະ ຖັງ ນ້ໍາ ແມ່ນ ສໍາ ຄັນ ຫລາຍ ກວ່າ ຈໍາ ນວນ ດິບ.
ການຫມູນວຽນທໍາລາຍການນໍາໃຊ້ຄືນໂດຍອາໄສ token ບໍ?
ບໍ່. ຮັກສາຄໍານໍາຫນ້າແບບດຽວກັນ; Token ຂອງເຈົ້າຈະຟື້ນຟູທີ່ຢູ່ຕໍ່ໆໄປ.
ເປັນຫຍັງລະຫັດຈຶ່ງຊ້າລົງໃນບາງຊົ່ວໂມງ?
ຈໍານວນ ຜູ້ ສົ່ງ ທີ່ ສູງ ສຸດ ແລະ ການ ຈໍາກັດ ຂອງ ຜູ້ ສົ່ງ ຈະ ຊຸກຍູ້ ຈົດຫມາຍ ທີ່ ບໍ່ ສໍາຄັນ ໃຫ້ ກັບ ຄືນ ໄປ ຫາ ແຖວ.
ທ່ານ ຄິດ ວ່າ ຂ້າ ພະ ເຈົ້າ ຄວນ ຫມູນ ອັດ ຕະ ໂນ ມັດ ໃນ ຄວາມ ລົ້ມ ເຫລວ ເທື່ອ ທໍາ ອິດ ບໍ?
ບໍ່. ຕິດຕາມຂັ້ນໄດເພື່ອຫຼີກລ່ຽງການປ່ຽນແປງທີ່ບໍ່ຈໍາເປັນແລະຄວາມເສຍຫາຍຕໍ່ຊື່ສຽງ.
ຂ້ອຍຈະເຫັນໂດເມນທີ່ "ເມື່ອຍ" ໄດ້ແນວໃດ?
TTFOM ທີ່ເພີ່ມຂຶ້ນແລະຄວາມສໍາເລັດທີ່ຕົກລົງສໍາລັບຜູ້ສົ່ງ × domain pair.
ເປັນຫຍັງໂປຣແກຣມຈຶ່ງປາກົດແຕ່ບໍ່ປາກົດໃນຮູບພາບຂອງຂ້ອຍ?
UI ອາດ ຖືກ ຕອງ; ປ່ຽນໄປເບິ່ງຂໍ້ຄວາມທໍາມະດາ ຫຼື spam ແລະຟື້ນຟູ.
ຄວາມ ແຕກ ຕ່າງ ໃນ ພາກ ພື້ນ ສໍາຄັນ ບໍ?
ເປັນໄປໄດ້. ຕິດຕາມປະເທດ/ISP ເພື່ອຢືນຢັນກ່ອນປ່ຽນນະໂຍບາຍ.
ຂ້ອຍຄວນລໍຖ້າດົນປານໃດລະຫວ່າງການສົ່ງຄືນ?
ປະມານ 60-90 ວິນາທີກ່ອນການທົດລອງ 2; 2-3 ນາທີ ກ່ອນ ການ ທົດ ລອງ 3.
ສະຫລຸບ
ຈຸດ ສໍາຄັນ ທີ່ ສຸດ ແມ່ນ ການ ຫມູນ ວຽນ ນັ້ນ ຈະ ທໍາ ງານ ພຽງ ແຕ່ ເມື່ອ ມັນ ເປັນ ຂັ້ນ ຕອນ ສຸດ ທ້າຍ ຂອງ ຂັ້ນ ຕອນ ທີ່ ມີ ລະບຽບ ວິໄນ ເທົ່າ ນັ້ນ. ວິນິໄສ, ນັບຖືປ່ອງຢ້ຽມສົ່ງຄືນ, ແລະຈາກນັ້ນປ່ຽນໂດເມນພາຍໃຕ້ຂອບເຂດທີ່ແຈ່ມແຈ້ງ. ວັດ ແທກ ສິ່ງ ທີ່ ປ່ຽນ ແປງ, ພັກຜ່ອນ ສິ່ງ ທີ່ ເສື່ອມ ໂຊມ ແລະ ໃຫ້ ຜູ້ ໃຊ້ ໃຊ້ ຄໍາ ນໍາ ຫນ້າ ອັນ ດຽວ ກັນ. ຖ້າທ່ານຕ້ອງການກົນໄກຄົບຖ້ວນທີ່ຢູ່ເບື້ອງຫຼັງຂອງຫີບສົ່ງເຂົ້າຊົ່ວຄາວ, ໃຫ້ກັບຄືນໄປເບິ່ງຄໍາອະທິບາຍກ່ຽວກັບວິທີທີ່ອີເມວຊົ່ວຄາວເຮັດວຽກ (A-Z).
