利用目的、串接對象（POS／EC／分析等）的申告

應用程式登錄利用目的串接對象類別 User系審查

本文的對象
適用於在 ReceiptRoller 登錄應用程式的開發者。說明在應用程式登錄表單申告的「利用目的」與「串接對象類別」的意義、選法、店鋪端的呈現方式。

在 ReceiptRoller，登錄應用程式時會請您申告利用目的與串接對象類別。這是為了讓店鋪使用者能一眼理解「這個應用程式是為了什麼的應用程式」，會在授權畫面、串接應用程式一覽、User 系權限範圍的審查等處被參照。

為什麼需要申告

店鋪使用者的判斷材料：在授權畫面上可判斷「可否將資料交給這個應用程式」
適當權限範圍範圍的確認：用途與要求權限範圍是否矛盾，可在 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 官方帳號所發送的
顧客訊息與自家 CRM（Salesforce）串接，與過去的購買紀錄
關聯，以提升應對品質。

串接資料：
・LINE Webhook 投放的訊息、追蹤事件
・從 ReceiptRoller 取得的購買紀錄（receipt.read）

資料保管：
・東京區域的 AWS（自家管理）
・不進行對第三方的提供
・保管期間為自最終取得起 13 個月，之後自動刪除

利用範圍：僅限簽約店鋪的業主、店長。不對員工、公司外揭露。

填入範例（不足的範例）

使用收據資料提供服務。

因為沒有寫為了誰、為了什麼、送往何處，店鋪端無法判斷。要求 User 系權限範圍的情況下，僅此記述審查無法通過。

申告內容顯示的場所

OAuth 授權畫面：店鋪使用者按下「許可」前，作為「這個應用程式的利用目的」顯示
串接應用程式一覽：店鋪管理畫面的「串接應用程式」區段
串接應用程式商店：也可從其他店鋪搜尋的應用程式的情況，在一覽頁面使用
User 系權限範圍審查：審查負責人確認的主要資料

想變更時

申告內容可從開發者入口 → 應用程式 → 「設定」分頁隨時編輯。但請注意下列各點。

類別變更：即時反映。不影響既有的已授權使用者
利用目的的大幅變更：變更「資料的送往對象」「保管期間」「有無第三方提供」等重要事項時，既有使用者的重新同意可能會成為必要
User 系權限範圍已審查完的情況：改變利用目的的主旨會成為重新審查

注意：請避免「先廣泛地寫」「在實作決定前就寫」。與實態不符的申告，會在審查時的聽證，或店鋪的洽詢時，作為矛盾而顯在化。建議在實作的方針確定後再記述。

使用 User 系權限範圍時的追加資訊

在處理一般消費者的資料（user.receipts.read 等）的應用程式中，除了利用目的外，還會要求提出下列資訊。

隱私權政策的 URL（須公開）
使用條款的 URL（任意）
刪除委託的受理窗口（電子郵件地址或表單 URL）
資料保管期間與刪除政策
有無第三方提供與提供對象
需要審查用測試帳戶的情況則備妥之

這些若未備齊，User 系權限範圍的審查無法通過，或無法進到審查開始。詳情在下節「User 系權限範圍的審查申請」解說。

常見問題

Q. 符合多個類別。全部選也可以嗎？

A. 請縮減至關聯較深者。3 個左右為參考。比起網羅式地選，明示主目的更容易獲得店鋪的信賴。

Q. 開發初期目的還沒確定。可以暫時登錄嗎？

A. 開發用應用程式（非正式的別應用程式）的話，暫時的記述即可。但正式應用程式，請作成沿著實際用途的記述。

Q. 利用目的可以用英文寫嗎？

A. 請配合授權畫面顯示的地區。日本的店鋪向以日文，海外向建議英文。也可以用雙語寫。

Q. 申告內容誰都看得到嗎？

A. 因為會顯示於授權畫面與串接應用程式一覽，授權的使用者看得到。公開至串接應用程式商店的情況任何人都可檢視。請勿記述公司內向的機密資訊。