ある代理店が80件のクライアントアカウントを共有ログイン1つなしでオンボーディングした方法
Davide Ferraro
エージェンシー・オペレーションズリード
破綻点は、いつものように、スプレッドシートとしてやってきた。一握りのクライアントから広大なポートフォリオへと成長したメディアバイイング代理店は、「ログイン」というタブを保持していた。クライアントごとに1行、ユーザー名、パスワード、2FAバックアップ、最後に変更した日付の列。そのシートが80行を超えた日、運用責任者はスクロールを止め、明白なことを認めた。これはシステムではない、検索バー付きの負債だ。これは、その代理店が認証情報をまったく共有せずにクライアント広告アカウントをオンボーディングする方法を学んだ物語である。一度入力した1つのSystem-Userトークン、すべてのアカウントを浮かび上がらせる自動検出、そしてパスワードの代わりの内部ロール。
手早い答え: 各クライアントのMetaユーザー名とパスワードを集める代わりに、代理店は一度入力したSystem-Userトークンを通じてアカウントを接続した。business_id経由の自動検出が、そのトークンが到達できるすべてのビジネスマネージャと広告アカウントを浮かび上がらせ、バイヤーは内部のロールベースアクセスを通じて作業した。誰も生のMetaログインを持たなかったので、オンボーディングは認証情報の引き渡しであることをやめ、オフボーディングは1クリックになった。
これはよくある代理店のパターンから組み立てた合成事例だが、その失敗のかたちと解決策は本物である。正確な数字は説明のためのものだが、認証情報の散乱と、それが代理店のスケールにつれて危険になる様子は、そうではない。
破綻点：クライアントごとにログイン
最初の数年、代理店は知っている唯一の方法でクライアントをオンボーディングした。新しいクライアントが契約し、キックオフ通話は同じ気まずい依頼で終わった。「広告アカウントに入れるよう、Metaログインを共有してもらえますか？」ときにクライアントは自分の個人FacebookパスワードをShareした。ときに管理者権限を持つ使い捨てユーザーを作った。どちらにせよ、代理店はもう1つ保存すべき認証情報を持って去り、「ログイン」タブがもう1行成長した。
10件のクライアントでは、これは煩わしかった。80件では、フルタイムのリスクだった。クライアント側で変更されたすべてのパスワードが、キャンペーンが古くなるまで静かにアクセスを壊した。すべての2FAプロンプトが1人の電話に着信し、その人がビジネス全体の単一故障点になった。そして誰も、一言で答えるべき問いに答えられなかった。今、このクライアントのアカウントに正確に誰がアクセスを持っているのか？
代理店は5件のクライアントでは共有ログインのコストを感じない。50件を過ぎたどこかで一斉に感じる。認証情報のリストが誰も所有しない負債になり、すべての新しいクライアントがそれを悪化させるときに。あなたを始動させたモデルが、あなたを頭打ちにするモデルなのだ。
なぜ共有ログインが実際のリスクだったのか
代理店は、自分たちのリスクがパフォーマンス（悪い1週間、外した目標）に住んでいると思い込んでいた。本当の露出はログインシートだった。なぜ共有ログインがあなたの広告代理店を殺しているのかで示すように、共有された認証情報は、あらゆる世界の最悪を一度に併せ持つ。帰属できず、安全に取り消せず、監査できない。
3つの失敗が積み重なった。第一に、2FAシードとパスワードがパスワードマネージャに住んでいたので、1つのボールトへのアクセスが80件のクライアントへのアクセスだった。どのクライアントも承認しないであろう侵害面だ。第二に、ジュニアがデフォルトでフルアクセスを持っていた。共有ログインにはロールの概念がないので、新しいバイヤーに「パスワード」を渡すことは、すべてを渡すことだった。第三に、オフボーディングは手作業の探索だった。バイヤーが去ると、誰かがそのバイヤーが触れたすべてのビジネスマネージャを覚えていて、何も見逃さないことを願いながら、アカウントごとに手作業でアクセスを引き抜かなければならなかった。
その最後のものが運用責任者を夜眠らせなかった。何十ものクライアントのビジネスマネージャにまたがってアクセスが残った去るバイヤーは、共有ログインモデルのデフォルトの帰結だ。まさに代理店の広告アカウント権限の間違いのまとめで目録化されている種類の隙間である。
共有ログインの危険は、誰かがそれを推測することではない。それを持っているのが誰かをきれいに証明したり、スコープを絞ったり、取り上げたりが決してできないことだ。80件のクライアントの信頼を持つ代理店にとって、「誰がまだアクセスを持っているのか完全には確信がない」は、関係を終わらせる文である。
シフト：パスワードではなくトークンで接続する
変化は新しいツールというより、新しい考え方だった。アカウントアクセスを集める認証情報として扱うのをやめ、一度確立する接続として扱い始める。代理店はポートフォリオをWevionに移し、個人ログインではなくSystem-Userトークンを通じてクライアントアカウントを接続した。
その仕組みはほとんど拍子抜けだった。各クライアントについて、代理店はクライアントのビジネスマネージャに対してSystem-Userトークンを確立した。誰かの個人パスワードや2FAに依存しない、正規の機械レベルの接続だ。トークンは一度入力された。それから自動検出が、かつて午後を要した部分をやった。business_idを読み、そのトークンが到達できるすべての広告アカウントとビジネスマネージャを浮かび上がらせ、自動的にワークスペースに引き込んだ。画面間でアカウントIDをコピーすることも、3週間後に見つかる見逃したアカウントもない。
共有ログインは永遠に守らなければならない秘密だ。System-Userトークンは一度確立して、それから統治する接続である。個別ログイン対マルチブランド運用層で探求された区別だ。代理店はもはやパスワードを保存するビジネスにいなかった。アクセスを付与するビジネスにいた。
パスワードではなくトークンでアカウントを接続するとき、オンボーディングは秘密の引き渡しであることをやめ、統治された接続の確立になる。一度接続すれば、認証情報を二度と回さない。その1つの反転こそが、次の80件のクライアントを複利ではなくスケールさせるものだ。
チームを認証情報ではなくロールにマッピングする
アカウントが接続されると、代理店は共有ログインの時代が決してきれいに尋ねさせなかった問いに直面した。チームの誰が、どのクライアントで、何をできるべきか？
内部のロールベースアクセスが、それを認証情報ではなく設定にした。各バイヤーは実際に作業するアカウントにスコープされたロールを与えられた。エンタープライズ名簿のシニアはそこで広いアクセスを得て、中小企業の帳簿では何も持たなかった。ジュニアは割り当てられたアカウントちょうどを得て、それ以上は何も持たなかった。決定的に、そのアクセスを付与することは決してMetaログインを渡すことを含まなかった。その下のトークンは代理店に留まり、バイヤーは単に自分の名前のついたロールのもとでワークスペース内で作業した。
これが共有ログインを不可能にするシステムの半分だ。パスワードはスコープできない。与えるか保留するかしかできない。ロールは、代理店が人が必要とする正確なアクセスを、それ以上ではなく付与することを可能にする。代理店の初週クライアントオンボーディングのプレイブックで説明する規律あるオンボーディングフローの前提だ。アクセスは、留まることを願う秘密ではなく、割り当て、レビューし、調整するものになった。
パスワードではなくロールでアクセスを付与することは、オンボーディングそのものが何であるかを変える。「この人にログインを与えるべきか」という二者択一の問いを尋ねるのをやめ、「この人はここで何をできるべきか」を尋ね始める。それは本物の運用がとにかく答える必要のある問いである。
次のクライアントを初週でオンボーディング
証拠は、代理店が次にクライアントと契約したときに現れた。古いモデルでは、新しいアカウントのオンボーディングは数日にわたる神経を使う事だった。クライアントを認証情報のために追いかけ、保存し、アクセスをテストし、誰も言及しなかったサブアカウントを発見し、また追いかけ、ついに2週目の終わりにバイヤーを作業させる。
新しいフローはそれを圧縮した。代理店はSystem-Userトークンを確立し、自動検出がクライアントのアカウントとビジネスマネージャを一度に浮かび上がらせ、運用責任者がバイヤーにロールを割り当てた。バイヤーは初週にワークスペース内で作業していた。パスワードリセットを待つこともなく、休暇中の誰かに回された2FAプロンプトにブロックされることもなく。クライアントの側も、個人のFacebookパスワードを外部の代理店に渡さずに済んで安堵し、気まずいキックオフの依頼を信頼の点に変えた。
オンボーディングモデルが壊れている最も明確なサインは、新しいアカウントでバイヤーを生産的に作業させるのにどれだけ時間がかかるかだ。それが緊張した2週間からきれいな初週に下がるとき、あなたは単に時間を節約しただけではない。代理店とクライアントの両方を神経質にさせていたオンボーディングの部分を取り除いたのである。
セキュリティと監査について何が変わったか
セキュリティの物語は、運用責任者が完全には予期していなかった部分だった。2つのことが一度に劇的に良くなった。
オフボーディングが探索から1クリックになった。バイヤーが去ったとき、くまなく探すビジネスマネージャのリストも、80件のクライアントでリセットする共有パスワードもなかった。バイヤーのロールはワークスペースで取り消され、彼らのアクセスは一度にあらゆる場所で終わった。実質的に1アクションだ。「全部取れたか?」の不安は消えた。アクセスがそもそも認証情報に散らばっていなかったからだ。
そして代理店はついにアクセスの問いに答えられた。すべてのバイヤーが共有された識別子ではなく名前のついたロールのもとで作業したので、代理店は誰が何に触れられるかの明確な像と、誰が触れたかの記録を持った。権限が誰がアカウントを変更できるかを決め、証跡が彼らが何を変更したかを記録する。このように自分のポートフォリオを運用する代理店は、どのクライアントにも正確に誰がアクセスを持ち何をしたかを伝えられる。「バイヤーの1人だったと思います」とは異なる会話だ。
トークンで接続しロールを付与することの静かな見返りは、最も難しい2つの代理店の問い(誰がアクセスを持つか、そしてどれだけ速くそれを取り除けるか)の両方が、簡単な答えを得ることだ。オンボーディングは速くなったが、オフボーディングは安全になった。そして多くのクライアントのアカウントを持つ代理店にとって、安全はより価値がある。
ポートフォリオビュー：1つのワークスペース、6つのプラットフォーム
トークンとロールのモデルはMeta専用の便宜ではなかった。同じ原則(アカウントを一度接続し、内部ロールを付与し、認証情報を決して回さない)が、ワークスペースがサポートする6つのプラットフォーム(Meta、Google、TikTok、Taboola、Snapchat、Outbrain)にまたがって広がる。MetaとTikTokと少しのTaboolaを動かすクライアントは、もはや3つのログイン問題ではなかった。1つのワークスペースの中の1つの接続されたクライアントであり、代理店のバイヤーはすでに持っていた同じロールのもとですべてのチャネルで作業した。
その統合がついに「ログイン」タブを永久に引退させた。代理店は6つのプラットフォームにまたがる80件のパスワードを管理してはいなかった。数百の認証情報に達していたであろう数だ。1つのポートフォリオを管理していた。ロールによって統治され、トークンによって接続され、1箇所に見える。運用プレイブックの残りはagency toolsハブにある。
価格について、モデルはチームではなくポートフォリオとともにスケールする。すべてのプランでシートは無制限なので、バイヤーを追加してもコストは増えず、並列アカウントは永続的なFreeティア(€0)の3から、月額€99のStarterと月額€499のProを経て、月額€1,499のPlus(年額€1,199、年払いで−20%)の無制限までスケールし、Enterpriseはカスタムプランだ。すべての有料ティアには無料プランと共存する14日間のトライアルが含まれる。
ポートフォリオビューの要点は、より美しいダッシュボードではない。アクセスモデル(一度接続し、ロールを付与し、1クリックで取り消す)が、クライアントが1つのプラットフォームを動かそうと6つすべてを動かそうと、同一に機能することだ。代理店はチャネルごとにログイン問題を持つのをやめ、1つの統治された運用を持ち始めた。
教訓：運用層を認証情報から分離する
代理店の若い版に何と伝えるかと問われて、運用責任者は率直だ。間違いはアカウントアクセスと運用ツールを同じものとして扱ったことだった。それらは違う。認証情報(パスワード、2FAシード)はクライアントのものだ。運用層、バイヤーがローンチ、編集、レポートする場所は、あなたのものだ。共有ログインの時代はそれらを融合させ、その融合がすべての問題の源だった。散乱、オフボーディングの探索、答えられないアクセスの問い。
それらを分離することが解決策全体だ。アカウントをSystem-Userトークンで一度接続し、自動検出にそのトークンが到達できるすべてを浮かび上がらせ、チームにパスワードの代わりに内部ロールを与える。それをすれば、81件目のクライアントのオンボーディングは1件目のオンボーディングのように見える。接続を1つ確立し、いくつかのロールを割り当てる。とうに成長を止めるべきだったスプレッドシートのもう1行ではなく。ログインを共有せずにクライアントアカウントをオンボーディングできる代理店こそが、リスクをそれと並んで複利にすることなくクライアントを増やし続けられる代理店なのだ。
よくあるご質問
The Ad Signal
推測を拒否するメディアバイヤーのための週刊インサイト。1通のメール。シグナルのみ。
関連記事
共有ログインがあなたの広告代理店を静かに蝕んでいる:ロールベースのシートが必要な理由
1つの共有パスワードは、クライアントが3社のうちは効率的に思えます。30社になると、それは運用上の負債です。説明責任もセキュリティも、弁明できる記録もありません。ここでは、範囲を絞った7段階の権限シートで共有ログインを完全に置き換える方法を紹介します。
ストアごとの個別ログイン vs. 1つのマルチブランド運用レイヤー
複数ストアのポートフォリオを運用するやり方は2つだけです。ブランドごとの個別ログインを行き来するか、すべてを1つのレイヤーから運用するか。 これは、その2つのモデルを手間・ミスのリスク・再利用・レポート、そして両者を分ける唯一の問い —「本当にキャンペーンをローンチできるのか、それともただ眺めるだけなのか」— で並べて比較する、忖度なしの記事です。
代理店が新規クライアントの広告アカウントを初週でオンボーディングする方法（Wevion活用）
月曜に新しい顧問契約が決まる。多くの代理店は初週を混乱のなかで過ごします。 バラバラなアクセス申請、その場しのぎのタグ付け、最初のレポートを巡る慌ただしさ。 ここでは、ある代理店がオンボーディング全体をひとつの連続したシーケンスとして回し、 金曜にはロール・UTM・予約レポートがすでに稼働している状態で締めくくる方法を紹介します。