การแจ้งวัตถุประสงค์การใช้งาน・ปลายทางเชื่อมต่อ（POS／EC／การวิเคราะห์ ฯลฯ）

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

บทความนี้เหมาะสำหรับใคร
สำหรับนักพัฒนาที่จะลงทะเบียนแอปใน ReceiptRoller บทความนี้อธิบายความหมาย, วิธีเลือก และมุมมองจากฝั่งร้านค้า ของ "วัตถุประสงค์การใช้งาน" และ "หมวดหมู่ปลายทางเชื่อมต่อ" ที่แจ้งในฟอร์มลงทะเบียนแอป

ใน ReceiptRoller เมื่อลงทะเบียนแอป คุณจะต้องแจ้งวัตถุประสงค์การใช้งานและหมวดหมู่ปลายทางเชื่อมต่อ สิ่งนี้มีไว้เพื่อให้ผู้ใช้ฝั่งร้านค้าเข้าใจได้ในทันทีว่า "แอปนี้เป็นแอปเพื่ออะไร" และจะถูกอ้างอิงในหน้าจ authorization・รายการแอปที่เชื่อมต่อ・การตรวจสอบสโคปตระกูล User เป็นต้น

ทำไมต้องแจ้ง

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

หมวดหมู่ปลายทางเชื่อมต่อ

ตอนลงทะเบียนแอป ให้เลือกหมวดหมู่ปลายทางเชื่อมต่อที่ใกล้เคียงที่สุดตั้งแต่ 1 หมวดขึ้นไป หากตรงกับหลายหมวด สามารถเลือกหลายหมวดได้

หมวดหมู่	ปลายทางเชื่อมต่อที่คาดการณ์	สโคปที่ใช้เป็นหลัก
POS	ระบบแคชเชียร์・POS（Smaregi, Square เป็นต้น）	`store.read` / `receipt.write`
EC	เว็บไซต์ EC（Shopify, BASE, makeshop เป็นต้น）	`order.read` / `product.write`
OMS	ระบบจัดการคำสั่งซื้อ	`order.` / `shipment.`
WMS	ระบบจัดการคลังสินค้า・จัดการสต็อก	`inventory.` / `warehouse.`
PIM	จัดการมาสเตอร์สินค้า	`product.*`
การวิเคราะห์（BI）	เครื่องมือ BI・แดชบอร์ด（Looker, Tableau เป็นต้น）	`analytics.read` / `*.read` ต่างๆ
CRM	เครื่องมือจัดการลูกค้า・MA	`customer.*` / `user.profile`
SNS／โฆษณา	เครื่องมือเชื่อมต่อ SNS・กระจายโฆษณา	`sns.` / `campaign.`
บัญชี・ออกใบแจ้งหนี้	ซอฟต์แวร์บัญชี・ระบบออกใบแจ้งหนี้	`billing.read` / `receipt.read`
วอลเล็ต／สำหรับผู้บริโภค	แอปจัดการใบเสร็จสำหรับผู้บริโภค ฯลฯ	`user.receipts.read`（ตระกูล User・ต้องตรวจสอบ）
อื่นๆ	การใช้งานที่ไม่ตรงกับข้างต้น	แล้วแต่กรณี

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

วัตถุประสงค์การใช้งาน（ข้อความอิสระ）

นอกจากเลือกหมวดหมู่แล้ว ให้เขียนวัตถุประสงค์การใช้งานด้วยความยาว 200〜800 ตัวอักษร โดยต้องมี 3 ข้อต่อไปนี้เสมอ

เพื่อใคร：สำหรับเจ้าของร้าน／สำหรับพนักงานร้าน／สำหรับผู้บริโภคทั่วไป／ภายในบริษัทเท่านั้น ฯลฯ
ทำอะไร：นำข้อมูลที่ดึงมาไปใช้อย่างไร（ซิงค์, แสดงผล, วิเคราะห์, กระจาย ฯลฯ）
ส่งไปที่ไหน：ที่จัดเก็บ・ที่ประมวลผลข้อมูล（คลาวด์ของบริษัทเอง, บริการบุคคลที่สาม, รีเจียนต่างประเทศ ฯลฯ）

ตัวอย่างการกรอก（ตัวอย่างที่ดี）

แอปนี้มีวัตถุประสงค์เพื่อเชื่อมต่อข้อความลูกค้าที่ส่งจาก LINE Official Account
ที่เจ้าของร้านดำเนินการ เข้ากับ CRM ของบริษัทเอง (Salesforce) แล้วผูกกับ
ประวัติการซื้อในอดีต เพื่อยกระดับคุณภาพการตอบกลับ

ข้อมูลที่เชื่อมต่อ：
・ข้อความ・ฟอลโลว์อีเวนต์ที่ส่งผ่าน LINE Webhook
・ประวัติการซื้อที่ดึงจาก ReceiptRoller（receipt.read）

การจัดเก็บข้อมูล：
・AWS รีเจียนโตเกียว（บริษัทจัดการเอง）
・ไม่มีการให้ข้อมูลแก่บุคคลที่สาม
・ระยะเวลาจัดเก็บ 13 เดือนนับจากดึงข้อมูลครั้งสุดท้าย จากนั้นลบอัตโนมัติ

ขอบเขตการใช้งาน：เฉพาะเจ้าของ・ผู้จัดการร้านค้าคู่สัญญาเท่านั้น ไม่เปิดเผยแก่พนักงาน・บุคคลภายนอก

ตัวอย่างการกรอก（ตัวอย่างที่ไม่เพียงพอ）

ให้บริการโดยใช้ข้อมูลใบเสร็จ

เนื่องจากไม่ได้เขียนว่าเพื่อใคร, เพื่ออะไร, ส่งไปที่ไหน ฝั่งร้านค้าจึงตัดสินใจไม่ได้ หากร้องขอสโคปตระกูล User การตรวจสอบจะไม่ผ่านด้วยคำอธิบายเพียงเท่านี้

ที่ที่เนื้อหาการแจ้งจะแสดง

หน้าจ authorization ของ OAuth：แสดงเป็น "วัตถุประสงค์การใช้งานของแอปนี้" ก่อนที่ผู้ใช้ฝั่งร้านค้าจะกด "อนุญาต"
รายการแอปที่เชื่อมต่อ：เซกชัน "แอปที่เชื่อมต่อ" ในหน้าจอจัดการของร้านค้า
สโตร์แอปที่เชื่อมต่อ：ใช้ในหน้ารายการ กรณีเป็นแอปที่ค้นหาได้จากร้านค้าอื่นด้วย
การตรวจสอบสโคปตระกูล User：เป็นเอกสารหลักที่ผู้ตรวจสอบใช้ดู

เมื่อต้องการเปลี่ยนแปลง

เนื้อหาการแจ้งสามารถแก้ไขได้ตลอดเวลาจาก พอร์ทัลนักพัฒนา → แอป → แท็บ "การตั้งค่า" แต่โปรดระวังประเด็นต่อไปนี้

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

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

ข้อมูลเพิ่มเติมกรณีใช้สโคปตระกูล User

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

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

หากสิ่งเหล่านี้ไม่ครบ การตรวจสอบสโคปตระกูล User จะไม่ผ่านหรือไม่สามารถเริ่มการตรวจสอบได้ รายละเอียดอธิบายไว้ในหัวข้อถัดไป "การยื่นขอตรวจสอบสำหรับสโคปตระกูล User"

คำถามที่พบบ่อย

Q. แอปตรงกับหลายหมวดหมู่ เลือกทั้งหมดได้ไหม?

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

Q. ช่วงต้นของการพัฒนา วัตถุประสงค์ยังไม่นิ่ง ลงทะเบียนแบบชั่วคราวได้ไหม?

A. หากเป็นแอปสำหรับพัฒนา（แอปแยกที่ไม่ใช่โปรดักชัน）คำอธิบายชั่วคราวก็เพียงพอ แต่แอปโปรดักชันโปรดเขียนให้ตรงกับการใช้งานจริง

Q. เขียนวัตถุประสงค์การใช้งานเป็นภาษาอังกฤษได้ไหม?

A. โปรดปรับให้เข้ากับภูมิภาคที่หน้าจ authorization จะแสดง สำหรับร้านค้าในญี่ปุ่นให้ใช้ภาษาญี่ปุ่น สำหรับต่างประเทศแนะนำภาษาอังกฤษ จะเขียนทั้งสองภาษาก็ได้

Q. เนื้อหาการแจ้งใครเห็นได้บ้าง?

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

คู่มือที่เกี่ยวข้อง

วันที่เผยแพร่: 2569-04-27 วันที่อัปเดต: 2569-07-05

กลับไปที่รายการวิธีใช้งาน

หมวดหมู่

ทั้งหมด ทั่วไป 14 Webhook 6 การแก้ปัญหา 6 การลงทะเบียนแอปพลิเคชัน 5 คู่มือตามประเภทข้อมูล 5 พื้นฐาน API 5 การดำเนินงานและความปลอดภัย 4 เริ่มต้นใช้งาน 4 การยืนยันตัวตนและข้อมูลรับรอง 3 คู่มือแยกตามโดเมนข้อมูล 3

แท็ก

API (22) OAuth (15) Android (10) iOS (9) Webhook (8) api (7) oauth (5) getting-started (4) การลงทะเบียนแอป (4) การแก้ปัญหา (4)

บทความที่เกี่ยวข้อง