Facebook Login Review筆記 Day 1 - Overview
由於今年的4月30日Facebook Graph API 1.0即將退休,取而代之的是2.0+,因此從年初開始,一直收到Facebook的Alert - "You have less than 85 days to upgrade 1 active app to Graph API v2.0 or above."。為了避免App被break,我開始對使用1.0的App做修改來提交Review。以下是一些筆記。
我們來看一下2.0改了什麼。
Facebook Graph API v2.0: What's Changed?
-
取得更少的使用者資料
-
App將無法再取得Global User Ids,而只能取得Application-Specific ID。
- global user ids:App彼此通用此ID
- application-specific ids:每個App所取得的使用者ID並不相同,不能共用
-
App只能取得授權給此App的好友(Application-Specific Friends),而不能再取得所有的好友。
- v1.0:列出的全部好友
- v2.0+:只會列出授權給此應用程式的好友
-
App將無法再取得Global User Ids,而只能取得Application-Specific ID。
-
Application-Specific IDs
- 每個App對每個使用者將取得不同的ID(Application-Specific ID)。
-
如果分別建立兩個App給開發與真正的產品使用,這兩個App所取到同一使用者的Application-Specific ID是不同的,可能會造成開發上的困擾。
- Sol:Test Apps(建立測試APP,即可分享同一個Application-Specific ID,Test App規則與其Parent App相同)。
-
- 使用者登入兩個App,即可使用Graph API分別得到Application-Specific ID,對照是否為同一個使用者。
-
限制:Business Manager必須為同一機構/單位。
//範例程式碼 FB.api( "/me/ids_for_business", function (response) { if (response && !response.error) { /* handle the result */ } } ); //結果 { "data": [ { "id": "10153949089790582", "app": { "name": "Business's App 1", "namespace": "business_app_1", "id": "647733625268125" } }, { "id": "605665581", "app": { "name": "Business's App 2", "namespace": "business_app_2", "id": "370612223054807" } }, { "id": "10154053730190582", "app": { "name": "Business's App 3", "namespace": "business_app_3", "id": "194890427204075" } } ] }
看來這是一個重大改版,很自然的會要我們做提交。那我們就來看看Reivew的範圍、標準、範例與步驟。
Login Review的範圍、標準
範圍:若是要求以下基本資訊(basic permissions),不需做Login Review
- public_profile
- user_friends
除此之外,都需要進行Login Review。
標準
- Utility: 請求的權限必須明確改善用戶體驗。
- Visibility: 經由權限取得的資料必須被使用,而不是取得但尚未決定如何使用。例如:取得publish_actions,但沒有做Graph API分享的動作。
備註:Facebook建議要求的額外權限數要低於4個權限,若超過4個權限將降低登入的轉換率。
範例:Examples of approvable and non-approvable permissions use
範例1:取得「user_likes」來做個人化的推薦
- 用途:使用「
user_likes
」來取得使用者按讚的所有資訊,而這些資訊應該要被用來優化App的體驗,例如提供客製化的內容給使用者。 -
範例:經由使用者的like資訊來推薦使用者特定內容。
-
備註:使用「
user_likes
」權限來確認使用者是否對特定頁面按讚的狀況是不會被允許的。- 例如:要求使用者對特定粉絲頁按讚,若按讚可獲得獎勵,不按讚可能無法執行後續活動。但這在去年就已經提醒開發者了 - 由於Facebook禁止第三方網站或平台獎勵使用者按讚加入粉絲團或點擊進入社群附屬軟體,防止洗讚(但我們可在Facebook站內對粉絲頁按讚)。另外也是希望經營者修正經營策略,經由正當方式得到真正的粉絲,而非使用利誘強迫的方式增加粉絲數,得到曝光在動態牆上的機會。給網站或平台的緩衝修改時間至2014/11/05。參考 Facebook updates app settings page to give you more control。
範例2:取得「user_activities」來做個人化的推薦
- 用途:使用取得「user_activities」來做個人化的推薦。
- 範例:經由使用者過去參加過的活動來推薦類似的活動項目或資訊。
- 參考資訊:Login Review - user_activities
如何提交Login Review?
App提交Reivew時必須有實際的功能,Review Team會以使用者的觀點來驗證。
在提交Reivew之前,必須測試每個要求的權限...
- 確認使用者在授權時,跳出的popup有顯示所有此App要求的權限
- 每個使用者皆可登入、授權、測試
- 測試此App可以存取經由授權而取得的內容
測試者的角色為admins、developers、testers和test users。
步驟
Step 1: Create a submission
- 從Status & Review tab,選擇要送審的權限,點選Submit來Reivew。
- 確認任何指定的平台皆可登入,設定參考Basic Settings - Platforms。
Step 2: Add Notes for Each Permission
增加註解,這些註解都必須使用英文撰寫。
Step 3: Provide Utility & Step-by-Step Instructions
解釋如何提升使用者體驗,並一步步的解說功能使用的方法。這部份也是要用英文撰寫,使用中文會被退回噢!
Step 4: Complete Submission Form
Within the App Details tab:
- Logo
- Long Description
- Privacy Policy
Within the Status & Review tab
- 此Appy在做什麼
- 至少放4張Screenshots
- A version of your iOS / Android app: provisioned IPA/APK file or Apple Store ID/Android Package Name
Step 5: Submit for Review
結果將會顯示在Status and Review page,下圖是一個正在Review的App,但審核沒有通過,下面會列出沒有通過的理由。
我的經驗是提交完後,一天內或一天就會回覆。圖片和文字說明要用點心,要把他們當成完全不熟悉網站功能的使用者,因為Reivew Team一旦有疑惑或卡住就會Reject了。
例如第一次被退件的理由是網站登入按鈕不夠明顯,而且必須和Facebook的品牌一致 XD
(Your app's Login with Facebook button needs to be easily recognizable and consistent with the Facebook brand.)
Related Articles
- Facebook Login Review筆記 Day 2 - Policies and Best Practices
- Upgrade Guide - Upgrading from v1.0 to v2.0
留言