สรุปสั้น ๆ (TL;DR)
- Meta ย้าย Login with Facebook เข้าสู่ open beta เมื่อ 27 สิงหาคม 2569 พร้อมสามการเปลี่ยนแปลง คือ Single Sign On แตะเดียว การรีเฟรช Limited Login แบบเงียบ และ Fast App Switch บน iOS
- Fast App Switch เป็น opt-in ใน SDK 18.0.2 และเปิดโดยค่าเริ่มต้นตั้งแต่ 18.0.3 แอปที่ประกาศ fbauth2 โดยไม่กำหนด appSwitch จึงเปลี่ยนโฟลว์ล็อกอินเองหลังอัปเกรด
- Single Sign On ต้องใช้ Android SDK 18.3.0 ขึ้นไป ส่วนบนเว็บต้องเพิ่ม fedCM: true ใน FB.init() ซึ่งย้ายพรอมป์ของ Facebook ไปอยู่บน FedCM ที่รองรับตั้งแต่ Chrome 117
- Limited Login Data Refresh ต้องใช้ iOS SDK 18.1.0 ขึ้นไป และรีเฟรช Profile.current กับ AuthenticationToken.current แบบเงียบเมื่อแอปกลับมาเบื้องหน้า จบปัญหาการบังคับล็อกอินใหม่
- Meta ไม่ได้เผยแพร่สัดส่วนการปล่อยใช้งาน ความพร้อมรายประเทศ กำหนดออกเวอร์ชันทั่วไป หรือข้อมูลคอนเวอร์ชันของทั้งสามฟีเจอร์เลย
Meta ย้าย Login with Facebook เข้าสู่สถานะ open beta เมื่อวันที่ 27 สิงหาคม 2569 พร้อมกับรวมการเปลี่ยนแปลงด้านการยืนยันตัวตนสามอย่างไว้ในรอบเดียว ได้แก่ พรอมป์แตะเดียวสำหรับผู้ใช้ที่กลับมาใช้งานบน Android และเว็บ การรีเฟรชโทเคนแบบเงียบสำหรับเซสชัน Limited Login บน iOS และค่าเริ่มต้นที่ส่งการล็อกอินบน iOS ไปยังแอป Facebook ตัวจริงแทนการเปิดเบราว์เซอร์ในแอป PPC Land รายงานการเปิดตัวนี้ ซึ่ง Meta ประกาศไว้บนบล็อก Meta for Developers ภายใต้ชื่อผู้เขียน Zoe Lieberman และวางกรอบทั้งหมดไว้ใต้คำสัญญาเดียวว่า "fewer steps and less maintenance" ทั้งสามฟีเจอร์มีเงื่อนไขเวอร์ชัน SDK ของตัวเอง และหนึ่งในนั้นเปลี่ยนพฤติกรรมของแอปโดยอัตโนมัติหลังการอัปเกรด
ปุ่มเข้าสู่ระบบด้วย Facebook อยู่ในตำแหน่งที่ไม่ค่อยมีใครพูดถึงในกองเทคโนโลยีการตลาด มันแทบไม่เคยถูกหยิบขึ้นมาในห้องประชุมวางแผน แต่มันเป็นตัวกำหนดว่าคนจะเข้ามาในแอปในฐานะผู้ใช้ที่ระบุตัวตนได้และติดต่อกลับได้ หรือเข้ามาเป็นเซสชันนิรนามที่หายไปพร้อมคุกกี้ การเปลี่ยนกลไกของปุ่มนี้จึงส่งผลถึงอัตราการสมัครสมาชิก การเก็บข้อมูล first-party และสัญญาณการวัดผลที่ป้อนกลับเข้าไปให้ระบบปรับแคมเปญ ข่าวที่ดูเหมือนเรื่องของนักพัฒนาล้วน ๆ จึงควรถูกอ่านจากฝั่งการตลาดด้วย โดยเฉพาะรอบนี้ที่มีค่าเริ่มต้นตัวหนึ่งเปลี่ยนตัวเลขได้ก่อนที่ใครจะทันสังเกต
Fast App Switch คือสิ่งที่เปลี่ยนได้โดยไม่มีใครตัดสินใจ
Fast App Switch ส่งผู้ใช้เข้าไปทำการล็อกอินให้เสร็จในแอป Facebook ตัวจริงบน iOS แทนการเปิดเบราว์เซอร์ภายในแอป การเชื่อมต่อต้องใช้ iOS SDK เวอร์ชัน 18.1.0 ขึ้นไป และต้องเพิ่ม fbauth2 ลงใน Info.plist ภายใต้ LSApplicationQueriesSchemes ซึ่งเป็นรูปแบบมาตรฐานของ iOS ในการประกาศ URL scheme ที่แอปตั้งใจจะตรวจสอบ อ่านมาถึงตรงนี้มันก็ยังดูเหมือนฟีเจอร์ทั่วไปที่ต้องเปิดใช้เอง ส่วนที่สำคัญจริงสำหรับโปรดักต์ที่ให้บริการอยู่แล้วซ่อนอยู่ในประวัติเวอร์ชัน Fast App Switch เป็นฟีเจอร์แบบ opt-in ใน SDK 18.0.2 และเปลี่ยนเป็นทำงานโดยค่าเริ่มต้นตั้งแต่ 18.0.3 เป็นต้นไป
ผลที่ตามมาชัดเจนมาก แอปที่ประกาศ fbauth2 ไว้ใน Info.plist โดยไม่ได้กำหนดค่า appSwitch อย่างชัดแจ้ง จะเริ่มสลับการล็อกอินที่เข้าเงื่อนไขไปยังแอป Facebook หลังการอัปเกรด SDK โดยที่นักพัฒนาไม่ได้แก้โค้ดแม้แต่บรรทัดเดียว ไม่มีใครเลือก ไม่มีใครรีวิว และไม่มีอะไรใน diff ที่บอกว่าเกิดขึ้น พฤติกรรมนี้ติดมากับการอัปเดต dependency ที่ release note มักจะเขียนสั้น ๆ ว่าเป็นงานบำรุงรักษาทั่วไป
ให้มองเรื่องนี้เป็นปัญหาการจัดการรีลีสก่อนจะมองเป็นฟีเจอร์ การเปลี่ยนโฟลว์ล็อกอินคือเหตุการณ์ที่กระทบอัตราคอนเวอร์ชันโดยตรง มันเปลี่ยนจำนวนหน้าจอระหว่างความตั้งใจกับการมีบัญชี เปลี่ยนว่าผู้ใช้ต้องออกจากแอปของคุณระหว่างทางหรือไม่ และบน iOS มันสร้างเงื่อนไขใหม่ว่าเครื่องนั้นต้องติดตั้งแอป Facebook และล็อกอินค้างไว้อยู่ ทุกข้อนี้ขยับตัวเลขการสมัครสำเร็จได้ทั้งขึ้นและลง Meta ไม่ได้เผยแพร่ข้อมูลเปรียบเทียบระหว่างโฟลว์แบบสลับแอปกับโฟลว์เบราว์เซอร์ในแอปเลย จึงไม่มีตัวเลขจากภายนอกให้ใช้วางแผน การวัดผลด้วยข้อมูลของคุณเองจึงเป็นทางเดียวที่ซื่อสัตย์พอจะบอกได้ว่าเกิดอะไรขึ้นกับโปรดักต์ของคุณ
รายการสั้น ๆ ที่ควรตรวจก่อนหรือทันทีหลังการอัปเกรด SDK
- บิลด์ปัจจุบันของคุณใช้ Facebook iOS SDK เวอร์ชันอะไร และการอัปเกรดรอบถัดไปข้ามเส้น 18.0.3 หรือไม่
- Info.plist ประกาศ fbauth2 ไว้หรือเปล่า ถ้ายังไม่ได้ประกาศ การสลับแอปจะยังไม่เกิด และวันที่เพิ่มเข้าไปคือวันที่พฤติกรรมนี้เริ่มทำงาน
- มีการกำหนดค่า appSwitch อย่างชัดแจ้งไว้ที่ LoginConfiguration หรือ FBLoginButton ตรงไหนบ้าง การไม่กำหนดในตอนนี้แปลว่าใช้ค่าเริ่มต้น และค่าเริ่มต้นเปลี่ยนไปแล้ว
- เหตุการณ์เริ่มล็อกอินกับล็อกอินสำเร็จถูกเก็บเป็นสองอีเวนต์แยกกันหรือไม่ เพื่อให้เห็นการหลุดหายระหว่างสองจุดนี้ แทนที่จะเดาเอาจากยอดสมัครที่ลดลง
- release note ของบิลด์นั้นพูดถึงโฟลว์ล็อกอินหรือเปล่า ถ้าการอัปเดต dependency เปลี่ยนสิ่งที่ผู้ใช้เห็น มันควรอยู่ในบันทึกที่เจ้าของโปรดักต์และคนดูแลการเติบโตอ่านจริง
ทีมที่ยังต้องการโฟลว์แบบเบราว์เซอร์สามารถตั้งค่า appSwitch: .disabled ที่อ็อบเจ็กต์ LoginConfiguration หรือที่คอมโพเนนต์ FBLoginButton ได้ ทั้งสองทางเลือกมีเหตุผลรองรับ ประเด็นคือทำให้มันกลายเป็นการตัดสินใจที่มีเจ้าของ ไม่ใช่สิ่งที่รับมาโดยไม่รู้ตัว และคนที่ดูแลกรวยสมัครสมาชิกต้องรู้ว่าโฟลว์ไหนถูกปล่อยขึ้นไปและปล่อยวันไหน
Single Sign On พาพรอมป์แตะเดียวมาสู่ Android และเว็บ
Single Sign On แสดงพรอมป์แตะเดียวให้กับคนที่ล็อกอินด้วยข้อมูลบัญชี Facebook อยู่บนเครื่องนั้นแล้ว แทนที่จะต้องผ่านโฟลว์ล็อกอินเต็มรูปแบบ ผู้ใช้ที่เข้าเงื่อนไขจะยืนยันด้วยการแตะครั้งเดียว ซึ่ง Meta อธิบายในประกาศว่าเป็นการ "cutting the friction out of returning logins" ฟีเจอร์นี้เล็งไปที่ผู้ใช้ที่กลับมาโดยเฉพาะ ขอบเขตของมันจึงขึ้นอยู่กับว่าผู้ชมของคุณมีเซสชัน Facebook ค้างอยู่บนเครื่องที่ใช้เข้าถึงคุณมากแค่ไหน
วิธีเชื่อมต่อต่างกันตามแพลตฟอร์ม บน Android ต้องอัปเดต SDK เป็นเวอร์ชัน 18.3.0 ขึ้นไป เรียกใช้ SSO API และเพิ่ม Facebook เข้าไปในบล็อก queries ของไฟล์ AndroidManifest.xml รายการ queries นี้ไม่ใช่ข้อกำหนดเฉพาะของ Meta แต่สะท้อนกฎ package visibility ที่ Android บังคับใช้มาตั้งแต่เวอร์ชัน 11 ซึ่งกำหนดให้แอปประกาศล่วงหน้าว่าตั้งใจจะตรวจหาแพ็กเกจใดบนเครื่องบ้าง ถ้าลืมประกาศ การตรวจหาจะล้มเหลวแบบเงียบ ๆ มากกว่าจะขึ้นข้อผิดพลาดที่สังเกตได้ง่าย
บนเว็บ นักพัฒนาอัปเดต JavaScript SDK แล้วเพิ่ม fedCM: true เข้าไปในการเรียก FB.init() หนึ่งแฟล็ก หนึ่งบรรทัด แต่กลไกเบื้องหลังเปลี่ยนไปคนละแบบ
Meta ไม่ได้เผยแพร่ตัวเลขการเพิ่มขึ้นใด ๆ สำหรับพรอมป์แตะเดียว ไม่มีเกณฑ์เทียบคอนเวอร์ชัน ไม่มีอัตราการสมัครก่อนและหลัง และไม่มีคำกล่าวอ้างว่าผู้ใช้ที่กลับมากี่เปอร์เซ็นต์เข้าเงื่อนไข ใครก็ตามที่อ้างตัวเลขการปรับปรุงจากล็อกอินแตะเดียว กำลังอ้างสิ่งที่ไม่ได้มาจากประกาศฉบับนี้
FedCM คือส่วนที่เงียบที่สุดของการเปลี่ยนแปลงฝั่งเว็บ
การเพิ่ม fedCM: true ทำให้พรอมป์บนเว็บของ Facebook ทำงานอยู่บน FedCM ซึ่งย่อมาจาก Federated Credential Management API เป็นกลไกที่ให้เบราว์เซอร์เป็นตัวกลางในการล็อกอินข้ามผู้ให้บริการโดยไม่ต้องพึ่งคุกกี้บุคคลที่สาม ภายใต้โมเดลนี้เบราว์เซอร์เป็นผู้เรนเดอร์หน้าต่างเลือกบัญชีเอง และจะติดต่อผู้ให้บริการตัวตนก็ต่อเมื่อผู้ใช้ให้ความยินยอมแล้วเท่านั้น ซึ่งตัดการรีไดเรกต์และการอ่านคุกกี้ที่โฟลว์แบบเดิมต้องพึ่งพาออกไป ข้อกำหนดนี้เดินอยู่ใน Federated Identity Working Group ของ W3C และการรองรับในเบราว์เซอร์เริ่มต้นที่ Chrome เวอร์ชัน 117
API ตัวนี้มีประวัติที่ควรรู้ Google ย้าย Sign in with Google มาอยู่บน FedCM ตั้งแต่เดือนเมษายน 2567 แทนกลไกที่อิงคุกกี้ซึ่งอยู่เบื้องหลังฟีเจอร์ One Tap และ Automatic Sign-In จากนั้น FedCM ก็อยู่รอดยาวกว่าเทคโนโลยีรุ่นเดียวกันหลายตัว เมื่อ Chrome ยกเลิก API ด้านโฆษณาส่วนใหญ่ของ Privacy Sandbox ในวันที่ 17 ตุลาคม 2568 หลังจากมีผู้นำไปใช้น้อย FedCM ยังคงอยู่ในเบราว์เซอร์ต่อไป และด้วย open beta รอบนี้ ผู้ให้บริการตัวตนรายใหญ่รายที่สองก็ย้ายพรอมป์ฝั่งเว็บมาสู่โมเดลที่เบราว์เซอร์เป็นตัวกลาง ทีละหนึ่งค่าคอนฟิก
นี่คือส่วนที่มีความหมายเกินกว่าปุ่มเดียว การล็อกอินผ่านโซเชียลเคยเป็นหนึ่งในสิ่งที่พึ่งพาคุกกี้ข้ามเว็บอย่างเงียบ ๆ และทิศทางที่กำลังไปคือเบราว์เซอร์ ไม่ใช่เว็บไซต์และไม่ใช่ผู้ให้บริการตัวตน จะกลายเป็นฝ่ายที่เรนเดอร์ตัวเลือกบัญชีและถือความยินยอมไว้ สำหรับคนที่ดูแลเส้นทางสมัครสมาชิกบนเว็บ แปลว่าพรอมป์ล็อกอินถูกกำกับด้วยนโยบายของเบราว์เซอร์บางส่วน ไม่ได้อยู่ใต้การควบคุมของหน้าเว็บคุณทั้งหมดอีกต่อไป ประกาศฉบับนี้ไม่ได้ระบุว่าผู้ให้บริการรายอื่นวางแผนจะตามมาหรือไม่ และไม่ได้ให้ไทม์ไลน์ใดนอกเหนือจากตัว open beta เอง
Limited Login Data Refresh ตัดปัญหาทั้งกลุ่ม ไม่ใช่บั๊กตัวเดียว
ฟีเจอร์ที่สามตอบข้อจำกัดที่เกิดจากสถาปัตยกรรมความเป็นส่วนตัวของ Apple ไทม์ไลน์จึงสำคัญ Apple ปล่อย App Tracking Transparency มาพร้อมกับ iOS 14.5 ในวันที่ 26 เมษายน 2564 โดยกำหนดให้แอปต้องขออนุญาตก่อนติดตามกิจกรรมข้ามแอปและเว็บไซต์ของบริษัทอื่น Facebook เริ่มแสดงหน้าจอขอความยินยอมภายใต้กรอบนี้ในระหว่างปี 2564 และ Meta ประเมินในไตรมาสสี่ของปีเดียวกันว่าการเปลี่ยนแปลงของ Apple จะทำให้บริษัทเสียรายได้ในระดับหนึ่งหมื่นล้านดอลลาร์สหรัฐ
Meta เปิดตัว Limited Login ในเดือนมกราคม 2564 โดยสร้างบนมาตรฐาน OpenID Connect เพื่อให้ข้อเท็จจริงที่ว่าผู้ใช้คนหนึ่งใช้ Facebook Login ภายในแอป iOS ไม่ถูกนำไปใช้กับการปรับโฆษณาให้ตรงบุคคลหรือการวัดผล มันเปิดทางให้ผู้ใช้ที่เลือกจำกัดการติดตามยังเข้าใช้งานแอปได้ตามปกติ แต่ในเวลาเดียวกันมันก็สร้างภาระการดูแล เพราะ Limited Login "does not use a long-lived access token" ดังนั้นโปรไฟล์และโทเคนยืนยันตัวตนที่ได้รับตอนล็อกอินจึง "can grow stale over time" ก่อนหน้ารีลีสนี้ ทางแก้เดียวคือผลักผู้ใช้กลับไปยืนยันตัวตนใหม่ทั้งกระบวนการ ซึ่งคือแรงเสียดทานที่มาถึงในจังหวะที่แอปไม่ต้องการมันที่สุด
Limited Login Data Refresh ตัดขั้นตอนนั้นออก ตอนนี้ SDK จะรีเฟรชเซสชันที่ใช้งานอยู่แบบเงียบ ๆ เมื่อแอปกลับมาทำงานเบื้องหน้า ทำให้ค่า Profile.current และ AuthenticationToken.current ยังใหม่อยู่เสมอ และมี API ใหม่ชื่อ refreshLimitedLogin() ให้สั่งรีเฟรชแบบเดียวกันได้เมื่อต้องการ การเชื่อมต่อเดิมยังคงล็อกอินผู้ใช้ผ่าน LoginConfiguration ด้วยโหมดติดตามแบบ .limited เหมือนเดิม และความสามารถรีเฟรชนี้ทำงานซ้อนอยู่บนเซสชันที่มีอยู่แล้ว เงื่อนไขคือ iOS SDK เวอร์ชัน 18.1.0 ขึ้นไป และต้องเป็น iOS 13.0 ขึ้นไปสำหรับเส้นทางรีเฟรชแบบเงียบ
อาการของข้อมูลเก่าค้างที่ Meta ระบุไว้ล้วนเป็นเรื่องเล็กและถูกจัดหมวดผิดได้ง่าย ได้แก่ รูปโปรไฟล์ที่ไม่ตรงกับปัจจุบัน ชื่อที่แสดงซึ่งตามหลังการเปลี่ยนชื่อบน Facebook ไม่ทัน และโทเคนยืนยันตัวตนที่ระบบหลังบ้านปฏิเสธไม่ยอมรับ ในคิวซัพพอร์ต ทั้งสามอย่างดูเหมือนบั๊กคนละตัว แต่ละอย่างได้ตั๋วของตัวเอง ได้ความพยายามทำซ้ำของตัวเอง และปิดจบแบบไม่ได้ข้อสรุปของตัวเอง ทั้งที่จริงมันมาจากกลไกเดียวกัน การทำให้ค่าเหล่านี้ตรงกันโดยไม่ต้องรบกวนผู้ใช้จึงเป็นการยกเลิกปัญหาทั้งหมวด ไม่ใช่การแก้รายงานใดรายงานหนึ่ง และนั่นคือเหตุผลที่ Meta วางฟีเจอร์นี้ไว้ในฐานะการลดภาระดูแลมากกว่าความสามารถใหม่
เงื่อนไขของแต่ละฟีเจอร์
ทั้งสามฟีเจอร์ไม่ได้ใช้เวอร์ชันขั้นต่ำร่วมกัน แอปหนึ่งจึงอาจเข้าเงื่อนไขของฟีเจอร์หนึ่งแต่ไม่เข้าอีกฟีเจอร์ เงื่อนไขตามที่ระบุในประกาศมีดังนี้
| ฟีเจอร์ | แพลตฟอร์ม | เงื่อนไข |
|---|---|---|
| Single Sign On | Android | SDK 18.3.0 ขึ้นไป เรียก SSO API และเพิ่ม Facebook ในบล็อก queries ของ AndroidManifest.xml |
| Single Sign On | เว็บ | อัปเดต JavaScript SDK และเพิ่ม fedCM: true ในการเรียก FB.init() |
| Limited Login Data Refresh | iOS | SDK 18.1.0 ขึ้นไป และ iOS 13.0 ขึ้นไปสำหรับเส้นทางรีเฟรชแบบเงียบ |
| Fast App Switch | iOS | SDK 18.1.0 ขึ้นไป เพิ่ม fbauth2 ใน Info.plist ใต้ LSApplicationQueriesSchemes เปิดโดยค่าเริ่มต้นตั้งแต่ 18.0.3 |
ทำไมปุ่มล็อกอินถึงเป็นเรื่องของการวัดผล
เหตุผลที่คนดูแลสื่อควรสนใจเรื่องนี้คือผู้ใช้ที่ยืนยันตัวตนแล้วกับเซสชันนิรนามไม่ใช่สินทรัพย์ชนิดเดียวกัน คนที่ล็อกอินผ่านโซเชียลสำเร็จจะให้ตัวระบุที่คงที่ ให้ประวัติที่ผูกพฤติกรรมเข้าไปได้ และในหลายกรณีให้อีเมลที่นำไปจับคู่ทีหลังได้ ส่วนคนที่หลุดออกไปตรงหน้าล็อกอินให้เพียงเซสชันที่จบลงพร้อมคุกกี้ ช่องว่างระหว่างสองผลลัพธ์นี้ทบต้นไปยังทุกอย่างที่อยู่ปลายน้ำ ทั้งขนาดของฐานข้อมูล first-party คุณภาพของสัญญาณคอนเวอร์ชันที่ส่งกลับไปให้แพลตฟอร์มโฆษณา และสัดส่วนของรีมาร์เก็ตติงที่ตั้งอยู่บนอะไรที่ทนกว่าตัวระบุระดับเบราว์เซอร์
ด้วยเหตุนี้การเปลี่ยนโฟลว์ล็อกอินจึงควรอยู่ในบทสนทนาเดียวกับรายงาน โฆษณาบน Facebook ไม่ใช่ค้างอยู่ใน backlog ที่ไม่มีใครนอกทีมพัฒนาอ่าน ถ้าอัตราการสมัครสำเร็จขยับในสัปดาห์ที่ปล่อย SDK ผลจะไปโผล่ที่ต้นทุนต่อการสมัครนานก่อนที่ใครจะเชื่อมโยงกลับไปถึงการอัปเดต dependency และสัญชาตญาณแรกมักจะไปโทษครีเอทีฟหรือการตั้งค่าประมูล การเก็บบันทึกลงวันที่ของการเปลี่ยนโฟลว์ล็อกอินไว้ข้าง ๆ รายงานโฆษณาโซเชียล เป็นวิธีราคาถูกที่ช่วยไม่ให้การเปลี่ยนแปลงของแพลตฟอร์มถูกวินิจฉัยผิดว่าเป็นปัญหาของสื่อ
เรื่องเดียวกันใช้กับการตั้งค่าวิเคราะห์ข้อมูล ถ้าเหตุการณ์เริ่มล็อกอินกับล็อกอินสำเร็จไม่ได้แยกกันใน การตั้งค่า GA4 ของคุณ โฟลว์แบบสลับแอปที่ทำให้คนหลุดระหว่างสองจุดจะมองไม่เห็นเลย คุณจะเห็นแค่ยอดสมัครน้อยลงโดยไม่มีคำอธิบาย และในฝั่งเว็บ พรอมป์ FedCM ถูกเรนเดอร์โดยเบราว์เซอร์ สิ่งที่ หน้าสมัครสมาชิก ของคุณควบคุมได้จึงเป็นทุกอย่างที่อยู่รอบพรอมป์ ไม่ใช่ตัวพรอมป์เอง ข้อจำกัดนี้ทำให้สิ่งที่งานออกแบบแก้ได้แคบลง และทำให้สิ่งที่การเก็บข้อมูลต้องจับให้ได้กว้างขึ้น
สิ่งที่ประกาศฉบับนี้ไม่ได้พูด
มีหลายอย่างที่นักการตลาดอยากรู้แต่ไม่ปรากฏในแหล่งข่าว และการเติมเองย่อมแย่กว่าการยอมรับว่าไม่มี
- ไม่มีสัดส่วนการปล่อยใช้งาน ประกาศ open beta ออกวันที่ 27 สิงหาคม 2569 โดยไม่ระบุว่าครอบคลุมแอปหรือผู้ใช้จำนวนเท่าใด
- ไม่มีรายละเอียดความพร้อมใช้งานรายประเทศ จึงไม่มีคำตอบว่าพรอมป์แตะเดียวทำงานเหมือนกันในไทยกับที่อื่นหรือไม่
- ไม่มีข้อมูลว่า open beta มีกำหนดออกเป็นเวอร์ชันทั่วไปเมื่อใด หรือเงื่อนไขอะไรจะทำให้ถึงจุดนั้น
- ไม่มีข้อมูลผลกระทบต่อคอนเวอร์ชันของทั้งสามฟีเจอร์ ไม่ว่าในทางบวกหรือลบ
- ไม่มีเกณฑ์เทียบหรือคำกล่าวอ้างเรื่องผลลัพธ์ที่ดีขึ้นจากล็อกอินแตะเดียว ไม่มีการเผยแพร่ตัวเลขใด ๆ และควรบอกตรง ๆ ว่าไม่มี แทนที่จะไปหยิบตัวเลขจากแพลตฟอร์มอื่นมาเติม
เรื่องนี้หมายความว่าอะไรสำหรับนักการตลาดไทย
Facebook ยังเป็นประตูหน้าหลักของแอปผู้บริโภคและการค้าขายในไทย ทำให้การล็อกอินผ่านโซเชียลมีสัดส่วนในการสร้างบัญชีสูงกว่าค่าเฉลี่ยระดับโลก และทำให้การเปลี่ยนค่าเริ่มต้นบน iOS มีน้ำหนักมากขึ้นตามไปด้วย ไม่มีเกณฑ์สาธารณะสำหรับอัตราการล็อกอินผ่านโซเชียลสำเร็จในไทย ไม่มีตัวเลขท้องถิ่นที่เชื่อถือได้ว่าผู้ใช้ iOS กี่เปอร์เซ็นต์ติดตั้งแอป Facebook และล็อกอินค้างไว้ และประกาศฉบับนี้ก็ไม่มีข้อมูลเฉพาะของไทย ให้สร้างตัวเลขของคุณเองแทนการยืมของคนอื่น ดึงข้อมูลเดือนล่าสุดที่ครบเดือนของการเริ่มล็อกอินและล็อกอินสำเร็จ แยกตามแพลตฟอร์ม แล้วใช้ตัวเลขนั้นเป็นเส้นฐานสำหรับตัดสินผลของการเปลี่ยน SDK ทุกครั้ง
ผลในทางปฏิบัติสองข้อตามมาสำหรับทีมโปรดักต์ในไทย ข้อแรก ค่าเริ่มต้นของ Fast App Switch ตั้งอยู่บนสมมติฐานว่าเครื่องนั้นมีแอป Facebook ติดตั้งและล็อกอินค้างอยู่ บนเครื่องที่ไม่เป็นเช่นนั้นโฟลว์จะย้อนกลับไปทางเดิม และประสบการณ์จะต่างจากที่ทีมทดสอบบนมือถือของพนักงานซึ่งมีแอปติดตั้งอยู่เสมอ ให้ทดสอบด้วยเครื่องที่ล็อกเอาต์และเครื่องที่ไม่มีแอปก่อนสรุปว่าโฟลว์ไม่มีปัญหา ข้อสอง อาการข้อมูลค้างของ Limited Login มีหน้าตาที่ผู้ใช้เห็นได้ในแอปไทยที่แสดงชื่อสมาชิกหรือรูปโปรไฟล์ ชื่อที่ไม่อัปเดตหลังผู้ใช้เปลี่ยนบน Facebook ถูกอ่านว่าบัญชีเสีย ไม่ได้ถูกอ่านว่าโทเคนเก่า และมันสร้างบทสนทนากับฝ่ายบริการเป็นภาษาไทยที่แพงกว่าตัวบั๊กเองหลายเท่า
ส่วนที่ถูกที่สุดของงานนี้คือการประสานงาน ทีมที่อัปเกรด SDK กับทีมที่รายงานต้นทุนต่อการสมัครมักไม่ใช่ทีมเดียวกัน และโฟลว์ล็อกอินคือรอยต่อระหว่างสองทีมนั้น บรรทัดเดียวที่ลงวันที่ไว้ในบันทึกการเปลี่ยนแปลงร่วม ระบุเวอร์ชัน SDK และวันที่ปล่อย ก็เพียงพอจะกันไม่ให้ค่าเริ่มต้นของแพลตฟอร์มถูกอ่านผิดเป็นผลของงานสื่อไปทั้งเดือน
คำถามที่พบบ่อย
ค่าเริ่มต้นของ Fast App Switch กระทบแอปของผมโดยอัตโนมัติไหม
กระทบ ถ้าแอปของคุณประกาศ fbauth2 ใน Info.plist และไม่ได้กำหนดค่า appSwitch อย่างชัดแจ้ง เพราะฟีเจอร์นี้เปลี่ยนเป็นทำงานโดยค่าเริ่มต้นตั้งแต่ SDK 18.0.3 เป็นต้นไป หลังจากเป็นแบบ opt-in ใน 18.0.2 ในคอนฟิกแบบนั้น การล็อกอินบน iOS ที่เข้าเงื่อนไขจะเริ่มวิ่งผ่านแอป Facebook ตัวจริงหลังอัปเกรด SDK โดยนักพัฒนาไม่ได้แก้โค้ด การตั้ง appSwitch: .disabled ที่ LoginConfiguration หรือ FBLoginButton จะกลับไปใช้โฟลว์แบบเบราว์เซอร์เหมือนเดิม
ทั้งสามฟีเจอร์ต้องใช้ SDK เวอร์ชันอะไรบ้าง
Single Sign On ต้องใช้ Android SDK 18.3.0 ขึ้นไป ส่วน Limited Login Data Refresh และ Fast App Switch ต้องใช้ iOS SDK 18.1.0 ขึ้นไป โดยเส้นทางรีเฟรชแบบเงียบต้องการ iOS 13.0 ขึ้นไปด้วย ฝั่งเว็บของ Single Sign On ไม่มีการระบุหมายเลขเวอร์ชันในประกาศ นอกจากให้อัปเดต JavaScript SDK และเพิ่ม fedCM: true ในการเรียก FB.init() เมื่อเวอร์ชันขั้นต่ำไม่เท่ากัน แอปหนึ่งจึงอาจเข้าเงื่อนไขฟีเจอร์หนึ่งแต่ไม่เข้าอีกฟีเจอร์
FedCM คืออะไร และทำไมถึงสำคัญกับพรอมป์บนเว็บ
FedCM คือ Federated Credential Management API ซึ่งให้เบราว์เซอร์เป็นตัวกลางในการล็อกอินข้ามผู้ให้บริการโดยไม่ใช้คุกกี้บุคคลที่สาม โดยเบราว์เซอร์เรนเดอร์หน้าต่างเลือกบัญชีเองและติดต่อผู้ให้บริการตัวตนหลังผู้ใช้ยินยอมแล้วเท่านั้น การรองรับเริ่มที่ Chrome 117 ข้อกำหนดเดินอยู่ใน Federated Identity Working Group ของ W3C และ Google ย้าย Sign in with Google มาใช้ตั้งแต่เมษายน 2567 เมื่อ Chrome ยกเลิก API โฆษณาส่วนใหญ่ของ Privacy Sandbox ในวันที่ 17 ตุลาคม 2568 FedCM ยังคงอยู่ในเบราว์เซอร์
Meta เผยแพร่ข้อมูลคอนเวอร์ชันของล็อกอินแตะเดียวหรือไม่
ไม่ได้เผยแพร่ ประกาศฉบับนี้ไม่มีสัดส่วนการปล่อยใช้งาน ไม่มีรายละเอียดความพร้อมรายประเทศ ไม่มีกำหนดออกเวอร์ชันทั่วไปของ open beta และไม่มีตัวเลขคอนเวอร์ชันของ Single Sign On, Limited Login Data Refresh หรือ Fast App Switch ตัวเลขผลลัพธ์ใดที่ถูกผูกกับข่าวนี้จึงไม่ได้มาจากแหล่งข่าว การวัดผลที่เชื่อถือได้จริงมีทางเดียวคือเทียบก่อนและหลังบนกรวยสมัครสมาชิกของคุณเอง
Limited Login Data Refresh เปลี่ยนข้อมูลที่แอปได้รับหรือเปล่า
ไม่เปลี่ยน มันรีเฟรชเซสชันที่มีอยู่แล้ว ทำให้ Profile.current และ AuthenticationToken.current เป็นข้อมูลปัจจุบันเมื่อแอปกลับมาทำงานเบื้องหน้า และการเชื่อมต่อเดิมยังล็อกอินผู้ใช้ผ่าน LoginConfiguration ด้วยโหมดติดตามแบบ .limited เหมือนเดิม ตัว Limited Login เองไม่เปลี่ยน มันสร้างบนมาตรฐาน OpenID Connect และเปิดตัวในเดือนมกราคม 2564 เพื่อให้การใช้ Facebook Login ในแอป iOS ไม่ถูกนำไปใช้กับการปรับโฆษณาให้ตรงบุคคลหรือการวัดผล
ถ้าแอปหรือเว็บของคุณใช้ Facebook Login และการอัปเกรด SDK ครั้งล่าสุดผ่านไปโดยไม่มีบันทึกเรื่องโฟลว์ล็อกอิน นั่นคือสิ่งแรกที่ควรตรวจในสัปดาห์นี้ และถ้าต้องการสายตาคู่ที่สองมาช่วยดูว่าการเปลี่ยนแปลงฝั่งล็อกอินไปโผล่ที่รายงานการสมัครและรายงานแคมเปญอย่างไร ทีมงานยินดีช่วยดูให้
