投稿

Google広告の機会損失をPythonで可視化する実装

イメージ
Google広告で「まだ伸ばせるはずなのに配信が頭打ち」と感じる場面は多い。その正体はたいてい機会損失、つまり出せたはずのインプレッションを取りこぼしている状態だ。管理画面でも数値は見えるが、複数アカウントを横断して毎日追うのは現実的でない。この記事では、インプレッションシェアをPythonで取得し、予算とランクどちらが原因かを自動で切り分ける実装を示す。読み終えれば、機会損失の可視化を定時実行に載せる下地ができる。 インプレッションシェアが機会損失を映す理由 インプレッションシェア（IS）は、出せたはずの表示回数のうち実際に出せた割合を示す。ISが60%なら、残り40%は何らかの理由で取りこぼしたことになる。つまりISは「配信の伸びしろ」を数値化した指標だ。運用者が本当に知りたいのは割合そのものより、失った40%の内訳である。 Google広告はこの内訳を2つに分けて提供する。予算不足で失った分と、広告ランク不足で失った分だ。前者は予算を積めば回収でき、後者は入札や品質の改善が要る。打ち手がまったく異なるため、混ぜて見てはいけない。 3つの指標で損失原因を切り分ける Google Ads APIには機会損失を切り分ける3指標がある。search_impression_share（取れた割合）、search_budget_lost_impression_share（予算で失った割合）、search_rank_lost_impression_share（ランクで失った割合）だ。この3つはおおよそ「IS＋予算ロス＋ランクロス≒100%」の関係になる。合計がほぼ100%に収まるので、内訳の検算にも使える。 判断はシンプルだ。予算ロスが大きいキャンペーンは、予算を積めば素直に配信が伸びる見込みが高い。ランクロスが大きいなら、入札引き上げか広告文・品質スコアの改善が先だ。数値で原因を特定してから動くので、感覚頼みの増額を避けられる。この切り分けの実データ運用は 広告の日予算を自動計算するPython実装 と組み合わせると効いてくる。 PythonとGoogle Ads APIで取得する手順 取得はGAQL（Google Ads Query Language）で書く。キャンペーン単位なら次の一行で3指標がまとめて取れる。SELECT campaign.na...
コメントを投稿
続きを読む

Google広告の曜日・時間帯別CPAをPythonで集計

イメージ
自動入札に任せているのに、曜日や時間帯でCPAがぶれる。そう感じる運用者は多い。Google広告の管理画面は曜日と時間帯を同時に見られず、168コマ（7曜日×24時間）の全体像がつかみにくい。ここではGoogle Ads APIとPythonで168コマを一括取得し、CPAの穴を見つけて入札調整へ落とすまでの手順を、実装でつまずく点も含めて示す。今日から自分のアカウントで再現できる。 自動入札の時代でも曜日・時間帯分析が効く理由 tCPAやコンバージョン最大化を使っていても、曜日・時間帯の分析は無駄にならない。理由は2つある。1つは、自動入札は過去データを学習するため、CVが薄い深夜帯に配信予算が漏れている期間が発生しうること。もう1つは、広告のスケジュール（ad schedule）による入札単価調整が、自動入札と併用できる場面が残っていることだ。 管理画面でも曜日別・時間帯別は見られるが、両者の掛け合わせは1画面に出ない。0-7時の日曜だけCPAが2倍、といった コマ単位の異常 は、168コマを一枚の表にして初めて見える。APIで取れば、この掛け合わせを一度に抜き出せる。 Google Ads APIで168コマを一括取得するGAQL Google Ads APIは、UI と違って1つのクエリに複数のセグメントを指定できる。曜日（segments.day_of_week）と時間帯（segments.hour）を同時に指定すれば、campaign リソースから168コマ分の行が返る。セグメントの仕様は公式のフィールド一覧（developers.google.com/google-ads/api/fields/v22/segments）で確認できる。 この記事で一番のアセットが次のGAQLだ。ブックマークして、campaign を ad_group に変えるなど自分の粒度に書き換えて使ってほしい。 SELECT campaign.name, segments.day_of_week, segments.hour, metrics.cost_micros, metrics.conversions, metrics.clicks FROM campaign WHERE segments.date DURING LAST_30_DAYS これを GoogleAdsServi...
コメントを投稿
続きを読む

Meta広告の重複をPythonで検知して分かった3つ

イメージ
Meta広告のCPAが下がらない。予算を足しても配信が伸びない。その原因が、実は自分の広告セット同士の「オーディエンス重複」にある場合は多い。同じユーザー層を複数の広告セットで狙うと、Metaのオークションで自社の広告が競合し、CPMが上がる。この記事では、広告マネージャの手動確認ではなく、Marketing APIとPythonで重複を検知する手順をまとめた。実運用で詰まった点も添える。 なぜ広告セットの重複がCPAを押し上げるのか オーディエンス重複とは、複数の広告セットが同一ユーザーを配信対象に含む状態を指す。重複率が高いと、Metaのオークションで自社の広告セット同士が入札を奪い合う。結果、CPMが上がりCPAも連動して悪化する。特にカスタムオーディエンスと類似オーディエンスを併用する構成で起きやすい。 広告マネージャにも「オーディエンスの重複を表示」機能はある。ただし手動で2つずつ選ぶ方式で、広告セットが10個を超えると現実的に回らない。運用規模が大きいほど、APIで一括取得して機械的に判定する価値が出る。手動確認の限界は Meta広告レポートをPythonで自動化する実装手順 でも触れたとおりだ。 Marketing APIで広告セットのtargetingを取得する 重複判定の入口は、各広告セットの配信条件（targeting）をAPIで取ることだ。エンドポイントは広告アカウント配下の adsets で、fields に name と targeting を指定する。1行で書くと GET https://graph.facebook.com/v20.0/act_アカウントID/adsets?fields=name,targeting,effective_status&access_token=トークン を叩けば、各広告セットのJSONが返る。 targetingの中で重複判定に効くキーは4つある。（1）geo_locations（地域）（2）age_min と age_max（年齢帯）（3）genders（性別）（4）custom_audiences と flexible_spec 内の interests（カスタム客層・興味関心）。特にcustom_audiencesのIDが複数の広告セットで一致していれば、それは明確な重複シグ...
コメントを投稿
続きを読む

Claude CodeとMCPで広告APIを繋ぐ実装手順

イメージ
広告レポートの集計や残予算の計算を、毎朝手作業でこなしていないだろうか。Google広告やMeta広告のAPIをClaude Codeから直接叩ければ、この定型作業は数十秒で終わる。鍵になるのがMCP（Model Context Protocol・AIツールと外部APIをつなぐ共通規格）だ。この記事では、PythonでMCPサーバーを自作し、Claude Codeに広告APIをつなぐまでの手順を、実際に詰まった点つきでまとめる。読み終えれば、今日から自分の運用環境に組み込める。 なぜ広告運用にMCPが必要なのか MCPはAnthropicが2024年末に公開した開かれた規格だ。AIツールが外部APIを使うための共通の口を定める。これまではツールごとに個別の連携を作る必要があった。MCPなら一度サーバーを用意すれば、Claude CodeでもChatGPTでも同じデータに届く。2026年時点で公式レジストリには8,000を超えるMCPサーバーが登録済みだ。広告分野はまだ法人メディアの実装記事が薄く、先行者の窓が開いている。 広告運用と相性が良い理由は3つある。1つ目は、GAQLやInsightsの複雑なクエリをAIに任せられる点。2つ目は、残予算や消化ペースの計算を自然言語で頼める点。3つ目は、複数媒体の数字を1つの窓口で横断できる点だ。手元のGoogle広告APIの叩き方は Google広告APIをPythonで動かす手順 にまとめている。MCP化の前にAPI単体で動かしておくと理解が早い。 Pythonで最小構成のMCPサーバーを作る 実装は驚くほど短い。Python公式のMCP SDKを使えば、3ステップで動く。まず環境を用意し、次にツールを1つ定義し、最後にClaude Codeへ登録するだけだ。以下の手順はブックマークして、自分のAPIキーとエンドポイントに書き換えて使ってほしい。詳しい仕様はMCP公式サイト（https://modelcontextprotocol.io）で確認できる。 （1）SDKを入れる: pip install "mcp[cli]" を実行する。（2）サーバー本体を書く: FastMCPを読み込み、関数の上に @mcp.tool() デコレータを付けるだけで、その関数がAIから呼べるツールになる。残予算を返す関...
コメントを投稿
続きを読む

Google広告スクリプトで予算超過を自動検知する方法

イメージ
広告運用で最も避けたいのは、月の半ばで日予算の消化ペースが崩れる事態だ。気づいた時には月予算を大きく超えている、という失敗はよくある。とはいえ毎朝すべてのキャンペーンの残予算を手で見るのは続かない。Google広告スクリプトを使えば、消化異常を検知して自動でメール通知できる。しかも管理画面の中だけで完結し、開発者トークンもサーバーもいらない。この記事では、コピペで動く監視の骨格と、実運用でつまずいた罠までまとめる。 なぜAPIでなくGoogle広告スクリプトなのか Google広告の自動化には二つの道がある。一つはGoogle広告APIをPythonなどの外部プログラムから叩く方法だ。もう一つが、管理画面の中でJavaScriptを動かすGoogle広告スクリプトである。前者は開発者トークンの申請やOAuth認証が要る。後者は申請なしで、アカウントにログインできれば今日から書ける。 監視や通知のような軽い自動化なら、後者の手軽さが効く。逆に、3媒体の横断集計や重い処理はAPI側が向く。用途で使い分けるのが正解だ。より本格的にPythonから制御したい場合は Google広告APIをPythonで動かす手順 を参照してほしい。日予算そのものの計算ロジックは 日予算を自動計算するPython実装 で扱った。 予算超過が起きる仕組みと監視の軸 Google広告の日予算は、1日の消化が設定額の最大2倍まで振れることがある。これは公式仕様で、月間ではならされる。だが月途中の日予算変更や急な配信増があると、体感としての超過は普通に起きる。だから「月予算に対して今どのくらいのペースか」を日次で見る必要がある。 監視の軸はシンプルだ。残予算を残日数で割った理想ペースと、実際の消化を比べる。実消化はGAQLという問い合わせ言語でcost_microsという項目を取る。この値は円ではなくマイクロ単位なので、100万で割って円に直す。例えばcost_microsが96810000なら、実消化は96.81ドル相当になる。桁を意識するだけで、通知の精度は大きく変わる。この監視の考え方の完全版はnoteの実践ガイドにまとめている。 コピペで使える監視スクリプトの骨格 ブックマークして、自分のアカウントに合わせて閾値やメールアドレスを書き換えて使ってほしい。全体は次の4ステップで組む。 （1）当...
コメントを投稿
続きを読む

Meta広告の疲労を自動検知するPython実装【保存版】

イメージ
Meta広告のクリエイティブは、配信して数日で効果が落ちる。同じ人に何度も表示されると飽きられ、CTRが静かに下がっていく。これがクリエイティブ疲労だ。運用者の悩みは「気づくのが遅れること」にある。管理画面を毎日見ても、数字のブレか本物の疲労かは判断しづらい。そこで有効なのが、フリークエンシー・CTR・CPMの3指標をPythonで毎日自動チェックし、閾値を割った瞬間にSlackへ飛ばす仕組みだ。この記事では、Meta Marketing APIから指標を取り、疲労を定量判定するまでの実装を手順で示す。 クリエイティブ疲労はなぜ検知が遅れるのか 疲労の主犯はフリークエンシーだ。同じユーザーへの表示回数が増えるほど、反応は鈍る。目安として、フリークエンシーが3〜4を超えると疲弊の予兆とされる。ただし単独では判断できない。数字は日々ブレるからだ。 現場で使える基準は「CTR低下」と「CPM上昇」の同時発生だ。この2つが揃ったとき、疲弊がオークションの非効率にまで波及したサインになる。逆に言えば、フリークエンシーだけを見て差し替えると、まだ効くクリエイティブを早期に捨ててしまう。判定ロジックの設計は 現場の指標解説 とも整合する。 人の目で毎日これを追うのは非効率だ。3指標の複合条件は、コードに落とすほうが速く正確になる。 疲労を定義する3つの指標と閾値 検知ロジックは、次の3条件をANDで結ぶ。1つでも欠けたら「疲労ではない」と判定する。過検知を防ぐための設計だ。 フリークエンシー ：直近7日で3.0を超えている CTR減衰 ：直近7日のCTRが、過去ピークから25%以上低下 CPM上昇 ：直近7日のCPMが、基準期間から10%以上上昇 閾値は媒体や商材で動く。BtoBの狭い配信面ならフリークエンシーは早く上がるため、3.0でなく2.5を採る場合もある。まず上の初期値で回し、誤検知の頻度を見て自分の口座に合わせて調整するのが実務的だ。この閾値表はブックマークして、自分の環境に合わせて書き換えて使ってほしい。 重要なのは「ピークからの相対低下」で見る点だ。CTRの絶対値は業種で桁が違う。だが「自分の過去最高から何%落ちたか」なら、どの口座でも同じ物差しになる。 Meta APIから指標を取るPython実装 データ取得はMeta Marketing APIのinsight...
コメントを投稿
続きを読む

GA4と広告のCVズレをPythonで自動検知する実装

イメージ
広告の管理画面では今日のCVが12件。だがGA4を開くと8件しかない。この食いちがいに手を止めた運用者は多いはずだ。数字が合わないまま予算判断を続けると、良い広告を止め、悪い広告に足す事故が起きる。原因はバグとは限らない。GA4と広告プラットフォームは、そもそも別の物差しでCVを数えている。ここでは、ズレが生まれる4つの理由を整理し、GA4 Data APIと広告APIをPythonで毎日つき合わせ、乖離が閾値を超えたら気づける監視の作り方までを示す。手作業の突合をやめ、判断できる数字を自動でそろえるのが狙いだ。 なぜGA4と広告のCVはズレるのか まず前提として、両者の数字は一致しない方が普通だ。ズレの正体は、大きく4つに分けられる。 アトリビューションの物差しが違う ：広告側は自媒体のなかの接点だけを成果とみなす。GA4は自然検索や他媒体も横断し、最後の流入元へ貢献を割りふる。同じCVでも帰属先が変わる。 Cookie規制とITP ：SafariのITPでCookieの寿命が短くなった。クリックからCVまで日数が空くと、GA4は広告流入と結びつけられなくなる。 タグの二重計測・未発火 ：イベント名の重複やトリガーの誤設定で、1件のCVが2件にふくらむ。逆に未発火で減ることもある。 クロスドメインの断絶 ：外部カートや決済へ移る瞬間に参照元が切れ、流入経路が失われる。 実運用での体感では、GA4のCVが広告管理画面より2〜3割ほど少なく出るのは珍しくない。媒体側の乖離要因は https://squadbeyond.com/blog/ga4_suuchikairi/ や https://markecats.co.jp/column/discrepancy-reasons/ が詳しい。大事なのは、この差をゼロにしようとしないことだ。閾値を決めて「いつもの差か、事故か」を見分ける発想に切りかえる。 手作業の突合が破綻する理由 毎朝、広告管理画面とGA4を並べて数える運用は長くは続かない。媒体が3つ、口座が10あれば、確認だけで30分が飛ぶ。人が見るかぎり、見落としと転記ミスが必ず混ざる。しかもズレは、数字が動いた瞬間に気づきたい。翌週に気づいても、その間の予算配分はもう狂っている。だから突合はコードに任せ、人は「閾値を超えた時だけ」見ればよい。異常を検知して通知に流す発...
コメントを投稿
続きを読む