แนวทางปฏิบัติที่ดีที่สุดสำหรับตัวระบุที่ไม่ซ้ำกัน

เอกสารนี้มีคำแนะนำในการเลือกตัวระบุที่เหมาะสมสำหรับแอปตาม Use Case ของคุณ

หากต้องการดูภาพรวมของสิทธิ์ของ Android โปรดดูที่สิทธิ์ ภาพรวม ดูแนวทางปฏิบัติแนะนำที่เฉพาะเจาะจงสำหรับการใช้สิทธิ์ Android ได้ที่แนวทางปฏิบัติแนะนำเกี่ยวกับสิทธิ์ของแอป

แนวทางปฏิบัติแนะนำสำหรับการทำงานกับตัวระบุ Android

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

  1. เลือกตัวระบุที่ผู้ใช้รีเซ็ตได้หากเป็นไปได้ แอปของคุณจะทํา Use Case ส่วนใหญ่ได้แม้ว่าจะใช้ตัวระบุอื่นที่ไม่ใช่รหัสฮาร์ดแวร์ที่รีเซ็ตไม่ได้ก็ตาม

  2. หลีกเลี่ยงการใช้ตัวระบุฮาร์ดแวร์ ใน Use Case ส่วนใหญ่ คุณหลีกเลี่ยงการใช้ตัวระบุฮาร์ดแวร์ เช่น หมายเลขระบุฮาร์ดแวร์ International Mobile Equipment Identity (IMEI) ได้โดยไม่จำกัดฟังก์ชันการทำงานที่จำเป็น

    Android 10 (API ระดับ 29) เพิ่มข้อจำกัดสำหรับตัวระบุที่รีเซ็ตไม่ได้ ซึ่งจะมีทั้ง IMEI และหมายเลขซีเรียล แอปของคุณต้องเป็นอุปกรณ์หรือ เจ้าของโปรไฟล์ แอป มีผู้ให้บริการขนส่งพิเศษ สิทธิ์ หรือมี สิทธิ์ READ_PRIVILEGED_PHONE_STATE เพื่อเข้าถึง ตัวระบุเหล่านี้

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

  4. อย่าเชื่อมกับการรีเซ็ตรหัสโฆษณา

  5. ใช้รหัสการติดตั้ง Firebase (FID) หรือ GUID ที่เก็บไว้แบบส่วนตัวทุกครั้งที่เป็นไปได้สำหรับ Use Case อื่นๆ ทั้งหมด ยกเว้นการป้องกันการประพฤติมิชอบทางการชำระเงินและการโทรคมนาคม สำหรับ Use Case ที่ไม่ใช่โฆษณาส่วนใหญ่ FID หรือ GUID ก็เพียงพอแล้ว

  6. ใช้ API ที่เหมาะสมกับ Use Case เพื่อลดความเสี่ยงด้านความเป็นส่วนตัว ใช้ DRM API สำหรับ การปกป้องเนื้อหาที่มีคุณค่าสูงและ Play Integrity API สำหรับการป้องกันการละเมิด Play Integrity API เป็นวิธีที่ง่ายที่สุดในการพิจารณาว่าอุปกรณ์เป็นของจริงหรือไม่โดยไม่ก่อให้เกิดความเสี่ยงด้านความเป็นส่วนตัว

ส่วนที่เหลือของคู่มือนี้จะอธิบายกฎเหล่านี้ในบริบทของการพัฒนาแอป Android

ทำงานร่วมกับรหัสโฆษณา

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

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

"...หากมีการรีเซ็ต ตัวระบุโฆษณาใหม่ต้องไม่เชื่อมโยงกับตัวระบุโฆษณาก่อนหน้านี้ หรือข้อมูลที่ได้มาจากตัวระบุโฆษณาก่อนหน้านี้หากไม่ได้รับการยินยอมอย่างชัดแจ้งจากผู้ใช้"

เคารพการแจ้งว่าไม่เหมาะสมที่เกี่ยวข้องกับโฆษณาที่ปรับตามโปรไฟล์ของผู้ใช้เสมอ รหัสโฆษณาคือ ที่สามารถกำหนดค่าได้เพื่อให้ผู้ใช้จำกัดจำนวนการติดตามที่เชื่อมโยงกับแท็ก ID ใช้วิธีการ AdvertisingIdClient.Info.isLimitAdTrackingEnabled() เสมอเพื่อให้มั่นใจว่าคุณไม่ได้ละเมิดความต้องการของผู้ใช้ เนื้อหาสำหรับนักพัฒนาซอฟต์แวร์ Play นโยบายจะระบุนโยบาย ดังต่อไปนี้:

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

โปรดระวังนโยบายความเป็นส่วนตัวหรือนโยบายความปลอดภัยที่เกี่ยวข้องกับ SDK ที่คุณใช้ซึ่งเกี่ยวข้องกับการใช้รหัสโฆษณา ตัวอย่างเช่น หากคุณส่ง true ไปยัง enableAdvertisingIdCollection() จาก Google Analytics SDK อย่าลืมอ่านและปฏิบัติตาม Analytics SDK ที่เกี่ยวข้อง นโยบาย

นอกจากนี้ โปรดทราบว่านโยบายเนื้อหาสำหรับนักพัฒนาแอป Google Play กําหนดว่าตัวระบุโฆษณา "ต้องไม่เชื่อมโยงกับข้อมูลส่วนบุคคลที่ระบุตัวบุคคลนั้นได้ หรือเชื่อมโยงกับตัวระบุอุปกรณ์ถาวร (เช่น SSAID, ที่อยู่ MAC, IMEI เป็นต้น)"

ตัวอย่างเช่น สมมติว่าคุณต้องการรวบรวมข้อมูลเพื่อป้อนข้อมูลในตารางฐานข้อมูลที่มีคอลัมน์ต่อไปนี้

ตาราง 01
timestamp ad_id account_id clickid
ตาราง 02
account_id name dob country

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

โปรดทราบว่าลิงก์ระหว่างรหัสผู้ลงโฆษณากับ PII อาจไม่เป็นเช่นนี้เสมอไป อาจไม่เหมาะสม อาจมี "ตัวระบุแบบใกล้เคียง" ที่ปรากฏทั้งใน PII และตารางที่มีการคีย์รหัสโฆษณา ซึ่งก็อาจทำให้เกิดปัญหาเช่นกัน ตัวอย่างเช่น สมมติว่าเราเปลี่ยน TABLE-01 และ TABLE-02 ดังนี้

ตาราง 01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

ในกรณีนี้ เมื่อเหตุการณ์คลิกเกิดขึ้นน้อยมาก คุณยังคงเข้าร่วมระหว่างรหัสผู้ลงโฆษณา TABLE-01 กับ PII ที่มีอยู่ใน TABLE-02 ได้โดยใช้การประทับเวลาของเหตุการณ์และรุ่นอุปกรณ์

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

วิธีแก้ปัญหาอื่นๆ มีดังนี้

  • ไม่ออกแบบตารางที่ลิงก์ PII กับรหัสโฆษณาอย่างชัดเจน ในตัวอย่างแรกด้านบน การดำเนินการนี้จะหมายถึงการไม่รวมคอลัมน์ account_id ใน TABLE-01

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

    1. แยกรายการควบคุมการเข้าถึง (ACL) สำหรับข้อมูลที่เข้ารหัสด้วยรหัสผู้ลงโฆษณาและ PII ออกจากกันเพื่อลดจํานวนบุคคลหรือบทบาทที่อยู่ในทั้ง 2 ACL
    2. ใช้การบันทึกการเข้าถึงและการตรวจสอบเพื่อตรวจหาและจัดการข้อยกเว้น ลงในกฎนี้

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการทำงานอย่างมีความรับผิดชอบกับรหัสโฆษณา โปรดดูที่ AdvertisingIdClient เอกสารอ้างอิง API

ทำงานกับ FID และ GUID

โซลูชันที่ตรงที่สุดในการระบุอินสแตนซ์แอปที่ทํางานบนอุปกรณ์คือการใช้รหัสการติดตั้ง Firebase (FID) ซึ่งเป็นโซลูชันที่แนะนําใน Use Case ส่วนใหญ่ที่ไม่ใช่โฆษณา เฉพาะอินสแตนซ์ของแอปที่ ซึ่งได้รับการจัดสรรจะสามารถเข้าถึงตัวระบุนี้ได้ (ค่อนข้าง) ง่าย รีเซ็ตได้ เนื่องจากจะยังคงอยู่ตราบใดที่มีการติดตั้งแอปไว้

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

ในกรณีที่ FID ไม่เหมาะสําหรับการใช้งาน คุณสามารถใช้รหัสที่ไม่ซ้ำกันทั่วโลก (GUID) ที่กําหนดเองเพื่อระบุอินสแตนซ์ของแอปที่ไม่ซ้ำกันได้ วิธีง่ายที่สุดในการทำเช่นนี้คือการสร้าง GUID ของคุณเองโดยใช้โค้ดต่อไปนี้

Kotlin

var uniqueID = UUID.randomUUID().toString()

Java

String uniqueID = UUID.randomUUID().toString();

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

ไม่ทำงานกับที่อยู่ MAC

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

การเปลี่ยนแปลงความพร้อมใช้งานของที่อยู่ MAC ใน Android 11

ในแอปที่กำหนดเป้าหมายเป็น Android 11 ขึ้นไป การสุ่ม MAC สำหรับ Passpoint เป็นเครือข่ายต่อโปรไฟล์ Passpoint ซึ่งจะสร้างที่อยู่ MAC ที่ไม่ซ้ำกันตาม ฟิลด์ต่อไปนี้:

  • ชื่อโดเมนแบบสมบูรณ์ในตัวเอง (FQDN)
  • Realm
  • ข้อมูลเข้าสู่ระบบตามข้อมูลเข้าสู่ระบบที่ใช้ในโปรไฟล์ Passpoint
    • ข้อมูลเข้าสู่ระบบของผู้ใช้: ชื่อผู้ใช้
    • ข้อมูลเข้าสู่ระบบของใบรับรอง: cert และประเภทใบรับรอง
    • ข้อมูลเข้าสู่ระบบซิม: ประเภท EAP และ IMSI

นอกจากนี้ แอปที่ไม่มีสิทธิ์จะเข้าถึงที่อยู่ MAC ของอุปกรณ์ไม่ได้ เท่านั้น อินเทอร์เฟซเครือข่ายที่มีที่อยู่ IP จะปรากฏขึ้น ซึ่งจะส่งผลต่อวิธีgetifaddrs() และNetworkInterface.getHardwareAddress() รวมถึงการส่งข้อความ RTM_GETLINK Netlink

วิธีที่แอปได้รับผลกระทบจากการเปลี่ยนแปลงนี้มีดังนี้

  • NetworkInterface.getHardwareAddress() แสดงผล Null สำหรับทุกอินเทอร์เฟซ
  • แอปใช้ฟังก์ชัน bind() ในซ็อกเก็ต NETLINK_ROUTE ไม่ได้
  • คำสั่ง ip จะไม่แสดงข้อมูลเกี่ยวกับอินเทอร์เฟซ
  • แอปไม่สามารถส่งข้อความ RTM_GETLINK ได้

โปรดทราบว่านักพัฒนาซอฟต์แวร์ส่วนใหญ่ควรใช้ API ระดับที่สูงกว่า ConnectivityManager แทนที่จะเป็น API ระดับล่าง เช่น NetworkInterface getifaddrs() หรือ Netlink Sockets ตัวอย่างเช่น แอปที่ต้องการข้อมูลล่าสุดเกี่ยวกับเส้นทางปัจจุบันสามารถรับข้อมูลนี้ได้โดยคอยฟังการเปลี่ยนแปลงของเครือข่ายโดยใช้ ConnectivityManager.registerNetworkCallback() และเรียกใช้ LinkProperties.getRoutes() ที่เชื่อมโยงกับเครือข่าย

ลักษณะของตัวระบุ

ระบบปฏิบัติการ Android มีรหัสหลายรายการที่มีลักษณะการทํางานแตกต่างกัน รหัสที่คุณควรใช้จะขึ้นอยู่กับวิธีการทำงานของลักษณะเฉพาะต่อไปนี้ Use Case ของคุณ อย่างไรก็ตาม ลักษณะเหล่านี้ก็อาจมีผลต่อความเป็นส่วนตัวด้วย คุณจึงควรทำความเข้าใจว่าลักษณะเหล่านี้ส่งผลต่อกันและกันอย่างไร

ขอบเขต

ขอบเขตตัวระบุจะอธิบายว่าระบบใดเข้าถึงตัวระบุได้ แอนดรอยด์ ขอบเขตตัวระบุโดยทั่วไปมี 3 แบบ ดังนี้

  • แอปเดียว: รหัสนี้เป็นรหัสภายในแอปและแอปอื่นๆ เข้าถึงไม่ได้
  • กลุ่มแอป: แอปที่เกี่ยวข้องซึ่งกำหนดไว้ล่วงหน้าสามารถเข้าถึงรหัสได้
  • อุปกรณ์: แอปทั้งหมดที่ติดตั้งในอุปกรณ์จะเข้าถึงรหัสได้

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

การรีเซ็ตและความต่อเนื่อง

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

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

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

ความเป็นเอกลักษณ์

ความเป็นเอกลักษณ์ทำให้เกิดการชนกัน ซึ่งก็คือความเหมือนกัน อยู่ในขอบเขตที่เกี่ยวข้อง ในระดับสูงสุด ตัวระบุที่ไม่ซ้ำกันทั่วโลกจะไม่ทับซ้อนกัน แม้แต่ในอุปกรณ์หรือแอปอื่นๆ มิฉะนั้น ระดับความไม่ซ้ำกันจะขึ้นอยู่กับเอนโทรปีของตัวระบุและ แหล่งที่มาของความสุ่มที่ใช้ในการสร้าง ตัวอย่างเช่น โอกาสในการ ค่า Collision สูงกว่ามากสำหรับตัวระบุแบบสุ่มซึ่งตั้งเด่นเป็นวันที่ตามปฏิทิน (เช่น 2019-03-01) มากกว่าตัวระบุที่ตั้งค่าด้วย Unix การประทับเวลาของการติดตั้ง (เช่น 1551414181)

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

การปกป้องความสมบูรณ์และการปฏิเสธความรับผิด

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

กรณีการใช้งานทั่วไปและตัวระบุที่เหมาะสม

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

บัญชี

สถานะผู้ให้บริการ

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

ตัวระบุที่แนะนําให้ใช้: IMEI, IMSI และ Line1

เหตุใดจึงแสดงรายการแนะนำนี้

คุณสามารถใช้ตัวระบุฮาร์ดแวร์ได้หากจำเป็นสำหรับ ฟังก์ชันการทำงานที่เกี่ยวข้องกับผู้ให้บริการ เช่น คุณอาจใช้ตัวระบุเหล่านี้เพื่อสลับระหว่างผู้ให้บริการเครือข่ายมือถือหรือช่องซิม หรือเพื่อส่งข้อความ SMS ผ่าน IP (สำหรับบรรทัดแรก) - บัญชีผู้ใช้ตามซิม อย่างไรก็ตาม สําหรับแอปที่ไม่มีสิทธิ์ เราขอแนะนําให้ใช้การลงชื่อเข้าใช้บัญชีเพื่อดึงข้อมูลอุปกรณ์ของผู้ใช้จากฝั่งเซิร์ฟเวอร์ เหตุผลหนึ่งก็คือใน Android 6.0 (API ระดับ 23) และ ตัวระบุเหล่านี้จะใช้ได้ในสิทธิ์รันไทม์เท่านั้น ผู้ใช้อาจ สลับปิดสิทธิ์นี้ เพื่อให้แอปของคุณควรจัดการข้อยกเว้นเหล่านี้ ด้วยความสง่างาม

สถานะการสมัครใช้บริการในอุปกรณ์เคลื่อนที่

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

ตัวระบุที่แนะนำให้ใช้: รหัสการสมัครใช้บริการ API ไปยัง ระบุซิมที่ใช้ในอุปกรณ์

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

ทำไมจึงให้คำแนะนำนี้

ปัจจุบันแอปบางแอปอาจใช้ ICCID เพื่อวัตถุประสงค์นี้ เนื่องจากรหัส ICC ไม่ซ้ำกันทั่วโลกและไม่สามารถรีเซ็ตได้ การเข้าถึง จำกัดไว้สำหรับแอปที่มีREAD_PRIVILEGED_PHONE_STATEเท่านั้น มาตั้งแต่ Android 10 เริ่มต้นด้วย Android 11 แต่เป็น Android มากกว่า จำกัดการเข้าถึง ICCID ผ่าน getIccId() API โดยไม่คำนึงถึงระดับ API เป้าหมายของแอป แอปที่ได้รับผลกระทบควรย้ายข้อมูลไปยัง ให้ใช้รหัสการสมัครใช้บริการแทน

การลงชื่อเพียงครั้งเดียว

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

ตัวระบุที่แนะนําให้ใช้: บัญชีที่เข้ากันได้กับผู้จัดการฝ่ายดูแลลูกค้า เช่น การลิงก์บัญชี Google

ทำไมจึงให้คำแนะนำนี้

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

โฆษณา

การกำหนดเป้าหมาย

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

ตัวระบุที่แนะนําให้ใช้: หากแอปใช้รหัสสําหรับโฆษณาและอัปโหลดหรือเผยแพร่ไปยัง Google Play รหัสนั้นต้องเป็นรหัสโฆษณา

เหตุใดจึงแสดงรายการแนะนำนี้

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

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

การวัดผล

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

ตัวระบุที่แนะนำให้ใช้: รหัสโฆษณาหรือ API ที่มาสำหรับการติดตั้งของ Play

ทำไมจึงให้คำแนะนำนี้

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

Conversion

ในกรณีนี้ คุณกําลังติดตาม Conversion เพื่อตรวจดูว่ากลยุทธ์ทางการตลาดประสบความสําเร็จหรือไม่

ตัวระบุที่แนะนําให้ใช้: Advertising ID หรือ Play Install Referrer API

ทำไมจึงให้คำแนะนำนี้

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

รีมาร์เก็ตติ้ง

ในกรณีนี้ แอปจะแสดงโฆษณาตามความสนใจที่ผ่านมาของผู้ใช้

ตัวระบุที่แนะนําให้ใช้: รหัสโฆษณา

ทำไมจึงให้คำแนะนำนี้

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

การวิเคราะห์แอป

ในกรณีนี้ แอปของคุณจะประเมินพฤติกรรมของผู้ใช้เพื่อช่วยคุณพิจารณา ดังต่อไปนี้

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

แนวทางแก้ปัญหาที่เป็นไปได้มีดังนี้

  • รหัสชุดแอป: รหัสชุดแอปช่วยให้คุณวิเคราะห์พฤติกรรมของผู้ใช้ใน แอปหลายแอปที่เป็นขององค์กรของคุณ ตราบใดที่คุณไม่ได้ใช้ข้อมูลผู้ใช้ เพื่อวัตถุประสงค์ในการโฆษณา หากคุณกำหนดเป้าหมายอุปกรณ์ที่ขับเคลื่อนโดย Google Play เราขอแนะนำให้คุณใช้รหัสชุดแอป
  • Firebase ID (FID): FID จะกำหนดขอบเขตอยู่ที่แอปที่สร้างรหัสขึ้น ซึ่ง ป้องกันไม่ให้ใช้ตัวระบุเพื่อติดตามผู้ใช้ข้ามแอป และยัง รีเซ็ตได้อย่างง่ายดาย เนื่องจากผู้ใช้สามารถล้างข้อมูลแอปหรือติดตั้งแอปอีกครั้ง กระบวนการสร้าง FID นั้นตรงไปตรงมา ดูการติดตั้ง Firebase

การพัฒนาแอป

รายงานข้อขัดข้อง

ในกรณีนี้ แอปจะรวบรวมข้อมูลเกี่ยวกับเวลาและสาเหตุที่แอปขัดข้องในอุปกรณ์ของผู้ใช้

ตัวระบุที่แนะนำให้ใช้: รหัส FID หรือรหัสชุดแอป

ทำไมจึงให้คำแนะนำนี้

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

การรายงานประสิทธิภาพ

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

ตัวระบุที่แนะนําให้ใช้: การตรวจสอบประสิทธิภาพ Firebase

เหตุใดจึงแสดงรายการแนะนำนี้

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

การทดสอบแอป

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

ตัวระบุที่แนะนำให้ใช้: รหัส FID หรือรหัสชุดแอป

ทำไมจึงให้คำแนะนำนี้

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

การติดตั้งข้ามอุปกรณ์

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

ตัวระบุที่แนะนำให้ใช้: FID หรือ GUID

เหตุใดจึงแสดงรายการแนะนำนี้

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

ความปลอดภัย

การตรวจจับการละเมิด

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

ตัวระบุที่แนะนำให้ใช้: โทเค็นความสมบูรณ์ของ Google Play Integrity API

เหตุใดจึงแสดงรายการแนะนำนี้

หากต้องการยืนยันว่าคำขอมาจากอุปกรณ์ Android จริง ไม่ใช่จากโปรแกรมจำลองหรือโค้ดอื่นๆ ที่แอบอ้างเป็นอุปกรณ์อื่น ให้ใช้ Google Play Integrity API

การฉ้อโกงผ่านโฆษณา

ในกรณีนี้ แอปจะตรวจสอบว่าการแสดงผลและการกระทำของผู้ใช้ในแอป เป็นของจริงและตรวจสอบได้

ตัวระบุที่แนะนำให้ใช้: รหัสโฆษณา

ทำไมจึงให้คำแนะนำนี้

จำเป็นต้องใช้รหัสโฆษณาสำหรับ Use Case การโฆษณา ตาม นโยบายเนื้อหาสำหรับนักพัฒนาแอป Google Play เพราะผู้ใช้สามารถรีเซ็ตได้

การจัดการสิทธิ์ดิจิทัล (DRM)

ในกรณีนี้ แอปของคุณต้องการปกป้องสิทธิการเข้าถึงทางปัญญาที่เป็นการฉ้อโกง หรือเนื้อหาที่ต้องชำระเงิน

ตัวระบุที่แนะนำให้ใช้: การใช้ FID หรือ GUID จะบังคับให้ผู้ใช้ต้องติดตั้งแอปอีกครั้งเพื่อหลีกเลี่ยงการจำกัดเนื้อหา ซึ่งถือเป็นภาระที่หนักพอที่จะยับยั้งผู้ใช้ส่วนใหญ่ หากวิธีนี้ยังไม่เพียงพอ Android มี DRM API ซึ่งสามารถ ใช้เพื่อจำกัดการเข้าถึงเนื้อหา ซึ่งรวมถึงตัวระบุต่อ APK รหัส Widevine

ค่ากำหนดของผู้ใช้

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

ตัวระบุที่แนะนําให้ใช้: FID หรือ GUID

ทำไมจึงให้คำแนะนำนี้

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