Facebook Graph API v4.0 / Marketing API v4.0 がリリースされた件


しばらく blog を書いていなかったが、7 月 30 日 (日本時間) に Facebook が Graph API / Marketing API / Messenger API v4.0 をリリースした。

正直なところ、ここのところ機能的な目玉がかなり少ないと感じていて消化不良感が半端ないが、今回の一番の大きな変更点は API rate limit 回りの変更ではないだろうか。

ハイライト

API rate limit における上限値の変更

カスタムオーディエンス、広告回り (リード広告含む)、メッセンジャーに関する API の呼び出し回数制限の計算方式が変更され、それぞれ関連するオブジェクトの数に依存するようになった。

  • カスタムオーディエンス → 広告アカウントに紐付いたアクティブなカスタムオーディエンス数
  • 広告 → 広告アカウントに紐付いた配信中の広告数
  • リード → Facebook Page のリードフォームの数
  • メッセンジャー → Facebook Page が送信できるユーザ数

気づいた向きもあるかと思うが、これのテストがどうやら 7 月頭に行われていたらしい

ダッシュボードを作るなどで高頻度にメトリクスを取得していたりすると突然 API rate limit にかかったりしていたかと思うが、おそらくはこれのテストだったと思われる。

広告作成・更新時の処理を非同期化

これまでは、広告キャンペーンや広告セット、広告そしてクリエイティブを作成または更新する際は同期的に処理が行われていた。しかし、作成・更新のために必要な内部処理が多く、API がタイムアウトしたり広告マネージャがエラーを返したりしていたことがあった
特に API 経由の場合に何も考えずにリトライすると同じオブジェクトが複数作成されたりするという問題がここ 5 年以上あったかと思う。

これに対する回答として、これらオブジェクトの作成・更新を複数の工程に分離し、非同期処理で行われるようになったPost-Processing for Ad Creation and Edits に図でも説明されているが、

API 経由でオブジェクトを作成・更新するといつも通りオブジェクトの ID が返され、まずは effective_statusIN-PROCESS になる。この時点では、オブジェクトの作成・更新処理はまだ終わっていない。

しばらく待ってから再度オブジェクトを参照し、まだ処理が終わっていなければ引き続き effective_statusIN-PROCESS が、処理が終わっている場合は以下のいずれかが返される。

  • PENDING_REVIEW: 操作したのが広告で審査がまだの場合
  • WITH_ISSUES: エラーのために配信できない場合
  • PAUSED: 配信停止状態
  • ACTIVE: 配信中

ここで気をつけないといけないのは、現時点では Webhook が存在しないため、ステータスが IN-PROCESS から変わったかどうかをこちらからポーリングする必要がある
そのため、同期処理前提で処理が実装されている場合は結構大きめの改修が必要になるケースがあると思われる。

その他変更点

Graph API v4.0

権限まわりの変更

まず、Instagram アカウントに紐付けられた Facebook Page にアクセスするためには、以下のどれかの権限が必要になった。

  • ads_management
  • ads_read
  • instagram_basic
  • manage_pages

次に manage_page を持っていない場合でもこれまでは Facebook Page で公開されているデータを API 経由で読めたが、今後は権限取得とそれに伴う審査が必要となる。
開発モードの場合は審査を通さなくても Facebook Page のデータにアクセスはできるが、アクセスできる対象となる Facebook Page の管理者権限を持っており、かつ Facebook App の権限を持っている必要がある。

Webhook

Facebook Page へ like されたとき、これまではページフィードの Webhook に送信されていたが、これがリアクションに変更された。

また、Webhook 回りの内部的な実装に大きく手が入れられ、処理速度と Webhook 経由の通知の成功率などが改善された。

Marketing API

ビジネスアセットグループ

8 月 14 日にビジネスアセットグループがリリースされる。大量のフィードやクリエイティブ、ビデオなどを持つ大規模な広告主や代理店はこの API を利用することで各種データとそれに対する権限管理が容易になる。
ドキュメントもあわせて 8 月 14 日に公開される予定。

ネイティブアプリまたはスマホ向け Web でのグルーピング

以前、スマホの Web 経由なのかネイティブアプリ向けなのかに関係なくすべてがまとめて表示されていたが、Web 経由かネイティブアプリ向けかでグルーピングできるようになった。

issues_info への新しいエラーの追加

何らかの問題で広告が配信できなくなった場合、v3.2 以降は effective_statusPAUSED ではなく WITH_ISSUES になる。具体的な問題は issues_info フィールドに格納されるが、格納されるエラーのバリエーションが増えた。

issues_info については News for Developers – Troubleshoot Ad Delivery with WITH_ISSUES Status が詳しい。


細かい変更 (破壊的なものを含む) は省略したので、詳細は ChangeLog を参照されたい。

ここのところずっと書いている気もするが、今回の変更も内部的な実装はともかくとして機能的な意味で言えばそこまで大きな変更点はなかった。
よく言えば安定してきているのかも知れないが、ここのところ個人情報問題のせいか、目玉機能のリリースが限られているように思える。

また、個別の機能も微妙に詰めが甘いと言わざるを得ない。API rate limit のアーキテクチャ変更とあわせて広告オブジェクトの生成・更新を非同期化するのであれば、API rate limit に対してのインパクトを軽減できる Webhook の実装はマストだと思うし、そこまで踏み込んで欲しかったと思う。