ข้ามไปเนื้อหาหลัก

Developer ใน​เอ​เจน​ซี: ผู้​วาง​ระบบ​ที่​ทำให้​วัดผล​ได้​จริง

อัปเดตล่าสุด 27 กันยายน 2569
เวลาอ่านประมาณ 17 นาที
Developer ใน​เอ​เจน​ซี: ผู้​วาง​ระบบ​ที่​ทำให้​วัดผล​ได้​จริง

KEY TAKEAWAYS

3 ประเด็น

งาน​ของ​นัก​พัฒนา​ใน​เอ​เจน​ซี​วัด​กัน​ที่​ระบบ​เก็บ​ข้อมูล​ถูก​ต้อง​หรือ​ไม่ ไม่ใช่​ที่​หน้า​เว็บ​สวย​แค่​ไหน

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

การ​ติด​ตั้ง​วัดผล​ทั้ง​ฝั่ง​เบราว์เซอร์​และ​ฝั่ง​เซิร์ฟเวอร์​พร้อม​กัน​ต้อง​กำหนด​รหัส​เหตุการณ์​ให้​ตรง​กัน

เอกสาร​ของ Meta ระบุ​ว่า​ระบบ​จะ​รวม​เหตุการณ์​ซ้ำ​เป็น​ครั้ง​เดียว​เมื่อ​รหัส​เหตุการณ์​และ​ชื่อ​เหตุการณ์​ตรง​กัน และ​เหตุการณ์​ที่​สอง​มา​ถึง​ภายใน 48 ชั่วโมง

เกณฑ์​ความเร็ว​เว็บ​มี​ตัวเลข​ทางการ​ให้​ยึด ไม่​ต้อง​เถียง​กัน​ด้วย​ความ​รู้สึก

เอกสาร Core Web Vitals ของ Google กำหนด​ระดับ​ที่​ถือว่า​ดี​ไว้​ที่ LCP ไม่​เกิน 2.5 วินาที INP ไม่​เกิน 200 มิลลิ​วินาที และ CLS ไม่​เกิน 0.1 โดย​วัด​ที่​เปอร์​เซ็น​ไทล์​ที่ 75 ของ​การ​เข้า​ชม

Developer ใน​เอ​เจน​ซี​โฆษณา​รับ​ผิด​ชอบ​อะไร ระบบ​วัดผล​ที่​ติด​ซ้อน​สอง​ทาง​ทำให้​ตัวเลข​เพี้ยน​ได้​อย่างไร และ​เกณฑ์​ความเร็ว​เว็บ​ที่​มี​ตัวเลข​กำกับ​จริง​คือ​อะไร

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

Developer ใน​เอ​เจน​ซี​คือ​ผู้รับ​ผิด​ชอบ​การ​เปลี่ยน​แผน​แคมเปญ​ให้​กลาย​เป็น​ระบบ​ที่​เปิด​ใช้​งาน​ได้​จริง ตั้งแต่​หน้า​เว็บ​ที่​ผู้​ใช้​กรอก​ข้อมูล ระบบ​หลัง​บ้าน​ที่​เก็บ​รายการ​สั่ง​ซื้อ ไป​จนถึง​ชุด​โค้ด​ที่​ส่ง​เหตุการณ์​การ​ซื้อ​กลับ​ไป​ยัง​แพลตฟอร์ม​โฆษณา บริษัท ฟิจิ⁠ทัล เอ​เจน​ซี จำกัด (PHYGITAL AGENCY) จัด​ให้​ตำแหน่ง​นี้​เข้า​ร่วม​ตั้งแต่​ขั้น​วางแผน ไม่ใช่​รับ​งาน​ต่อ​เมื่อ​แบบ​เสร็จ​แล้ว

Developer ใน​เอ​เจน​ซี​รับ​ผิด​ชอบ​อะไร

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

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

ฝั่ง​ที่​สาม​ถูก​มอง​ข้าม​มาก​ที่สุด เพราะ​ไม่มี​หน้า​จอ​ให้​ดู​และ​ไม่มี​ใคร​เห็น​ตอน​พลาด ระบบ​สมาชิก​ที่​ผูก​กับ​การ​แลก​ของ​รางวัล​เป็น​ตัวอย่าง​ที่​ทั้ง​สาม​ฝั่ง​ต้อง​ออกแบบ​พร้อม​กัน อ่าน​ต่อ​ได้​ในบริการ Web3 Loyalty แต้ม​สะสม​ดิจิทัล​ที่​ไม่ใช่​โท​เคน​ซื้อ​ขาย

ทีม​เล็ก​ควร​จ้าง​นัก​พัฒนา​ที่​ทำได้​ทุก​ฝั่ง​หรือ​แยก​คน

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

งาน​พัฒนา​หนึ่ง​ชิ้น​เดิน​อย่างไร​จาก​โจทย์​ถึง​ระบบ​ที่​เปิด​ใช้​จริง

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

  1. แปลง​โจทย์​การ​ตลาด​เป็น​รายการ​สิ่ง​ที่​ระบบ​ต้อง​ทำได้ ระบุ​ให้​ชัด​ว่า​ผู้​ใช้​ต้อง​ทำ​อะไร​ได้ ข้อมูล​อะไร​ต้อง​ถูก​เก็บ และ​ใคร​จะ​เอา​ข้อมูล​นั้น​ไป​ใช้​ต่อ ขั้น​นี้​ตัดสิน​ขนาด​ของ​งาน​ทั้งหมด
  2. เลือก​โครงสร้าง​ให้​ตรง​กับ​อายุ​การ​ใช้​งาน​ของ​แคมเปญ เว็บ​แคมเปญ​ที่​ใช้​สาม​เดือน​กับ​ระบบ​สมาชิก​ที่​ต้อง​อยู่​หลาย​ปี ควร​เลือก​วิธี​ทำ​คนละ​แบบ​ตั้งแต่​ต้น
  3. กำหนด​ชุด​เหตุการณ์​ที่​จะ​วัด​ก่อน​เริ่ม​เขียน​หน้า​จอ ทั้ง​ชื่อ​เหตุการณ์ ข้อมูล​ที่​แนบ​ไป​ด้วย และ​วิธี​สร้าง​รหัส​กัน​นับ​ซ้ำ การ​ทำ​ทีหลัง​มักได้​ข้อมูล​ที่​เทียบ​กับ​ช่วง​ก่อน​หน้า​ไม่​ได้
  4. สร้าง​ระบบ​แล้ว​ทดสอบ​ด้วย​ข้อมูล​จริง​ใน​บัญชี​ทดสอบ ไม่ใช่​ทดสอบ​ด้วย​การ​กด​ดู​ว่า​หน้า​จอ​ขึ้น​หรือ​ไม่ แต่​ตรวจ​ว่า​เหตุการณ์​ไป​ถึง​ปลาย​ทาง​ครบ​และ​ไม่​ซ้ำ
  5. ทดสอบ​ภาย​ใต้​ปริมาณ​การ​เข้า​ชม​ที่​คาด​ว่า​จะ​เกิด​จริง ระบบ​ที่​ทำงาน​ดี​กับ​ผู้​ใช้​สิบ​คน​ไม่​ได้​บอก​อะไร​เลย​เกี่ยว​กับ​วัน​ที่​มี​คน​เข้า​พร้อม​กัน​หลัก​พัน และ​วัน​นั้น​คือ​วัน​ที่​ซื้อ​สื่อ​ไว้​แล้ว
  6. ส่ง​มอบ​พร้อม​สิ่ง​ที่​ทำให้​ดูแล​ต่อ​ได้ รวม​ถึง​สิทธิ์​เข้า​ถึง​เซิร์ฟเวอร์​และ​โดเมน รายการ​ที่​ระบบ​เชื่อม​ต่อ​อยู่ และ​เอกสาร​ว่า​เหตุการณ์​แต่ละ​ตัว​ถูก​ยิง​จาก​จุด​ไหน​ใน​โค้ด

ทำไม​ต้อง​กำหนด​ชุด​เหตุการณ์​ก่อน​เริ่ม​เขียน​หน้า​จอ

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


ตัวเลข​ที่​ระบบ​เก็บ​มา​เชื่อ​ได้​แค่​ไหน​เมื่อ​ติด​ตั้ง​ซ้อน​สอง​ทาง

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

เอกสาร​เรื่อง​การ​จัดการ​เหตุการณ์​ซ้ำ​ของ Meta อธิบาย​วิธี​ที่​ระบบ​ใช้​ตัดสิน​ว่า​สอง​เหตุการณ์​คือ​เหตุการณ์​เดียวกัน​ไว้​สอง​วิธี

  • วิธี​ที่​เอกสาร​แนะนำ คือ​ให้​ค่า eventID ที่​ยิง​จาก​ฝั่ง​เบราว์เซอร์​ตรง​กับ​ค่า event_id ที่​ส่ง​จาก​ฝั่ง​เซิร์ฟเวอร์ และ​ให้​ชื่อ​เหตุการณ์​ทั้ง​สอง​ฝั่ง​ตรง​กัน​ด้วย
  • วิธี​สำรอง คือ​เทียบ​ชื่อ​เหตุการณ์​คู่​กับ​ตัว​ระบุ​ผู้​ใช้​อย่าง fbp หรือ external_id

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

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

จะ​รู้​ได้​อย่างไร​ว่าย​อด​ที่​รายงาน​ถูก​นับ​ซ้ำ

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

เกณฑ์​ความเร็ว​เว็บ​ที่​มี​ตัวเลข​ทางการ​กำกับ

การ​ถก​เรื่อง​ความเร็ว​เว็บ​มัก​จบ​ลง​ด้วย​ความ​รู้สึก​ของ​คนใน​ห้อง​ประชุม ทั้ง​ที่ Google ประกาศ​เกณฑ์​ที่​ใช้​ตัดสิน​ไว้​เป็น​ตัวเลข​ชัดเจน เอกสาร Core Web Vitals ระบุ​ระดับ​ที่​ถือว่า​ดี​ของ​ตัว​วัด​สาม​ตัว คือ Largest Contentful Paint ไม่​เกิน 2.5 วินาที Interaction to Next Paint ไม่​เกิน 200 มิลลิ​วินาที และ Cumulative Layout Shift ไม่​เกิน 0.1

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

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

ควร​แก้ตัว​วัด​ตัว​ไหน​ก่อน​เมื่อ​มี​เวลา​จำกัด

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


ระบบ​ที่​เก็บ​ข้อมูล​ลูกค้า​ต้อง​รองรับ​อะไร​ตาม​กฎหมาย​ไทย

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

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

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

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

ระบบ​ที่​ทำงาน​อยู่​แล้ว​ต้อง​รื้อ​ใหม่​ทั้งหมด​หรือ​ไม่

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

นัก​พัฒนา​สาย​เอ​เจน​ซี​ทำงาน​ต่าง​จาก​สาย​ซอฟต์แวร์​องค์กร​อย่างไร

ทั้ง​สอง​สาย​ใช้​เครื่อง​มือ​ชุด​เดียวกัน แต่​เงื่อนไข​ของ​งาน​ต่าง​กัน​สี่​เรื่อง และ​ความ​ต่าง​เหล่า​นี้​คือ​เหตุผล​ที่​คน​ย้าย​สาย​แล้ว​รู้สึก​ว่า​เป็น​งาน​อีก​อาชีพ

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

ข้อ​สุดท้าย​คือ​เหตุผล​ที่​งาน​สาย​นี้​ต้อง​เข้าใจ​เป้า​หมาย​การ​ตลาด ไม่ใช่​รับ​สเปก​มา​ทำ​ตาม แช​ทบ​อต​ที่​ต้อง​ส่ง​ยอด​สมัคร​กลับ​ไป​ให้​ระบบ​โฆษณา​นับ​ผล​เป็น​ตัวอย่าง​ที่​เห็น​ชัด อ่าน​ต่อ​ได้​ในChatbot ยิม​และ​ฟิตเนส ส่ง​ยอด​สมัคร​จาก​แช​ทก​ลับ​ไป​วัดผล​โฆษณา

อยาก​เข้า​สาย​นี้​ควร​เตรียม​อะไร​นอกจาก​ทักษะ​เขียน​โค้ด

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

รายการ​ที่​ผู้​ว่า​จ้าง​ตรวจ​เอง​ได้​ก่อน​รับ​มอบ​ระบบ

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

  1. เปิด​ใช้​งาน​จริง​บน​โทรศัพท์​ของ​ตัว​เอง​ทุก​ขั้น​ตอน​จน​จบ ตั้งแต่​หน้า​แรก​จนถึง​หน้า​ยืนยัน โดย​ใช้​อินเทอร์เน็ต​มือ​ถือ​ไม่ใช่​ไวไฟ​ใน​สำนักงาน เพราะ​ผู้​ใช้​ส่วน​ใหญ่​อยู่​ใน​เงื่อนไข​แบบ​นั้น
  2. ตรวจ​ว่า​ข้อมูล​ที่​กรอก​ไป​โผล่​ใน​ที่​ที่​ควร​โผล่ ทั้ง​ใน​ระบบ​หลัง​บ้าน ใน​อีเมล​แจ้ง​เตือน และ​ใน​รายงาน​ของ​เครื่อง​มือ​วิเคราะห์ การ​หาย​ไป​หนึ่ง​ใน​สาม​ที่​คือ​อาการ​ของ​การ​เชื่อม​ต่อ​ที่​ยัง​ไม่​ครบ
  3. กด​ส่ง​ซ้ำ​และ​กด​ย้อน​กลับ​แล้ว​ส่ง​อีก​ครั้ง เพื่อ​ดู​ว่า​ระบบ​สร้าง​รายการ​ซ้ำ​หรือ​ไม่ นี่​คือ​พฤติกรรม​ที่​ผู้​ใช้​จริง​ทำ​ตลอด​เวลา​และ​เป็น​สาเหตุ​อันดับ​ต้น​ของ​ข้อมูล​ซ้ำ​ใน​ฐาน​ข้อมูล
  4. ขอ​ดู​รายการ​สิ่ง​ที่​ระบบ​เชื่อม​ต่อ​อยู่ ทั้ง​บริการ​ภายนอก คีย์​ที่​ใช้ และ​ผู้​ถือ​สิทธิ์​เข้า​ถึง​บัญชี​เหล่า​นั้น ข้อ​นี้​มี​ผล​เมื่อ​ต้อง​เปลี่ยน​ผู้​ดูแล
  5. ขอ​สิทธิ์​เข้า​ถึง​โดเมน​และ​ที่​เก็บ​โค้ด​ใน​ชื่อ​ของ​ธุรกิจ​เอง ไม่ใช่​ใน​ชื่อ​ผู้​พัฒนา เรื่อง​นี้​จัดการ​ตอน​ส่ง​มอบ​ง่าย​กว่า​ตอน​ความ​สัมพันธ์​จบ​ลง​แล้ว​หลาย​เท่า
  6. ขอ​เอกสาร​ว่า​เหตุการณ์​วัดผล​แต่ละ​ตัว​ยิง​จาก​จุด​ไหน เพื่อ​ให้​ผู้​ดูแล​คน​ถัด​ไป​ตรวจ​ได้​ว่า​ตัวเลข​ใน​รายงาน​มา​จาก​การก​ระ​ทำ​แบบ​ใด

ข้อ​ที่​สาม​กับ​ข้อ​ที่​ห้า​ถูก​ข้าม​บ่อย​ที่สุด ข้อ​แรก​เพราะ​ดู​เหมือน​การ​จับผิด ข้อ​หลัง​เพราะ​ดู​เหมือน​เรื่อง​ธุรการ ทั้ง​ที่​ต้นทุน​ของ​การ​ละเลย​สูง​ที่สุด​ใน​รายการ​นี้

เรื่อง​ที่​การ​เขียน​โค้ด​แก้​ให้​ไม่​ได้

ห้า​ข้อ​นี้​ควร​พูด​กัน​ให้​ชัด​ตั้งแต่​ก่อน​เซ็น​สัญญา เพราะ​ไม่มี​วิธี​เขียน​โค้ด​แบบ​ใด​ทำให้​หาย​ไป​ได้

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

ยัง​ไม่มี​คน​ดูแล​ด้าน​เทคนิค ควร​ลงเงิน​กับ​อะไร​ก่อน

สาม​เรื่อง​นี้​ลงมือ​ได้​เลย​โดย​ยัง​ไม่​ต้อง​ตั้ง​งบ​ก้อน​ใหญ่ และ​ผล​ของ​มัน​บอก​ได้​ว่า​ควร​จ้าง​อะไร​เป็น​ลำดับ​ต่อ​ไป

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

สัญญาณ​ที่​บอก​ว่า​ถึง​เวลา​ต้อง​มี​ผู้​ดูแล​ด้าน​เทคนิค​ประจำ คือ​เมื่อ​ระบบ​เริ่ม​เก็บ​เงิน​หรือ​เก็บ​ข้อมูล​อ่อน​ไหว​เอง เมื่อ​การ​เชื่อม​ต่อ​กับ​บริการ​ภายนอก​เกิน​สาม​จุด หรือ​เมื่อ​รายงาน​จาก​เครื่อง​มือ​ต่าง​ชุด​เริ่ม​ให้​ตัวเลข​ที่​ไม่​ตรง​กัน​โดย​ไม่มี​ใคร​ใน​ทีม​อธิบาย​ได้ ธุรกิจ​ที่​เริ่ม​ขยาย​ไป​ยัง​ช่อง​ทางการ​สั่ง​ซื้อ​รูป​แบบ​ใหม่​ก็​เข้า​เงื่อนไข​นี้​เช่น​กัน อ่าน​ต่อ​ได้​ในVoice Commerce และ Voice Search ภาษา​ไทย ข้อ​จำกัด​ของ​แพลตฟอร์ม

สรุป

งาน​ของ​นัก​พัฒนา​ใน​เอ​เจน​ซี​วัดผล​กัน​ที่​ระบบ​ส่ง​ข้อมูล​ถูก​ต้อง​หรือ​ไม่ มากกว่า​ที่​หน้า​จอ​สวย​ตาม​แบบ​เพียง​ใด การ​ติด​ตั้ง​วัดผล​สอง​ทาง​พร้อม​กัน​ต้อง​ใช้​รหัส​เหตุการณ์​เดียวกัน​และ​ชื่อ​ที่​สะกด​ตรง​กัน โดย​เอกสาร​ของ​แพลตฟอร์ม​ระบุ​กรอบ​เวลา​รวม​เหตุการณ์​ซ้ำ​ไว้​ที่ 48 ชั่วโมง ฝั่ง​ความเร็ว​เว็บ​มี​เกณฑ์​ตัวเลข​ทางการ​ครบ​ทั้ง​สาม​ตัว​และ​วัด​ที่​เปอร์​เซ็น​ไทล์​ที่ 75 ไม่ใช่​ค่า​เฉลี่ย ส่วน​ระบบ​ที่​เก็บ​ข้อมูล​ลูกค้า​ต้อง​รองรับ​การ​ขอ​และ​ถอน​ความ​ยินยอม​ตาม​กฎหมาย​ตั้งแต่​ขั้น​วาง​โครงสร้าง และ​ก่อน​รับ​มอบ​ยัง​มี​รายการ​ที่​ผู้​ว่า​จ้าง​ตรวจ​เอง​ได้​อีก​ชุด

คำถามที่พบบ่อย (FAQ)

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

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

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

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

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

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

PHYGITAL INSIGHT

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

ให้ PHYGITAL AGENCY ช่วยต่อยอดเรื่องนี้สู่ผลลัพธ์จริง

ระบบ​ที่​บอก​ได้​ว่า​ทุก​ตัวเลข​ใน​รายงาน​มา​จาก​การก​ระ​ทำ​แบบ​ใด

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

PARANATH PANARATANA

WRITTEN BY

PARANATH PANARATANA

CHAIRMAN OF PHYGITAL AGENCY

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