Audience APIでoperation_type:REPLACEに該当する機能はありませんか?


#1

v3 -> v4 へのバージョンアップを実施中なのですが、
v3 では、以下APIを利用する事で、operation:REPLACEによるオーディエンスデータの総入れ替えが可能だったと思います。
POST accounts/:account_id/tailored_audience_changes

v4でも同じ事をしたいのですが、やり方はありますでしょうか?
以下Audience APIでは、UpdateとDeleteしかなさそうです。
POST accounts/:account_id/tailored_audiences/:tailored_audience_id/users

※tailored_audience自体の削除は広告が停止してしまうと思いますので、そのような解決の仕方は無理です。


#2

こんにちは。

内容について確認し、分かり次第こちらにアップデートさせていただきます。
以上、よろしくお願いいたします。


#3

@masahita

こんにちは。こちら確認をとりましたが、REPLACEの機能は Audience API では提供されないとのことです。

以上、よろしくお願いいたします。

前田


#4

確認ありがとうございます。

すみません、その場合、
テイラードオーディエンスの内容を洗い替えするには、どのようにすれば良いでしょうか?

もし代替機能が無い場合、以下 3 点を追加で質問させてください。

  1. 1回のリクエスト内で、全く同じ要素をUpdate&Deleteした場合、どのような処理になりますか?
    → Updateが優先される?(されて欲しいです)

  2. 複数回リクエスト内で、全く同じ要素をUpdate&Deleteした場合、どのような処理になりますか? (リクエストAでUpdate、リクエストBでDeleteなど)
    → バッチ処理時にjsonデータが連結され、リクエストAのUpdateが優先される?(されて欲しいです)
    ※優先されるとしても、それでは防げないパターンはありますが、、、(リクエストAがバッチA、リクエストBが6〜8時間後のバッチBでキャッチアップされてしまった場合など)
    ※こちらで実験してみても良いですが、公式に仕様を明記して頂けると幸いです。

  3. POSTデータサイズ上限はいくつに設定されていますでしょうか?
    → かなりのビッグサイズであれば、一度のリクエストでREPLACE同等のjsonデータにできると思いますので、色々な工夫が不要になるかなと考えています。

また、今想定している代替仕様としまして、
ローカル環境に、過去に送信したオーディエンスデータを保存しておき、
過去のオーディエンスデータ全件を削除するリクエストと、新規追加したいオーディエンスデータを同時に送信する事を考えています。
その場合に、上記 3 点の内容次第では、Delete処理を先に完了させてからUpdate処理を実行する必要があるかと思いますが、それだと6〜8時間待機しなければ反映がされないため、実用性に欠けると考えています。(削除処理が完了してから最速でも6〜8時間は空のオーディエンスデータになっている状態が存在してしまう)

正直なところ、代替する機能が無いのであれば、廃止は少し延期して欲しいと思っているのと、
REPLACEが廃止なのであれば、その理由を確認させてください。


#5

@masahita

質問の内容については現在確認中となります。
TAの洗い替えについてですが、line_itemに対して TA を Delete -> Create という運用は難しいでしょうか?

Batch jobによる新しい TA リストの作成完了を確認後、DELETE accounts/:account_id/targeting_criteria/:targeting_criterion_id エンドポイントにより削除、その後すぐに新しい TA リストを POST エンドポイントにて作成、という流れになるかと思います。


#6

TAの洗い替えについてですが、line_itemに対して TA を Delete -> Create という運用は難しいでしょうか?

すみません、そのような運用は難しいのです・・。
キャンペーンターゲティングに紐づけるオーディエンスIDは固定にした上で、オーディエンスの内容を更新する必要があります。
キャンペーンの設定自体は変えずに、定期的にオーディエンスの内容を更新したいです。(現在v3ではそうしています)


#7

すみません、追加の質問となってしまいますが、

・バッチ処理時には、effective_at のパラメータを参照して、その順序で処理が実行されるという認識で合っていますでしょうか?

e.g. 全く同じオーディエンスデータを Update -> Delete -> Update とリクエストすると、きちんとオーディエンスデータが追加された状態になる。
※デフォルトで effective_at が現在時刻になっているため、Update -> Delete -> Update の順番で処理され、最後のUpdateでオーディエンスデータが追加された状態で完了する

上記が正しければ、REPLACEが無くとも、ローカルに前回送信データを保存しておく事である程度同様の処理ができると考えています。