あるチームが12のビジネスマネージャーを1つのワークスペースに統合した方法

何年もの間、この急成長する消費者ブランドは1つの広告運用を持っていませんでした。12持っていました。12の別々のMetaビジネスマネージャー、つまり拡大した地域ごとに1つ、いくつかは買収から無傷で継承され、いくつかは誰も引退させなかった古いエージェンシーのセットアップから残ったもので、すべての営業日にそのメディアバイヤーは、それらの間を移動する静かな税を払っていました。これは、チームがconsolidate multiple business managers one workspaceを、別々のログインの壁ではなく1つのSystem-Userトークンとbusiness_idの自動検出を使って、一度に1つずつ単一の運用レイヤーに統合することをどう学んだかの物語です。

これは複合的な物語ですが、そのどの拍子も、単一のビジネスマネージャーを越えてスケールするあらゆるブランドにとって本物です。名前と正確な数字は説明用です。失敗のモードと修正はそうではありません。

散在：誰も計画しなかった十数のビジネスマネージャー

誰一人として座って、12のビジネスマネージャーを運用しようと決めたことはありません。それらは蓄積しました。ブランドは1つで始まり、それから2つ目の国でローンチしそのために別々のBMを立ち上げました。よりクリーンな請求、よりクリーンな権限、という理屈でした。3つ目が次の市場のために続きました。2つの買収が、それぞれライブの広告アカウントと、誰も飛行中に移行したくなかったページ、ピクセル、過去の支出のもつれを保持する、完全に構築された自身のビジネスマネージャーとともに届きました。古いエージェンシーの関係が、まだ稼働するアカウントを保持するBMを残していました。誰かが数えた頃には、エステートは12のビジネスマネージャーの深さで、地域と起源にわたって散らばり、全体像を示す単一の場所がありませんでした。

その中のアカウントは健全でした。キャンペーンが走り、支出が流れ、パフォーマンスは良好でした。問題はどの1つのビジネスマネージャーでもありませんでした。問題は、それらが12あり、ブランドの広告チームが、そのすべてにわたって働くことを期待されたひと握りの人々だったことです。ビジネスマネージャーの中で複数のアカウントを運用するガイドで説明するように、BMは組織的なコンテナであり、コンテナは統合するよりはるかに簡単に増えます。

隠れた税：一日中BMを切り替える運用者

散在のコストは項目として現れませんでした。摩擦として現れ、すべての時間にわたって薄く広がりました。ブランドのトップ3市場にわたってペーシングをチェックするバイヤーは、それをするために3つのビジネスマネージャーに、次々と、それぞれ独自の読み込み、アカウントピッカー、再確立すべきコンテキストとともにログインしなければなりませんでした。リーダーシップのデッキのために週次の数字を引き出すことは、12すべてを開き、それぞれからエクスポートし、スプレッドシートで支出を手作業で再組み立てすることを意味しました。完了した頃にはすでに古くなっていくスナップショットを生み出す午後の作業です。

より悪かったのは認知的な切り替えでした。1つのBMから次への移動はすべて、メンタルマップを再読み込みしました。どのアカウントがここに存在するか、この地域がどの命名規則を使うか、誰がアクセスを持つか、最後に何が変わったか、です。そのどれも単独では難しくありませんでした。12で、すべての運用者で、毎日で掛け合わされ、それはチームが常態化した着実な消耗でした。彼らはそれを半ば冗談で「BMホッピング」と呼び、自然の法則であるかのように一日に予算化しました。同じ摩擦は、チームがそれらを統一するレイヤーなしに複数のFacebook広告アカウントを管理しようとするときはいつでも現れます。仕事は良好で、切り替えが税です。

なぜこれが成長したり買収したりするすべてのブランドに起きるのか

ブランドは何も間違ったことをしませんでした。12のBMの問題は悪い運用者の症状ではありません。成長がMetaのモデルとどう相互作用するかの構造的な帰結です。新しい市場に拡大すると、別々のビジネスマネージャーが賢明に見えます。会社を買収すると、そのBMを丸ごと、ライブのアカウントもすべて継承し、痛みなくあなたのものに折り込む方法がありません。エージェンシーと働くと、それぞれが自身のコンテナを立ち上げるかもしれません。それらの決定の一つひとつが局所的に妥当であり、全体の結果が散在です。

それが罠です。エステートが「間違う」単一の瞬間がないので、それを修正する明白な瞬間がありません。ビジネスマネージャーは一度に1つの弁護できる決定で積み重なり、コストはあまりに徐々に上がるので誰もそれを通報しません。ブランドは、新しいオペレーションリードが、3週間入ってまだ聞いたことのないBMにログインしながら、明白な質問をしたときにだけ問題に直面しました。なぜ私たちは12の別々のログインを12の別々の仕事として扱っているのか、と。

単一のトークン：すべてのBMを一度に表示する自動検出

答えは、単一のビジネスマネージャーを移行、マージ、削除することを必要としないと判明しました。ブランドは運用を統一されたレイヤーに移し、エステート全体を1つの仕組み、つまり単一のSystem-Userトークンで接続しました。各運用者を12のBMの各々に招待する、彼らが常に使ってきた遅く、エラーを起こしやすく、アクセスを広げるアプローチではなく、チームは1つのSystem-Userトークンを追加し、business_idの自動検出が残りをしました。そのトークンが見られるすべてのビジネスマネージャーと広告アカウントを列挙し、それらすべてを一度に表示したのです。

1つのステップで、12の別々のログインが1つの接続になりました。ビジネスマネージャーはMeta側でまさにあった場所にとどまりました。何も移されず再構築されませんでした。しかしブランドはそれらを12の宛先として扱うのをやめました。これは、個別ログイン対マルチブランドの運用レイヤーについての記事で私たちが指す仕組みです。ログインの散在の修正は、より良いログイン管理ではなく、運用の経路からログインを完全に取り除くことです。

十数のBMを1つのワークスペースと1つのロールモデルに統一する

アカウントを表示することは勝利の半分でした。もう半分はガバナンスでした。すべてのBMのアカウントが1つのワークスペースに存在すると、チームは共有ログインと散らばったBM招待の古い寄せ集めを、単一のロールベースのモデルに置き換えました。各運用者はスコープされたロールを持つ名前付きシートを得て、それを通じて働きました。根底のビジネスマネージャーに決して直接触れることなく、です。ジュニアバイヤーは、それらのアカウントがどのBMに存在しても、それらのどれへのMetaアクセスも決して保持することなく、仕事が必要とするまさにそのアカウントと権限を与えられました。

それが2つの古い問題を一度に折りたたみました。アクセスの散在の問題、つまり個人的に保持すべきでないBMに招待され、後でそれを取り消すクリーンな方法のない人々が消えました。運用者がもはやBMレベルのアクセスを全く持たなかったからです。そして一貫性の問題も消えました。同期を保つ12の権限セットアップの代わりに、エステート全体を管理する1つのロールモデルがあり、12の即興のものではなく、12のビジネスマネージャーすべてに単一の首尾一貫したレイヤーとしてまたがりました。

初めて、それらすべてにわたって1画面でレポートする

リーダーシップが最初に気づいた変化は、トークンでもロールでもありませんでした。レポートでした。初めて、誰かが1画面を開き、エステート全体にわたる支出とパフォーマンス、つまり12すべてのビジネスマネージャーからのすべてのアカウントを、単一のビューで、何かに12回ログインしたりスプレッドシートを手作業で再構築したりせずに見られました。

かつて午後を消費した週次のデッキが一瞥になりました。3つのタブで3つのBMを開くことを意味したクロスマーケットの比較が、単一の並べ替えられたリストになりました。そしてビューがワークスペース全体にわたって一度に読んだので、事実上答えられなかった質問、つまりすべての地域と買収したブランドにわたる今週の総支出が、突然1画面の答えを持ちました。これは、広告アカウントレポートを統合するガイドで私たちが説明する結果です。価値はよりきれいなダッシュボードではなく、エステート全体の質問を尋ねるには高くつきすぎた手作業の継ぎ合わせの消失です。レポートはアカウントで実際に起きたことを反映し、MetaのAPIによって約15分の同期で最新に保たれ、それは週次のリーダーシップのビューにとって見えません。

BMの切り替え税を終わらせることがチームを解放してできるようにすること

統合のポイントは、決してそれ自体のための整頓ではありませんでした。チームが切り替え税として払ってきた時間を取り戻すことでした。BMホッピングが一日の一部であることをやめると、運用者はその取り戻した時間を、切り替えが押しのけていた仕事に費やしました。

かつて毎朝の最初の区間をビジネスマネージャーにわたって再方向づけして失っていたバイヤーが、すでにエステート全体を見ながら一日を始めました。オペレーションリードはついに、ブランドの広告を12ではなく1つの運用として見られ、それが命名を標準化し、一貫したガードレールを設定し、もう1つのサイロを立ち上げる代わりに新しい市場を既存のレイヤーにオンボーディングすることを可能にしました。新しい買収は吸収すべき問題であることをやめ、接続する単一のトークンになりました。チームは新しいツールを得たというより、永続的だと想定していた税を払うのをやめたのです。

教訓：BMはMetaの産物、あなたの運用レイヤーはそれを継承すべきでない

ブランドの12のビジネスマネージャーは決して消えず、消える必要も決してありませんでした。チームがこの取り組みから得た教訓はクリーンです。ビジネスマネージャーはMetaの組織的な産物であり、あなたの日々の運用レイヤーがその形を継承すべき理由はありません。MetaにはBMの境界の理由、つまり請求、所有権、地域構造がありますが、そのどれも、あなたの運用者があなたの広告を12の別々の仕事として体験することを義務づけません。

チームが2つを分けると、つまりMetaにそのコンテナを保たせ、実際の仕事をbusiness_idの自動検出を持つ1つのSystem-Userトークンで接続された単一のレイヤーに置くと、何年も彼らの運用を定義していた散在が単に重要でなくなりました。Wevionのプランは、永続的な無料ティア（€0）から始まり、次にStarterが月€99、Proが月€499、Plusが月€1,499（年払いで-20%）、そしてEnterpriseがカスタムプランで、すべての有料ティアには無料プランと共存する14日間のトライアルが含まれるので、チームはトークンを接続し、ビジネスマネージャーが自動検出されるのを見守り、コミットする前にエステート全体を1つのワークスペースで見られます。プレイブックの残りはエージェンシーツールクラスターにあります。

原則は、成長したり買ったりしてマルチBMのエステートに至るあらゆるブランドに一般化します。ビジネスマネージャーの数に、あなたが働く場所の数を決めさせてはいけません。それらを1つのトークンで接続し、1つのロールセットで管理し、1つのビューでレポートしましょう。そうすれば、誰も何かをマージ、移行、削除する必要なく、12が1つになります。