# First-Party Data คุกกี้ของเว็บเองก็หมดอายุใน 7 วันได้

> ที่มา: https://phygital.co.th/insights/first-party-data-strategy-cookieless · เผยแพร่ 23 พฤศจิกายน 2567 · อ่าน 11 นาที · โดย PARANATH PANARATANA

WebKit ITP 2.1 จำกัดคุกกี้ที่สคริปต์บนเว็บสร้างเองไว้ 7 วันใน Safari ข้อมูลของตัวเองส่วนไหนหายได้ และควรเก็บด้วยวิธีใดให้มั่นคง โดย PHYGITAL AGENCY

## Key Takeaways

- **WebKit ซึ่งเป็นเอนจินของ Safari จำกัดอายุคุกกี้ถาวรที่สร้างผ่าน document.cookie ไว้ที่ 7 วันตั้งแต่ ITP 2.1** — ข้อจำกัดนี้ใช้กับคุกกี้ที่สคริปต์บนเว็บของธุรกิจเองสร้างด้วย ไม่ได้ใช้เฉพาะคุกกี้บุคคลที่สาม
- **WebKit อธิบายเหตุผลว่าสคริปต์ติดตามข้ามเว็บเริ่มใช้โถคุกกี้ของเว็บเจ้าของเองเพื่อติดตามผู้ใช้** — ข้อมูลที่ธุรกิจคิดว่าเป็นของตัวเองจึงถูกจำกัดไปด้วย เมื่อเก็บด้วยวิธีเดียวกับสคริปต์ติดตาม
- **คุกกี้ที่ตั้งผ่านการตอบกลับของเซิร์ฟเวอร์ไม่อยู่ใต้ข้อจำกัดนี้** — และ WebKit แนะนำให้คุกกี้ยืนยันตัวตนตั้งผ่านการตอบกลับของเซิร์ฟเวอร์พร้อมค่า Secure และ HttpOnly

ธุรกิจที่เตรียมรับยุคหลังคุกกี้บุคคลที่สามหันมาให้น้ำหนักกับ First-Party Data หรือข้อมูลที่เก็บจากเว็บและช่องทางของตัวเอง แต่ลูกค้าเก่าที่กลับมาเว็บหลังผ่านไปสองสัปดาห์อาจถูกนับเป็นผู้เข้าชมใหม่ ถ้าเข้าผ่าน Safari และเว็บจำลูกค้าด้วยคุกกี้ที่สคริปต์สร้างขึ้น บทนี้อธิบายกติกาของ Intelligent Tracking Prevention รุ่น 2.1 ใน WebKit ว่าจำกัดคุกกี้แบบไหน เหตุผลที่ WebKit ให้ไว้ และข้อมูลแบบไหนที่ธุรกิจเก็บได้โดยไม่ต้องพึ่งอายุของคุกกี้ เพื่อให้ธุรกิจวางแผนเก็บข้อมูลของตัวเองได้ตรงกับการทำงานจริงของเบราว์เซอร์

กติกาในบทนี้มาจาก[บทความ Intelligent Tracking Prevention 2.1 บนบล็อกของ WebKit](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/) ที่ John Wilander เผยแพร่เมื่อ 21 กุมภาพันธ์ 2019 ข้อความถูกอ่านเมื่อ 27 ก.ย. 2569 WebKit ออกรุ่นปรับปรุงของ ITP ต่อมาอีกหลายครั้ง บทนี้อ้างเฉพาะสิ่งที่อยู่ในบทความรุ่น 2.1 ส่วนการจับคู่ลูกค้าคนเดียวกันจากหลายช่องทาง บทนี้ไม่ได้ลงรายละเอียด

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

## First-Party Data ไม่ได้แปลว่าอยู่รอดทุกเบราว์เซอร์

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

แผนของ Chrome เรื่องคุกกี้บุคคลที่สามเปลี่ยนไปหลายรอบ รายละเอียดว่าทำไมคุกกี้บุคคลที่สามยังไม่หายไปอย่างที่เคยคาด อยู่ใน[PDPA อัปเดต 2567-2569 คำสั่งปรับ 6 เรื่อง กับคุกกี้ Chrome](https://phygital.co.th/insights/pdpa-cookie-update-thailand) บทนี้มองอีกด้าน คือคุกกี้ที่เว็บของธุรกิจสร้างเองก็มีข้อจำกัดในเบราว์เซอร์บางตัวอยู่แล้ว

### ธุรกิจที่ลูกค้าส่วนใหญ่ใช้ Android ต้องสนใจเรื่องนี้ไหม

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

## ITP 2.1 จำกัดอะไร

บทความของ WebKit อธิบายว่าคุกกี้ตั้งได้สองทาง ทางหนึ่งตั้งในการตอบกลับของเซิร์ฟเวอร์ (HTTP response) อีกทางตั้งผ่าน document.cookie API ซึ่งบางครั้งเรียกว่าคุกกี้ฝั่งไคลเอนต์ ตั้งแต่ ITP 2.1 คุกกี้ถาวรทุกตัวที่สร้างผ่าน document.cookie ถูกจำกัดอายุไว้ที่เจ็ดวัน

รายละเอียดการทำงานที่บทความระบุ

1. **ใช้เฉพาะคุกกี้ที่สร้างผ่าน document.cookie**
2. **ใช้ทั้งในบริบทของเว็บเจ้าของเอง และใน iframe ของบุคคลที่สาม**
3. **คุกกี้แบบ session ไม่ได้รับผล** ยังคงเป็นคุกกี้แบบ session ตามเดิม
4. **คุกกี้ถาวรที่ตั้งอายุไว้สั้นกว่าเจ็ดวันอยู่ตามอายุเดิม**

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

### รายงานผู้เข้าชมใหม่ที่สูงผิดปกติเกี่ยวกับเรื่องนี้ไหม

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

### ITP 2.1 ออกมากับ Safari รุ่นไหน และเปลี่ยนอะไรอีก

[บทความเดียวกันของ WebKit](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/) ระบุว่า ITP 2.1 อยู่ใน iOS 12.2 รุ่นเบตา และ Safari 12.1 บน macOS High Sierra กับ Mojave อีกเรื่องที่ประกาศพร้อมกันคือ Safari เลิกรองรับสัญญาณ Do Not Track (DNT) ซึ่งเป็นค่าที่ผู้ใช้เปิดในเบราว์เซอร์เพื่อขอให้เว็บไม่ติดตาม WebKit ให้เหตุผลว่าเว็บส่วนใหญ่ไม่ได้เปลี่ยนพฤติกรรมตามสัญญาณนี้ โครงการ DNT ปิดไปโดยไม่ได้ออกเป็นมาตรฐาน และสัญญาณนี้กลับเพิ่มข้อมูลให้ใช้ระบุตัวเบราว์เซอร์ (fingerprinting) ได้มากขึ้น

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

## ทำไม WebKit จำกัดคุกกี้ของเว็บเจ้าของเอง

บทความของ WebKit ให้เหตุผลไว้สามด้าน คือความเป็นส่วนตัว ความปลอดภัย และประสิทธิภาพ

1. **ความเป็นส่วนตัว** ผู้ติดตามข้ามเว็บเริ่มใช้โถคุกกี้ของเว็บเจ้าของเองเพื่อติดตามผู้ใช้แบบถาวร และสคริปต์ติดตามทุกตัวที่ทำงานในบริบทของเว็บเจ้าของอ่านและเขียนข้อมูลของกันและกันได้ บทความยกตัวอย่างว่าถ้าเครือข่ายโซเชียลเขียนรหัสติดตามผู้ใช้เป็นคุกกี้ของเว็บข่าว สคริปต์วิเคราะห์ สคริปต์โฆษณา และสคริปต์วิดีโอบนเว็บข่าวนั้นก็ใช้รหัสเดียวกันได้
2. **ความปลอดภัย** คุกกี้ที่อ่านได้ผ่าน document.cookie ถูกขโมยได้ด้วยการโจมตีแบบ speculative execution และ cross-site scripting จึงไม่ควรเก็บข้อมูลอ่อนไหว เช่นข้อมูลยืนยันตัวตน
3. **ประสิทธิภาพ** คุกกี้ถูกส่งไปกับทุกคำขอที่เกี่ยวข้อง คุกกี้จำนวนมากทำให้หน้าโหลดช้า และบทความเล่าว่าทีมเคยตรวจกรณีผู้สมัครสมาชิกเว็บข่าวถูกออกจากระบบเอง เพราะคุกกี้ของผู้ติดตามมีมากจนคุกกี้ล็อกอินของเว็บถูกดันออก

### Verified Partitioned Cache ในรุ่นเดียวกันคืออะไร

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

### ข้อนี้บอกอะไรกับธุรกิจที่ติดสคริปต์หลายตัวบนเว็บ

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

## คุกกี้แบบไหนไม่ถูกจำกัด

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

| คุกกี้                                        | ตั้งผ่าน       | อยู่ใต้การจำกัด 7 วันของ ITP 2.1 หรือไม่ |
| --------------------------------------------- | --------------- | --------------------------------------------- |
| คุกกี้ถาวรที่สคริปต์บนหน้าเว็บสร้าง    | document.cookie | อยู่                                          |
| คุกกี้ถาวรที่ตั้งอายุไว้น้อยกว่า 7 วัน | document.cookie | อยู่ตามอายุเดิมที่สั้นกว่า              |
| คุกกี้แบบ session                            | document.cookie | ไม่ได้รับผล                                |
| คุกกี้ที่เซิร์ฟเวอร์ตั้งในการตอบกลับ   | HTTP response   | บทความจำกัดเฉพาะ document.cookie            |

แถวสุดท้ายเป็นเหตุผลที่บางธุรกิจย้ายการติดตามไปทำฝั่งเซิร์ฟเวอร์ ข้อดี ข้อจำกัด และเรื่องความยินยอมของการติดตามฝั่งเซิร์ฟเวอร์ อธิบายไว้ใน[Server-Side Tracking คืออะไร ย้ายแท็กแล้วยังต้องขอความยินยอม](https://phygital.co.th/insights/server-side-tracking-explained)

## ข้อมูลของตัวเองที่ไม่ต้องพึ่งคุกกี้

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

1. **ระบบสมาชิกที่ลูกค้าล็อกอินเอง** เมื่อลูกค้าล็อกอิน ร้านรู้ว่าเป็นลูกค้าคนเดิมโดยไม่ต้องพึ่งคุกกี้ที่ตั้งไว้เมื่อหลายสัปดาห์ก่อน ตัวอย่างระบบสมาชิกของร้านเล็กบนแพลตฟอร์มแชต อยู่ใน[สมาชิกร้านสัตว์เลี้ยงบน LINE OA บัตรแสตมป์กับ CRM 369 บาท](https://phygital.co.th/insights/pet-business-loyalty-program-agency)
2. **ประวัติคำสั่งซื้อ** ข้อมูลในระบบหลังร้านไม่ขึ้นกับอายุคุกกี้ในเบราว์เซอร์
3. **ความยินยอมที่ลูกค้าให้ไว้ตามวัตถุประสงค์** ข้อมูลที่เก็บด้วยความยินยอมที่ชัดเจน ใช้ต่อได้ตามวัตถุประสงค์นั้นโดยไม่ต้องพึ่งการติดตามเบื้องหลัง

ข้อมูลกลุ่มนี้ก็ยังเป็นข้อมูลส่วนบุคคลตาม PDPA ลูกค้าจึงมีสิทธิขอดู ขอลบ หรือขอระงับการใช้ ขั้นตอนรับคำขอเหล่านี้อธิบายไว้ใน[PDPA กับการตลาด ลูกค้าขอดู ขอลบ ขอระงับข้อมูลต้องทำอะไร](https://phygital.co.th/insights/pdpa-digital-marketing-guide) ส่วนธุรกิจที่มีข้อมูลจากหลายระบบและกำลังพิจารณาระบบรวมข้อมูล อ่านนิยามและข้อจำกัดได้ใน[CDP ต่างจาก CRM ตามนิยามปี 2026 ของ CDP Institute](https://phygital.co.th/insights/cdp-vs-crm-difference)

### ทำไมข้อมูลสมาชิกจึงมั่นคงกว่าข้อมูลจากคุกกี้

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

## สามเรื่องที่ควรตรวจในเว็บของตัวเอง

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

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

## สรุป

ITP 2.1 ของ WebKit จำกัดอายุคุกกี้ถาวรที่สร้างผ่าน document.cookie ไว้ที่เจ็ดวัน ทั้งในเว็บเจ้าของเองและใน iframe ของบุคคลที่สาม โดยให้เหตุผลว่าผู้ติดตามข้ามเว็บใช้โถคุกกี้ของเว็บเจ้าของเพื่อติดตามผู้ใช้ คุกกี้แบบ session ไม่ได้รับผล และคุกกี้ยืนยันตัวตนควรตั้งผ่านการตอบกลับของเซิร์ฟเวอร์แบบ Secure และ HttpOnly First-Party Data ที่เก็บด้วยคุกกี้จากสคริปต์จึงหายได้ในเบราว์เซอร์บางตัว ข้อมูลที่มั่นคงกว่าคือข้อมูลที่ผูกกับการล็อกอินและประวัติการซื้อของลูกค้า

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

### ข้อจำกัด 7 วันใช้กับเครื่องมือวิเคราะห์เว็บทุกตัวหรือไม่

บทความของ WebKit จำกัดคุกกี้ถาวรที่สร้างผ่าน document.cookie เครื่องมือที่จำผู้เข้าชมด้วยคุกกี้แบบนี้จึงได้รับผลใน Safari ส่วนเครื่องมือที่ตั้งคุกกี้ผ่านเซิร์ฟเวอร์ใช้วิธีตั้งอีกแบบ ธุรกิจควรตรวจกับผู้ให้บริการเครื่องมือว่าคุกกี้ของเครื่องมือตั้งด้วยวิธีใด

### ลูกค้าที่ล็อกอินค้างไว้จะหลุดจากระบบหลัง 7 วันไหม

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

### บทความนี้เป็นกติกาล่าสุดของ Safari หรือไม่

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

### ย้ายการติดตามไปฝั่งเซิร์ฟเวอร์แล้วยังต้องขอความยินยอมไหม

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

### ธุรกิจเล็กที่ไม่มีทีมพัฒนาควรเริ่มจากอะไร

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

## คุกกี้ที่สคริปต์บนเว็บของคุณสร้างเอง อาจอยู่ใน Safari ได้เพียง 7 วัน

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

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