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

> ที่มา: https://phygital.co.th/insights/what-is-developer-advertising-agency · เผยแพร่ 26 ตุลาคม 2563 · อ่าน 17 นาที · โดย PARANATH PANARATANA

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

## Key Takeaways

- **งานของนักพัฒนาในเอเจนซีวัดกันที่ระบบเก็บข้อมูลถูกต้องหรือไม่ ไม่ใช่ที่หน้าเว็บสวยแค่ไหน** — เว็บแคมเปญที่สวยแต่ส่งข้อมูลการซื้อไปนับซ้ำสองรอบ เท่ากับส่งตัวเลขที่ผิดให้คนอนุมัติงบใช้ตัดสินใจต่อทุกครั้ง
- **การติดตั้งวัดผลทั้งฝั่งเบราว์เซอร์และฝั่งเซิร์ฟเวอร์พร้อมกันต้องกำหนดรหัสเหตุการณ์ให้ตรงกัน** — เอกสารของ Meta ระบุว่าระบบจะรวมเหตุการณ์ซ้ำเป็นครั้งเดียวเมื่อรหัสเหตุการณ์และชื่อเหตุการณ์ตรงกัน และเหตุการณ์ที่สองมาถึงภายใน 48 ชั่วโมง
- **เกณฑ์ความเร็วเว็บมีตัวเลขทางการให้ยึด ไม่ต้องเถียงกันด้วยความรู้สึก** — เอกสาร Core Web Vitals ของ Google กำหนดระดับที่ถือว่าดีไว้ที่ LCP ไม่เกิน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 โดยวัดที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชม

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

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

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

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

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

ฝั่งที่สามถูกมองข้ามมากที่สุด เพราะไม่มีหน้าจอให้ดูและไม่มีใครเห็นตอนพลาด ระบบสมาชิกที่ผูกกับการแลกของรางวัลเป็นตัวอย่างที่ทั้งสามฝั่งต้องออกแบบพร้อมกัน อ่านต่อได้ใน[บริการ Web3 Loyalty แต้มสะสมดิจิทัลที่ไม่ใช่โทเคนซื้อขาย](https://phygital.co.th/insights/web3-loyalty-tokenized-rewards-agency)

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

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

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

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

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

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

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

---

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

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

[เอกสารเรื่องการจัดการเหตุการณ์ซ้ำของ Meta](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/) อธิบายวิธีที่ระบบใช้ตัดสินว่าสองเหตุการณ์คือเหตุการณ์เดียวกันไว้สองวิธี

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

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

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

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

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

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

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

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

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

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

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

---

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

ระบบการตลาดเกือบทุกแบบเก็บข้อมูลส่วนบุคคล ตั้งแต่ชื่อกับเบอร์โทรในหน้าลงทะเบียน ไปจนถึงพฤติกรรมการกดที่ผูกกับตัวระบุอุปกรณ์ [พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562](https://ratchakitcha.soc.go.th/documents/17082307.pdf) มาตรา 19 กำหนดเงื่อนไขของการขอความยินยอมไว้ และเงื่อนไขเหล่านั้นแปลเป็นข้อกำหนดของระบบได้โดยตรง

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

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

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

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

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

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

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

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

ข้อสุดท้ายคือเหตุผลที่งานสายนี้ต้องเข้าใจเป้าหมายการตลาด ไม่ใช่รับสเปกมาทำตาม แชทบอตที่ต้องส่งยอดสมัครกลับไปให้ระบบโฆษณานับผลเป็นตัวอย่างที่เห็นชัด อ่านต่อได้ใน[Chatbot ยิมและฟิตเนส ส่งยอดสมัครจากแชทกลับไปวัดผลโฆษณา](https://phygital.co.th/insights/chatbot-gym-fitness-class-booking-agency)

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

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

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

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

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

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

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

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

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

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

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

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

สัญญาณที่บอกว่าถึงเวลาต้องมีผู้ดูแลด้านเทคนิคประจำ คือเมื่อระบบเริ่มเก็บเงินหรือเก็บข้อมูลอ่อนไหวเอง เมื่อการเชื่อมต่อกับบริการภายนอกเกินสามจุด หรือเมื่อรายงานจากเครื่องมือต่างชุดเริ่มให้ตัวเลขที่ไม่ตรงกันโดยไม่มีใครในทีมอธิบายได้ ธุรกิจที่เริ่มขยายไปยังช่องทางการสั่งซื้อรูปแบบใหม่ก็เข้าเงื่อนไขนี้เช่นกัน อ่านต่อได้ใน[Voice Commerce และ Voice Search ภาษาไทย ข้อจำกัดของแพลตฟอร์ม](https://phygital.co.th/insights/voice-commerce-voice-search-optimization-agency)

## สรุป

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

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

### สัญญาจ้างพัฒนาระบบต้องเขียนเรื่องอะไรไว้ให้ครบ

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

### เว็บสำเร็จรูปกับการพัฒนาขึ้นใหม่ควรเลือกอย่างไร

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

### ใช้ปัญญาประดิษฐ์เขียนโค้ดแทนคนได้มากน้อยเพียงใด

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

### ระบบที่พัฒนาเสร็จแล้วต้องมีค่าดูแลต่อเนื่องหรือไม่

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

### ทำไมระบบที่ทดสอบผ่านแล้วยังพังตอนเปิดใช้จริง

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

### ธุรกิจที่มีเว็บอยู่แล้วควรวัดอะไรก่อนตัดสินใจทำใหม่

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

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

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

- [นัดประชุมผ่าน Google Meet](https://calendar.app.google/DotQdE7Ca8LZG6Us5)
- [เพิ่มเพื่อนใน LINE](https://lin.ee/J8Qq8Do)