ホワイトラベルでのデータ収集とは、クライアントがデータを自社ブランドで、自社の条件で、請求書にも自社名で受け取ることを意味する。クライアントは背後のインフラと契約するわけではなく、それを目にすることもなく、多くの場合それを望んでもいない。
この取り決めは商取引としては単純だが、多くの代理店が想定する以上にあなたの責任範囲を変える。データセットに自社ブランドを載せた瞬間、あなたはレジデンシャルプロキシネットワークを利用する会社ではなく、正式なデータ提供者になる。信頼性、来歴、コンプライアンス、継続性のすべてについて、あなたが説明責任を負うことになる。
このガイドでは、それが実務上何を意味するか、そして一つのアカウントで複数のクライアントを、互いに干渉させることなく運用する構造をどう組むかを扱う。
「一つのアカウント」とは一つのログインを意味し、一つの器を意味しない
これはすぐに確定させておく価値がある。この言葉は曖昧であり、誤った解釈は実害を招くからだ。
うまくいくのは、代理店用に一つのShifterアカウントを持ち、一つのログイン、一つのベンダー関係、すべてを見渡せる一つの場所を用意した上で、その下で各クライアントを個別のワークスペースと個別のプランに分離することだ。
うまくいかないのは、すべてのクライアントの収集作業が一つの共有プランを通して行われることだ。そのやり方では各クライアントにかかったコストが分からず、あるクライアントの急増が別のクライアントの割当を消費してしまい、オフボーディングも手作業での切り分け作業になってしまう。
前者の仕組み、すなわちワークスペース、権限ロール、サイドバーの切り替え、プランごとの使用量については、複数クライアント向けのサブアカウントと使用量トラッキングで扱っている。要点を言えば、クライアントごとに常に一つのプランを用意し、請求やクライアントアクセスがそれを正当化する場合には、クライアントごとにワークスペースを設けるということだ。
自社ブランドをデータに載せるときに引き受けること
五つのことが、あなたの側の責任範囲に移る。
信頼性。 クライアントのレポートは、あるポータルが前夜にマークアップを変更したかどうかに関わらず、期日通りに提出されなければならない。監視、アラート、フォールバック計画が必要だ。なぜなら「サプライヤー側で問題があった」は、ホワイトラベル提供者が使ってよい言い訳ではないからだ。
来歴。 クライアントが数値に異議を唱えたとき、それがどこで、いつ観測されたものかを説明できなければならない。つまり、すべての成果物には市場、観測地点、タイムスタンプ、収集方法が付随している必要がある。これを第一級のフィールドとして扱うべき理由については、観測地点の標準で述べている。
コンプライアンス。 クライアントの義務は、あなたのブランドのところで止まらない。クライアントがデータ管理者であり、あなたがその代理として処理を行っているのであれば、その責任はあなたに流れ込んでくる。
継続性。 ソース、市場、契約のいずれかを失った場合、クライアントはそれをあなたのサービス障害として経験する。
サポート。 あなたが最前線だ。クライアントが「なぜこの数値が動いたのか」と尋ねてきたとき、その答えが転送されたチケットであってはならない。
これらはどれも、ホワイトラベル化をやめる理由にはならない。むしろ、それを適切に値付けする理由となる。それについては最後のセクションで扱う。
コンプライアンスはブランドの背後に消えるわけではない
これは最も見落とされがちな部分であり、自社の計画段階よりもクライアントの調達審査で表面化する可能性が高い部分でもある。
クライアントが管理者であり、あなたが処理者である場合、データ処理契約(DPA)は通常、再委託先(サブプロセッサ)の開示と、変更前の通知を求める。データ収集のために依存しているインフラは、その定義に該当しうる。ホワイトラベル化はあくまで商取引上の取り決めであり、法的な盾ではない。契約が生じさせる開示義務を取り除くものではない。
実務上の帰結は二つある。クライアントとのDPAに署名する前に、サブプロセッサ、通知期間、監査権について何が書かれているかを確認すること。これらの条項が、あなたが自社のスタックをどれだけ自由に変更できるかを左右するからだ。そして、自社の収集作業が何に依存しているかについて、最新の内部記録を保持すること。そうすれば、クライアントから問われたときに、答えが1週間ではなく数分で出せる。
これに関連し、しばしば混同されるものがある。リクエストがどこから出ていくかは、データがどこで処理・保存されるかとは別だという点だ。「私たちのデータはEU内にありますか」と尋ねるクライアントは、あなたの出口地点についてではなく、パイプラインについて尋ねている。この区別についてはデータレジデンシーはプロキシの所在地ではないで説明している。電話で聞かれる前に理解しておく価値がある。
アカウントの構造化
運用上の設定は短く、それを正確に守ることが、その後のすべてを容易にする。
クライアントごとに一つのプラン。 例外はない。使用量はプラン単位で報告されるため、共有プランは後から絶対に帰属を追えないコストになる。
それに見合うクライアントにはワークスペースを設ける。 独自の請求関係を望むクライアント、自分たちの使用量を可視化したいクライアント、あるいは超過分が共有の資金を消費すべきでないほど大きなクライアントだ。ワークスペース内の全員は、その中のすべてを見られることを忘れないように。したがってクライアントの担当者は、常に自分たちのワークスペースにのみ所属すべきだ。
認証情報はクライアントごとに分離する。 各プランには独自の認証情報がある。クライアントごとにシークレットマネージャーに保管し、各クライアントのジョブにはそのクライアントの認証情報のみを使わせ、あるクライアントのプランを別のジョブを素早く済ませるために借用することは絶対にしない。この一つの近道こそが、帰属を静かに壊す原因となる。
セッションIDにクライアント接頭辞を付ける。 パネルはセッション識別子ごとに使用量を分解して表示しないが、自社のログではそれができる。sid-acme-listings-04にはコストがかからず、自社のデバッグを読みやすくする。
観測地点を成果物ごとに記録する。 単に異議申し立てのためだけではない。同じカテゴリの二社のクライアントがなぜ数値が異なるのかと尋ねてきたとき、たいてい答えは観測地点にある。
Shifterのゲートウェイでは、クライアント接頭辞と市場の両方がp.shifter.io:443に対する認証情報の中に存在する。
customer-USERNAME-country-de-city-berlin-sid-acme-de-07-ttl-600:PASSWORD独立したリクエストではsidを省略すればゲートウェイはリクエストごとにローテーションする。複数ステップのジョブで一つの出口を保持したい場合はsidを含め、ttlで保持時間を設定する。このトレードオフについてはスティッキー対ローテーティングのレジデンシャルプロキシで、リクエストのペース配分についてはレート制限とリクエストスロットリングで述べている。
ギガバイトではなく成果物に値付けする
最もよくあるホワイトラベルの価格設定の誤りは、帯域幅をコストにマージンを乗せて再販することだ。しかしクライアントは帯域幅を買っているわけではない。クライアントが買っているのはレポートであり、フィードであり、ダッシュボードだ。彼らにはギガバイト単価を評価する方法がなく、それを学ぶ関心もない。
成果物ごとに値付けし、実際にコストを左右する指標、すなわち使用可能なレコード1件あたりのギガバイト数で、自社のマージンを管理すること。転送量は少なくても、ブロックされたり地理的に誤ったデータを返すワークフローは、動作はするがより重いワークフローよりも、配信済みレコード1件あたりでは高コストになる。予測の手法についてはレジデンシャルプロキシ帯域幅の予測で述べている。
マージンを守る習慣は三つある。請求時ではなく毎週、クライアントごとの消費量を確認すること。スコープの変更はスコープの変更として扱うこと。クライアントは価格の話し合いを期待せずに、メールで市場や頻度を追加することがよくあるからだ。そして、超過分を流すべきか、ジョブを一時停止すべきかを、クライアントごとに事前に決めておくこと。
継続性とオフボーディング
両方とも、必要になる前に計画しておくこと。
継続性のためには、クライアントごと、ソースごとに収集の成功率を監視し、劣化しているソースをクライアントが気づく前に可視化する。どの成果物が単一のソースに依存しているかを把握しておくこと。それらが最も深刻に壊れる箇所だからだ。
オフボーディングのためには、クライアントの解約が調査ではなくチェックリストになるようにする。すべてのジョブからそのクライアントの認証情報を退役させ、そのプランを終了または移管し、ワークスペースからその人員を削除し、過去データをどう扱うかを契約で合意しておくこと。クライアントが自分のワークスペースを所有している場合、これは大部分がクライアント側の作業になる。これは、より大規模なアカウントにおいてその構造を採用するさらなる論拠となる。
よくある質問
クライアントが小規模なら、複数のクライアントを一つのプランで運用してもよいか。
できるが、その場合、誰にどれだけコストがかかったかを説明できず、急増を封じ込めることもできなくなる。実際に量がごく小さいのであれば、節約分は小さく、帰属の喪失は恒久的だ。
どのインフラを使っているか、クライアントに伝える必要があるか。
それはブランディングではなく契約次第だ。多くのクライアントのDPAは、再委託先の開示と変更の通知を求めている。署名済みの契約を確認すること。
一つの代理店アカウントで何社のクライアントを扱えるか。
一つのログインは多くのワークスペースに属することができ、サイドバーから切り替えられる。席数の上限はワークスペースごとに適用されるのであって、扱っているワークスペースの数に対してではない。
ホワイトラベルの成果物には何を含めるべきか。
データに加えて、それを裏付けるのに十分な来歴、すなわち市場、観測地点、観測タイムスタンプ、方法だ。表紙にはあなたのブランドが載る。その方法は、その下に依然として存在していなければならない。
結論
ホワイトラベル化とは、そのデータを自分が保証できるという約束だ。その約束を守るコストが低くなるようアカウントを構造化すること。すなわち、多くのワークスペースにまたがる一つの代理店ログイン、例外なくクライアントごとに一つのプラン、クライアントごとに分離された認証情報とセッション識別子、そしてすべての成果物に付随する来歴だ。
そして、ギガバイトではなく成果物に値付けし、クライアントごとの使用量を毎週確認し、自社のスタックを変更する前に、後ではなく、クライアントとのDPAを読むこと。ネットワーク自体についてはレジデンシャルプロキシネットワークページを、料金については料金ページを参照のこと。