Facebook開発者向けドキュメントの日本語訳とTips

http://developers.facebook.com/docs/ に記載されているdocumentationの和訳と、調べていて分かったノウハウを紹介します。
Life is tough, so are we.
ドキュメント全体の目次はこちら
Facebook関連情報はFacebookページで共有しています。

Feed Gaming

https://developers.facebook.com/docs/feed-gaming/


フィード上でのゲーム機能を実装することで、ユーザのエンゲージメントを高めることができます。この機能では、フラッシュオブジェクト付きのウォール投稿をユーザの代理として投稿することが可能です。ユーザの友だちは、その添付ファイルをクリックしてフィード上でゲームをプレイできます。これにより、縮小版のゲームをユーザの友だちに紹介し、ゲームの最後にはアプリのキャンバスページへの遷移を促すような流れを創り出すことになります。


attachment

利用例は以下の通りです。

  • 特定レベルでのハイスコアをウォール投稿し、友だちに挑戦させる
  • ユーザアクティビティのリプレイを投稿し、友だちが参考にしてレベルクリアできるようにする
  • 簡単なサンプルゲームを作成し、ユーザがフィード上で遊んでインストールするようにする
これは、潜在ユーザに対してプレビューを提供し、競争させて既存ユーザと共有させるのに最適な方法となります。

実際のゲームからの投稿は以下の通りです。

  • Angry Birdsでは、友だちのスコアに挑戦させる。試してみる
  • Bubble Witch Sagaはコインを友だちと共有し、スコアに応じて増やせる。試してみる
  • Idle Worshipは、ゲーム全体のサンプルが見れるミニゲームを共有させる。試してみる
  • Tetris Battle allows publishing a replay of a two-player battle. Try now. Tetris Battleでは、2ユーザ対戦のリプレイを投稿できる。試してみる

注意:フィード上でゲームをプレイするユーザは「匿名」となります。キャンバスページと違ってsigned_requestは渡されませんし、JavaScript SDKを初期化することもできません。ですので、そのユーザがアプリをインストール済みなのかは判別できず、潜在ユーザと既存ユーザの両方にとって有用な設計にしなくてはなりません。

Publishing a Feed Gaming story

Feed Gamingを投稿するには、以下のステップが必要です。

  1. 添付用のOpen Graphオブジェクトを生成する
  2. ユーザの代理として投稿する
  3. 投稿のエンゲージメントを追跡する

1. Create an Open Graph object for the attachment

まずはog:videoメタタグを実装するOpen Graphオブジェクトを生成します。このオブジェクトは、ユーザの代理として投稿する時、添付ファイルを扱うのに使われます。
名称 説明 必須
fb:app_id このオブジェクトを所有するアプリID true
og:type gameなど、適切なOpen Graph type
true
og:url ウォール投稿に使うユニークURL
true
og:title シェアされるウォール投稿のタイトル。例: 'Beat Gareth's high score' true
og:description ウォール投稿に使われる、このオブジェクト説明文 true
og:image オブジェクトを象徴する画像のURL。最低でも50 x 50pxで、アスペクト比は最大で3:1です。PNG, JPEG, GIFがサポートされています。
true
og:video 埋め込まれるSWFファイルのURL true
og:video:type swfファイルのレンダリングを指定します。application/x-shockwave-flashを指定してください。 true
og:video:width 埋め込み時の横幅 true
og:video:height 埋め込み時の高さ true
 <head prefix="og: http://ogp.me/ns fb: http://ogp.me/ns/fb">
   <meta property="fb:app_id"       content="APP_ID" />
   <meta property="og:type"         content="game" />
   <meta property="og:url"          content="http://example.com/embed/" />
   <meta property="og:title"        content="Beat Gareth's high score" />
   <meta property="og:description"  content="Gareth scored 2800, can you beat it?" />
   <meta property="og:image"        content="http://example.com/game.png" />
   <meta property="og:video"        content="http://example.com/game.swf" />
   <meta property="og:video:width"  content="398" />
   <meta property="og:video:height" content="299" />
   <meta property="og:video:type"   content="application/x-shockwave-flash" />

詳しくはOpen Graph Protocolをご覧ください。

2. Publish the story on behalf of a user

たとえばユーザがレベル達成後に投稿するなど、適切な投稿のタイミングを考慮してください。


Feed Dialog example

推奨される投稿方法はFeed Dialogで、これなら追加でパーミッションを要求する必要がありません。linkプロパティにOpen GraphオブジェクトのURLを指定します。

 function postToFeed() {

   // calling the API ...
   var obj = {
     method: 'feed',
     link: 'http://example.com/embed/'
   };

   function callback(response) {
     console.log(response);
   }

   FB.ui(obj, callback);
 }
詳しくはFeed Dialogのドキュメントをご覧ください。


Graph API example

Graph APIを用いて投稿することも可能です。その場合は、Userオブジェクトの/USER_ID/feed コネクションに対してHTTP POSTリクエストを送信します。詳しくはPermissionsをご覧ください。

 POST /USER_ID/feed?
   link=http://example.com/embed/
   access_token=USER_ACCESS_TOKEN

投稿がFacebook上でレンダリングされる時、これは矢印が重なった最大90 x 90pxの画像と一緒にリンクとして表示されます。タイトルと説明文、それからユーザのメッセージも以下のように表示されます。


attachment2

ユーザが矢印をクリックすると、画像はog:videoタグで指定されたSWFに置き換えられます。Facebook上のレンダリング個所によって表示サイズの制限が変わります。スケールするのを避けたい場合は、横・縦共に398pxを越えないようにしてください。


attachment3

3. Track story engagement

ユーザの代理として投稿するとき、Facebook Insightsのカテゴリを指定するrefパラメータを指定することができます。これで、ことなる投稿のパフォーマンスを計測することが可能になります。アプリのInsightsを見る時に Traffic の Stream Publish を選択すると、Story Typeというドロップダウンメニューが表示され、それぞれのカテゴリ毎の投稿数、インプレッション、クリック数を見ることができます。これにより、異なる画像や投稿タイミングでのパフォーマンスを比較できます。


attachment4

ここで指定した値は、ユーザがウォール投稿のタイトルをクリックして直接ゲームへ遷移する時に、fb_refパラメータとしてアプリへ渡されます。これは、埋め込まれたゲームをプレイせずに遷移した場合です。

ログイン時、Batch Requestでユーザのパーミッション一覧を取得する

認証ダイアログの移行

新しい認証ダイアログが導入されて以来、ユーザから見た認証ダイアログのステップは以下の2つに別れました。
  1. ユーザ本人とその友だちの情報に関するパーミッションを要求するステップ。
    ここで要求されるパーミッション全てを許可しない限り、ユーザはアプリをインストールすることができません。
  2. 追加のパーミッションを要求するステップ。
    ユーザはどのパーミッションを許可するか選択することができます。

以前は、アプリをインストールするには要求される全てのパーミッションを許可する必要があり、与えたパーミッションを消すには、導線の分かりづらい設定ページへ行くしかありませんでした。しかし、新しい認証ダイアログ移行後は、認証ステップの途中で与えるパーミッションを取捨選択できてしまいます。アプリ側はこれまで以上に気をつけて、どのパーミッションが与えられているのか把握する必要があります。

許可されたパーミッションを確認する

タイミング

では、いつ確認するかという問題ですが、新規ユーザがアプリをインストールしたときと既存ユーザがログインするときの2つのタイミングが良いのかなと思っています。既存ユーザのログイン時にも都度チェックするのは、インストール時に許可を与えた後でも、プライバシ設定で任意のパーミッションを取り消すことができる為です。

利用するAPI

ユーザが許可したパーミッション一覧を得るには、以下のいずれかのエンドポイントへアクセスします。
  • https://graph.facebook.com/USER_ID/permissions?access_token=APP_ACCESS_TOKEN
  • https://graph.facebook.com/me/permissions?access_token=USER_ACCESS_TOKEN
これにより、以下のようにユーザが許可したパーミッションの一覧を得ることができます。
'data' => [
    {
        'installed' => 1,
        'publish_actions' => 1
    }
]

バッチリクエストを使う

流れ

ログイン時にチェックしようとすると、取得したアクセストークンからユーザ情報を取得し、許可されたパーミッション一覧も取得するという2度のリクエストを行うことになってしまい、レスポンスが遅くなってしまいます。
こういった場合にはBatch Requestで複数リクエストを1つにまとめてしまうのが便利です。このAPIの仕様はBatch Requestの和訳を参照してください。
my $batch = encode_json([
    +{ method => 'GET', relative_url => 'me', },
    +{ method => 'GET', relative_url => 'me/permissions', },
]);

my $query = +{
batch => $batch,
access_token => $access_token,
};

my $ua = LWP::UserAgent->new;
my $response = $ua->post(
"https://graph.facebook.com/", $query
); my $datam = decode_json( $response->content );
これにより、以下のような形式でデータを取得できます。
$VAR1 = [
          { # 1つ目のリクエストのレスポンス
            'body' => '{ ....... }', # ユーザ情報
            'headers' => [ ..... ], # HTTPヘッダ情報
            'code' => 200 # status code
          },
          { # 2つ目のリクエストのレスポンス
            'body' => '{"data":[{"installed":1,"publish_actions":1}]}', # パーミッション一覧
            'headers' => [ ..... ], # HTTPヘッダ情報
            'code' => 200 # status code
          }
];

Facebook::Graphで

Facebook::Graphでバッチリクエストを利用するため、Facebook::Graphを継承するMyApp::FacebookGraphに以下のようにbulk_fetchとbatchメソッドを足して使っています。
package MyApp::FacebookGraph;
use Any::Moose;
extends 'Facebook::Graph';
.........

sub bulk_fetch {
my ( $self, $paths ) = @_;
my @queries = map {
+{ method => 'GET', relative_url => $_ }
} @$paths;

return $self->batch( \@queries );
}
sub batch { my ($self, $batch) = @_;

my $query = +{ batch => encode_json( $batch ), access_token => $self->access_token, };

my $bulk_res = $self->ua->post( $self->uri->as_string, $query ); my @datam = (); my $contents = Facebook::Graph::Response->new( response => $bulk_res )->as_hashref; for my $content ( @$contents ) { my @headers = map { $_->{name} => $_->{value} } @{$content->{headers}}; my $http_res = HTTP::Response->new( $content->{code}, undef, \@headers, $content->{body} ); my $fb_res = Facebook::Graph::Response->new( response => $http_res ); push @datam, $fb_res->as_hashref; } return \@datam; }

Batch RequestではHTTPヘッダ情報を含むレスポンスが配列で返されるので、batchメソッドではそれを元にHTTP::Responseオブジェクトを生成し、Facebook::Graph::Responseに渡しています。それをas_hashrefしたものを配列に入れて返しているのですが、これにより、配列の個々の要素はfetchメソッドの返り値と同等になっています。また、Facebook::Graph::Responseオブジェクトのas_hashrefがステータスコード確認と例外を投げるところまでやってくれるので、それを流用することで既存のfetchメソッドと同様に例外など扱えるよう意識し、置き換え易いようにしています。


先ほどのようにユーザ情報とパーミッション一覧を得る場合だと、以下のように書けます。

my $fb = MyApp::FacebookGraph->new( .... );
$fb->access_token( $access_token );
my $datam = $fb->bulk_fetch(['me', 'me/permissions']);

#my $datam = $fb->batch([ # +{ method => 'GET', relative_url => 'me', }, # +{ method => 'GET', relative_url => 'me/permissions', }, #]);

返り値は以下の通りです。

$VAR1 = [
          {
            'link' => 'http://www.facebook.com/profile.php?id=100003754895087',
            'timezone' => 9,
            'middle_name' => 'Amcgedhiejhg',
            'name' => 'Sharon Amcgedhiejhg Schrockberg',
            'locale' => 'ja_JP',
            'last_name' => 'Schrockberg',
            'updated_time' => '2012-04-11T02:22:58+0000',
            'id' => '100003754895087',
            'first_name' => 'Sharon',
            'gender' => 'female'
          },
          {
            'data' => [
                        {
                          'installed' => 1,
                          'publish_actions' => 1
                        }
                      ]
          }
        ];

名前がSharon Schrockbergになっているのは、アプリ管理ページで作成したテストユーザだからです。実際の自分のアカウントを使っていると、APIのテストで連続投稿したときにスパム判定されてしまったりするので、テストユーザを使うのが推奨されています。詳細についてはTest Usersの和訳を参照してください。

Batch Requests

Batch Requestsのドキュメントの和訳です。これを用いると、複数のGraph API問い合わせを実行する際に、問い合わせを1度にまとめることができるという利点があります。1度にまとめられる問い合わせは50個が限度で、それ以上の場合は、50個ずつ複数に分ける必要があります。「ログイン時、Batch Requestでユーザのパーミッション一覧を取得する」で実装法を紹介していますのでご覧ください。


以下、2012年7月9日 1:49更新分までの本文です。
------------------------------------------------------------------------------------------

Introduction

Graph APIは、個々のオブジェクトやオブジェクト同士の繋がりのデータを取得するように設計されているだけでなく、複数のオブジェクトを同時に取得する機能も持っています。大量のデータに対して1度にアクセスしたかったり、複数個のオブジェクトを1度に変更したい場合は、個々にHTTPリクエストを送るよりも一括で処理する方が効率的です。それを可能にするためにGraph APIはバッチリクエストをサポートしていて、これにより、一度のHTTPリクエストで複数処理の指示を渡すことができます。以下のセクションで説明しますが、関連する処理同士の依存関係を記述することも可能です。Facebookは独立した処理を並列で処理し、依存し合う処理は順番に処理します。全ての処理が完了すると統合されたレスポンスが返され、HTTP接続が断たれます。

Making a simple batched request

バッチAPIでは、JSONの配列で表現した"HTTP リクエスト"を用います。つまり、それぞれのリクエストは以下の要素で成り立ちます。

  • メソッド(HTTPメソッドのGET/PUT/POST/DELETE その他に該当)
  • relative_url(graph.facebook.comに続く部分)
  • オプションでヘッダ情報(HTTPヘッダに該当)
  • オプションでボディ(POSTとPUT用)

そして、バッチAPIではJSONの配列で表現したHTTPレスポンスが返されます。要素は以下の通りです。

  • ステータスコード
  • オプションでヘッダ情報
  • オプションでボディ(JSONエンコードされた文字列)

バッチリクエストを実行するには、個々の処理をJSON形式で記述し、https://graph.facebook.comにPOST送信します。以下の例は、ログイン中のユーザ自身のプロフィールと共に、友だち50人の情報を一回のリクエストで取得しています。

curl \
    -F 'access_token=…' \
    -F 'batch=[ \
            {"method": "GET", "relative_url": "me"}, \
            {"method": "GET", "relative_url": "me/friends?limit=50"} \
        ]'\
    https://graph.facebook.com

これら両方の処理が完了すると、Facebookは個々のレスポンスをまとめて返します。それぞれのレスポンスにはステータスコード、ヘッダ情報、ボディが含まれます。これらは、Graph APIで個別にリクエストした場合と同じものです。bodyフィールドはエンコードされたJSONオブジェクトで、上記例の場合だと、以下のような形式になります。

[
    { "code": 200, 
      "headers":[
          { "name": "Content-Type", 
            "value": "text/javascript; charset=UTF-8" }
      ],
      "body": "{\"id\":\"…\"}"},
    { "code": 200,
      "headers":[
          { "name":"Content-Type", 
            "value":"text/javascript; charset=UTF-8"}
      ],
      "body":"{\"data\": [{…}]}}
]

Batch requests containing multiple methods

通常ならば異なるHTTPメソッドを使い分けるような処理も1個のバッチリクエストに含めることが可能です。GETとDELETEはrelative_urlとmethodフィールドしか持たないのに対し、POSTとPUTはオプションでbodyフィールドを渡すことができます。bodyフィールドを渡す際には、URLクエリ文字列のように、HTTP POST bodyの文字列と同じ形式にしてください。以下は、ユーザのニュースフィードに新規投稿し、ニュースフィーロから最新のアイテムを取得しています。
curl \
    –F 'access_token=…' \
    -F 'batch=[ \
          { "method": "POST", \
            "relative_url": "me/feed", \
            "body": "message=Test status update&link=https://developers.facebook.com/" \
          }, \
          { "method":"GET", \
            "relative_url":"me/feed?limit=1" \
          } \
        ]'\
    https://graph.facebook.com

この結果は以下のようになります。

[
    { "code": 200,
      "headers": [
          { "name":"Content-Type", 
            "value":"text/javascript; charset=UTF-8"}
       ],
      "body":"{\"id\":\"…\"}"
    },
    { "code": 200,
      "headers": [
          { "name":"Content-Type", 
            "value":"text/javascript; charset=UTF-8"
          },
          { "name":"ETag", 
            "value": "…"
          }
      ],
      "body": "{\"data\": [{…}]}
    }
]

Errors

リクエストした処理のうち1つがエラーとなることもあり得ます。適切なパーミッションを持っていない場合などです。そういった場合には、バッチAPIは通常のGraph APIと似たレスポンスを、バッチレスポンスの形式に則って返します。
curl \
     -F 'access_token=...'\
     -F 'batch=[{ "method": "POST", \
              "relative_url": "me/feed", \
                  "body": "message=Test update"}]\
https://graph.facebook.com

例えば、上記のアクセストークンがpublish_streamパーミッションを持っていなかったとしましょう。その場合のレスポンスは以下のようになります。

[
    { "code": 403,
      "headers": [
          {"name":"WWW-Authenticate", "value":"OAuth…"},
          {"name":"Content-Type", "value":"text/javascript; charset=UTF-8"} ],
      "body": "{\"error\":{\"type\":\"OAuthException\", … }}"
    }
]

同じリクエストで指定した他の処理は通常通り完了し、ステータスコード200と共に返されます。

Using fql.query and fql.multiquery in the Batch API

Batch APIは旧REST APIメソッドをサポートしていませんが、fql.queryとfql.multiqueryをBatch APIリクエストに含めることは可能です。例えば、以下の例のようにFQLクエリを含めることができます。

curl \
     -F 'access_token=…' \
     -F 'batch=[{ "method": "POST", \
    "relative_url": "method/fql.query?query=select+name+from+user+where+uid=4", \
     }]
https://graph.facebook.com

Specifying dependencies between operations in the request

デフォルトでは、Batch APIのリクエストで渡される処理は独立したもので、サーバ側でどの順番で処理されても問題なく、1つの処理でエラーが起きたとしても他の処理には影響しません。しばしば、依存し合う処理をリクエストしたい場合があります。たとえば、一方の処理の結果を次の処理に渡したい場合です。Batch RequestはJSONPath(http://code.google.com/p/jsonpath/)の利用でこれをサポートしています。JSONPath形式での記述によってJSONオブジェクト内のデータを参照することが可能になります。実行済み処理(親)の結果を参照するには、実行済み処理を命名し、クエリ文字列内でそれを参照するかJSONPath形式でパラメータを生成します。クエリ文字列やパラメータを生成するときのJSONPath表記は、{result=(親処理名):(JSONPath表記)} となります。セキュリティのため、filterとscriptを用いたJSONPath生成は利用できません。

たとえば、あなたの友だち5人の詳細を得るには、以下のようなバッチリクエストを送信します。


curl \
   -F 'access_token=...' \
   -F 'batch=[{ "method": "GET", \
                "name" : "get-friends", \
                "relative_url": "me/friends?limit=5", \
              }, \
              { "method": "GET", \
                "relative_url": "?ids={result=get-friends:$.data.*.id}" \
              }]' \
      https://graph.facebook.com/

上記の例では、1個目の処理はget-friendsと命名され、2個目の処理はJSONPath構文中で友だちIDを取得しています。JSONPath表記の $.data.*.id は、トップレベルの要素の全雇用そのIDを取得することを意味します。

上記の例ではJSONPathを用いて2個目の処理が1個目の処理を参照しているため、サーバは2個目の処理が1個目の処理に依存していることを察知します。そのため、依存されている側の処理が完了するまで、依存する側の処理は実行されません。親処理がエラーを返せば、依存する処理は実行されません。またデフォルトでは、処理が正しく完了した場合、親処理の結果はレスポンスには含まれません。

つまり、上記Batch APIリクエストのレスポンスは以下のようになります。

[
    null,
    { "code": 200,
      "headers":[
          { "name":"Content-Type", 
            "value":"text/javascript; charset=UTF-8"}
      ],
      "body":"{\"data\": [{…}]}}
]

"omit_response_on_success":false を親処理に指定することによって、サーバに対して親処理の結果も返すように指示できます。例えば以下のように書きます。

curl \
     -F 'access_token=...' \
     -F 'batch=[{ "method": "GET", \
                  "name" : "get-friends", \
                  "relative_url": "me/friends?limit=5", \
              "omit_response_on_success": false, \
                }, \
                { "method": "GET", \
                  "relative_url": "?ids={result=get-friends:$.data.*.id}" \
                }]' \
                https://graph.facebook.com/

JSONPath利用によって実行済み処理を参照しています。たとえば以下の例では、1個目の処理で取得した友だち名を利用してステータス投稿します。

curl -F 'access_token=...'  \
     -F 'batch=[{ "method": "GET", \
                  "name" : "one-friend", \
                  "relative_url": "me/friends?limit=1", \
                }, \
                { "method": "POST", \
                  "relative_url": "me/feed", \
                  "body": "message={result=one-friend:$.data.0.name} is my friend" \
                }]' \
        https://graph.facebook.com/

先述したように、JSONPath表記によってサーバは自動的に依存関係を検出しますが、場合によっては特に実行順序を指定したい場合があります。その場合には、depends_onアトリビュートを使います。

たとえば、以下のリクエストでは、2個目の処理が1個目に依存するというのが指定されています。

curl 
    -F 'access_token=...' \
    -F 'batch=[\
               { "method": "POST", \
                 "name": "first", \
                 "relative_url": "me/feed", \
                 "body": "message=Test status update" \
               }, \
               { "method":"GET", \
                 "depends_on": "first", \
                 "relative_url":"me/feed?limit=1" \
               }\
              ]' \
    https://graph.facebook.com

Batch calls with JSONP

Batch APIはGrpah APIと同様にJSONPをサポートしています。つまりJSONPのコールバック関数はパラメータの callback クエリ文字列で指定できます。

Specifying different access tokens for different operations

紹介した全部の例ではトップレベルのパラメータで一個のアクセストークンを指定したのみでした。Batch  APIは柔軟ですので、個々のリクエストでもクエリ文字列やパラメータを通じてアクセストークンを指定できます。その場合、トップレベルで指定したアクセストークンはフォールバック用に用いられます。

これはユーザ毎に異なるアクセストークンを使いたい場合や、一部でアプリのアクセストークンを使いたい場合に便利です。

個々のリクエストのいずれでもアクセストークンが指定されていない場合、トップレベルにアクセストークンを指定しなくてはなりません。

Uploading binary data

The following example shows how to upload 2 photos in a single batch call:

Batch APIリクエストのmultipart/mimeに指定することでバイナリデータをアップロードできます。これを実行するには、multipart/mimeタイプの添付として全バイナリデータを追加し、個々の処理がattached_filesプロパティを通じて参照できるようにします。attached_filesプロパティはカンマ区切りで添付ファイル名を指定することが可能です。

以下の例は、2個の画像ファイルを1回のバッチリクエストでアップロードしています。


curl 
     –F  'access_token=…' \
     -F  'batch=[{"method":"POST", \
                  "relative_url":"me/photos", \
                  "body":"message=My cat photo" \
                  "attached_files":"file1" \
                 },
                 {"method":"POST", \
                  "relative_url":"me/photos", \
                  "body":"message=My dog photo" \
                  "attached_files":"file2" \
                 },
                ]'
     -F  'file1=@cat.gif' \
     -F 'file2=@dog.jpg' \
    https://graph.facebook.com

Limits

一度に実行できる処理の上限は、現在50個です。


App Center Guidelines

App Center Guidelinesの和訳です。自分のFacebookアプリをApp Centerに登録するまでの手順についてはApp Center Tutorialの和訳で紹介されていますので、そちらをご覧ください。このページには、アプリ開発からApp Center登録の間に守らなくてはならないルールが書かれています。


以下、2012年7月13日 17:29変更分までの和訳です。
App Centerは優れたソーシャルアプリを見つけ出す場所で、質が高く優れたユーザ体験を提供するアプリが際立つように設計されています。

皆さんが多くの時間を開発に費やしているのは理解していますので、レビューのプロセスについて、また、私たちがどのようなアプリを期待しているかを理解していたく為、このドキュメントを準備しました。

アプリを提出する前には必ず、以下のガイドラインやpolicy guidelinesに準拠している事を確かめてください。全てのアプリがApp Centerに登録されるわけではなく、基準を満たさないアプリが一覧から削除される事もあり得ます。アプリの詳細ページが完成すると、そのページとアプリ本体はレビューされ、基準を満たしているか確認されます。

あなたのアプリが成功する事、それをApp Center上で宣伝できる事を楽しみにしています。

Eligibility

以下の各アプリはApp Centerに登録する資格を有します

  • Facebook キャンバスページで動作するアプリ
  • web, iOS, Androidに対応したモバイルアプリで、Facebookログインを実装しているもの
  • Facebookログインと遷移直後の自動ログインを実装していて、パーソナライズされたユーザ体験を提供するモバイルウェブサイト(詳しくはApp Qualityをご覧下さい)
  • Facebookログインと遷移直後の自動ログインを実装していて、パーソナライズされたユーザ体験を提供するウェブサイト(詳しくはApp Qualityをご覧下さい)

以下のアプリは現在サポートされていません。

  • Facebookページのタブアプリ

App Detail Submission

アプリの詳細ページを作成するのが最初のステップです。これが完了すると検索結果に表示されるようになり、App Center登録の資格を有するようになります。作成時には以下のガイドラインに従ってください。

  • Display Name - 余分な単語や文字列の無い、アプリと完全に同一の名前を使ってください。たとえば、アプリ名がBilliardsだったとしたら、"Billiards - Pool"という名前を使用してはいけません。ただし、対応するプラットホームが一つのみの場合、そのプラットホーム名を含むことはできます。(例:[App Name] for Android)
  • Tagline - Display Nameを含んではいけません。代わりに、広報用のキャッチコピーを入れることができます。
  • Short & Detailed Descriptions - アプリが何をするのか、どこが他のアプリと違うのかを説明してください。ユーザが使い始めてから混乱しないよう、きちんと正確に書いてください。URLが含まれていたり、余計な句読点、値段情報、キーワードリスト、一般的でない記号が入っていてもいけません。
  • Category & Subcategory - 適切なカテゴリを選択してください。App Center Categoriesに詳細な情報が記載されています。
  • Review Your app settings - アプリ詳細ページは、アプリ設定画面に入力した内容に基づいてダイナミックに変わります。アプリ設定を確認し、旧式だったり既に機能しないような実装個所を省いてください。たとえばiOSアプリを作っているのであれば、Site URL、Mobile Web URL、Canvas URLの項目は空にしなくてはいけません。

Image Guidelines

アイコン、バナー、カバー画像などを作成する際には、以下のガイドラインに従うよう気をつけてください。

  • Icons - 魅力的でアプリと関連がある独自のアイコンをアップロードします。これらのアイコンはシンプルであるべきで、ボタンや追加情報のような余計なノイズが入るべきではありません。各サイズのアイコンは似たものを使い、歪曲やピクセレーション(distortion and pixilation)は避けてください。
  • Cover Image - あなたのアプリを適切に伝える画像を選択します。簡単に認識できるよう、文字や影やノイズになるパターンのないシンプルな画像を使ってください。カバー画像の下にあるボタンを押してアプリのインストールを促すような矢印、もしくはそれに類するものを置いてはなりません。左下に128 x 128pxのアイコン画像が重なって表示されることを忘れないでください。
    attachment

  • Small and Large Banners - アプリの名前を用いてあり、なおかつ視覚的に訴えかける画像を使って潜在ユーザをアプリ詳細ページへ引き込みます。ボタン、URL、過剰なテキスト、宣伝文句、値段情報を入れないでください。枠全体を完全に埋めている必要があります。(角丸や余白や枠線はだめです。)
    attachment2


  • Screenshots - そのアプリについて、特徴的で魅力があり、どのように"ソーシャル"なのかを伝えるキャプチャが像を選びます。関連性がなかったり、誤解を招きやすいもの、もしくは多くのユーザが体験する内容からかけ離れているものを使ってはいけません。キャッチコピーなどを含んではだめで、機能一覧や「ここをクリックして今すぐプレイ!」などを載せることは許されません。Facebookログインを実装している場合は、少なくとも1枚はパーソナライズされたユーザ体験を示すキャプチャを使う必要があります。
    attachment3


  • Images (general) - 画像はアプリの質と合っているべきです。ボタンや過剰なテキスト、ボーダー、ドロップシャドウ、URL、キャッチコピー、サードパーティのロゴを含んではなりません。バナーはアプリ名を含めなくてはならず、白背景、角丸、枠線が入ってはいけません。アイコンは白か透過背景も可能で、透過の場合はGIFではなくPNGを推奨します。キャプチャ画像は実際の画像にしてください(追加でグラフィックが足されていたり、ゆがんだアングルを取り入れてはいけません)。

App Quality

App Centerは、人々が使いたがるハイクオリティのアプリを見せる場所です。ここに登録されるには、以下の項目をクリアする必要があります。

  • 使いやすいインターフェイス、明快なコンテンツ、ユーザへの価値、そして致命的なバグがないこと
  • 広告とコンテンツの明快な区別があり、過剰に広告が表示されないこと
  • アプリの評価が高く、ネガティブなフィードバックが少ないこと
  • いつ、どのようにユーザアクティビティがFacebookで共有されるかを明確にすること
  • ユーザの誤解を招いたり直感的でない形で、FacebookのUI要素を真似しないこと
  • ウェブサイトの場合:アプリの詳細ページからウェブサイトへ遷移した段階で、自動でログインし、パーソナライズされたユーザ体験が提供されること。ユーザが「Facebookでログイン」ボタンを押す必要の無いようにしてください。ユーザ体験は何らかの形でパーソナライズされていて、自分がログインしていることが分かるようにしてください(ユーザの名前やプロフィール画像を表示するなど)。詳しくはcheck user statusを参照してください。

The Review Process

アプリの詳細ページが提出されるとレビューが始まります。詳細ページを作成したからといって、App Centerへの登録が保証されるわけではないことに気をつけてください。また、アプリが基準を満たさなくなった場合、App Centerの登録が抹消されることもあります。

アプリが却下された場合、却下の理由とともに変更案を提示します。変更案を実装したら再度提出することが可能です。

アプリがApp Centerに登録されなくとも、ユーザは検索やブックマークやソーシャルチャンネル(リクエスト、フィード、タイムライン)を通じてアプリにたどり着きます。

Common Submission Mistakes

迅速にレビューするため、ガイドラインに準拠していることを申請前に確認してください。申請された物のうち、変更が必要であった主な理由は以下の通りです。

  • 白背景のバナーだった
  • アプリ名がバナーに入っていなかった
  • 過剰なテキストが挿入された画像。キャプチャ画像の内容を強調する内容であれば大丈夫ですが、キャプチャに関係のないテキストは挿入しないでください。
  • サードパーティ(Android StoreやiPhone Store)の広告(Android StoreやiPhone Store)を含む、もしくは広報文言(「Store Xで1位受賞」など)を含む画像
  • アプリの説明文に文法ミスがある
  • サブカテゴリを指定していないゲーム(アクションやアーケードなど)
  • 実際のゲーム内容を示していないキャプチャ画像
  • バナーやキャプチャ画像にFacebookの商標が含まれている
  • Facebookログインを実装していても、遷移直後の自動ログインとパーソナライズを実装していない

Thank you

このガイドラインが、ユーザが楽しむアプリを開発する助けとなることを祈っています。また、このドキュメントは随時更新されます。

私たち自身もかつてはFacebookアプリ開発者でしたから、こうして優れたアプリを紹介して広められること、そしてあなた方の成功を楽しみにしています。

Facebookアプリ開発に携わっていただいてありがとうございます。

App Center

App Centerの和訳です。2012年6月8日に公開されたApp Centerの役割や、その対応のためにアプリ開発者がするべきことの概要が書かれています。Facebook上のアプリ詳細ページ作成や、その後の申請方法については、App Centerチュートリアルの和訳をご覧ください。


以下、2012年7月9日 6:18更新分までの和訳です。

A place to find great apps

Facebookを使う9億人以上の人々にとって、App Centerは優れたソーシャルアプリを見つける中心的な場所です。App Centerの全てのアプリには詳細ページがあり、アプリを理解するのを助け、アプリへ遷移する前にインストールを完了させます。


attachment

アプリの詳細ページは、ユーザがスクリーンショットを見、特徴を理解し、ログインしてアプリを使い始めるのを助けます。詳細ページから認証を済ませれば、ユーザはアプリへとリダイレクトされます。


attachment2

Growth for high-quality apps

App Centerでの成功はアプリの質に結びついています。Facebookはユーザの評価やエンゲージメントを用い、アプリをApp Centerに表示するか決定します。ユーザのフィードバックを監視するために、Facebook インサイトに新しい情報が追加され、ユーザの評価を見られるようになりました。


attachment3

よく設計されたアプリであれば目立って表示されますが、ユーザの評価が低かったりガイドラインに準拠しないものは表示されません。

Driving mobile installs

iOS,Android,モバイルウェブのいずれを使うのであれ、App CenterはFacebookを用いるモバイルアプリの成長を促すものです。モバイル版のApp Centerからユーザは自分の端末で利用できるアプリを探し、必要であればApp StoreGoogle Playへと誘導されてアプリをインストールします。


attachment4

Create Your App Detail Page

開発者は皆、チュートリアルに従ってアプリの詳細ページを作成すべきです。詳細ページの作成はApp Centerへのアプリ登録時に必須となるだけでなく、潜在ユーザがFacebookでアプリを検索する際のランディングページにもなります。

Developer AppのApp Centerの項目から詳細ページを作成してください。そこではキャプチャ画像をアップロードしたり、追加の説明文を書いたり、アプリが要求するパーミッションを指定できます。詳細はチュートリアルをご覧ください。

アプリがApp Centerから削除されたりしないよう、また、アプリの適切なカテゴリを選択できるよう、詳細ページを作成する前にガイドラインも読んで把握する必要があります。App Centerが適切に設定できたらFacebookによってレビューされ、App Centerに追加されます。

記事検索