Verification Checklist

From Facebook Developer Wiki

Jump to: navigation, search

The descriptions below explain how Facebook Platform's integration points should be used. They contain questions that give you an idea of the types of checks we will do through our Application Verification Program. All verified applications must also meet our http://www.facebook.com/terms.php, and all the documents incorporated therein, such as the Platform Principles and Policies.

Contents

1. Application Communication in General

Purpose

Facebook's various communication channels are tools for creating great social experiences that engage and delight, not surprise or deceive users. Applications should respect user identity, relationships and attention through honoring user choices, meeting their expectations, and being transparent about how features work. As users share information, they'll share application content too.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Landing Pages: Do the landing pages from links directly relate to the content around the link and not take a new user directly to the allow access page?
  • Content Quality: Does content avoid inappropriate language, unnecessary repetition and trademark violations?
  • Correctness: Is the Feed story grammatically correct with proper capitalization and punctuation?
  • Dual Communication: Does the application use a single Facebook “push” communication channel (e.g., Notifications, Feed, Requests, and Email) to deliver content based on a single user action?

2. Email

Purpose

Email serves to notify users of time-sensitive or user-requested application activity in their off-Facebook email inbox.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Directed Action: Is email content focused on actions taken by another user towards the recipient, or a transaction involving the recipient specifically?
  • Format: Is the email well formatted (avoids excessive white space, font sizes, colors)?
  • Opt in: Does the application offer an opt-in and opt-out option for receiving emails for promotional, newsletter, or market research purposes?
  • Soliciting Email Addresses: For other emails not controlled by Facebook's opt-in, are email addresses solicited with clear explanation of intended usage, provide a setting to opt back out, and contain a privacy policy link directly near the solicited email information?

3. Requests

Purpose

Requests ask or prompt a user to take an action that will change something. And unless the user responds, nothing will change. For example, requests are used to request permission to change user status, content, event attendance status or friend connections. If content will change without action by the recipient, a notification about the change would be more appropriate. Though many requests today are actually invitations wrapped within a question, invitations are a sub-category of requests.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Requires Action: Is the request sent only because specific action is required by the user?
  • Substantive: Once accepted, does the request actually change something?
  • Non-Forced: If the sending user does not wish to send a request, does the user have the clear option to opt-out, with a compliant skip mechanism?
  • Flow: Does the application only ask for invites/requests after the user has performed or received a certain action (i.e., completion of an action is not preceded by an invite screen)?
  • Language: Does the application use language about "allowing" an application "access" (instead of the deprecated "install" or "add" language)?
  • Login: If a request is sent to a non-application user, can that user view the content, respond to the request and interact with the request without being presented with the allow screen?
  • Repeated requests: Does the application encourage the user not to send the same requests repeatedly to the same friend?

4. User-to-User Notifications

Purpose

User-to-user notifications inform a user of a change in content that has already taken place, almost always public content changed by another user and typically as a directed action towards the recipient.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Social: Is the notification social? Does the notification involve the sender in addition to the recipient?
  • Directed: Does the notification involve action taken on or regarding the recipient?
  • Expectedness: Is it understood by the sender that a particular action will result in a notification being sent to the specific recipients?
  • Publicness: If the user does not explicitly consent to the notification, is the notification about content that is otherwise public information accessible to the receiver?
  • Consent: If user consent is solicited (e.g., for non-public information), is the option clear and visible to users (i.e., not a small checkbox in the corner that's enabled by default)?
  • No Required Action: Does the notification focus on communicating information and avoid asking for users to take action?
  • Links: Is there a link to the content that the notification references? Does the link take the app user to the action described?

5. Application-to-User Notifications

Purpose

Application-to-user notifications are sent on an application's behalf to a user of the application and do not require an active session. These do not need to be triggered by or pertain to social actions.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Targeted: Is the notification targeted to the user?
  • Directed: Does the notification involve application information directly relevant to the receiving user or something in which the user has expressed interest?
  • Informative: Does the notification provide useful information to the user and link to relevant content when appropriate?
  • Voice: Is the notification written in the voice of the application (versus a sending friend)?
  • Promotion: Does the notification avoid reference to other applications and/or advertisements? Note: Advertisements in notifications can be addressed as a policy issue see here.

6. News Feed Stories

Purpose

Unlike notifications, which communicate about changes in a user's own content, Feed stories expose new content or actions that the user's friends have taken.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Completeness: Does the Feed story completely answer the question "what did the user do (and to whom)?" without masking pieces of information?
  • Accuracy: Does the Feed story accurately represent an explicit user action?
  • Short stories: Do short stories make use of available space to provide viewers with an excerpt/abstract directly related to the action?
  • Flow: Does the application avoid presenting the user with multiple Feed forms in a row?
  • Format/Layout:
    • One line stories should be succinct, communicate the entire story, link to the featured content, and not include any promotional links or explicit calls to action.
    • Headlines for short stories should be succinct, summarize the action, not duplicate content in story body, link to relevant content, and not include promotional links or explicit calls to action.
    • Story body should highlight the featured content, not repeat information in the headline, and not include promotional links or explicit calls to action.
    • Links: All links should go to pages that don't require.
    • Links: Does the application use action links relevant to the action being published (see Action Links)?
    • Links: Does the application meet the criteria in our Action Link Guidelines?

7. Publisher

Purpose

The Publisher lets applications provide functionality for posting rich content to a user's own Wall or their friends' Walls. Applications can provide different content options or publishing interfaces for a user's own profile versus those of the user's friends'. Checklist

8. Tabs

Purpose

Application tabs allow users to feature their favorite applications and to personalize their profiles with rich application content. Tabs should focus on sharing information about a user and can be highly dynamic and interactive.

Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • User-focus: Does the tab prominently and predominantly show information about the user?
  • Substance: Has the user entered enough data or engaged with your application enough for your profile tab to be compelling?

9. Application Info Sections

Purpose

Application info sections allow users to express their interests in a structured, easily digestible form. This information tends to change infrequently and helps friends learn more about a user.

Checklist

10. Profile Boxes

Purpose

Profile boxes share basic application information about the user. Boxes can appear on the left-hand column on the Wall and Info tabs, as well as on the Boxes tab.

Checklist

11. Message Attachments

Purpose

Message attachments highlight or share information privately between users. Generally, the content is new or a point of reference. Checklist

  • Policy: Is the usage of this channel in compliance with the Facebook Platform Principles and Policies and the Statement of Rights and Responsibilities?
  • Language: Does the message attachment button text begin with a verb?
  • Clarity: Does the message attachment button text make it clear what the attachment will be?
  • Accuracy: Does the resulting message attachment act as expected?

12. Application Content in General

Checklist

  • Does the application provide a way to report content that users have generated?
  • Does the application respond to reports of inappropriate user-generated content?

See Also