広告アカウントのトラブルは、環境の品質そのものより、環境が変わり続けることから起きる場合があります。アカウントと支払い情報を長期的に一致させ、説明可能なログイン地域を保ち、チーム操作を記録し、切り替えを抑えることが重要です。
代理店が数十、数百の広告主アカウントを管理しているとき、最も怖いのは配信量を伸ばせないことではありません。1つのアカウントの問題が連鎖的に他のアカウントへ波及することです。失うのは予算だけでなく、代理店の実行力に対するクライアントの信頼でもあります。
多くの人は環境品質に注目します。フィンガープリントが十分に自然か、IPがクリーンか、といった点です。もちろん重要な指標ですが、Media Buyの現場で実際に問題につながりやすいのは別の要素です。
アカウント情報と支払い情報は長期的に一致させる
広告プラットフォームは、どの端末からログインしたかだけでアカウントを判断するわけではありません。アカウント主体、紐づけた支払い方法、請求情報、連絡先など、背後にある事業情報が安定しているかも見ます。これらが長期にわたって一貫していれば、プラットフォームから見たアカウント履歴は明確です。途中で頻繁に変更し、とくに支払い構成を突然別のものへ切り替えると、手動審査につながりやすくなります。
もう1つ見落とされやすい点があります。複数のアカウントで同じカードや同じ支払い情報を共有すると、プラットフォーム側で関連するアカウントとして見られる可能性があります。代理店が異なる広告主の配信を担当する場合、支払い情報は広告主ごとに分けるべきです。これはコンプライアンスのためでもあり、無関係なアカウント同士が影響し合うのを避けるためでもあります。
ログイン地域には説明できる関係性を持たせる
米国市場向けに配信しているアカウントが、事業と関係のない地域から長期間ログインされている場合、そのパターンには説明が必要です。それだけで直ちに停止されるとは限りませんが、リスク履歴の一部として残り、後から行動やコンテンツに別の問題が出た際に再び参照される可能性があります。
合理的なのは、ログイン地域と配信地域の間に説明可能な関係を持たせることです。アカウントが主に特定の市場を対象としているなら、ログインの出口もできるだけその市場に近づけます。チームが複数の都市に分散して働く場合は、問題が起きてから補うのではなく、あらかじめこの関係を設計しておく必要があります。
チーム運用で最も困るのは、誰も状況を説明できないこと
代理店チームは通常、役割で業務を分けます。広告主アカウントの作成やオンボーディングを担当する人、クリエイティブと入札を最適化する人、ランディングページを担当する人、といった形です。全員が同じ環境を共有すると、問題は主に次の3点に集中します。
- 誰かが入札や配信地域を変更したのに、後から誰が変更したのか分からない
- 環境メモやプロキシ設定が上書きされ、引き継ぎ時に情報が一致しない
- アカウントに問題が出たとき、構築工程と最適化工程のどちらに責任があるのか分からない
ロール別の権限設定で多くは解決できます。構築ロールは環境作成、IPの紐づけ、開設情報の入力だけを担当します。最適化ロールはクリエイティブや入札を変更できますが、IPやタイムゾーンなどの環境パラメータは変更できません。責任者はすべての環境と操作ログを確認できます。権限以上に重要なのが、操作履歴を残すことです。 誰が、いつ、どの環境にログインし、どのパラメータを変更したのかを確認できる必要があります。小規模なチームでは価値が見えにくくても、複数のクライアントを同時に担当するようになると、履歴がなければ責任の切り分けができません。
頻繁な環境切り替えは、環境品質が平均的であることより危険になり得る
ここが最も直感に反する点です。品質が平均的でもずっと変わらない環境のほうが、設定は優れていても数日ごとにIP、端末、タイムゾーンを変更する環境より、一般には安全です。
理由は、プラットフォームがリスクを見るときに「変化」を重視するからです。同じアカウントが短期間にログイン地域を何度も移動したり、毎回端末特性が違ったりすれば、その変化自体が異常として履歴に残ります。反対に環境が安定していれば、一般的な住宅IPであっても、プラットフォームが追加で注視する理由は少なくなります。
したがって、環境戦略の重点は不要な変更を減らすことです。アカウントを環境に紐づけた後は、安易に移行しないようにします。IPを変更するのは、元のノードが使えなくなったなど明確な理由がある場合に限り、よりクリーンに見せる目的で定期的にローテーションしないようにします。複数人で作業する場合も、同じアカウントへメンバーごとの端末から順番にログインする運用は避けます。
実際の運用ではこう進める
- クライアントとプラットフォームごとに環境を作り、プラットフォーム、クライアント、地域など統一した命名形式を使ってグループ管理します。環境が増えるほど、命名ルールが重要になります。
- 同一プラットフォームの各アカウントに独立した環境を割り当て、フィンガープリントを差別化して設定し、Cookieとローカルストレージを完全に分離します。PurpleMarkはこのような環境分離機能を提供し、1台のPCで数百の環境を管理しながら、ログイン情報や環境データを相互に共有しない運用を可能にします。
- 配信前に対象地域の環境からクリエイティブを確認し、禁止表現がないか、現地の慣習に合っているかをチェックして、配信後の却下を避けます。
- 環境メモに紐づけたIP、アカウントの用途、担当者を明記し、引き継ぎやトラブル調査をしやすくします。
前提として、アカウント自体が規約に準拠している必要がある
環境分離が解決するのは、アカウント間の技術的な干渉です。各アカウントがプラットフォームのポリシーに従う必要があるという前提は変わりません。アカウント資格、クリエイティブ規定、ランディングページのコンプライアンス要件は、環境をうまく整えたからといって緩くなるものではありません。アカウント基盤の目的は、複数の正当なアカウントを安定して運用することであり、それ以外ではありません。
本記事はアカウント管理の経験共有のみを目的としており、配信や収益に関する助言ではありません。
