ເຫັນໃບຫນ້າທີ່ແທ້ຈິງຂອງຜະລິດຕະພັນແລະຢູ່ລອດ. ຂໍ້ມູນກ່ຽວກັບການປ່ຽນແປງຂອງຜູ້ໃຊ້ເປັນເຫດຜົນທີ່ຈະຂຽນສອງສາມບໍລິການໃຫມ່

ມີຫລາຍຮ້ອຍບົດຄວາມໃນອິນເຕີເນັດກ່ຽວກັບຜົນປະໂຫຍດຂອງການວິເຄາະພຶດຕິກໍາຂອງລູກຄ້າ. ສ່ວນຫຼາຍມັກ, ນີ້ກ່ຽວຂ້ອງກັບຂະແຫນງການຂາຍຍ່ອຍ. ຈາກການວິເຄາະກະຕ່າອາຫານ, ການວິເຄາະ ABC ແລະ XYZ ກັບການຕະຫຼາດເກັບຮັກສາໄວ້ແລະການສະເຫນີສ່ວນບຸກຄົນ. ເຕັກນິກຕ່າງໆໄດ້ຖືກນໍາໃຊ້ສໍາລັບທົດສະວັດ, algorithms ໄດ້ຖືກຄິດອອກ, ລະຫັດໄດ້ຖືກຂຽນແລະ debugged - ເອົາມັນແລະໃຊ້ມັນ. ໃນກໍລະນີຂອງພວກເຮົາ, ບັນຫາພື້ນຖານຫນຶ່ງໄດ້ເກີດຂື້ນ - ພວກເຮົາຢູ່ທີ່ ISPsystem ແມ່ນມີສ່ວນຮ່ວມໃນການພັດທະນາຊອບແວ, ບໍ່ແມ່ນການຂາຍຍ່ອຍ.
ຂ້ອຍຊື່ Denis ແລະຕອນນີ້ຂ້ອຍຮັບຜິດຊອບດ້ານຫຼັງຂອງລະບົບການວິເຄາະຢູ່ ISPsystem. ແລະນີ້ແມ່ນເລື່ອງຂອງວິທີການເພື່ອນຮ່ວມງານຂອງຂ້ອຍແລະຂ້ອຍ ດານິລ — ຜູ້ທີ່ຮັບຜິດຊອບສໍາລັບການເບິ່ງເຫັນຂໍ້ມູນ — ພະຍາຍາມເບິ່ງຜະລິດຕະພັນຊອບແວຂອງພວກເຮົາໂດຍຜ່ານ prism ຂອງຄວາມຮູ້ນີ້. ໃຫ້ເລີ່ມຕົ້ນ, ຕາມປົກກະຕິ, ກັບປະຫວັດສາດ.

ໃນຕອນເລີ່ມຕົ້ນມີຄໍາຫນຶ່ງ, ແລະຄໍາວ່າ "ພວກເຮົາຈະພະຍາຍາມບໍ?"

ໃນເວລານີ້ຂ້ອຍເຮັດວຽກເປັນນັກພັດທະນາໃນພະແນກ R&D. ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນໃນເວລາທີ່ Danil ອ່ານຢູ່ທີ່ນີ້ໃນHabre ກ່ຽວ​ກັບ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ — ເຄື່ອງ​ມື​ສໍາ​ລັບ​ການ​ວິ​ເຄາະ​ການ​ປ່ຽນ​ແປງ​ຂອງ​ຜູ້​ໃຊ້​ໃນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​. ຂ້າພະເຈົ້າບໍ່ຄ່ອຍເຊື່ອງ່າຍໆກ່ຽວກັບຄວາມຄິດຂອງການນໍາໃຊ້ມັນຢູ່ທີ່ນີ້. ເປັນຕົວຢ່າງ, ນັກພັດທະນາຫ້ອງສະຫມຸດໄດ້ອ້າງເຖິງການວິເຄາະຂອງຄໍາຮ້ອງສະຫມັກທີ່ການປະຕິບັດເປົ້າຫມາຍໄດ້ຖືກກໍານົດຢ່າງຊັດເຈນ - ການວາງຄໍາສັ່ງຫຼືບາງການປ່ຽນແປງອື່ນໆຂອງວິທີການຈ່າຍຄ່າບໍລິສັດເຈົ້າຂອງ. ຜະລິດຕະພັນຂອງພວກເຮົາແມ່ນສະຫນອງໃຫ້ຢູ່ໃນສະຖານທີ່. ນັ້ນແມ່ນ, ຜູ້ໃຊ້ທໍາອິດຊື້ໃບອະນຸຍາດ, ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນເລີ່ມຕົ້ນການເດີນທາງຂອງລາວໃນຄໍາຮ້ອງສະຫມັກ. ແມ່ນແລ້ວ, ພວກເຮົາມີສະບັບສາທິດ. ທ່ານສາມາດລອງຜະລິດຕະພັນຢູ່ທີ່ນັ້ນເພື່ອວ່າທ່ານຈະບໍ່ມີຫມູຢູ່ໃນປາກ.

ແຕ່ຜະລິດຕະພັນສ່ວນໃຫຍ່ຂອງພວກເຮົາແມ່ນແນໃສ່ຕະຫຼາດໂຮດຕິ້ງ. ເຫຼົ່ານີ້ແມ່ນລູກຄ້າຂະຫນາດໃຫຍ່, ແລະພະແນກພັດທະນາທຸລະກິດແນະນໍາໃຫ້ພວກເຂົາກ່ຽວກັບຄວາມສາມາດຂອງຜະລິດຕະພັນ. ມັນຍັງປະຕິບັດຕາມວ່າໃນເວລາຊື້, ລູກຄ້າຂອງພວກເຮົາຮູ້ແລ້ວວ່າບັນຫາໃດແດ່ທີ່ຊອບແວຂອງພວກເຮົາຈະຊ່ວຍໃຫ້ພວກເຂົາແກ້ໄຂ. ເສັ້ນທາງຂອງພວກເຂົາໃນແອັບພລິເຄຊັນຕ້ອງກົງກັນກັບ CJM ທີ່ຝັງຢູ່ໃນຜະລິດຕະພັນ, ແລະວິທີແກ້ໄຂ UX ຈະຊ່ວຍໃຫ້ພວກເຂົາຢູ່ໃນເສັ້ນທາງ. Spoiler: ນີ້ບໍ່ໄດ້ເກີດຂຶ້ນສະເຫມີ. ການແນະນຳຫໍສະໝຸດໄດ້ຖືກເລື່ອນອອກໄປ... ແຕ່ບໍ່ດົນ.

ທຸກສິ່ງທຸກຢ່າງມີການປ່ຽນແປງດ້ວຍການເປີດຕົວຂອງພວກເຮົາ - Cartbee - ເວທີສໍາລັບການສ້າງຮ້ານອອນໄລນ໌ຈາກບັນຊີ Instagram. ໃນແອັບພລິເຄຊັນນີ້, ຜູ້ໃຊ້ໄດ້ຮັບໄລຍະເວລາສອງອາທິດເພື່ອໃຊ້ຟັງຊັນທັງຫມົດໂດຍບໍ່ເສຍຄ່າ. ຫຼັງຈາກນັ້ນ, ທ່ານຕ້ອງໄດ້ຕັດສິນໃຈວ່າຈະສະຫມັກຫຼືບໍ່. ແລະນີ້ເຫມາະຢ່າງສົມບູນເຂົ້າໄປໃນແນວຄວາມຄິດ "ເສັ້ນທາງເປົ້າຫມາຍ". ມັນໄດ້ຖືກຕັດສິນໃຈ: ໃຫ້ພະຍາຍາມ!

ຜົນໄດ້ຮັບທໍາອິດຫຼືບ່ອນທີ່ໄດ້ຮັບແນວຄວາມຄິດຈາກ

ທີມງານພັດທະນາແລະຂ້ອຍໄດ້ເຊື່ອມຕໍ່ຜະລິດຕະພັນກັບລະບົບການເກັບກໍາເຫດການທີ່ຮູ້ຫນັງສືໃນມື້ຫນຶ່ງ. ຂ້າພະເຈົ້າຈະເວົ້າທັນທີວ່າ ISPsystem ໃຊ້ລະບົບຂອງຕົນເອງເພື່ອເກັບກໍາເຫດການກ່ຽວກັບການໄປຢ້ຽມຢາມຫນ້າ, ແຕ່ບໍ່ມີຫຍັງປ້ອງກັນທ່ານຈາກການນໍາໃຊ້ Yandex.Metrica ສໍາລັບຈຸດປະສົງດຽວກັນ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດດາວໂຫລດຂໍ້ມູນດິບໄດ້ໂດຍບໍ່ເສຍຄ່າ. ຕົວຢ່າງຂອງການນໍາໃຊ້ຫ້ອງສະຫມຸດໄດ້ຖືກສຶກສາ, ແລະຫຼັງຈາກຫນຶ່ງອາທິດຂອງການລວບລວມຂໍ້ມູນພວກເຮົາໄດ້ຮັບເສັ້ນສະແດງການປ່ຽນແປງ.

ເສັ້ນສະແດງການຫັນປ່ຽນ. ການທໍາງານພື້ນຖານ, ການຫັນປ່ຽນອື່ນໆອອກເພື່ອຄວາມຊັດເຈນ

ມັນໄດ້ຫັນອອກຄືກັນກັບໃນຕົວຢ່າງ: planar, ຊັດເຈນ, ງາມ. ຈາກກາຟນີ້, ພວກເຮົາສາມາດກໍານົດເສັ້ນທາງແລະເສັ້ນທາງຂ້າມຜ່ານເລື້ອຍໆທີ່ສຸດທີ່ຄົນໃຊ້ເວລາດົນທີ່ສຸດ. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາເຂົ້າໃຈດັ່ງຕໍ່ໄປນີ້:

• ແທນທີ່ຈະເປັນ CJM ຂະຫນາດໃຫຍ່, ເຊິ່ງກວມເອົາອາຍແກັສຫນ່ວຍງານ, ພຽງແຕ່ສອງແມ່ນຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະຕ້ອງນໍາຜູ້ໃຊ້ໄປຫາສະຖານທີ່ທີ່ພວກເຮົາຕ້ອງການໃຊ້ວິທີແກ້ໄຂ UX.
• ບາງຫນ້າ, ອອກແບບໂດຍຜູ້ອອກແບບ UX ເພື່ອເປັນບ່ອນສິ້ນສຸດ, ຈົບລົງດ້ວຍຄົນທີ່ໃຊ້ເວລາທີ່ບໍ່ສົມເຫດສົມຜົນກັບພວກເຂົາ. ທ່ານຈໍາເປັນຕ້ອງຄິດອອກສິ່ງທີ່ອົງປະກອບຢຸດຢູ່ໃນຫນ້າສະເພາະໃດຫນຶ່ງແລະປັບໃຫ້ເຂົາເຈົ້າ.
• ຫຼັງຈາກ 10 ການປ່ຽນແປງ, 20% ຂອງປະຊາຊົນເລີ່ມເມື່ອຍແລະອອກຈາກກອງປະຊຸມໃນຄໍາຮ້ອງສະຫມັກ. ແລະນີ້ແມ່ນການຄໍານຶງເຖິງຄວາມຈິງທີ່ວ່າພວກເຮົາມີຈໍານວນຫຼາຍເຖິງ 5 ຫນ້າ onboarding ໃນຄໍາຮ້ອງສະຫມັກ! ທ່ານຈໍາເປັນຕ້ອງກໍານົດຫນ້າທີ່ຜູ້ໃຊ້ປະຖິ້ມກອງປະຊຸມແລະຫຍໍ້ເສັ້ນທາງໄປຫາພວກເຂົາ. ດີກວ່າ: ກໍານົດເສັ້ນທາງປົກກະຕິໃດໆແລະອະນຸຍາດໃຫ້ມີການຫັນປ່ຽນໄວຈາກຫນ້າແຫຼ່ງໄປຫາຫນ້າປາຍທາງ. ບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນກັບການວິເຄາະ ABC ແລະການວິເຄາະໂຄງຮ່າງການປະຖິ້ມໄວ້, ເຈົ້າຄິດບໍ?

ແລະໃນທີ່ນີ້ພວກເຮົາໄດ້ພິຈາລະນາທັດສະນະຄະຕິຂອງພວກເຮົາຄືນໃຫມ່ຕໍ່ກັບການນໍາໃຊ້ເຄື່ອງມືນີ້ສໍາລັບຜະລິດຕະພັນຢູ່ໃນສະຖານທີ່. ມັນໄດ້ຖືກຕັດສິນໃຈວິເຄາະຜະລິດຕະພັນທີ່ຂາຍແລະນໍາໃຊ້ຢ່າງຫ້າວຫັນ - VMmanager 6. ມັນ​ມີ​ຄວາມ​ສັບ​ສົນ​ຫຼາຍ​, ມີ​ຄໍາ​ສັ່ງ​ຂອງ​ຫນ່ວຍ​ງານ​ຂະ​ຫນາດ​ໃຫຍ່​ກວ່າ​. ພວກເຮົາຕື່ນເຕັ້ນລໍຖ້າເບິ່ງວ່າເສັ້ນສະແດງການປ່ຽນແປງຈະກາຍມາເປັນແນວໃດ.

ກ່ຽວກັບຄວາມຜິດຫວັງແລະການດົນໃຈ

ຄວາມຜິດຫວັງ #1

ມັນແມ່ນມື້ສິ້ນສຸດຂອງມື້ເຮັດວຽກ, ທ້າຍເດືອນແລະທ້າຍປີໃນເວລາດຽວກັນ - ວັນທີ 27 ທັນວາ. ຂໍ້ມູນໄດ້ຖືກສະສົມ, ຄໍາຖາມໄດ້ຖືກຂຽນ. ມີວິນາທີທີ່ເຫຼືອກ່ອນທີ່ທຸກສິ່ງທຸກຢ່າງຈະຖືກປຸງແຕ່ງແລະພວກເຮົາສາມາດເບິ່ງຜົນຂອງແຮງງານຂອງພວກເຮົາເພື່ອຊອກຫາບ່ອນທີ່ປີເຮັດວຽກຕໍ່ໄປຈະເລີ່ມຕົ້ນ. ພະແນກ R&D, ຜູ້ຈັດການຜະລິດຕະພັນ, ຜູ້ອອກແບບ UX, ຫົວຫນ້າທີມ, ຜູ້ພັດທະນາໄດ້ລວບລວມຢູ່ທາງຫນ້າຂອງຈໍສະແດງຜົນເພື່ອເບິ່ງວ່າເສັ້ນທາງຂອງຜູ້ໃຊ້ໃນຜະລິດຕະພັນຂອງພວກເຂົາແມ່ນຫຍັງ, ແຕ່ ... ພວກເຮົາເຫັນນີ້:

ເສັ້ນສະແດງການປ່ຽນແປງທີ່ສ້າງຂຶ້ນໂດຍຫ້ອງສະໝຸດ Retentioneering

ແຮງບັນດານໃຈ #1

ເຊື່ອມຕໍ່ຢ່າງແຂງແຮງ, ມີຫຼາຍສິບຫົວໜ່ວຍ, ສະຖານະການທີ່ບໍ່ຊັດເຈນ. ມັນພຽງແຕ່ຈະແຈ້ງວ່າປີການເຮັດວຽກໃຫມ່ຈະເລີ່ມຕົ້ນບໍ່ແມ່ນການວິເຄາະ, ແຕ່ດ້ວຍການປະດິດວິທີການເພື່ອເຮັດໃຫ້ການເຮັດວຽກທີ່ງ່າຍດາຍດ້ວຍກາຟດັ່ງກ່າວ. ແຕ່ຂ້າພະເຈົ້າບໍ່ສາມາດສັ່ນຄວາມຮູ້ສຶກວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍຫຼາຍກ່ວາມັນເບິ່ງຄືວ່າ. ແລະຫຼັງຈາກສິບຫ້ານາທີຂອງການສຶກສາລະຫັດແຫຼ່ງ Retentioneering, ພວກເຮົາສາມາດສົ່ງອອກກາຟທີ່ສ້າງຂຶ້ນເປັນຮູບແບບ dot. ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະອັບໂຫລດກາຟກັບເຄື່ອງມືອື່ນ - Gephi. ແລະມີຂອບເຂດສໍາລັບການວິເຄາະກາຟແລ້ວ: ການຈັດວາງ, ຕົວກອງ, ສະຖິຕິ - ທັງຫມົດທີ່ທ່ານຕ້ອງເຮັດແມ່ນກໍານົດຕົວກໍານົດການທີ່ຈໍາເປັນໃນການໂຕ້ຕອບ. ດ້ວຍຄວາມຄິດນີ້ຢູ່ໃນໃຈ, ພວກເຮົາອອກໄປໃນທ້າຍອາທິດຂອງປີໃຫມ່.

ຄວາມຜິດຫວັງ #2

ຫຼັງຈາກກັບຄືນໄປເຮັດວຽກ, ມັນໄດ້ຫັນອອກວ່າໃນຂະນະທີ່ທຸກຄົນພັກຜ່ອນ, ລູກຄ້າຂອງພວກເຮົາໄດ້ສຶກສາຜະລິດຕະພັນ. ແມ່ນແລ້ວ, ຍາກຫຼາຍທີ່ເຫດການປາກົດຢູ່ໃນບ່ອນເກັບມ້ຽນທີ່ບໍ່ເຄີຍມີມາກ່ອນ. ນີ້ຫມາຍຄວາມວ່າການສອບຖາມຈໍາເປັນຕ້ອງໄດ້ຮັບການປັບປຸງ.

ພື້ນຖານເລັກນ້ອຍທີ່ຈະເຂົ້າໃຈຄວາມໂສກເສົ້າຂອງຄວາມເປັນຈິງນີ້. ພວກເຮົາສົ່ງທັງສອງເຫດການທີ່ພວກເຮົາໄດ້ຫມາຍ (ຕົວຢ່າງເຊັ່ນການຄລິກໃສ່ບາງປຸ່ມ) ແລະ URL ຂອງຫນ້າທີ່ຜູ້ໃຊ້ໄດ້ໄປຢ້ຽມຢາມ. ໃນກໍລະນີຂອງ Cartbee, ຮູບແບບ "ຫນຶ່ງປະຕິບັດ - ຫນຶ່ງຫນ້າ" ໄດ້ເຮັດວຽກ. ແຕ່ກັບ VMmanager ສະຖານະການແມ່ນແຕກຕ່າງກັນຫມົດ: ປ່ອງຢ້ຽມ modal ຫຼາຍສາມາດເປີດຢູ່ໃນຫນ້າດຽວ. ໃນພວກເຂົາຜູ້ໃຊ້ສາມາດແກ້ໄຂບັນຫາຕ່າງໆ. ຕົວຢ່າງ, URL:

/host/item/24/ip(modal:modal/host/item/ip/create)

ຫມາຍຄວາມວ່າໃນຫນ້າ "ທີ່ຢູ່ IP" ຜູ້ໃຊ້ໄດ້ເພີ່ມທີ່ຢູ່ IP. ແລະນີ້ສອງບັນຫາແມ່ນເຫັນໄດ້ໃນເວລາດຽວກັນ:

• URL ປະກອບມີບາງປະເພດຂອງພາລາມິເຕີເສັ້ນທາງ - ID ຂອງເຄື່ອງ virtual. ມັນຈໍາເປັນຕ້ອງຖືກຍົກເວັ້ນ.
• URL ປະກອບມີ ID window modal. ທ່ານຈໍາເປັນຕ້ອງ "unpack" URL ດັ່ງກ່າວຢ່າງໃດ.
  ບັນຫາອີກອັນໜຶ່ງແມ່ນເຫດການທີ່ພວກເຮົາໝາຍໄວ້ມີພາລາມິເຕີ. ຕົວຢ່າງ, ມີຫ້າວິທີທີ່ແຕກຕ່າງກັນເພື່ອໄປຫາຫນ້າທີ່ມີຂໍ້ມູນກ່ຽວກັບເຄື່ອງ virtual ຈາກບັນຊີລາຍຊື່. ດັ່ງນັ້ນ, ເຫດການຫນຶ່ງຖືກສົ່ງ, ແຕ່ມີພາລາມິເຕີທີ່ຊີ້ບອກວ່າວິທີການໃດທີ່ຜູ້ໃຊ້ເຮັດການປ່ຽນແປງ. ມີຫຼາຍເຫດການດັ່ງກ່າວ, ແລະຕົວກໍານົດການທັງຫມົດແມ່ນແຕກຕ່າງກັນ. ແລະພວກເຮົາມີເຫດຜົນການດຶງຂໍ້ມູນທັງຫມົດໃນພາສາ SQL ສໍາລັບ Clickhouse. ການສອບຖາມຂອງ 150-200 ເສັ້ນໄດ້ເລີ່ມເບິ່ງຄືວ່າເປັນເລື່ອງທໍາມະດາ. ບັນຫາອ້ອມຮອບພວກເຮົາ.

ແຮງບັນດານໃຈ #2

ໃນຕອນເຊົ້າເຊົ້າມື້ຫນຶ່ງ, Danil, ໂສກເສົ້າເລື່ອນໄປຫາຄໍາຮ້ອງຂໍສໍາລັບນາທີທີສອງ, ໄດ້ແນະນໍາກັບຂ້ອຍວ່າ: "ມາຂຽນທໍ່ການປຸງແຕ່ງຂໍ້ມູນບໍ?" ພວກເຮົາຄິດກ່ຽວກັບມັນແລະຕັດສິນໃຈວ່າຖ້າພວກເຮົາຈະເຮັດມັນ, ມັນຈະເປັນບາງສິ່ງບາງຢ່າງເຊັ່ນ ETL. ເພື່ອໃຫ້ມັນກັ່ນຕອງທັນທີແລະດຶງຂໍ້ມູນທີ່ຈໍາເປັນຈາກແຫຼ່ງອື່ນໆ. ນີ້ແມ່ນວິທີການບໍລິການການວິເຄາະຄັ້ງທໍາອິດຂອງພວກເຮົາກັບ backend ເຕັມປະສິດທິພາບໄດ້ເກີດມາ. ມັນປະຕິບັດຫ້າຂັ້ນຕອນຕົ້ນຕໍຂອງການປະມວນຜົນຂໍ້ມູນ:

1. ການໂຫຼດເຫດການຈາກການເກັບຂໍ້ມູນດິບ ແລະກະກຽມພວກມັນສຳລັບການປະມວນຜົນ.
2. ຄວາມກະຈ່າງແຈ້ງແມ່ນ "unpacking" ຂອງຕົວລະບຸຫຼາຍຂອງປ່ອງຢ້ຽມ modal, ຕົວກໍານົດການເຫດການແລະລາຍລະອຽດອື່ນໆທີ່ຊີ້ແຈງເຫດການ.
3. ການເສີມສ້າງ (ຈາກຄໍາວ່າ "ກາຍເປັນອຸດົມສົມບູນ") ແມ່ນການເພີ່ມເຫດການທີ່ມີຂໍ້ມູນຈາກແຫຼ່ງພາກສ່ວນທີສາມ. ໃນເວລານັ້ນ, ນີ້ປະກອບມີພຽງແຕ່ລະບົບການເອີ້ນເກັບເງິນຂອງພວກເຮົາ BILLmanager.
4. ການກັ່ນຕອງແມ່ນຂະບວນການຂອງການກັ່ນຕອງອອກເຫດການທີ່ບິດເບືອນຜົນໄດ້ຮັບຂອງການວິເຄາະ (ເຫດການພາຍໃນ, outliers, ແລະອື່ນໆ).
5. ການອັບໂຫລດເຫດການທີ່ໄດ້ຮັບເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນ, ເຊິ່ງພວກເຮົາເອີ້ນວ່າຂໍ້ມູນສະອາດ.
   ໃນປັດຈຸບັນມັນເປັນໄປໄດ້ທີ່ຈະຮັກສາຄວາມກ່ຽວຂ້ອງໂດຍການເພີ່ມກົດລະບຽບສໍາລັບການປະມວນຜົນເຫດການຫຼືແມ້ກະທັ້ງກຸ່ມຂອງເຫດການທີ່ຄ້າຍຄືກັນ. ຕົວຢ່າງ, ນັບຕັ້ງແຕ່ນັ້ນມາພວກເຮົາບໍ່ເຄີຍປັບປຸງ URL unpacking. ເຖິງແມ່ນວ່າ, ໃນລະຫວ່າງເວລານີ້, ການປ່ຽນແປງ URL ໃຫມ່ຈໍານວນຫນຶ່ງໄດ້ຖືກເພີ່ມ. ພວກເຂົາປະຕິບັດຕາມກົດລະບຽບທີ່ວາງໄວ້ແລ້ວໃນການບໍລິການແລະຖືກປຸງແຕ່ງຢ່າງຖືກຕ້ອງ.

ຄວາມຜິດຫວັງ #3

ເມື່ອພວກເຮົາເລີ່ມວິເຄາະ, ພວກເຮົາຮູ້ວ່າເປັນຫຍັງເສັ້ນສະແດງຈຶ່ງສອດຄ່ອງກັນ. ຄວາມຈິງແລ້ວແມ່ນວ່າເກືອບທຸກໆ N-gram ປະກອບດ້ວຍການຫັນປ່ຽນທີ່ບໍ່ສາມາດດໍາເນີນການຜ່ານການໂຕ້ຕອບ.

ການສືບສວນຂະຫນາດນ້ອຍໄດ້ເລີ່ມຕົ້ນ. ຂ້າພະເຈົ້າສັບສົນວ່າບໍ່ມີການຫັນປ່ຽນທີ່ເປັນໄປບໍ່ໄດ້ພາຍໃນຫນຶ່ງຫົວຫນ່ວຍ. ນີ້ຫມາຍຄວາມວ່ານີ້ບໍ່ແມ່ນຂໍ້ບົກພ່ອງໃນລະບົບການເກັບກໍາເຫດການຫຼືການບໍລິການ ETL ຂອງພວກເຮົາ. ມີຄວາມຮູ້ສຶກວ່າຜູ້ໃຊ້ເຮັດວຽກພ້ອມໆກັນຢູ່ໃນຫຼາຍຫນ່ວຍງານ, ໂດຍບໍ່ມີການຍ້າຍຈາກຫນຶ່ງໄປຫາອື່ນ. ເຮັດແນວໃດເພື່ອບັນລຸນີ້? ໃຊ້ແທັບທີ່ແຕກຕ່າງກັນໃນຕົວທ່ອງເວັບ.

ເມື່ອວິເຄາະ Cartbee, ພວກເຮົາຖືກບັນທຶກໄວ້ໂດຍສະເພາະຂອງມັນ. ແອັບພລິເຄຊັນໄດ້ຖືກນໍາໃຊ້ຈາກອຸປະກອນມືຖື, ບ່ອນທີ່ການເຮັດວຽກຈາກຫຼາຍໆແຖບແມ່ນບໍ່ສະດວກ. ໃນທີ່ນີ້ພວກເຮົາມີ desktop ແລະໃນຂະນະທີ່ວຽກງານໃດຫນຶ່ງຖືກປະຕິບັດຢູ່ໃນຫນ່ວຍງານຫນຶ່ງ, ມັນສົມເຫດສົມຜົນທີ່ຈະຕ້ອງການໃຊ້ເວລານີ້ໃນການຕັ້ງຄ່າຫຼືຕິດຕາມສະຖານະໃນອື່ນ. ແລະເພື່ອບໍ່ໃຫ້ສູນເສຍຄວາມຄືບຫນ້າ, ພຽງແຕ່ເປີດແຖບອື່ນ.

ແຮງບັນດານໃຈ #3

ເພື່ອນຮ່ວມງານຈາກການພັດທະນາດ້ານຫນ້າໄດ້ສອນລະບົບການລວບລວມເຫດການເພື່ອຈໍາແນກລະຫວ່າງແຖບ. ການວິເຄາະສາມາດເລີ່ມຕົ້ນໄດ້. ແລະພວກເຮົາໄດ້ເລີ່ມຕົ້ນ. ດັ່ງທີ່ຄາດໄວ້, CJM ບໍ່ກົງກັບເສັ້ນທາງທີ່ແທ້ຈິງ: ຜູ້ໃຊ້ໃຊ້ເວລາຫຼາຍໃນຫນ້າໄດເລກະທໍລີ, ກອງປະຊຸມທີ່ຖືກປະຖິ້ມໄວ້ແລະແຖບຢູ່ໃນສະຖານທີ່ທີ່ບໍ່ຄາດຄິດທີ່ສຸດ. ການນໍາໃຊ້ການວິເຄາະການຫັນປ່ຽນ, ພວກເຮົາສາມາດຊອກຫາບັນຫາໃນບາງ Mozilla ກໍ່ສ້າງ. ໃນພວກມັນ, ເນື່ອງຈາກລັກສະນະການປະຕິບັດ, ອົງປະກອບການນໍາທາງຫາຍໄປຫຼືຫນ້າເຄິ່ງຫນຶ່ງທີ່ຫວ່າງເປົ່າໄດ້ຖືກສະແດງ, ເຊິ່ງຄວນຈະເຂົ້າເຖິງໄດ້ໂດຍຜູ້ເບິ່ງແຍງເທົ່ານັ້ນ. ຫນ້າເວັບໄດ້ເປີດ, ແຕ່ບໍ່ມີເນື້ອຫາມາຈາກ backend. ການນັບການຫັນປ່ຽນເຮັດໃຫ້ມັນເປັນໄປໄດ້ເພື່ອປະເມີນວ່າຄຸນສົມບັດໃດຖືກໃຊ້ຕົວຈິງ. ລະບົບຕ່ອງໂສ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເຂົ້າໃຈວິທີທີ່ຜູ້ໃຊ້ໄດ້ຮັບນີ້ຫຼືຄວາມຜິດພາດນັ້ນ. ຂໍ້ມູນທີ່ອະນຸຍາດໃຫ້ທົດສອບໂດຍອີງໃສ່ພຶດຕິກໍາຂອງຜູ້ໃຊ້. ມັນເປັນຜົນສໍາເລັດ, ຄວາມຄິດບໍ່ໄດ້ຢູ່ໃນ vain.

ອັດຕະໂນມັດການວິເຄາະ

ໃນຫນຶ່ງໃນການສາທິດຜົນໄດ້ຮັບ, ພວກເຮົາໄດ້ສະແດງໃຫ້ເຫັນວ່າ Gephi ຖືກໃຊ້ສໍາລັບການວິເຄາະກາຟ. ໃນເຄື່ອງມືນີ້, ຂໍ້ມູນການແປງສາມາດສະແດງຢູ່ໃນຕາຕະລາງ. ແລະຫົວຫນ້າພະແນກ UX ກ່າວວ່າຄວາມຄິດທີ່ສໍາຄັນຫນຶ່ງທີ່ມີອິດທິພົນຕໍ່ການພັດທະນາທິດທາງການວິເຄາະພຶດຕິກໍາທັງຫມົດໃນບໍລິສັດ: "ໃຫ້ເຮັດເຊັ່ນດຽວກັນ, ແຕ່ໃນ Tableau ແລະການກັ່ນຕອງ - ມັນຈະສະດວກກວ່າ."

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າຄິດວ່າ: ເປັນຫຍັງບໍ່, Retentioneering ເກັບຮັກສາຂໍ້ມູນທັງຫມົດໃນໂຄງສ້າງ pandas.DataFrame. ແລະນີ້ແມ່ນ, ໂດຍແລະຂະຫນາດໃຫຍ່, ຕາຕະລາງ. ນີ້ແມ່ນວິທີການບໍລິການອື່ນປາກົດ: ຜູ້ໃຫ້ບໍລິການຂໍ້ມູນ. ລາວບໍ່ພຽງແຕ່ສ້າງຕາຕະລາງຈາກກາຟ, ແຕ່ຍັງຄິດໄລ່ວ່າຫນ້າທີ່ນິຍົມແລະຫນ້າທີ່ເຊື່ອມໂຍງກັບມັນແມ່ນຫຍັງ, ມັນມີຜົນກະທົບຕໍ່ການຮັກສາຜູ້ໃຊ້, ຜູ້ໃຊ້ຢູ່ໃນມັນດົນປານໃດ, ແລະຫນ້າເວັບໃດທີ່ຜູ້ໃຊ້ອອກເລື້ອຍໆ. ແລະການນໍາໃຊ້ການເບິ່ງເຫັນໃນ Tableau ຫຼຸດລົງຄ່າໃຊ້ຈ່າຍໃນການສຶກສາກາຟຫຼາຍດັ່ງນັ້ນເວລາ iteration ສໍາລັບການວິເຄາະພຶດຕິກໍາໃນຜະລິດຕະພັນແມ່ນເກືອບເຄິ່ງຫນຶ່ງ.

Danil ຈະສົນທະນາກ່ຽວກັບວິທີການເບິ່ງເຫັນນີ້ຖືກນໍາໃຊ້ແລະສິ່ງທີ່ສະຫຼຸບທີ່ມັນອະນຸຍາດໃຫ້ແຕ້ມ.

ຕາຕະລາງເພີ່ມເຕີມສໍາລັບພຣະເຈົ້າຕາຕະລາງ!

ໃນຮູບແບບທີ່ງ່າຍດາຍ, ວຽກງານໄດ້ຖືກສ້າງຂື້ນດັ່ງຕໍ່ໄປນີ້: ສະແດງເສັ້ນສະແດງການປ່ຽນແປງໃນ Tableau, ສະຫນອງຄວາມສາມາດໃນການກັ່ນຕອງແລະເຮັດໃຫ້ມັນຊັດເຈນແລະສະດວກທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້.

ຂ້ອຍບໍ່ຢາກແຕ້ມເສັ້ນສະແດງໃນ Tableau ແທ້ໆ. ແລະເຖິງແມ່ນວ່າຈະປະສົບຜົນສໍາເລັດ, ຜົນປະໂຫຍດ, ເມື່ອທຽບກັບ Gephi, ເບິ່ງຄືວ່າບໍ່ຊັດເຈນ. ພວກເຮົາຕ້ອງການບາງສິ່ງບາງຢ່າງທີ່ງ່າຍກວ່າ ແລະເຂົ້າເຖິງໄດ້ຫຼາຍ. ໂຕະ! ຫຼັງຈາກທີ່ທັງຫມົດ, ເສັ້ນສະແດງສາມາດຖືກສະແດງໄດ້ງ່າຍໃນຮູບແບບຂອງແຖວຕາຕະລາງ, ເຊິ່ງແຕ່ລະແຖວແມ່ນຂອບຂອງປະເພດ "ແຫຼ່ງ - ຈຸດຫມາຍປາຍທາງ". ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຮົາໄດ້ກະກຽມຕາຕະລາງດັ່ງກ່າວຢ່າງລະມັດລະວັງໂດຍໃຊ້ເຄື່ອງມື Retentioneering ແລະ Data Provider. ທັງຫມົດທີ່ປະໄວ້ເພື່ອເຮັດແມ່ນເພື່ອສະແດງຕາຕະລາງໃນ Tableau ແລະ rummage ຜ່ານບົດລາຍງານ.

ເວົ້າກ່ຽວກັບວິທີທີ່ທຸກຄົນຮັກຕາຕະລາງ.

ຢ່າງໃດກໍຕາມ, ໃນທີ່ນີ້ພວກເຮົາປະເຊີນກັບບັນຫາອື່ນ. ຈະເຮັດແນວໃດກັບແຫຼ່ງຂໍ້ມູນ? ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຊື່ອມຕໍ່ pandas.DataFrame; Tableau ບໍ່ມີຕົວເຊື່ອມຕໍ່ດັ່ງກ່າວ. ການສ້າງພື້ນຖານແຍກຕ່າງຫາກສໍາລັບການເກັບຮັກສາເສັ້ນສະແດງເບິ່ງຄືວ່າເປັນການແກ້ໄຂທີ່ມີແນວໂນ້ມທີ່ບໍ່ແນ່ນອນ. ແລະທາງເລືອກໃນການ unloading ທ້ອງຖິ່ນແມ່ນບໍ່ເຫມາະສົມເນື່ອງຈາກຄວາມຕ້ອງການສໍາລັບການດໍາເນີນງານຄູ່ມືຄົງທີ່. ພວກເຮົາໄດ້ເບິ່ງຜ່ານບັນຊີລາຍຊື່ຂອງຕົວເຊື່ອມຕໍ່ທີ່ມີຢູ່, ແລະການເບິ່ງຂອງພວກເຮົາຕົກຢູ່ໃນລາຍການ ຕົວເຊື່ອມຕໍ່ຂໍ້ມູນເວັບ, ຜູ້ທີ່ huddled forlornly ຢູ່ລຸ່ມສຸດ.

Tableau ມີທາງເລືອກທີ່ອຸດົມສົມບູນຂອງຕົວເຊື່ອມຕໍ່. ພວກເຮົາພົບເຫັນຫນຶ່ງທີ່ແກ້ໄຂບັນຫາຂອງພວກເຮົາ

ສັດປະເພດໃດ? ບາງແຖບເປີດໃຫມ່ໃນຕົວທ່ອງເວັບ - ແລະມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າຕົວເຊື່ອມຕໍ່ນີ້ຊ່ວຍໃຫ້ທ່ານໄດ້ຮັບຂໍ້ມູນໃນເວລາທີ່ເຂົ້າເຖິງ URL. backend ສໍາລັບການຄິດໄລ່ຂໍ້ມູນຕົວມັນເອງແມ່ນເກືອບພ້ອມແລ້ວ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອເຮັດໃຫ້ມັນເປັນເພື່ອນກັບ WDC. ສໍາລັບຫຼາຍໆມື້ Denis ໄດ້ສຶກສາເອກະສານແລະຕໍ່ສູ້ກັບກົນໄກຂອງ Tableau, ແລະຫຼັງຈາກນັ້ນໄດ້ສົ່ງການເຊື່ອມຕໍ່ທີ່ຂ້ອຍໄດ້ວາງໄວ້ໃນປ່ອງຢ້ຽມເຊື່ອມຕໍ່.

ແບບຟອມການເຊື່ອມຕໍ່ກັບ WDC ຂອງພວກເຮົາ. Denis ເຮັດຫນ້າແລະດູແລຄວາມປອດໄພ

ຫຼັງຈາກສອງສາມນາທີລໍຖ້າ (ຂໍ້ມູນຖືກຄິດໄລ່ແບບໄດນາມິກເມື່ອຮ້ອງຂໍ), ຕາຕະລາງປາກົດ:

ນີ້ແມ່ນສິ່ງທີ່ array ຂໍ້ມູນດິບເບິ່ງຄືວ່າຢູ່ໃນການໂຕ້ຕອບ Tableau

ດັ່ງທີ່ໄດ້ສັນຍາໄວ້, ແຕ່ລະແຖວຂອງຕາຕະລາງດັ່ງກ່າວເປັນຕົວແທນຂອງຂອບຂອງກາຟ, ນັ້ນແມ່ນ, ການປ່ຽນແປງທີ່ຊີ້ບອກຂອງຜູ້ໃຊ້. ມັນຍັງປະກອບດ້ວຍລັກສະນະເພີ່ມເຕີມຈໍານວນຫນຶ່ງ. ຕົວຢ່າງ, ຈໍານວນຜູ້ໃຊ້ທີ່ບໍ່ຊ້ໍາກັນ, ຈໍານວນການຫັນປ່ຽນທັງຫມົດ, ແລະອື່ນໆ.

ມັນເປັນໄປໄດ້ທີ່ຈະສະແດງຕາຕະລາງນີ້ຢູ່ໃນບົດລາຍງານ, ໂດຍທົ່ວໄປ sprinkle ການກັ່ນຕອງແລະສົ່ງ sailing ເຄື່ອງມື. ມີເຫດຜົນ. ເຈົ້າສາມາດເຮັດຫຍັງໄດ້ກັບຕາຕະລາງ? ແຕ່ນີ້ບໍ່ແມ່ນວິທີການຂອງພວກເຮົາ, ເພາະວ່າພວກເຮົາກໍາລັງເຮັດບໍ່ພຽງແຕ່ຕາຕະລາງ, ແຕ່ເປັນເຄື່ອງມືສໍາລັບການວິເຄາະແລະການຕັດສິນໃຈຜະລິດຕະພັນ.

ໂດຍປົກກະຕິ, ເມື່ອວິເຄາະຂໍ້ມູນ, ບຸກຄົນຕ້ອງການທີ່ຈະໄດ້ຮັບຄໍາຕອບຕໍ່ຄໍາຖາມ. ຍິ່ງໃຫຍ່. ໃຫ້ເລີ່ມຕົ້ນດ້ວຍພວກມັນ.

• ການຫັນປ່ຽນເລື້ອຍໆຫຼາຍທີ່ສຸດແມ່ນຫຍັງ?
• ພວກເຂົາໄປໃສຈາກຫນ້າທີ່ສະເພາະ?
• ເຈົ້າໃຊ້ເວລາສະເລ່ຍໃນໜ້ານີ້ດົນປານໃດກ່ອນທີ່ຈະອອກໄປ?
• ເຈົ້າປ່ຽນຈາກ A ຫາ B ເລື້ອຍໆສໍ່າໃດ?
• ກອງປະຊຸມຈົບລົງໃນໜ້າໃດ?

ແຕ່ລະບົດລາຍງານຫຼືການປະສົມປະສານຂອງພວກມັນຄວນອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດຊອກຫາຄໍາຕອບຕໍ່ຄໍາຖາມເຫຼົ່ານີ້ຢ່າງເປັນອິດສະຫຼະ. ຍຸດທະສາດທີ່ສໍາຄັນຢູ່ທີ່ນີ້ແມ່ນເພື່ອໃຫ້ທ່ານມີເຄື່ອງມືເພື່ອເຮັດມັນເອງ. ນີ້ແມ່ນເປັນປະໂຫຍດທັງການຫຼຸດຜ່ອນການໂຫຼດຂອງພະແນກການວິເຄາະແລະການຫຼຸດຜ່ອນເວລາສໍາລັບການຕັດສິນໃຈ - ຫຼັງຈາກທີ່ທັງຫມົດ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງໄປຫາ Youtrack ແລະສ້າງວຽກງານສໍາລັບນັກວິເຄາະ, ທ່ານພຽງແຕ່ຕ້ອງການເປີດບົດລາຍງານ.

ພວກເຮົາໄດ້ຮັບຫຍັງ?

ຄົນສ່ວນໃຫຍ່ມັກຈະແຍກອອກຈາກ dashboard ຢູ່ໃສ?

ຊິ້ນສ່ວນຂອງບົດລາຍງານຂອງພວກເຮົາ. ຫຼັງຈາກ dashboard, ທຸກຄົນໄດ້ໄປຫາບັນຊີລາຍຊື່ຂອງ VMs ຫຼືບັນຊີລາຍຊື່ຂອງ nodes

ໃຫ້ເອົາຕາຕະລາງທົ່ວໄປທີ່ມີການຫັນປ່ຽນແລະການກັ່ນຕອງໂດຍຫນ້າແຫຼ່ງ. ສ່ວນຫຼາຍມັກ, ພວກເຂົາໄປຈາກ dashboard ໄປຫາບັນຊີລາຍຊື່ຂອງເຄື່ອງຈັກ virtual. ຍິ່ງໄປກວ່ານັ້ນ, ຄໍລໍາ Regularity ແນະນໍາວ່ານີ້ແມ່ນການກະທໍາທີ່ຊ້ໍາກັນ.

ພວກເຂົາມາຈາກໃສໃນບັນຊີລາຍຊື່ຂອງກຸ່ມ?

ການກັ່ນຕອງໃນບົດລາຍງານເຮັດວຽກທັງສອງທິດທາງ: ທ່ານສາມາດຊອກຫາບ່ອນທີ່ທ່ານໄປ, ຫຼືບ່ອນທີ່ທ່ານໄປ

ຈາກຕົວຢ່າງມັນເປັນທີ່ຊັດເຈນວ່າເຖິງແມ່ນວ່າການປະກົດຕົວຂອງສອງຕົວກອງທີ່ງ່າຍດາຍແລະການຈັດລໍາດັບແຖວໂດຍມູນຄ່າຊ່ວຍໃຫ້ທ່ານສາມາດໄດ້ຮັບຂໍ້ມູນຢ່າງໄວວາ.

ໃຫ້ຖາມສິ່ງທີ່ຍາກກວ່າ.

ຜູ້ໃຊ້ສ່ວນໃຫຍ່ມັກຈະປະຖິ້ມເຊດຊັນຂອງພວກເຂົາຢູ່ໃສ?

ຜູ້ໃຊ້ VMmanager ມັກຈະເຮັດວຽກຢູ່ໃນແຖບແຍກຕ່າງຫາກ

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງການບົດລາຍງານທີ່ຂໍ້ມູນຖືກລວບລວມໂດຍແຫຼ່ງອ້າງອີງ. ແລະອັນທີ່ເອີ້ນວ່າ breakepoints ໄດ້ຖືກປະຕິບັດເປັນການມອບຫມາຍ - ເຫດການທີ່ເຮັດຫນ້າທີ່ເປັນຈຸດສິ້ນສຸດຂອງລະບົບຕ່ອງໂສ້ການຫັນປ່ຽນ.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່ານີ້ອາດຈະເປັນການສິ້ນສຸດຂອງກອງປະຊຸມຫຼືການເປີດແຖບໃຫມ່. ຕົວຢ່າງສະແດງໃຫ້ເຫັນວ່າລະບົບຕ່ອງໂສ້ສ່ວນຫຼາຍມັກຈະສິ້ນສຸດຢູ່ໃນຕາຕະລາງທີ່ມີບັນຊີລາຍຊື່ຂອງເຄື່ອງຈັກ virtual. ໃນກໍລະນີນີ້, ລັກສະນະລັກສະນະແມ່ນປ່ຽນໄປແຖບອື່ນ, ເຊິ່ງສອດຄ່ອງກັບຮູບແບບທີ່ຄາດໄວ້.

ກ່ອນອື່ນ ໝົດ ພວກເຮົາທົດສອບຜົນປະໂຫຍດຂອງບົດລາຍງານເຫຼົ່ານີ້ກ່ຽວກັບຕົວເຮົາເອງເມື່ອພວກເຮົາປະຕິບັດການວິເຄາະໃນລັກສະນະທີ່ຄ້າຍຄືກັນ Vepp, ຜະລິດຕະພັນອື່ນຂອງພວກເຮົາ. ດ້ວຍການມາເຖິງຂອງຕາຕະລາງແລະການກັ່ນຕອງ, ສົມມຸດຕິຖານໄດ້ຖືກທົດສອບໄວ, ແລະຕາບໍ່ເມື່ອຍຫນ້ອຍ.

ເມື່ອພັດທະນາບົດລາຍງານ, ພວກເຮົາບໍ່ໄດ້ລືມກ່ຽວກັບການອອກແບບສາຍຕາ. ເມື່ອເຮັດວຽກກັບຕາຕະລາງຂະຫນາດນີ້, ນີ້ແມ່ນປັດໃຈສໍາຄັນ. ຕົວຢ່າງ, ພວກເຮົາໄດ້ໃຊ້ລະດັບສີທີ່ສະຫງົບ, ງ່າຍທີ່ຈະຮັບຮູ້ ຕົວອັກສອນ monospace ສໍາ​ລັບ​ຕົວ​ເລກ​, ການ​ເນັ້ນ​ສີ​ຂອງ​ສາຍ​ຕາມ​ຄຸນ​ຄ່າ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ລັກ​ສະ​ນະ​. ລາຍລະອຽດດັ່ງກ່າວປັບປຸງປະສົບການຂອງຜູ້ໃຊ້ແລະເພີ່ມຄວາມເປັນໄປໄດ້ຂອງເຄື່ອງມືທີ່ເອົາໄປປະສົບຜົນສໍາເລັດພາຍໃນບໍລິສັດ.

ຕາຕະລາງໄດ້ຫັນອອກເປັນ voluminous ຂ້ອນຂ້າງ, ແຕ່ພວກເຮົາຫວັງວ່າມັນຍັງບໍ່ໄດ້ຢຸດເຊົາທີ່ຈະອ່ານໄດ້

ມັນເປັນມູນຄ່າທີ່ຈະກ່າວເຖິງແຍກຕ່າງຫາກກ່ຽວກັບການຝຶກອົບຮົມຂອງລູກຄ້າພາຍໃນຂອງພວກເຮົາ: ຜູ້ຊ່ຽວຊານດ້ານຜະລິດຕະພັນແລະຜູ້ອອກແບບ UX. ຄູ່ມືທີ່ມີຕົວຢ່າງການວິເຄາະແລະຄໍາແນະນໍາສໍາລັບການເຮັດວຽກກັບການກັ່ນຕອງໄດ້ຖືກກະກຽມເປັນພິເສດສໍາລັບພວກເຂົາ. ພວກເຮົາໄດ້ໃສ່ລິ້ງໄປຫາຄູ່ມືໂດຍກົງເຂົ້າໃນໜ້າລາຍງານ.

ພວກເຮົາສ້າງຄູ່ມືແບບງ່າຍໆເປັນການນຳສະເໜີໃນ Google Docs. ເຄື່ອງມື Tableau ຊ່ວຍໃຫ້ທ່ານສາມາດສະແດງຫນ້າເວັບໂດຍກົງພາຍໃນປື້ມບັນທຶກລາຍງານ.

ແທນທີ່ຈະເປັນຄໍາຕອບ

ແມ່ນຫຍັງຢູ່ໃນເສັ້ນທາງລຸ່ມ? ພວກເຮົາສາມາດໄດ້ຮັບເຄື່ອງມືສໍາລັບທຸກໆມື້ຂ້ອນຂ້າງໄວແລະລາຄາຖືກ. ແມ່ນແລ້ວ, ນີ້ບໍ່ແມ່ນການທົດແທນຢ່າງແນ່ນອນສໍາລັບກາຟຕົວມັນເອງ, ແຜນທີ່ຄວາມຮ້ອນຂອງການຄລິກຫຼືຕົວເບິ່ງເວັບ. ແຕ່ບົດລາຍງານດັ່ງກ່າວໄດ້ເສີມສ້າງເຄື່ອງມືທີ່ລະບຸໄວ້ຢ່າງຫຼວງຫຼາຍແລະສະຫນອງອາຫານສໍາລັບຄວາມຄິດແລະຜະລິດຕະພັນໃຫມ່ແລະສົມມຸດຕິຖານການໂຕ້ຕອບ.

ເລື່ອງນີ້ໄດ້ຮັບໃຊ້ພຽງແຕ່ເປັນການເລີ່ມຕົ້ນສໍາລັບການພັດທະນາການວິເຄາະໃນລະບົບ ISP. ໃນໄລຍະຫົກເດືອນທີ່ຜ່ານມາ, ເຈັດບໍລິການໃຫມ່ໄດ້ປະກົດຕົວ, ລວມທັງຮູບຄົນດິຈິຕອນຂອງຜູ້ໃຊ້ໃນຜະລິດຕະພັນແລະການບໍລິການສ້າງຖານຂໍ້ມູນສໍາລັບການກໍານົດເປົ້າຫມາຍທີ່ມີລັກສະນະຄ້າຍຄືກັນ, ແຕ່ພວກເຮົາຈະເວົ້າກ່ຽວກັບພວກມັນໃນຕອນຕໍ່ໄປນີ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com