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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLE-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 ได้โดยใช้ การประทับเวลาของเหตุการณ์และรุ่นอุปกรณ์

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

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

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

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

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

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

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

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

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

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

สถานะการสมัครใช้บริการเครือข่ายมือถือ

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

โฆษณา

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

การวัดผล

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

Conversion

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

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

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

วิธีแก้ปัญหาที่ทำได้มีดังนี้

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

การพัฒนาแอป

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

การทดสอบแอป

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

ความปลอดภัย

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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

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

ในกรณีนี้ แอปของคุณต้องการปกป้องการเข้าถึงทรัพย์สินทางปัญญาหรือเนื้อหาที่ต้องชำระเงินอย่างไม่สุจริต

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

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

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

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

ทำไมจึงแนะนำวิดีโอนี้

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