大量のAnalyticsデータ取得についてのご相談

ktym · 2017-11-29T11:46:15.263Z

お世話になっております。

アカウントが保持しているpromoted_tweet単位のAnalyticsデータを取得しようとしているのですが
データ数が多く、APIを呼ぶ回数も多いので、効率の良い取り方が出来ないかと思いご相談させていただきました。

promoted_tweetを全件取得

GET accounts/:account_id/promoted_tweets

で全てのpromoted_tweetを取得 → 7000件のpromoted_tweetがある状態です。

analyticsデータを取得

POST stats/jobs/accounts/:account_id

1ヶ月ほどのデータがほしいため
parameterは
entity=PROMOTED_TWEET
granularity=DAY
start_time,end_time=1ヶ月
を設定しています。

POST stats/jobs/accounts/:account_id
のparamterのentity_idsはmax20件のため、7000件のデータがあると350回のpostを行うことになり、
結果の待ちもかなりの時間がかかってしまいそうな状態になっています。

何か効率の良い取得方法は無いでしょうか。
取得の自動化を考えているためAPI連携で出来ればと思っています（手動でUIからのダウンロードは避けたい）

例えば
1.
GET accounts/:account_id/promoted_tweets
で取れるデータ件数は7000もありますが、実際対象の期間にimpなどの数値があるものは10分の1程度なので、絞り込む方法が無いか

POST stats/jobs/accounts/:account_id
にentity_idsにpromoted_tweet_idを20個ずつ渡して何度もAPIを呼び出していますが、
accountIdだけでPROMOTED_TWEET単位でAnalyticsデータが取れる方法が別にある

等、何か良い手段が無いか、もしくはアドバイスがをいただければと思っています。

JBabichJapan · 2017-12-18T06:52:05.554Z

@ktym さん、お問い合わせありがとうございます。

こちらは、基本的にentity_idsのところに渡すオブジェクト（ラインアイテムやツイート）を減らすのは攻略としてありだと思いますが、基本的なアドバイスは：
１）全く変わっていないデータを何度も取得しないこと
２）時間のローリング・ウィンドーを使って少しずつDBに保存します（例えば二日前は１２月０９日〜１６日時、次回は１２月１０日〜１７日、今日は１２月１１日〜１８日みたいな・・）
３）必要な時だけは長い期間のデータをバックフィル（例えば、新しくアカウントを追加、過去のデータを修正）
４）まだ配信中・インプレッションがあるかもしれないっていうキャンペーンやラインアイテムのみを同期します、これは簡単な機能はないんですが「削除されていない」「end_dateが過去じゃない」などの簡単なチェックでもだいぶレートリミットに影響する認識です（それ以外は終わったキャンペーンに関してはコンバージョンデータがまだ入ってくることがあり得ますが必要かどうかはweb_event_tagとapp_event_tagのウィンドー設定で確認できます）

セグメント分けのstatsが必要でしたらまたそれが別のスレッド・遅くに同期してもいいような優先低いキューに入れたりするのもおすすめできます。すぐにコストデータやリアルタイムデータが必要でしたら同期エンドポイントで上と同じような「配信中かどうか」みたいなフィルターとかあったらいいかもしれませんがアカウントトークンが重複されていないことが重要です（例えば@kaihatsu っていうハンドルで５つのアカウントのデータを同期エンドポイントで取得しようとしていたら、レートリミットが５つのアカウントの分で割ります、非同期エンドポイントはトークンではなくてアカウントごとにレートリミットもらえます）

まだ運用的に数値の同期に困っていましたら実際の数などを書いていただけたらそれがSLA以内かどうか調べたりできます。

ktym · 2017-12-19T10:21:38.170Z

@JBabichJapan さん

ご回答ありがとうございます。

現在、無駄にデータを取らない様に試行錯誤しているため、
いただいた情報を追加で考慮して実装してみます。

ありがとうございました。

ktym · 2018-01-11T11:37:40.996Z

@JBabichJapan

お世話になっております。

こちらでアドバイスをいただき、対象となるデータ数を少なくなるように工夫しました。
その状態で現在、配信中・impressionの可能性があるpromoted_tweetが数万件程度あります。

AsyncのAnalyticsAPIを使った際、全く同じparameterで
数秒で作成が終わる場合と、１時間かかる場合があります。
実行した時間が違うため、時間によって遅い時間があるのか確認しているのですが
実行する時間によって遅くなること、もしくは他の要因が何かあったりしますでしょうか？

SyncのAnalyticsAPIを使う方法も考えたのですが
RateLimitがCategoryで250/15minの制限があり、対象となるaccount,promoted_tweetが多く
すぐにRateLimitに達してしまうため1requestで20件のSyncのAPIを利用することは難しそうでした。

Asyncの場合、遅い時があるという課題
Syncの場合、RateLimitに引っかかり結果遅くなるという課題

があり何とか早くできないか考えています。
何か解決に繋がるアプローチはありますでしょうか。

JBabichJapan · 2018-01-15T09:07:16.505Z

@ktym さん、同時に数万件のツイートが配信中の状態っていうことは、一つのアカウントでしょうか？非同期のレートリミットは（アカウント x アプリID）みたいな単位で、同期のレートリミットは（アカウントに紐づいてるユーザートークンごと x アプリID)です。もちろん大量のユーザートークンやアプリIDは対応してしていないんですが同期のエンドポイントに関してはレートリミットを増やす手はそれしかありません。

数万件のツイートが配信中っていうのは相当多い方ですが、そのラインアイテムやキャンペーンのstartとendの中に絞ったり、そういうフィルターをかけた後にそれぐらい多ければ、全部リフレッシュみたいな戦略っていうよりは、新しい部分だけを取得みたいなことしかないかもしれないです・・（古い部分を取りに行くのやめて・・）。

１時間かかるケースの一つのリクエストの内容を教えていただけますか？基本的に内部的にキューみたいなものに変身してシンプルに徐々に次のジョブをピックアップする認識ですが改めて例外があるかどうか確認してみます。

ktym · 2018-01-16T05:36:55.106Z

@JBabichJapan

１つのアプリIDのトークンを利用しており、紐付いているアカウントは100以上ある状態です。

時間がかかるリクエストの内容は以下となります。

    {
      "start_time": "2018-01-06T15:00:00Z",
      "segmentation_type": null,
      "url": "xxxx.gz",
      "id_str": "951677020949200896",
      "entity_ids": null,
      "end_time": "2018-01-11T15:00:00Z",
      "country": null,
      "placement": "ALL_ON_TWITTER",
      "id": 951677020949200900,
      "expires_at": "2018-01-14T04:47:39Z",
      "account_id": "18ce53vzzv6",
      "status": "SUCCESS",
      "granularity": "DAY",
      "entity": "ACCOUNT",
      "created_at": "2018-01-12T04:47:37Z",
      "platform": null,
      "updated_at": "2018-01-12T04:47:39Z",
      "metric_groups": [
        "ENGAGEMENT"
      ]
    },
    {
      "start_time": "2018-01-05T15:00:00Z",
      "segmentation_type": null,
      "url": "xxxx.gz",
      "id_str": "951392665110659072",
      "entity_ids": null,
      "end_time": "2018-01-10T15:00:00Z",
      "country": null,
      "placement": "ALL_ON_TWITTER",
      "id": 951392665110659100,
      "expires_at": "2018-01-13T10:39:44Z",
      "account_id": "18ce53vzzv6",
      "status": "SUCCESS",
      "granularity": "DAY",
      "entity": "ACCOUNT",
      "created_at": "2018-01-11T09:57:42Z",
      "platform": null,
      "updated_at": "2018-01-11T10:39:44Z",
      "metric_groups": [
        "ENGAGEMENT"
      ]
    }

上の方が早く終ったもの、下の方が時間がかかったものとなっています。

こちらは弊社のテスト配信用のアカウントで有効なpromoted_tweetの数はほとんど無いのですが
それでも時間がかかっている様です。

実施した日時が違うだけで期間は5日間分の指定でパラメータも同じになっています。
今回はentity:Account ですが、entity:PROMOTED_TWEETでも同様に時間がかかってしまうことが多いです。