TikTok広告の数値を毎朝Slackに通知したくて、実装方針を整理しました。
いろいろ試した結論として、TikTok Marketing API を正攻法で申請し、GAS からエンドポイントを叩く構成にしています。
TikTok広告の日次通知は、Yoom/Make経由よりも、App申請してGASからAPIを直接叩くほうが運用コストと自由度のバランスが良いです。
前提: やりたいことはシンプル
欲しいのは次の3つだけです。
- 昨日のキャンペーン別 spend / clicks / impressions
- キャンペーン通算の消化額
- 毎朝9時にSlackへ自動通知
この要件だと、データ加工は軽く、取得ロジックも固定できます。
Yoom / Make も見たけど、今回は見送り
ノーコード連携はセットアップが速い反面、今回のケースでは次の点が気になりました。
- 指標や粒度の細かい調整で、結局ロジックが複雑化しやすい
- リトライやトークン更新など、運用の核心を外部に依存しやすい
- 将来の通知フォーマット変更時に、実装自由度が下がる
「早く始める」だけならノーコード連携は有効ですが、毎日運用の精度を上げる段階ではコード実装のほうが安定しやすいです。
最終方針: App申請 + GAS直叩き
今回の実装は、TikTokのApp申請を通したうえで、/report/integrated/get/ を使ってデータ取得する方針です。
構成は以下です。
- OAuthでトークン取得（初回）
- refresh_token でアクセストークン更新
- 昨日分のキャンペーン指標を取得
- 通算消化額を同じくAPIで集計
- Slack Webhookへ見やすく整形して送信
- GASトリガーで毎朝9時に実行
初回だけはApp申請とOAuthの導線を作り、その後は GASトリガー + refresh_token更新 で自動運用に寄せるのが実務的です。
この方針のメリット
- 通知フォーマットを自由に変更できる
- 取得指標の追加・削除が早い
- 失敗時の原因切り分けがしやすい
- 外部連携ツールのプラン制約に左右されにくい
TikTok APIは権限・審査・トークン期限の管理が前提です。実装より先に、申請と権限付与の導線を確定させると詰まりにくくなります。
まとめ
今回の判断としては、遠回りに見えても正攻法が最短でした。
「App申請して、GASで必要なエンドポイントを叩いてSlack通知する」が、今の要件には一番合っています。
TikTok広告通知の実装は、まず正規App申請を通してからGASで組む。これが最終的に一番ラクです。
