ホワイトラベルのデータ収集とは、クライアントがあなたのブランドで、あなたの条件で、インボイスにあなたの名前が入った状態でデータを受け取ることを意味する。クライアントは背後のインフラとは契約せず、それを目にすることもなく、多くの場合それを知りたいとも思わない。
この取り決めは商業的には単純だが、ほとんどの代理店が想定する以上にあなたの責任範囲を変える。データセットにあなたのブランドを付けた瞬間、あなたはプロキシネットワークを利用する会社であることをやめ、記録上のデータ提供者になる。信頼性、来歴、コンプライアンス、継続性のすべてに、あなたが答える責任を負うことになる。
このガイドでは、それが実務上何を意味するか、そして1つのアカウントで複数のクライアントを、互いに干渉させることなく扱えるよう構成する方法を扱う。
1つのアカウントとは1つのログインであって、共有予算のことではない
すぐに片付けておく価値がある。この言葉は曖昧であり、誤った解釈は実害をもたらすからだ。
うまくいくのは、代理店用にShifterアカウントを1つ持ち、ログインは1つ、ベンダーとの関係も1つ、すべてを見渡せる場所も1つにした上で、その下で各クライアントを、それぞれ専用のプランとワークスペースによって、あるいは共有プラン上の専用サブアカウントによって分離する形だ。
うまくいかないのは、すべてのクライアントの収集作業が、クライアント同士を区別する手段を何も持たない単一の共有プランを通して動くことだ。このやり方では、各クライアントのコストが何であったかが分からず、あるクライアントの急増が気づかれないまま別のクライアントの割り当てを消費してしまい、オフボーディングは手作業による切り分け作業になる。
最初の構成の仕組み、ワークスペース、ロール、サブアカウント、プランごとの使用量については、複数クライアント向けのサブアカウントと使用量トラッキングで扱っている。要点を言えば、予算を分離する必要があるクライアントにはクライアントごとのプランを、プランを共有するクライアントにはクライアントごとのサブアカウントを、請求やクライアントアクセスが正当化する場合にはクライアントごとのワークスペースを用意する、ということだ。
完成データの販売 vs プロキシアクセスの再販
ホワイトラベルと呼ばれるビジネスは2種類あり、それぞれ負う責任が異なる。
完成データの販売。 クライアントはレポート、フィード、あるいはダッシュボードを購入する。プロキシネットワークは、あなたのサーバーと同様に、あなたの制作プロセスの一部である。このガイドの内容はすべてこのモデルについてのものだ。
自社ブランドでのプロキシアクセスの再販。 クライアントは自分自身のトラフィックを送る能力を購入し、あなたはクライアントから見えるプロバイダーとなる。この場合、顧客ごとの使用量データ、あなた自身の制限と請求、そしてあなたの顧客が同意する明確な利用規約が必要になる。Shifterのリセラープログラムはこのために作られている。サブアカウントがパネルおよびAPI上で各顧客のトラフィックを追跡し、価格、制限、請求は自分のプラットフォーム上で設定できる。
多くの代理店は最初のモデルから始め、クライアントが自分自身でジョブを実行したいと言い出したときに2つ目を追加する。責任範囲が異なるため、アカウントと契約の両方でこの2つを明確に分けておくこと。
あなたのブランドがデータに付くとき、あなたが引き受けるもの
5つの事項があなた側の責任に移る。
信頼性。 クライアントのレポートは、ポータルが昨夜マークアップを変更したかどうかに関わらず、期日通りに届く必要がある。監視、アラート、フォールバックプランが必要だ。「サプライヤーに問題があった」は、ホワイトラベルのプロバイダーが使える言い訳ではないからだ。
来歴。 クライアントがある数値に異議を唱えたとき、それがどこで、いつ観測されたかを答えられなければならない。つまり、すべての成果物に市場、観測地点、タイムスタンプ、収集方法が付随する必要がある。これを第一級のフィールドとして扱うべき理由は、観測地点の標準に書かれている。
コンプライアンス。 クライアントの義務は、あなたのブランドの手前で止まるわけではない。クライアントがデータ管理者であり、あなたがその代わりに処理を行っている場合、その責任はあなたに流れてくる。
継続性。 あなたがソース、市場、契約を失った場合、クライアントはそれを自分たちへの障害として経験する。
サポート。 あなたは最前線である。クライアントは、なぜ数値が動いたのかをあなたに尋ねる。その答えが転送されたチケットであってはならない。
これらはどれもホワイトラベルを行うべきでない理由ではない。これらは、それを適切に価格付けすべき理由であり、それについては以下で扱う。
すべての成果物が持つべき来歴フィールド
防御可能な成果物には、各値の隣にいくつかのフィールドが付随する。価格監視フィードからの1行の例を示す。
| フィールド | 例 |
|---|---|
| 値 | 49.99 |
| 通貨 | EUR |
| ソースURL | retailer.example/product/123 |
| 市場 | ドイツ |
| 観測地点 | レジデンシャル出口、ベルリン、コンシューマーISP |
| 観測日時 | 2026-10-21 09:14 UTC |
| 収集方法 | HTTPリクエスト、スティッキーセッション、商品ページからパース |
| クライアント | acme |
あなたのブランドは表紙に付くが、これらのフィールドはその下に付く。同じカテゴリーの2つのクライアントがなぜ数値が異なるのかと尋ねたとき、たいていの場合、観測地点とタイムスタンプが答えになる。
コンプライアンスはあなたのブランドの陰に消えない
ここは最も見落とされやすい部分であり、あなた自身の計画の中よりも、クライアントの調達審査の中で表面化する可能性が最も高い部分でもある。
クライアントがデータ管理者であり、あなたが処理者である場合、データ処理契約(DPA)では通常、再委託先の開示と、それを変更する前の通知が義務付けられている。データ収集のために依存しているインフラは、その定義に該当し得る。ホワイトラベルのブランディングは商業的な取り決めであって、法的な盾ではない。それはあなたの契約が生み出す開示義務を取り除くものではない。
実務上の帰結は2つある。クライアントとのDPAに署名する前に、再委託先、通知期間、監査権について何が書かれているかを確認すること。これらの条項は、あなた自身のスタックをどれだけ自由に変更できるかを左右する。そして、自分の収集が何に依存しているかの最新の社内記録を保持すること。そうすれば、クライアントから尋ねられたとき、回答は1週間ではなく数分で済む。大規模なクライアントはベンダー質問票も送ってくる。想定される質問と、用意しておくべき回答については、InfoSecチームがプロキシベンダーに送るセキュリティ質問票にまとめている。
関連していて、しばしば混同される点がある。リクエストがどこから出ているかは、データがどこで処理・保存されているかとは別の話だということだ。「私たちのデータはEU内にあるか」と尋ねるクライアントは、あなたのパイプラインについて尋ねているのであって、出口の所在地について尋ねているのではない。この区別はデータレジデンシーはプロキシの所在地ではないで説明されている。電話がかかってくる最中ではなく、クライアントに尋ねられる前に理解しておく価値がある。
代理店アカウントの構成方法
運用上のセットアップは短く、それを正確に守ることが、その後のすべてを容易にする。
- すべてのクライアントに、専用プランか専用サブアカウントを与える。 別個のプランは予算を分離する。サブアカウントはプロキシのユーザー名内のラベルであり、1つのプランのトラフィックをクライアントごとに分割して、パネルおよびAPI上で別々に報告するが、そのプランの帯域幅を共有し、それ自体の制限は設定しない。どちらか一方を持たずにクライアントのジョブを実行してはならない。
- それに値するクライアントには、クライアントごとのワークスペースを追加する。 独自の請求関係を望むクライアント、自分の使用量を可視化したいクライアント、あるいは超過分が共有ウォレットに影響すべきでないほど大きなクライアントが対象だ。ワークスペース内の全員がその中のすべてを見られるので、クライアントの担当者は常に自分専用のワークスペースにのみ所属させること。
- クライアントごとに認証情報を分ける。 シークレットマネージャーにクライアントごとに保存し、各クライアントのジョブにはそのクライアントのプランまたはサブアカウントのみを使わせ、あるクライアントの認証情報を別のクライアントのジョブを急いで完了させるために借用しないこと。この一つの近道こそが、帰属関係が静かに崩れる原因となる。
- セッションIDにクライアント名の接頭辞を付ける。
sid-acme-listings-04はコストがかからず、自分自身のデバッグを読みやすくする。 - 成果物ごとに観測地点を記録する。 上記のフィールドを使う。
Shifterのゲートウェイでは、クライアント、市場、セッションはすべて p.shifter.io:443 に対する認証情報の中にある。
customer-USERNAME-subaccount-acme-country-de-city-berlin-sid-acme-de-07-ttl-600:PASSWORD独立したリクエストには sid を省略すれば、ゲートウェイがリクエストごとにローテーションする。複数ステップのジョブで1つの出口を維持するには sid を含め、ttl でその保持時間を設定する。このトレードオフはスティッキー vs ローテーティングのレジデンシャルプロキシにまとめている。
ギガバイトではなく成果物に価格を付ける
最も多いホワイトラベルの価格設定ミスは、帯域幅を購入していないクライアントに対して、帯域幅をコストにマージンを乗せて再販することだ。あなたのクライアントが購入しているのは、レポート、フィード、あるいはダッシュボードである。彼らにはギガバイト単価を評価する手段がなく、それを学ぶ関心もない。
成果物ごとに価格を付け、実際にコストを左右する指標、すなわち使用可能なレコード1件あたりのギガバイト数で、自分自身のマージンを管理すること。転送量は少ないがブロックされたデータや地理的に誤ったデータを返すワークフローは、転送量が多くても正しく動作するワークフローよりも、配信レコード1件あたりのコストが高くなる。
マージンを守るための3つの習慣がある。請求時ではなく週次でクライアントごとの消費量を確認すること。スコープの変更はスコープの変更として扱うこと。クライアントはメール1本で市場や頻度を追加しがちで、価格の相談が必要だとは思っていないからだ。そして、超過分を流すべきか、ジョブを一時停止すべきかを、クライアントごとに事前に決めておくこと。
継続性とオフボーディング
どちらも必要になる前に計画しておくこと。
継続性については、クライアントごと、ソースごとに収集の成功率を監視し、劣化しているソースがクライアントに気づかれる前に見えるようにする。どの成果物が単一のソースに依存しているかを把握しておくこと。それらが最も壊れやすいものだからだ。
オフボーディングは調査ではなく、チェックリストであるべきだ。
- そのクライアントの認証情報とサブアカウントラベルを、すべてのジョブから取り除く。
- そのクライアントのプランを解約または移管する。
- ワークスペースからそのクライアントの人員を削除するか、彼らがオーナーである場合はそのワークスペースから離れる。
- 契約に従って、過去のデータを引き渡すか削除する。
クライアントが自分のワークスペースを所有している場合、このほとんどは彼ら自身の行動となる。これは、大規模なアカウントほどこの構造を採用すべきだという、さらなる論拠になる。
よくある質問
クライアントが小規模であれば、複数のクライアントを1つのプランで扱えるか。
各クライアントが自分専用のサブアカウントを持っているなら可能だ。その場合、パネルとAPIは各クライアントのトラフィックを別々に報告する。共有プランにできないのは、あるクライアントの使用量に上限を設けることであり、そのため1つのクライアントの急増は、他のクライアントが共有する帯域幅から引き続き消費される。大量または予測不能な量を持つクライアントには、専用プランを与えること。
どのインフラを使っているかをクライアントに伝える必要があるか。
それはブランディングではなく契約次第だ。多くのクライアントDPAは再委託先の開示と変更時の通知を義務付けている。署名した契約を確認すること。
1つの代理店アカウントで何人のクライアントを扱えるか。
1つのログインは、サイドバーから切り替えて多数のワークスペースに属することができる。シート数の上限はワークスペースごとに適用され、あなたが横断して作業するワークスペースの数には適用されない。
ホワイトラベルの成果物には何を含めるべきか。
データに加え、それを防御するのに十分な来歴情報、すなわち市場、観測地点、観測タイムスタンプ、収集方法。あなたのブランドは表紙に付く。その方法論は、やはりその下に存在していなければならない。
ホワイトラベルデータとプロキシの再販の違いは何か。
ホワイトラベルデータとは、あなたが自分のブランドで完成データを販売し、ネットワークがあなたの制作プロセスの一部であり続けることを意味する。再販とは、あなたの顧客があなたが提供するアクセスを通して自分自身のトラフィックを送ることを意味し、そのため顧客ごとの使用量トラッキング、あなた自身の制限と請求、利用規約が必要になる。
クライアントは私がShifterを使っていることを知ることができるか。
あなたの成果物を通しては分からない。クライアントは、あなたがワークスペースに招待した場合、あるいは認証情報を渡した場合にのみShifterを目にする。だからこそ、クライアントの担当者は常に自分専用のワークスペースにのみ参加させるべきなのだ。
各クライアントへの収集作業の請求はどうすればよいか。
各クライアントのプラン、あるいは共有プラン上の各クライアントのサブアカウントを使用量の指標として使い、その上に成果物の価格を乗せる。インボイスに驚きがないよう、クライアントごとの使用量を週次で確認すること。
クライアントが離脱した場合、そのデータはどうなるか。
契約書に書かれている通りになる。署名の時点で合意しておくこと。引き渡すか、一定期間保持するか、削除するか。その上で、上記のオフボーディングチェックリストに従うこと。
結論
ホワイトラベル化とは、そのデータを自分が責任を持って守るという約束である。その約束を守るコストが低くなるよう、アカウントを構成すること。多数のワークスペースにまたがる1つの代理店ログイン、すべてのクライアントに対するプランまたはサブアカウント、クライアントごとに分離された認証情報とセッション識別子、そしてすべての成果物に付随する来歴情報だ。
そのうえで、ギガバイトではなく成果物に価格を付け、クライアントごとの使用量を週次で監視し、自分のスタックを変更した後ではなく前に、クライアントのDPAを読むこと。ネットワークそのものについてはレジデンシャルプロキシネットワークのページにある。