ソーシャルメディアマーケティングのためのアンチディテクトブラウザ:実践的なセットアップ
代理店のワークフローを最初から最後まで解説。クライアントごとのワークスペース、プロキシとタイムゾーンを揃えたアカウント単位のプロファイル、引き継ぎのためのロール、API自動化。
ソーシャルメディア代理店の運用上の問題は、コンテンツそのものであることはまれです。問題になるのは配管の部分です。複数のプラットフォームにまたがるクライアントアカウントの山、互いに邪魔をせずにそれらを扱わなければならないチーム、そしてすべてのセッションの環境を読み取るプラットフォーム。この記事では、PowerOpsを実例として、その配管を退屈なものに保つためのセットアップを、最初から最後まで紹介します。
構造:ワークスペース、グループ、プロファイル
プロファイルを1本の長いリストにしたくなる誘惑には抵抗してください。規模が大きくなっても運用を維持できるかどうかは構造で決まり、3つの階層があれば十分です。
- クライアントごとのワークスペース。クライアントのプロファイル、プロキシ、メモをひとまとめにし、別のクライアントで作業している間は、他のクライアントの情報が画面に出ないようにします。オフボーディングも、遺跡の発掘調査ではなく、1つのワークスペースに対する操作で済みます。
- ワークスペース内のプラットフォームごとのグループ。クライアントのFacebookのプロファイルを1つのグループに、Instagramを別のグループに、TikTokを3つ目のグループに入れます。一括操作はグループ単位で行われるため、この分け方によって、1つのプラットフォームのプロファイルをまとめて開始または停止できます。
- アカウントごとに1つのプロファイル。他のすべてを支えるルールです。プロファイルは、ちょうど1つのアカウントのストレージ、アイデンティティ、経路を保持し、その名前がどのアカウントかを示します。
命名ルールには30秒かける価値があります。クライアント、プラットフォーム、ハンドルの順です。プロファイルには番号が振られ、検索もできるので、騒がしい部屋で「41番を開いて」と言うだけで、同僚はどの行か正確に分かります。
構造は、監査に関する問いにも、誰かが尋ねる前に答えを出してくれます。クライアントが「いつ誰がアカウントに触れたか」を知りたがったとき、メンバーシップが明示され、プロファイルが一度に1人ずつ開かれるワークスペースなら、その答えは最初から組み込まれています。
プロファイルごとのアイデンティティと経路
各プロファイルには、一貫したセットとして生成され保存されたデバイスのアイデンティティが与えられるため、開くたびに同じ現実的なマシンを報告します。この部分は自動です。人間の判断が必要になるのは経路の部分です。
- クライアントのアカウントが運用されている国で、アカウントごとに1つずつ、スティッキーなアドレスを購入します。
- それらをプロキシライブラリに追加してテストします。テストでは観測されたアドレスと国が報告されます。請求書に何と書いてあっても、プラットフォームから見えるのはそちらです。
- 最初のログインの前に、それぞれのプロファイルに割り当て、同じ作業の中でプロファイルのタイムゾーンと言語も経路の国に合わせます。
- ライブラリを定期的に再テストします。エンドポイントは静かに劣化し、劣化した経路は、接続エラーとして現れるよりずっと前に、アカウントのトラブルとして現れます。
パスワードを共有しない引き継ぎ
代理店では、アカウントが人から人へ絶えず引き継がれます。インターンが投稿を予約し、マネージャーが承認し、誰かが週末をカバーします。従来のやり方はパスワードのスプレッドシートで、その結果、誰も見つけられないノートパソコンにクライアントのアカウントがログインしたまま残ってしまう、という事態になります。
ロールがそれに代わります。ワークスペースのメンバーには、仕事に必要なアクセスだけが与えられます。チームメイトはプロファイルを開いて中で作業し、マネージャーはさらにプロファイルと経路を編集でき、オーナーはさらにメンバーシップ自体を管理できます。アカウントの認証情報は一度だけプロファイルに保存され、新しいチームメンバーへの引き継ぎは、パスワードを送るのではなくアクセス権を付与することで行います。誰かが退職するときは、メンバーシップを取り消せばすべての場所でアクセスが一度に閉じられ、本人が一度も見ていないパスワードを変更し直す必要もありません。
引き継ぎを機能させる習慣は、プロファイルを閉じることです。プロファイルは一度に1台のマシンでしか開かれないので、同僚は現在誰が使っているかを確認でき、セッションの競合を痛い目に遭って初めて知ることがありません。作業を終えたらプロファイルを閉じれば、次の人は、セッションがきれいに書き出された状態でそれを開けます。
新規クライアントのオンボーディング、手順ごとに
オンボーディングは、構造が作られるか省略されるかの分かれ目なので、専用の手順を持つ価値があります。新規クライアントは、特別な奮闘なしに、半日のセットアップで済むべきです。
- どのアカウントにも触れる前に、ワークスペースとプラットフォームのグループを作成します。
- クライアントからアカウントの一覧を集めます。ハンドル、プラットフォーム、各アカウントが対象とする国、そして現在誰が認証情報を持っているか。
- アカウントごとに、適切な国のスティッキーな経路を1つ購入してテストし、実際に何が届いたかをライブラリのテストで確認します。
- プロファイルを作成してクライアント、プラットフォーム、ハンドルの順に名前を付け、同じ作業の中で経路、タイムゾーン、言語を割り当てます。
- 各アカウントに、そのプロファイル内であらためてログインします。2要素認証や確認メールのために、クライアントに待機してもらいます。
- チームにロールを付与し、クライアントの運用リズムをチームに共有したうえで、認証情報が届いた経路は廃棄します。
あらためてのログインは、アカウントが以前あった場所からCookieをインポートして、チームが省略しようとする手順です。やめておきましょう。インポートされたセッションは、元のマシンの履歴を引き継いでいます。オンボーディングの目的は、今後クライアントのアカウントが持つすべてのセッションが、それを使い続ける環境の中で確立されることにあるのです。
繰り返し作業の自動化
有用な線引きがあります。判断を要する作業は人が行い、巡回作業はスクリプトが行う、というものです。十数個の受信箱の未読数を確認する、金曜のレポートのためにフォロワー数を集める、朝のプロファイル群を開く、といった作業が巡回作業です。ローカルAPIはこれらを、環境の問題を誰かが解き直すことなく処理します。APIで起動したプロファイルは、人が行から開いたときと同じアイデンティティと経路を持つからです。
const { profiles } = await api(`/profiles?groupId=${clientInstagramGroup}`);
for (const profile of profiles) {
const { ws } = await api("/browser/start", { profileId: profile.id });
try {
const browser = await chromium.connectOverCDP(ws);
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();
// The profile's identity, storage and route are already attached.
await collectForReport(profile.name, page);
} finally {
await api("/browser/stop", { profileId: profile.id });
}
}実行は数件ずつ、間隔を空けて、アカウントの現地の勤務時間帯に行います。デスクに向かう人のように振る舞う自動化は、使い続けられます。プラットフォームを叩きまくる自動化は、同じ教訓に二度お金を払う方法です。
セットアップの中での1週間
この構造が何をもたらすかは、日々のルーティンに現れます。月曜の朝、チームはクライアントのInstagramグループを開き、プロファイルを1つずつ巡回して受信箱を処理します。金曜のレポートはAPIで自動的に作成され、チームは午後をもっと有意義なことに使えます。オフボーディングはワークスペースのアーカイブです。どれも気の利いたものではなく、それが狙いです。このセットアップの役目は、環境の問題を面白いものではなくすことなのです。
うまく機能しているかどうかは、2つの数字で分かります。1つ目は、プラットフォームのパスワードを誰かが入力する頻度で、オンボーディングが終われば限りなくゼロに近づくはずです。2つ目は、セッションが予期せぬ認証要求を出す頻度で、これはまれであり、原因をたどれるものであるべきです。経路の変更、異常な量の急増、育っていないアカウントを急がせすぎたこと、などです。どちらかが上昇したら、答えは経路とリズムにあり、最初に見るべきは最も最近変わったものです。
ルールははっきりと
このワークフローに登場するすべてのプラットフォームには、アカウントと自動化に関する規約があり、このセットアップはそのどれも変えません。分離は、クライアント同士が互いを汚染するのを防ぎます。ロールは、認証情報をスプレッドシートから遠ざけます。APIは、手間を取り除きます。しかしそのどれも、禁止されたアカウント、禁止された自動化、プラットフォームが禁じる行為を許可するものではなく、私たちが管理していないプラットフォームでの結果をここで約束するものでもありません。長続きする代理店は、プラットフォームのルールをクライアントワークの一部として扱い、ツールをその仕事をきれいに行うための手段として扱っています。
セットアップのチェックリスト
- クライアントごとにワークスペースを、その中にプラットフォームごとのグループを作成する。
- アカウントごとに、そのアカウントの運用国で1つのスティッキーなアドレスを購入し、プロキシライブラリのすべてのエンドポイントをテストする。
- アカウントごとに1つのプロファイルを作成し、クライアント、プラットフォーム、ハンドルの順に名前を付け、最初のログインの前に経路を割り当てる。
- 各プロファイルのタイムゾーンと言語を、その経路の国に合わせる。
- パスワードを送る代わりに、各チームメンバーにロールを付与する。
- 巡回作業はローカルAPIで自動化し、人のペースに合わせる。
- 毎回の作業の終わりにプロファイルを閉じる。
