# Server-Side Tracking คืออะไร ย้ายแท็กแล้วยังต้องขอความยินยอม

> ที่มา: https://phygital.co.th/insights/server-side-tracking-explained · เผยแพร่ 3 พฤษภาคม 2568 · อ่าน 11 นาที · โดย PARANATH PANARATANA

Server-Side Tracking ย้ายตัวรับข้อมูลไปไว้บนเซิร์ฟเวอร์ของธุรกิจ Google ประเมินค่าเครื่องราว 45 ดอลลาร์ต่อเดือน และความยินยอมยังต้องส่งมาจากหน้าเว็บ

## Key Takeaways

- **Server-side tagging ของ Google Tag Manager ย้ายการประมวลผลแท็กจากเบราว์เซอร์ของผู้ใช้ไปไว้บนเซิร์ฟเวอร์ที่ธุรกิจควบคุม** — ข้อมูลจากหน้าเว็บส่งเข้าเซิร์ฟเวอร์ก่อน แล้วเซิร์ฟเวอร์จึงส่งต่อไปยังเครื่องมือแต่ละตัว
- **คู่มือของ Google ประเมินค่าเซิร์ฟเวอร์บน Cloud Run ไว้ราว 45 ดอลลาร์ต่อเครื่องต่อเดือน และแนะนำให้รันอย่างน้อย 2 เครื่อง** — ค่า log อาจเพิ่มขึ้นมากเมื่อมีคำขอเกินหนึ่งล้านครั้งต่อเดือน
- **ความยินยอมต้องตั้งที่ web container บนหน้าเว็บ แล้วส่งไปกับคำขอถึงเซิร์ฟเวอร์** — เมื่อผู้ใช้ปฏิเสธ analytics_storage ระบบจะไม่เขียนหรืออ่านคุกกี้ของ Analytics ไม่ว่าในเครื่องของผู้ใช้หรือบนเซิร์ฟเวอร์ของธุรกิจ

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

ต้นทุนและขั้นตอนมาจากคู่มือ server-side tagging ของ Google สามหน้า คือ[หน้าแนะนำ server-side tagging](https://developers.google.com/tag-platform/tag-manager/server-side/intro) [คู่มือติดตั้งบน Cloud Run](https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide) และ[หน้าวิธีใช้ Consent Mode กับ server-side Tag Manager](https://developers.google.com/tag-platform/tag-manager/server-side/consent-mode) หน้าทั้งสามมีวันปรับปรุงเป็น 30 กรกฎาคม 2569 ส่วนการกันนับซ้ำมาจาก[เอกสารของ Meta เรื่องการลบข้อมูลซ้ำระหว่างพิกเซลกับ Conversions API](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/)

## ข้อมูลเดินทางอย่างไรเมื่อย้ายแท็กไปฝั่งเซิร์ฟเวอร์

ในการตั้งค่าแบบเดิม ซึ่งเรียกกันว่า client-side ตัว container ของ Tag Manager ทำงานอยู่ในเบราว์เซอร์ของผู้ใช้ แล้วแต่ละแท็กส่งข้อมูลตรงไปยังเซิร์ฟเวอร์ของเครื่องมือแต่ละตัว เช่น Google Analytics และแพลตฟอร์มโฆษณา เว็บที่ติดห้าเครื่องมือจึงให้เบราว์เซอร์ของผู้ใช้ส่งข้อมูลออกไปห้าทาง

เมื่อใช้ server-side tagging หน้าคู่มือของ Google อธิบายว่า server container ไม่ได้ทำงานในเบราว์เซอร์หรือในโทรศัพท์ของผู้ใช้ แต่ทำงานบนเซิร์ฟเวอร์ที่ธุรกิจควบคุม เช่น ในโปรเจกต์ Google Cloud ของธุรกิจเอง ข้อมูลจากหน้าเว็บส่งเข้าเซิร์ฟเวอร์นี้ก่อน และมีเพียงธุรกิจที่เข้าถึงข้อมูลได้จนกว่าจะเลือกส่งต่อ ภายในเซิร์ฟเวอร์ใช้ tag trigger และ variable แบบเดียวกับที่ทีมคุ้นเคย เพิ่มส่วนใหม่ที่เรียกว่า client

client ทำหน้าที่เป็นตัวแปลง รับคำขอที่เข้ามา แปลงเป็นเหตุการณ์ ส่งให้แท็กในเซิร์ฟเวอร์ประมวลผล แล้วตอบกลับไปยังผู้ส่ง server container มี client ติดมาให้สองตัว คือ Google Analytics และ Measurement Protocol หน้าเว็บจะส่งข้อมูลเข้ามาได้ด้วยการตั้งค่า server\_container\_url ในแท็กของ Google ให้ชี้ไปที่ URL ของเซิร์ฟเวอร์

### ทำไม Google แนะนำให้ใช้โดเมนของตัวเอง

คู่มือของ Google แนะนำอย่างหนักแน่นให้ติดตั้งเซิร์ฟเวอร์บนโดเมนของธุรกิจเอง เช่น ซับโดเมนของเว็บหลัก และเปลี่ยนเป็นโหมด production ก่อนส่งการเข้าชมจริง ด้วยเหตุผลเรื่องประสิทธิภาพและความปลอดภัย ผลอีกข้อคือคุกกี้ที่เซิร์ฟเวอร์ตั้งผ่านการตอบกลับอยู่ในฐานะคุกกี้ของโดเมนเจ้าของเว็บ ซึ่งเบราว์เซอร์บางตัวจำกัดน้อยกว่าคุกกี้ที่สคริปต์สร้าง รายละเอียดข้อจำกัดของ Safari อยู่ใน[First-Party Data คุกกี้ของเว็บเองก็หมดอายุใน 7 วันได้](https://phygital.co.th/insights/first-party-data-strategy-cookieless) ข้อนี้เปลี่ยนอายุของคุกกี้ แต่ไม่ได้เปลี่ยนหน้าที่ของธุรกิจในการขอความยินยอม

## ต้นทุนที่ต้องจ่ายทุกเดือน

คู่มือติดตั้งบน Cloud Run ให้ตัวเลขไว้ดังนี้

| รายการ                  | ตามคู่มือของ Google                                                                                                            |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| ค่าเซิร์ฟเวอร์         | ราว 45 ดอลลาร์ต่อเครื่องต่อเดือน สำหรับ Cloud Run 1 vCPU หน่วยความจำ 0.5GB แบบจัดสรร CPU ตลอดเวลา                        |
| จำนวนเครื่องที่แนะนำ | อย่างน้อย 2 เครื่อง เพื่อลดความเสี่ยงข้อมูลหายเมื่อเครื่องหนึ่งล่ม                                                     |
| ความสามารถรับโหลด    | ขยายอัตโนมัติ 2 ถึง 10 เครื่อง รับได้ราว 35 ถึง 350 คำขอต่อวินาที ขึ้นกับจำนวนและการทำงานของแท็ก                     |
| ค่า log                 | บันทึกทุกคำขอเป็นค่าเริ่มต้น ถ้าเกินหนึ่งล้านคำขอต่อเดือนอาจมีค่าบันทึกสูง คู่มือแนะนำให้ปิดการบันทึกคำขอ |
| สิ่งที่ต้องมีก่อน   | บัญชีเรียกเก็บเงินของ Google Cloud                                                                                           |

ค่าตั้งต้นตามคู่มือจึงอยู่ที่ราว 90 ดอลลาร์ต่อเดือนสำหรับสองเครื่อง ก่อนนับค่า log ค่าโดเมน และค่าคนดูแล คู่มือยังแนะนำให้ตั้งการแจ้งเตือนค่าใช้จ่ายไว้ เพราะ Cloud Run เพิ่มเครื่องเองตามปริมาณคำขอ และค่า max-instances คือกรณีที่ต้องจ่ายสูงสุด

### ธุรกิจเล็กคำนวณความคุ้มค่าอย่างไร

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

## ความยินยอมยังต้องมาจากหน้าเว็บ

หน้าวิธีใช้ Consent Mode กับ server-side Tag Manager อธิบายลำดับไว้สามขั้น ป้ายขอความยินยอมบนหน้าเว็บรับคำตอบของผู้ใช้แล้วส่งให้แท็กของ Google แท็กของ Google เพิ่มพารามิเตอร์ความยินยอมลงในคำขอที่ส่งไปยัง server container แล้วแท็กผลิตภัณฑ์ของ Google ในเซิร์ฟเวอร์ปรับปริมาณและชนิดข้อมูลที่ส่งต่อตามคำตอบนั้น คู่มือจึงบอกว่าการตั้ง Consent Mode ทำที่ web container บนหน้าเว็บเพียงที่เดียว

พฤติกรรมของแท็กของ Google ในเซิร์ฟเวอร์เมื่อผู้ใช้ปฏิเสธเป็นดังนี้

1. **Google Analytics** เมื่อ analytics\_storage เป็นปฏิเสธ ไม่มีการเขียน เข้าถึง หรืออ่านคุกกี้ของ Analytics เลย ข้อนี้ใช้กับทั้งหน้าเว็บและ server container
2. **Google Ads Conversion** เมื่อ ad\_storage เป็นปฏิเสธ ไม่เขียนและไม่อ่านคุกกี้ของ Google Ads และต้องติดตั้งแท็ก Conversion Linker ในเซิร์ฟเวอร์ก่อนจึงจะทำงาน
3. **Google Ads Remarketing** เมื่อ ad\_storage เป็นปฏิเสธ บล็อกทั้งคำขอ HTTP และการใช้คุกกี้

หน้านี้อธิบายเฉพาะแท็กของ Google แท็กของแพลตฟอร์มอื่นที่วางไว้ในเซิร์ฟเวอร์เดียวกันจึงต้องตั้งให้อ่านสถานะความยินยอมแยกเอง ถ้าไม่ตั้ง ข้อมูลของคนที่ปฏิเสธอาจถูกส่งออกไปทั้งที่หน้าเว็บบอกว่าไม่ส่ง วิธีเลือกแบบของ Consent Mode อยู่ใน[Consent Mode v2 คืออะไร โมเดลเติมข้อมูลได้เฉพาะเว็บคนเข้ามาก](https://phygital.co.th/insights/google-consent-mode-v2-explained)

### ใช้ server-side เพื่อหลบตัวบล็อกโฆษณาได้หรือไม่

ในทางเทคนิค คำขอที่ส่งไปโดเมนของเว็บเองอาจไม่ถูกตัวบล็อกบางตัวจับ แต่ในทางกฎหมายและความไว้ใจ คำถามที่ต้องตอบคือผู้ใช้ยินยอมหรือไม่ กฎหมายข้อมูลส่วนบุคคลไทยมาตรา 19 วางหลักว่าธุรกิจนำข้อมูลของบุคคลไปเก็บรวบรวม ใช้ หรือส่งต่อได้เมื่อเจ้าของข้อมูลยินยอมไว้ก่อนหรือในขณะนั้น เว้นแต่มีกฎหมายให้ทำได้ และการถอนคำยินยอมต้องทำได้ง่ายไม่ต่างจากตอนที่ให้ ผู้ใช้ที่ติดตั้งตัวบล็อกกำลังบอกความต้องการของตัวเองอยู่แล้ว การออกแบบระบบเพื่ออ้อมความต้องการนั้นเสี่ยงทั้งข้อกฎหมายและชื่อเสียงของแบรนด์ ถ้าผู้ใช้รู้ภายหลัง ตัวบทฉบับเต็มอยู่ใน[ไฟล์กฎหมายที่เผยแพร่บนเว็บของสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล](https://www.pdpc.or.th/wp-content/uploads/2023/12/1%5FPersonal-Data-Protection-2562.pdf)

## ส่งซ้ำสองทางต้องกันการนับซ้ำ

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

1. **ใช้รหัสเหตุการณ์** ส่ง eventID จากพิกเซลให้ตรงกับ event\_id ของ Conversions API และให้ชื่อเหตุการณ์ของพิกเซลตรงกับ event\_name ของเซิร์ฟเวอร์ ถ้า Meta ได้รับคู่ที่ตรงกันไปยังพิกเซลเดียวกันภายใน 48 ชั่วโมง จะทิ้งเหตุการณ์ที่มาทีหลัง
2. **ใช้ข้อมูลระบุผู้ใช้** ส่ง event\_name คู่กับ fbp หรือ external\_id ให้ตรงกันทั้งสองทาง แล้ว Meta จะเทียบกันเอง

เอกสารย้ำว่า Meta จะตัดเหตุการณ์ที่มีรหัสซ้ำออกได้ก็ต่อเมื่อเหตุการณ์ที่สองมาถึงไม่เกิน 48 ชั่วโมงหลังเหตุการณ์แรกที่ใช้รหัสเดียวกัน ระบบที่ส่งข้อมูลจากเซิร์ฟเวอร์ช้าเป็นวัน เช่น ส่งเป็นชุดทุกคืน จึงควรตรวจเวลาส่งด้วย โครงสร้างบัญชีโฆษณาของ Meta ที่ต้องเข้าใจก่อนตั้งค่านี้อยู่ใน[Meta Ads พอร์ตโฟลิโอธุรกิจ บัญชีโฆษณา และแคมเปญสามชั้น](https://phygital.co.th/insights/meta-ads-101)

## ค่าเซิร์ฟเวอร์ในคู่มือเป็นราคาประมาณ

ข้อมูลในบทนี้มีขอบเขตห้าข้อ

1. **45 ดอลลาร์เป็นตัวเลขประมาณของ Google** ราคา Cloud Run จริงขึ้นกับภูมิภาคที่เลือกและปริมาณคำขอ คู่มือให้ใช้เครื่องคำนวณราคาของ Google Cloud ประเมินเอง
2. **บทนี้ไม่ได้ตรวจผู้ให้บริการโฮสต์ server container รายอื่น** ผู้ให้บริการแต่ละรายมีราคาและเงื่อนไขการเก็บข้อมูลต่างกัน
3. **ไม่มีตัวเลขว่าย้ายแล้วได้ข้อมูลเพิ่มกี่เปอร์เซ็นต์** ผลขึ้นกับสัดส่วนผู้ใช้ที่ใช้ตัวบล็อก สัดส่วนที่กดปฏิเสธ และแท็กที่เว็บใช้
4. **เอกสารของ Meta ที่อ้างเป็นฉบับที่เปิดอ่านในเดือนกันยายน 2569** Meta ปรับเอกสารสำหรับนักพัฒนาเป็นระยะ ก่อนตั้งค่าจริงควรเปิดหน้าล่าสุดอีกครั้ง
5. **บทนี้ไม่ใช่คำแนะนำทางกฎหมาย** มาตรา 19 ยกมาเพื่อให้เห็นหลักเรื่องความยินยอม การประเมินว่าข้อมูลแต่ละชนิดใช้ฐานทางกฎหมายใดควรให้ที่ปรึกษากฎหมายตรวจ

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

## ห้าคำถามก่อนตอบรับข้อเสนอ

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

หน้าบริการที่เกี่ยวกับการตรวจระบบวัดผลก่อนลงทุนคือ[บริการที่ปรึกษาการตลาด](https://phygital.co.th/solutions/consulting)

### ใช้แพลตฟอร์มร้านค้าแบบเช่าใช้อยู่ ควรเริ่มตรงไหน

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

## สรุป

Server-side tagging ของ Google Tag Manager ย้ายการประมวลผลแท็กไปไว้บนเซิร์ฟเวอร์ที่ธุรกิจควบคุม ข้อมูลจากหน้าเว็บผ่านเซิร์ฟเวอร์ก่อนส่งต่อ คู่มือของ Google ประเมินค่าเซิร์ฟเวอร์ราว 45 ดอลลาร์ต่อเครื่องต่อเดือนและแนะนำอย่างน้อย 2 เครื่อง บวกค่า log เมื่อคำขอเกินหนึ่งล้านครั้งต่อเดือน ความยินยอมต้องตั้งที่หน้าเว็บแล้วส่งไปกับคำขอ แท็กของ Google ในเซิร์ฟเวอร์ปรับตามสถานะนั้น ส่วนแท็กของแพลตฟอร์มอื่นต้องตั้งเอง ธุรกิจที่ส่งข้อมูลให้ Meta ทั้งจากพิกเซลและ Conversions API ต้องใช้รหัสเหตุการณ์ที่ตรงกันภายใน 48 ชั่วโมงเพื่อกันนับซ้ำ การย้ายระบบจึงคุ้มเมื่องบโฆษณาสูงพอ และไม่ควรใช้เป็นทางอ้อมความต้องการของผู้ใช้ที่ปฏิเสธการเก็บข้อมูล

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

### Server-Side Tracking กับ Client-Side ต่างกันที่จุดไหน

client-side ให้เบราว์เซอร์ของผู้ใช้ส่งข้อมูลตรงไปยังเครื่องมือแต่ละตัว server-side ให้เบราว์เซอร์ส่งข้อมูลมาที่เซิร์ฟเวอร์ของธุรกิจก่อน แล้วเซิร์ฟเวอร์เป็นผู้ส่งต่อ ธุรกิจจึงเลือกได้ว่าจะตัดหรือส่งข้อมูลใดต่อไปยังเครื่องมือใด

### ย้ายไปฝั่งเซิร์ฟเวอร์แล้วต้องเลิกใช้แท็กบนหน้าเว็บหรือไม่

ไม่ต้องเลิกทั้งหมด หน้าเว็บยังต้องมีแท็กของ Google ที่ส่งข้อมูลเข้าเซิร์ฟเวอร์ และยังต้องมีป้ายขอความยินยอม ส่วนแท็กของเครื่องมืออื่นย้ายไปอยู่ในเซิร์ฟเวอร์ได้ทีละตัว

### ต้องมีทีมพัฒนาเองไหม

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

### server-side ช่วยเรื่องความปลอดภัยของบัญชีไหม

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

### เว็บที่มีคนเข้าวันละไม่กี่ร้อยคนควรย้ายไหม

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

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

ส่งใบเสนอราคาเรื่อง server-side tracking ที่ได้รับมาให้ PHYGITAL AGENCY อ่าน แล้วเราจะไล่ห้าคำถามนี้ให้ก่อนคุณตัดสินใจ

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