ほとんどの代理店は、プロキシの構成を偶然の積み重ねで手に入れている。SEOチームは順位計測用に何かを購入した。有料広告チームは広告チェック用に別の何かを見つけた。あるストラテジストは、提案資料のために競合価格を取得する3つ目のツールに登録した。3つのベンダー、3つのインテグレーション、3種類の地域コード、3通りの請求書、そしてクライアントからの単純な質問に答える術がない。SEOレポートと広告レポートが両方とも「マドリード」と言うとき、それらは同じものを指しているのか、という質問だ。
これが1つのネットワークに統合すべき理由だ。多くの場合実際に安くなるからではなく、3つのワークロードが同じ根本的な問いを尋ねているからだ。この市場の実際のユーザーには何が見えているのか、その答えは同じであるべきだ。
3つのワークロード、3種類のトラフィックの形
これらのワークロードは、ローカルな視点を必要とする点では共通しているが、それ以外のほぼすべての点で異なる。この違いを理解することが、1つのネットワークで3つすべてを機能させる鍵になる。
SEOモニタリングは高ボリュームで軽量だ。多数の独立したクエリがあり、それぞれが小さく、それぞれが正確な位置情報とデバイスプロファイルを必要とし、それぞれが前のものから独立している。すべてのリクエストでのローテーションと、都市レベルのターゲティングを求める。なぜならローカル検索結果は国単位よりも細かい粒度で変化するからだ。その仕組みはローカルSEOのための地域ターゲティングSERP APIにある。
広告検証は低ボリュームで重量級だ。チェックの回数は少ないが、それぞれがインプレッションからランディングページまでの複数ステップの道のりであり、多くの場合ブラウザでレンダリングされ、それぞれが最初から最後まで一貫したロケール情報を必要とする。スティッキーセッションと、一貫したデバイス・言語設定を求める。プログラムの設計は広告掲載を大規模に検証するにある。
競合インテリジェンスはその中間に位置する。カテゴリーの巡回、ページ分割された結果セット、ランディングページやオファーがあり、それぞれが一連のリクエストを通じた内部的な一貫性を必要とする。巡回ごとのスティッキーセッションと、控えめで安定したペースを求める。詳細は競合キャンペーンインテリジェンスでカバーされている。
| ワークロード | セッションパターン | チェックごとの重さ | 重要なターゲティング |
|---|---|---|---|
| SEOモニタリング | リクエストごとにローテーション | 軽量 | 都市とデバイス |
| 広告検証 | 一連の流れごとにスティッキー | 重量級、多くはレンダリングあり | 国、都市、ロケールの一貫性 |
| 競合インテリジェンス | 巡回ごとにスティッキー | 中程度 | 国、場合によっては都市 |
なぜ1つのネットワークが3つより優れているのか
1つのターゲティングモデル。 3つのワークロードすべてが位置情報を同じ方法で表現すれば、マドリードのクライアントに関する発見は、SEOレポート、広告レポート、競合分析資料のすべてで同じ意味を持つ。3つのベンダーを使っていると、一致しないかもしれない3通りの「マドリード」の定義を照合することになり、それに気づいたクライアントはなぜかと尋ねてくるだろう。
維持すべきインテグレーションが1つ。 ベンダーごとに、認証形式、エラー用語、ターゲティングコードの体系、サポート窓口との関係が異なる。統合することで、誰も請求しない余計な作業がなくなる。
比較可能な観測地点。 SEOチームがあるローカル競合の台頭を目にし、有料広告チームが同じ競合が同じ都市でより積極的に入札しているのを目にするとき、この2つの観測は比較可能な出口から得られたものであり、議論の的にするのではなく並べて検討できる。
支出を理解するための1つの場所。 レジデンシャルの帯域幅がコストの主要因であり、3つのワークロードすべてが同じダッシュボードで同じ単位で測定されていれば、予測ははるかに容易になる。その方法はレジデンシャルプロキシの帯域幅予測にある。
Shifterのゲートウェイを使うと、3つのワークロードすべてが同じエンドポイント p.shifter.io:443 を使用し、その違いは完全に認証情報の中で表現される。
# SEO: リクエストごとにローテーション、都市レベル
customer-USERNAME-country-es-city-madrid:PASSWORD
# 広告検証: 一連の流れ全体で1つの出口
customer-USERNAME-country-es-city-madrid-sid-adv-221-ttl-600:PASSWORD
# 競合インテリジェンス: カテゴリー巡回ごとに1つの出口
customer-USERNAME-country-es-sid-ci-walk-09-ttl-600:PASSWORD
# 上記のいずれも、共有プラン上で1つのクライアントとしてカウント
customer-USERNAME-subaccount-acme-country-es-city-madrid:PASSWORDsid を省略するとリクエストごとのローテーションになる。追加すると1つの出口が維持され、ttl がその持続時間を設定する。この1つの違いこそが、1つのネットワークで設定を3つに分けることなく3種類のトラフィックに対応できる理由だ。subaccount ラベルはユーザー名のすぐ後に続き、そのトラフィックがどのクライアントに属するかをパネルに伝える。
SEOワークロードについては特に、リクエストを自分で管理する代わりにSERP APIを検討する価値がある。位置情報とデバイスの処理が済んだ構造化された結果を返してくれるからだ。
クライアントは分けておく
ワークロードを統合するのは正しい。クライアントを1つの未分化なプールに統合するのは正しくない。理由は3つある。
コストの帰属。 クライアントは作業に対して請求される。すべてのクライアントの収集作業が、クライアントを区別する手段のない1つのプランを通じて行われると、各クライアントにかかったコストを言うことができず、クライアントごとの利益率は推測になってしまう。クライアントごとのサブアカウントを使えば、共有プラン上でもこれを解決できる。パネルとAPIが各クライアントのトラフィックを別々に報告する。
予算の封じ込め。 あるクライアントのキャンペーンの急増が、別のクライアントのレポート作成が依存する割り当てを消費してしまうべきではない。サブアカウントはトラフィックを追跡するが上限は設けないため、ボリュームが大きい、あるいは予測不能なクライアントには専用のプランを用意すべきだ。
きれいなオフボーディング。 クライアントが離れるとき、そのアクセス権、プラン、履歴も、他の誰にも影響を与えることなく一緒に消えるべきだ。
Shifterでは、各クライアントは専用のプランを持つことも、共有プラン上の専用サブアカウントを持つこともできる。クライアントが独自の請求を必要とする場合、あるいは自分の使用状況を確認したい場合には、独自のプラン、ウォレット、請求書を備えた独自のワークスペースを持つこともでき、代理店のアカウント担当者は1つのログインとサイドバーの切り替えでメンバーとして参加する。プランがワークスペースをまたぐことは決してない。この設定手順は複数クライアントのためのサブアカウントと使用状況追跡で説明されている。
すべてのクライアント向け成果物に観測地点を記録する
1つのネットワークという実用上の利点は、レポートがそれを示して初めて実現する。クライアント資料に届くすべての観測結果は、市場、該当する場合は都市、デバイスプロファイル、タイムスタンプを伴うべきだ。そうすれば、3つの分野を1つの会話の中で相互参照でき、異論のある数字も、それがどこで観測されたか正確に遡ることができる。
これはまた、データを報告するだけの代理店と、それを裏付けられる代理店を分けるものでもある。「それはどこで確認したのか」と尋ねられたクライアントは、数秒で答えを得られるべきだ。
よくある質問
あるクライアントの大量クロールが別のクライアントの結果に影響することはあるか?
出口は1つのクライアントに割り当てられるのではなく、プール全体でローテーションするため、あるクライアントが使い尽くせる固定のアドレス群は存在しない。共有されているのは振る舞いだ。あるアドレスがターゲットに対して過度に酷使されると、次にそれを引き当てた人にとって状況が悪くなるため、すべてのクライアントのリクエスト頻度を通常の範囲に保つこと。もう1つの共有リソースは予算であり、だからこそ各クライアントには専用のプランを用意すべきだ。
1つのネットワークですべての市場のすべてのクライアントに対応できるか?
ほとんどの代理店にとっては可能だ。ただし、クライアントが活動する国や都市を、SEO業務に必要な粒度でカバーしている場合に限る。統合する前に、主要市場における都市レベルのカバレッジを確認すること。
SEOチームはプロキシを使うべきか、SERP APIを使うべきか?
構造化された結果が欲しく、リクエスト管理をしたくないならSERP API。APIがカバーしないページを観測する必要がある、あるいは完全な制御が欲しいならプロキシ。多くの代理店は両方を使っている。
収集作業についてクライアントにどう請求すればよいか?
各クライアントに専用のプラン、あるいは共有プラン上の専用サブアカウントを与え、その使用状況から請求する。パネルとAPIはプランごと、サブアカウントごとの使用状況を報告するため、クライアント単位での帰属をきれいに行える。
結論
代理店はセッションパターン、重さ、ターゲティングが異なる3つの収集ワークロードを運用しているが、共通して1つの問いを抱えている。この市場の実際のユーザーには何が見えているのか、という問いだ。これに1つのネットワークと1つのターゲティングモデルで答えることで、3つの分野を比較可能にし、2つのインテグレーションを取り除き、支出を1つの単位にまとめることができる。
統合すべきはワークロードであって、クライアントではない。各クライアントを専用のプランまたはサブアカウントに保ち、請求が必要な場合は専用のワークスペースに保ち、すべての成果物に観測地点を記録し、ベンダーではなく認証情報にSEOチェックと広告の一連の流れの違いを表現させること。製品そのものはレジデンシャルプロキシページに、料金は価格ページにある。