Tapjoyの Marketing APIは、APIの過剰または不正な呼び出しを避けるための仕組みがあります。実装の結果として閾値を超えてしまう場合は、Tapjoyの担当またはサポートへご連絡いただき、実装の最適化や閾値の増加等についてご相談ください。
下記は広告主の立場での API 使用例ですが、パブリッシャーとしての実装に関しても同様に当てはまります。
ページ送りのあるデータにクエリを実行する場合、クライアントは下記を守る必要があります:
first
または last
引数を指定する最大値を超えた場合、結果は切り詰められ、引数の first / last の指定は無視されます。
例:
{
advertiser {
adSets(first: 50) {
edges {
node {
id
name
ads(first: 50) {
edges {
node {
id
name
}
}
}
}
}
}
}
}
上記のクエリでは、最大で50の adSet が返され、各 adSet には最大で50の ad が含まれます。
結果群に対してページ送りをする場合、after または before 引数でどこからページを開始するかを指定する必要があります。例:
{
advertiser {
adSets(first: 50, after: "Mg==") {
edges {
node {
id
name
}
}
pageInfo {
endCursor
hasNextPage
}
}
}
}
このクエリの例では、カーソル位置 "Mg==" から最大50の adSet が返されます。このカーソル位置は、その前のクエリで返された endCursor の値に基づいて決められます。hasNextPage が false となった場合にページ送りが完了したとみなされます。
ページ送りに関しては、公式の GraphQL ウェブサイト で詳細を確認できます。
スキーマの検証を成功させるには、Marketing API への"コール"が 10,000 を超えないようにする必要があります。ここでの "コール"はリソースに対するリクエストを指します。GraphQLは一つのクエリに複数のコールを含める事ができるため、一つのクエリに含まれるコールの総数はAPIのクエリが実行される前に算出されます。
コールの回数は、結果に含まれるリソース (campaign, adSet, ad, app, insight 等) の数とおよそ同等です。
上記の例を確認してみましょう:
{
advertiser {
adSets(first: 50) { # <= 50 calls
edges {
node {
id
name
ads(first: 50) { # <= 50 calls
edges {
node {
id
name
}
}
}
}
}
}
}
}
この例では、クライアントは一回につき最大50個のadSetを要求しています。また各adSetに対し、最大50個のad を要求しています。
コールの総数を計算すると下記のようになります:
50 = 50 ad sets
+
50 x 50 = 2500 ads
= 2550 calls
現時点では、一時間あたりのコールの総数には制限を設けていません。しかしながら、この状況は将来変更される見込みです。
インサイトのレポートへのクエリをする場合、どのレベルに対するクエリでも上記の計算に含まれない複雑性によるコストが追加発生します。クエリに含まれる一日分に対し1コールが追加されます。
下記の例を考えてみましょう:
{
advertiser {
# 50 calls
adSets(first: 50) {
edges {
node {
id
name
# 7 calls
insights(timeRange: {from: "2018-03-01T00:00:00Z", until: "2018-03-08T00:00:00Z"}) {
timestamps
reports {
country
impressions
conversions
spend
}
}
}
}
}
}
}
この例では、クライアントは一度に最大50個の adSet を要求しており、各 adSet に対して7日分の3つの指標と一つのセグメントを要求しています
コールの総数を計算すると下記のようになります:
50 = 50 ad sets
+
50 x 7 = 350 insights
= 400 calls
本APIでは過去二年間分のデータにアクセスできます。