お久しぶりです。GMO NIKKOのS.Tです。
今回はFacebookとTwitterのAPIでレポートを取得する機会があったので簡単に比較してみました。
FacebookはマーケティングAPIがよく使われていてベースとなっているグラフAPIを拡張したライブラリ(と私は認識しています)なのですが
マーケティングAPIは更新頻度が多く使用期限が短いので比較的安定しているグラフAPIを使っています。
Twitterは広告APIを使いますがPythonとRubyは公式のライブラリがあるようです。
使い慣れたPHPを使いたいのですがPHPは非公式のライブラリしかないので使っていません。
私の場合はPHPでcurlを使ってHTTPのGETリクエストを投げています。
APIの階層の比較
■Facebook
Facebookの公式を探しても見つからなかったので図を作りましたがFacebookの広告は基本的にはこのような3層構造になっています。
YahooやGoogleと似たような感じですね。
キャンペーン・広告セット・広告はそれぞれプラットフォームやデバイス単位で細かく別れます。
例えばインスタグラムのレポートはプラットフォームにinstagramとして返ってきます。
コンバージョンが細かくなっていてFacebookで予め用意されている標準イベントと条件を自由に設定できるカスタムコンバージョンがあります。
また、アクティベーションウィンドウと呼ばれるものがあり、1-DayClickや7-DayClickなどがあります。
■Twitter
Twitterは結構違っていて
支払い情報
↓
キャンペーン
↓
広告グループ(Line Items)
↓
広告(Promoted Tweets)
のような階層になっています。
あとはマスターとしてカード情報も取得しています。
API使用までの比較
■Facebook
この手順でAPIキーを使えばAPIを利用できますが広告情報にアクセスするにはアプリレビューを行う必要があります。
パーミッションごとにFacebookへ使用目的等の説明を行って審査の上、承認されると広告レポートが取得できるようになります。
ads_readが承認済みになっていればOKです。
■Twitter
Twitterも申請が必要なのは同じですが、TwitterAPIとTwitter広告APIへのアクセス申請が必要なようです。
リクエストの比較
■Facebook
|
1 2 3 4 5 6 7 |
https://graph.facebook.com/v[APIバージョン]/ [アカウントID|キャンペーンID|広告セットID|広告ID]/ [campaigns|adsets|ads|insights]? fields=[clicks等の取得したい項目]& time_increment=1& breakdowns=***& access_token=*** |
fields: campaigns等どれを選んだかによって取得できる項目が決まっている
time_increment: 日付ごとに取得したい場合は1を指定
breakdowns: デバイスごとに取得したい場合はimpression_deviceを指定
|
1 2 3 4 5 6 7 |
https://ads-api.twitter.com/[APIバージョン]/ [accounts|stats/accounts|stats/jobs/accounts]/ [アカウントID]/ [funding_instruments|campaigns|line_items|promoted_tweets]?granularity=DAY& metric_groups=ACCOUNT|FUNDING_INSTRUMENT|CAMPAIGN|LINE_ITEM|PROMOTED_TWEET& placement=ALL_ON_TWITTER& sort_by=created_at-des |
非同期処理で取得する場合はjobsを指定(2行目)
granularity: 日付ごとに取得したい場合はDAYを指定
metric_groups: ACCOUNT等の取得するマトリックスを指定
placement: 検索結果やタイムラインのみを指定もできるが基本的にすべて取得するのでALL_ON_TWITTERを指定
sort_by: ソートする項目
TwitterはURLの他にヘッダーを指定する必要があります。
CURLOPT_HTTPHEADER = ‘Authorization: OAuth oauth_version=“1.0”, oauth_nonce= md5(microtime() . mt_rand()), oauth_timestamp= time(), oauth_consumer_key=“***”, oauth_token=“***”, oauth_body_hash= base64_encode(sha1(”, true)), oauth_signature_method=“HMAC-SHA1”,URLで指定したパラメーター, oauth_signature= base64_encode(hash_hmac(‘sha1’, $signatureBase, $key, true))’
長いので省略しますが、oauth_nonceはユニークなID、 oauth_timestampはその名のとおりタイムスタンプ、 oauth_consumer_keyやoauth_tokenはアカウントに設定されているアクセストークン、 oauth_body_hashはsha1のハッシュ、 oauth_signatureは簡単に言うとURLパラメーターをURLエンコードしてハッシュ化したものです。FacebookはURLにアクセストークンを追加するだけですがTwitterはかなり面倒ですね。
レスポンスの比較
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Array( [data] => Array( [0] => Array( [account_id] => 2178116579001520 [impressions] => 121 [inline_link_clicks] => 3 [spend] => 85.004831 [date_start] => 2021-04-28 [date_stop] => 2021-04-28 [publisher_platform] => audience_network [impression_device] => android_smartphone ) [1] => Array( |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Array( [time_series_length] => 7 [data] => Array( [0] => Array( [id] => do3ni [id_data] => Array( [0] => Array( [metrics] => Array( [impressions] => Array( [0] => 27784 [1] => 28201 [2] => 29646 [3] => 0 [4] => 0 [5] => 0 [6] => 0 ) |
GETリクエストを投げた時に返ってくるレスポンスですが、Facebookは日付と一緒に値が返ってくるので直感的にわかりやすいのですが、Twitterは7日分取得すると図のように値ごとに配列になるので扱いにくいです。また、同期取得する場合は7日分しか取れないので何度かリクエストを分ける必要があります。
非同期(レポート作成要求と取得を別々にリクエストする方法)で取得すれば90日分までリクエストできます。
Twitterの場合、気をつけなければならないのはリクエストしすぎるとすぐに429エラーが返ってくるので指定時間まで待つ必要があります。
正直使い物にならないので非同期処理は必須です。
Facebookでは普通に1か月分10アカウント同時リクエストとかできていたので、TwitterのAPIは扱いにくいと言われるのはこの事かもしれません。
Twitterの場合、気をつけなければならないのはリクエストしすぎるとすぐに429エラーが返ってくるので指定時間まで待つ必要があります。
正直使い物にならないので非同期処理は必須です。
Facebookでは普通に1か月分10アカウント同時リクエストとかできていたので、TwitterのAPIは扱いにくいと言われるのはこの事かもしれません。
まとめ
Facebookはドキュメントの情報量も多くリクエストの試し打ちもできてとにかく環境が色々揃っている印象でした。
また、リクエストもURLパラメーターにアクセストークンを追加するだけなので比較的簡単です。
Twitterはリクエストが多すぎるとすぐに429エラーになるので非同期リクエスト必須なのも取っ付きにくい部分かもしれません。
Twitterが優位な部分はドキュメントが見やすいところでしょうか。
Facebookは余計な情報が多すぎてまとまっていない感じでした。
