วิธีการตัดสินใจว่าจะติดตามเหตุการณ์ใด?

นี่เป็นส่วนที่ห้าของชุด ข้อมูลลูกค้า ห้า ส่วน นี่ คือ ส่วน ที่ หนึ่ง สอง สาม และ สี่

เริ่มต้นด้วยการถามคำถาม

ในการตัดสินใจว่าจะติดตามเหตุการณ์ใดและรวบรวมข้อมูลใด คุณต้องระบุคำถามที่คุณมีเกี่ยวกับผู้ใช้และการใช้งานผลิตภัณฑ์ของพวกเขา

คุณจะรู้ว่ามีหลายสิ่งหลายอย่างที่คุณอยากรู้เมื่อคุณเริ่มเขียนคำถามของคุณลงไป คำถามทำให้เกิดคำถามมากขึ้น และเมื่อเป็นเช่นนั้น คุณอาจต้องการคำตอบทั้งหมดในคราวเดียว เนื่องจากกระบวนการนี้ทำให้คนส่วนใหญ่รู้สึกอย่างไร ให้อ้างอิงคำถามเหล่านี้เป็นคำถามที่ เผาไหม้

หากคุณไม่รู้สึกเช่นนั้น แสดงว่าคุณอาจไม่อยากรู้อะไรมากหรือมีความเชื่อมั่นอย่างแรงกล้าในสมมติฐานของคุณ อย่างไรก็ตาม อย่าปล่อยให้สิ่งนั้นรั้งคุณไว้จากการถามคำถาม คุณอาจจะประหลาดใจหรือผิดหวังอย่างยิ่งเมื่อพบคำตอบ

การถามคำถามเกี่ยวกับข้อมูลจะง่ายกว่ามากเมื่อคุณแสดงข้อมูลเป็นภาพได้—แต่อาจส่งผลตรงกันข้ามหากคุณสร้างรายงานหรือแสดงข้อมูลเป็นภาพโดยไม่ถาม คำถามก่อน

คำถามสุดแสบ

คำถามที่เผาไหม้อาจตรงไปตรงมาเช่น "มีผู้ใช้ลงทะเบียนในช่วง 7 วันที่ผ่านมากี่คน" หรือซับซ้อนเช่น “มีผู้ใช้ จากอุตสาหกรรม SaaS ลงทะเบียนในช่วง 7 วันที่ผ่านมาและ เชิญผู้ใช้รายอื่นเข้าร่วม องค์กรของพวกเขากี่คน”

เมื่อนึกถึงคำถามที่เขียนลวกๆ ให้เริ่มเขียนการกระทำต่อไปนี้:

• การดำเนินการที่ผู้ใช้ต้องทำเพื่อเข้าถึงช่วงเวลา aha (เหตุการณ์การเปิดใช้งาน)
• การดำเนินการที่ระบุว่าผู้ใช้พร้อมที่จะทำการซื้อหรืออัปเกรดบัญชี
• การกระทำที่กระตุ้นการมีส่วนร่วมของผู้ใช้และรักษาผู้ใช้ไว้
• การกระทำที่ส่งสัญญาณว่าผู้ใช้ได้รับคุณค่าจากผลิตภัณฑ์ไม่เพียงพอ
• การกระทำที่อาจนำไปสู่การเลิกรา

นอกจากนี้ยังเป็นเวลาที่ดีที่จะเริ่มตั้งคำถามเกี่ยวกับประสบการณ์ของผลิตภัณฑ์และพิจารณาข้อเสนอหลักของคุณ คำถามต่อไปนี้ใช้ได้กับผลิตภัณฑ์เทคโนโลยีส่วนใหญ่:

• เวลาที่มีคุณค่าหรือผู้ใช้ใช้เวลานานเท่าใดในการเข้าถึงช่วงเวลา aha?
• เส้นทางต่างๆ ที่ผู้ใช้ใช้หลังจากสมัครใช้งานมีอะไรบ้าง?
• อะไรคือจุดเสียดสีในการเดินทางของผู้ใช้?
• คุณลักษณะใดที่ผู้ใช้ที่ใช้งานอยู่ใช้มากที่สุด?
• ฟีเจอร์ที่ใช้น้อยที่สุดโดยผู้ใช้ที่ชำระเงินคืออะไร
• คุณลักษณะใดที่นำไปสู่การแปลงผู้ใช้ฟรีเป็นผู้ใช้ที่ชำระเงิน

คุณสมบัติเหตุการณ์และเหตุการณ์

เมื่อคุณมีรายการคำถามที่น่าสนใจแล้ว (ระหว่าง 5 ถึง 10 เป็นตัวเลขที่ดีในการเริ่มต้น) คุณสามารถไปยังขั้นตอนที่สำคัญที่สุด นั่นคือการกำหนดเหตุการณ์และคุณสมบัติของเหตุการณ์

นี่คือที่ที่คุณเริ่มสร้างแผนการติดตามข้อมูลในที่สุด

นอกจากเหตุการณ์หลักแล้ว คุณควรเริ่มคิดถึงข้อมูลต่างๆ ที่คุณต้องการรวบรวมเมื่อมีเหตุการณ์ใดเกิดขึ้น คู่มือนี้มีตัวอย่างเหตุการณ์ทั่วไปและคุณสมบัติที่เกี่ยวข้อง ซึ่งจะให้บริบทเกี่ยวกับวิธีการคิดเกี่ยวกับกระบวนการนี้

มีบางสิ่งเพิ่มเติมด้านล่างที่คุณต้องรู้ก่อนที่คุณจะเริ่มสร้างแผนการติดตาม

การคลิก มุมมอง และกระบวนการ

สิ่งสำคัญคือต้องคำนึงถึงความแตกต่างระหว่างการคลิก การดู และกระบวนการที่เกิดขึ้นภายในผลิตภัณฑ์ของคุณ—ทุกปุ่มที่คลิก หน้าที่ดู หรือกระบวนการที่เสร็จสมบูรณ์สามารถติดตามเป็นเหตุการณ์ที่ไม่ซ้ำกันได้

นอกจากนี้ ในบางกรณี สามารถติดตามกิจกรรมเป็นแบบใดแบบหนึ่งจากสามแบบ ได้แก่ การดูหน้าเว็บ การคลิกปุ่ม หรือกระบวนการที่เสร็จสิ้น

ลองมาดูอย่างใกล้ชิดโดยใช้ขั้นตอนการลงชื่อสมัครใช้ตามสมมุติฐาน:

ขั้นแรก ผู้ใช้คลิก ที่นี่ กิจกรรมที่ดำเนินการสามารถติดตามได้ด้วยการคลิกปุ่ม (ปุ่มลงทะเบียนที่หน้าแรก) หรือดูหน้า (หน้าลงทะเบียน)

ถัดไป ผู้ใช้กรอกแบบฟอร์มลงทะเบียน คลิก หากทุกอย่างเป็นไปด้วยดี การส่งไปยังฐานข้อมูลและแถวใหม่จะถูกสร้างขึ้น

ที่นี่ สามารถติดตามกิจกรรมที่ดำเนินการได้ด้วยการคลิกปุ่ม (ปุ่มส่ง) การดูหน้าเว็บ (หน้าขอบคุณ) หรือกระบวนการที่เสร็จสิ้น (แถวใหม่ในฐานข้อมูล)

ดังนั้น วิธีที่คุณเลือกติดตามเหตุการณ์ทั้งหมดขึ้นอยู่กับกรณีการใช้งานของคุณ และบางครั้ง การติดตามการคลิกปุ่มรวมถึงการดูหน้าเว็บหรือการดำเนินการที่เสร็จสิ้นพร้อมกันอาจเป็นเรื่องที่สมเหตุสมผลในบางครั้ง

and sign up ที่กล่าวว่า หากวัตถุประสงค์ของคุณคือการทำความเข้าใจพฤติกรรมของผู้ใช้ คุณควรหลีกเลี่ยงความซ้ำซ้อนของเหตุการณ์โดยตรวจสอบให้แน่ใจว่าไม่มีการติดตามการกระทำของผู้ใช้หลายครั้ง ( คลิกปุ่ม ลงทะเบียน และ ลงชื่อสมัครใช้ หน้าที่ดู

. ในการติดตามการดูหน้าเว็บ คุณอาจระบุเหตุการณ์ที่ไม่ซ้ำกันสำหรับแต่ละเพจ เช่น ลงทะเบียน ที่ อย่างไรก็ตาม นั่นจะทำให้รายการกิจกรรมของคุณยาวเหยียดเมื่อคุณต้องการติดตามการดูหน้าเว็บสำหรับหน้าที่ไม่ซ้ำกันทุกหน้า

แทนที่จะกำหนดเหตุการณ์แยกกันสำหรับแต่ละหน้า คุณสามารถระบุเหตุการณ์ทั่วไปที่เรียกว่า หน้าที่ดู ด้วยคุณสมบัติของเหตุการณ์ดังนี้:

คลิกปุ่มแล้ว

เช่นเดียวกับการดูหน้าเว็บ การคลิกปุ่มควรได้รับการติดตามผ่านเหตุการณ์ทั่วไป เช่น การ คลิกปุ่ม ที่มีคุณสมบัติที่เกี่ยวข้องดังนี้:

เสร็จสิ้นกระบวนการ

กระบวนการเกิดขึ้นจากการโต้ตอบกับฐานข้อมูลที่มีการเขียนข้อมูล (ในตารางเฉพาะ) หรือดึงข้อมูล (จากตาราง)—หากการโต้ตอบล้มเหลว กระบวนการก็จะล้มเหลว

ดังนั้น การติดตามความสมบูรณ์ของกระบวนการจึงเป็นวิธีที่น่าเชื่อถือที่สุดในการติดตามเหตุการณ์ที่ต้องอาศัยความสมบูรณ์ของการโต้ตอบกับฐานข้อมูล

นี่เป็นสถานการณ์ที่ธรรมดาเกินไป:

ผู้ใช้คลิกปุ่มส่งหลังจากกรอกแบบฟอร์มลงทะเบียนเท่านั้นเพื่อให้แสดงข้อผิดพลาดในการตรวจสอบความถูกต้อง เช่น "รหัสผ่านต้องมีอักขระพิเศษ" ที่นี่ ผู้ใช้ดำเนินการเหตุการณ์ที่ ปุ่ม Clicked แต่จริง ๆ แล้วไม่ได้ทำขั้นตอนการลงทะเบียนให้เสร็จสิ้น

ในทำนองเดียวกัน หากผู้ใช้คลิกปุ่มส่งแต่เกิดข้อผิดพลาดฝั่งเซิร์ฟเวอร์ กระบวนการก็จะล้มเหลวและข้อมูลผู้ใช้ไม่ได้ส่งไปยังฐานข้อมูล ดังนั้นแม้ว่าผู้ใช้ส่งแบบฟอร์มลงทะเบียนเรียบร้อยแล้ว กระบวนการลงทะเบียนก็ยังไม่สมบูรณ์

ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องนึกถึงกระบวนการทั้งหมด (หรือการโต้ตอบของฐานข้อมูล) ที่ควรจะเสร็จสมบูรณ์เมื่อมีเหตุการณ์เกิดขึ้น

นอกจากนี้ คุณต้องทราบด้วยว่าผู้ใช้ลงชื่อสมัครใช้ผลิตภัณฑ์ของคุณแต่ไม่ยืนยันที่อยู่อีเมลของพวกเขา วิธีหนึ่งในการทำเช่นนี้คือการตรวจสอบว่าผู้ใช้เข้าสู่ระบบหลังจากลงทะเบียนหรือไม่ (ซึ่งสามารถเกิดขึ้นได้หลังจากยืนยันอีเมลแล้วเท่านั้น) แต่อาจมีผู้ใช้ที่ยืนยันอีเมลแต่ไม่เคยเข้าสู่ระบบ

ดังนั้น แนวทางที่ดีกว่าอาจเป็นการติดตาม 2 เหตุการณ์ที่แยกจากกัน— ลง ทะเบียนแล้ว (ขั้นตอนการลงทะเบียนเสร็จสมบูรณ์) และ นอกจากนี้ยังจะบอกคุณว่ามีผู้ลงทะเบียนกี่คนแต่ไม่ยืนยันอีเมลของพวกเขา ทำให้คุณสามารถส่งอีเมลยืนยันอีกครั้งหลังจากผ่านไปหนึ่งหรือสองวัน

เหตุการณ์ฝั่งไคลเอ็นต์กับเหตุการณ์ฝั่งเซิร์ฟเวอร์

เหตุการณ์ เช่น การคลิกและมุมมองที่ไม่ขึ้นอยู่กับการโต้ตอบของฐานข้อมูล (หรือกระบวนการแบ็คเอนด์) เป็นเหตุการณ์ฝั่งไคลเอ็นต์

เหตุการณ์ฝั่งไคลเอ็นต์เกิดขึ้นเฉพาะบนไคลเอ็นต์ (หรืออุปกรณ์ของผู้ใช้) และเรียกอีกอย่างว่าเหตุการณ์ส่วนหน้า

ในทางกลับกัน เหตุการณ์ที่ใช้กระบวนการแบ็กเอนด์จะเรียกว่าเหตุการณ์ฝั่งเซิร์ฟเวอร์ ตามชื่อที่แนะนำ เหตุการณ์ฝั่งเซิร์ฟเวอร์เกิดขึ้นบนเซิร์ฟเวอร์เมื่อการโต้ตอบกับฐานข้อมูลเสร็จสมบูรณ์

เหตุการณ์ฝั่งเซิร์ฟเวอร์ยังเรียกว่าเหตุการณ์แบ็กเอนด์

การทราบความแตกต่างระหว่างเหตุการณ์ฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์จะช่วยในกระบวนการวัดเนื่องจากเหตุการณ์สองประเภทมักจะถูกนำไปใช้โดยบุคคลที่แตกต่างกันในองค์กร

การระบุแหล่งที่มาของเหตุการณ์ในแผนการติดตามจะเป็นประโยชน์เสมอ แม้ว่านักพัฒนาฟูลสแต็กจะได้รับมอบหมายให้ใช้งานเหตุการณ์ทั้งสองประเภท

ขั้นตอนต่อไปในการติดตามกิจกรรม

สิ่งนี้นำเราไปสู่จุดสิ้นสุดของชุดข้อมูลลูกค้าห้าส่วน หากต้องการเริ่มติดตามกิจกรรมของคุณวันนี้ ให้เริ่มต้นด้วยบัญชี Amplitude ฟรี