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

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

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

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

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

  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 ที่เหมาะกับกรณีการใช้งานของคุณเพื่อลดความเสี่ยงด้านความเป็นส่วนตัวให้เหลือน้อยที่สุด ใช้ DRM API เพื่อการปกป้องเนื้อหาที่มีมูลค่าสูง และ Play Integrity API เพื่อการปกป้องจากการละเมิด Play Integrity API เป็นวิธีที่ง่ายที่สุดในการระบุว่าอุปกรณ์เป็นของแท้หรือไม่โดยไม่ก่อให้เกิดความเสี่ยงด้านความเป็นส่วนตัว

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLE-01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

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

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

โซลูชันอื่นๆ ได้แก่

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

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

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

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

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

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

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

ในกรณีที่ 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)
  • ขอบเขต
  • ข้อมูลเข้าสู่ระบบ ซึ่งอิงตามข้อมูลเข้าสู่ระบบที่ใช้ในโปรไฟล์ Passpoint:
    • ข้อมูลเข้าสู่ระบบของผู้ใช้: ชื่อผู้ใช้
    • ข้อมูลเข้าสู่ระบบใบรับรอง: ใบรับรองและประเภทใบรับรอง
    • ข้อมูลเข้าสู่ระบบของ SIM: ประเภท 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 ตัวอย่างเช่น แอปที่ต้องการข้อมูลล่าสุดเกี่ยวกับเส้นทางปัจจุบันจะได้รับข้อมูลนี้โดยการฟังการเปลี่ยนแปลงเครือข่ายโดยใช้ ConnectivityManager.registerNetworkCallback() และโทรหา LinkProperties.getRoutes() ที่เชื่อมโยงของเครือข่าย

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

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

ขอบเขต

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

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

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

ความสามารถในการรีเซ็ตและความคงอยู่

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

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

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

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

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

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

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

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

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

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

บัญชี

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

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

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

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

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

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

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

ตัวระบุที่แนะนําให้ใช้: Subscription ID API เพื่อระบุ SIM ที่ใช้อยู่ในอุปกรณ์

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

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

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

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

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

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

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

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

โฆษณา

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

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

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

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

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

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

การวัดผล

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

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

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

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

Conversion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การพัฒนาแอป

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

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

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

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

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

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

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

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

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

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

การทดสอบแอป

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

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

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

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

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

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

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

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

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

ความปลอดภัย

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

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

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

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

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

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

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

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

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

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

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

ในกรณีนี้ แอปของคุณต้องการปกป้องการเข้าถึงที่เป็นการฉ้อโกงทรัพย์สินทางปัญญาหรือเนื้อหาที่ต้องซื้อ

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

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

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

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

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

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