화이트라벨 데이터 수집은 클라이언트가 당신의 브랜드로, 당신의 조건으로, 당신의 이름이 적힌 인보이스로 데이터를 받는다는 것을 의미합니다. 그들은 그 아래에 있는 인프라와 계약하지 않고, 그것을 보지 않으며, 대부분의 경우 보고 싶어 하지도 않습니다.
이 구조는 상업적으로는 단순하지만, 대부분의 에이전시가 예상하는 것보다 더 많이 당신의 의무를 변화시킵니다. 데이터셋에 자신의 브랜드를 올리는 순간, 당신은 프록시 네트워크를 사용하는 회사에서 공식적인 데이터 제공자로 바뀝니다. 신뢰성, 출처, 컴플라이언스, 연속성 모두 당신이 책임져야 할 몫이 됩니다.
이 가이드는 그것이 실제로 무엇을 의미하는지, 그리고 클라이언트들이 서로 접촉하지 않으면서도 하나의 계정으로 여러 클라이언트를 감당할 수 있도록 구조화하는 방법을 다룹니다.
하나의 계정은 하나의 로그인을 의미하며, 하나의 공유 예산을 의미하지 않습니다
이 부분은 즉시 정리할 가치가 있습니다. 왜냐하면 이 문구는 모호하고, 잘못 해석하면 실제로 피해가 발생하기 때문입니다.
효과적인 방식: 에이전시용 Shifter 계정 하나, 로그인 하나, 하나의 벤더 관계, 모든 것을 볼 수 있는 하나의 공간, 그리고 그 아래에서 각 클라이언트가 자체 플랜과 워크스페이스로, 또는 공유 플랜 내 자체 서브계정으로 분리되는 방식입니다.
효과적이지 않은 방식: 모든 클라이언트의 수집이 클라이언트를 구분할 방법이 전혀 없는 하나의 공유 플랜을 통해 실행되는 것입니다. 이 방식으로는 각 클라이언트가 얼마를 소비했는지 알 수 없고, 한 클라이언트의 사용량 급증이 다른 클라이언트의 할당량을 눈에 띄지 않게 소비하게 되며, 오프보딩은 수작업으로 풀어내야 하는 작업이 됩니다.
첫 번째 구조의 메커니즘, 즉 워크스페이스, 역할, 서브계정, 플랜별 사용량은 다수의 클라이언트를 위한 서브계정과 사용량 추적에서 다룹니다. 요약하면: 예산을 분리해야 하는 곳에는 클라이언트별 플랜을, 플랜을 공유하는 곳에는 클라이언트별 서브계정을, 그리고 청구나 클라이언트 접근이 그것을 정당화하는 곳이라면 어디든 클라이언트별 워크스페이스를 사용하십시오.
완성된 데이터 판매 vs 프록시 액세스 재판매
화이트라벨이라고 불리는 두 가지 비즈니스가 있으며, 이들은 서로 다른 의무를 수반합니다.
완성된 데이터 판매. 클라이언트는 리포트, 피드, 또는 대시보드를 구매합니다. 프록시 네트워크는 서버와 마찬가지로 당신의 생산 과정의 일부입니다. 이 가이드의 모든 내용은 이 모델에 관한 것입니다.
당신의 브랜드로 프록시 액세스 재판매. 클라이언트는 자신의 트래픽을 보낼 수 있는 능력을 구매하며, 당신은 그들이 보는 제공자입니다. 이 경우 고객별 사용량 수치, 자체 한도 및 청구, 그리고 고객이 동의하는 명확한 사용 정책이 필요합니다. Shifter의 리셀러 프로그램이 이를 위해 만들어졌습니다. 서브계정은 패널과 API를 통해 각 고객의 트래픽을 추적하며, 당신은 자신의 플랫폼에서 가격, 한도, 청구를 설정합니다.
많은 에이전시는 첫 번째 방식으로 시작한 후 클라이언트가 자체 작업을 실행하고 싶어 할 때 두 번째 방식을 추가합니다. 책임이 다르기 때문에, 계정과 계약에서 이 둘을 분리하여 유지하십시오.
당신의 브랜드가 데이터에 붙을 때 떠안게 되는 것
다섯 가지가 당신 쪽 경계로 넘어옵니다.
신뢰성. 어젯밤 포털이 마크업을 변경했든 안 했든, 클라이언트의 리포트는 기한대로 나와야 합니다. 모니터링, 경고, 대체 계획이 필요합니다. “우리 공급업체에 문제가 있었다”는 화이트라벨 제공자가 쓸 수 있는 문장이 아니기 때문입니다.
출처. 클라이언트가 어떤 수치에 이의를 제기할 때, 당신은 그것이 어디서 언제 관측되었는지 말할 수 있어야 합니다. 즉, 모든 결과물에는 시장, 관측 지점, 타임스탬프, 수집 방법이 포함되어야 합니다. 이를 일급 필드로 취급해야 하는 근거는 관측 지점 표준에 있습니다.
컴플라이언스. 클라이언트의 의무는 당신의 브랜드에서 멈추지 않습니다. 클라이언트가 데이터 컨트롤러이고 당신이 그들을 대신해 처리하는 경우, 그 책임은 당신에게 흘러갑니다.
연속성. 소스, 시장, 또는 계약을 잃으면 클라이언트는 그것을 당신의 장애로 경험합니다.
지원. 당신이 1선 대응입니다. 클라이언트가 숫자가 왜 변했는지 물으면, 답은 전달된 티켓일 수 없습니다.
이 중 어느 것도 화이트라벨을 하지 말아야 할 이유는 아닙니다. 이는 그것을 제대로 가격 책정해야 할 이유이며, 아래에서 다룹니다.
모든 결과물이 포함해야 할 출처 필드
방어 가능한 결과물은 모든 값 옆에 몇 가지 필드를 포함합니다. 가격 모니터링 피드에서 가져온 예시 행 하나:
| 필드 | 예시 |
|---|---|
| 값 | 49.99 |
| 통화 | EUR |
| 소스 URL | retailer.example/product/123 |
| 시장 | Germany |
| 관측 지점 | Residential exit, Berlin, consumer ISP |
| 관측 시각 | 2026-10-21 09:14 UTC |
| 수집 방법 | HTTP request, sticky session, parsed from product page |
| 클라이언트 | acme |
당신의 브랜드는 표지에 올라갑니다. 이 필드들은 그 아래에 있습니다. 같은 카테고리의 두 클라이언트가 왜 자신들의 숫자가 다른지 물을 때, 관측 지점과 타임스탬프가 보통 그 답입니다.
컴플라이언스는 당신의 브랜드 뒤로 사라지지 않습니다
이 부분은 가장 자주 간과되는 부분이며, 당신 자신의 계획이 아니라 클라이언트의 조달 심사에서 드러날 가능성이 가장 높은 부분입니다.
클라이언트가 컨트롤러이고 당신이 프로세서인 경우, 당신의 데이터 처리 계약은 대개 서브프로세서를 공개하고 변경 전에 통지할 것을 요구합니다. 데이터 수집을 위해 의존하는 인프라가 그 정의에 포함될 수 있습니다. 화이트라벨 브랜딩은 법적 방패가 아니라 상업적 합의입니다. 그것은 당신의 계약이 만드는 공개 의무를 없애지 않습니다.
두 가지 실질적인 결과가 있습니다. 클라이언트 DPA에 서명하기 전에 서브프로세서, 통지 기간, 감사 권리에 대해 무엇이 적혀 있는지 읽어보십시오. 이 조항들이 당신이 자신의 스택을 얼마나 자유롭게 변경할 수 있는지를 결정하기 때문입니다. 그리고 당신의 수집이 무엇에 의존하는지에 대한 최신 내부 기록을 유지하여, 클라이언트가 물을 때 답이 일주일이 아니라 몇 분 안에 나오도록 하십시오. 대형 클라이언트는 또한 벤더 설문지를 보낼 것입니다. 예상해야 할 질문과 준비해야 할 답변은 당신의 InfoSec 팀이 프록시 벤더에게 보낼 보안 설문지에 있습니다.
이와 관련이 있으면서도 자주 혼동되는 것: 요청이 나가는 위치가 데이터가 처리되거나 저장되는 위치는 아닙니다. 클라이언트가 “우리 데이터가 EU에 있습니까”라고 묻는 것은 당신의 파이프라인에 대해 묻는 것이지 당신의 출구 위치에 대해 묻는 것이 아닙니다. 이 구분은 데이터 레지던시는 프록시 위치가 아니다에 설명되어 있으며, 전화 통화 중이 아니라 클라이언트가 묻기 전에 이해해 둘 가치가 있습니다.
에이전시 계정을 구조화하는 방법
운영 설정은 간단하며, 이를 정확히 따르는 것이 이후 모든 과정을 쉽게 만듭니다.
- 모든 클라이언트에게 자체 플랜 또는 자체 서브계정을 부여하십시오. 별도의 플랜은 예산을 분리시킵니다. 서브계정은 프록시 사용자명 안의 레이블로, 하나의 플랜 트래픽을 클라이언트별로 나누어 패널과 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를 생략하면 게이트웨이가 요청마다 회전합니다. 다단계 작업에서 하나의 출구를 유지하려면 이를 포함시키고, ttl로 유지 시간을 설정하십시오. 이 트레이드오프는 고정 프록시 vs 로테이팅 레지덴셜 프록시에 있습니다.
기가바이트가 아니라 결과물에 가격을 매기십시오
가장 흔한 화이트라벨 가격 책정 실수는 대역폭을 구매하는 것이 아닌 클라이언트에게 원가에 마진을 더해 대역폭을 재판매하는 것입니다. 당신의 클라이언트는 리포트, 피드, 또는 대시보드를 구매하고 있습니다. 그들은 기가바이트당 가격을 평가할 방법도 없고, 그것을 배우고 싶은 관심도 없습니다.
결과물 단위로 가격을 매기고, 실제로 비용을 좌우하는 지표인 사용 가능한 레코드당 기가바이트에서 자신의 마진을 관리하십시오. 전송량은 적지만 차단되거나 지리적으로 잘못된 데이터를 반환하는 워크플로는, 전송량은 더 많지만 제대로 작동하는 워크플로보다 전달된 레코드당 비용이 더 높습니다.
세 가지 습관이 마진을 보호합니다. 인보이스 시점이 아니라 매주 클라이언트별 소비를 검토하십시오. 범위 변경을 범위 변경으로 취급하십시오. 클라이언트는 가격 논의를 기대하지 않고 이메일로 시장이나 빈도를 추가하는 경우가 흔하기 때문입니다. 그리고 초과 사용이 그대로 진행되어야 하는지 작업이 일시 중지되어야 하는지를 클라이언트별로 미리 결정하십시오.
연속성과 오프보딩
둘 다 필요해지기 전에 계획하십시오.
연속성을 위해서는: 소스별, 클라이언트별 수집 성공률을 모니터링하여, 저하되는 소스가 클라이언트가 눈치채기 전에 드러나도록 하십시오. 당신의 어떤 결과물이 단일 소스에 의존하는지 파악하십시오. 그것들이 가장 심하게 망가지는 것들이기 때문입니다.
오프보딩은 조사가 아니라 체크리스트여야 합니다:
- 모든 작업에서 클라이언트의 자격 증명과 서브계정 레이블을 제거하십시오.
- 클라이언트의 플랜을 해지하거나 이전하십시오.
- 워크스페이스에서 클라이언트의 담당자들을 제거하거나, 그들이 워크스페이스를 소유하고 있다면 그 워크스페이스를 떠나십시오.
- 계약에 따라 과거 데이터를 인계하거나 삭제하십시오.
클라이언트가 자신의 워크스페이스를 소유하고 있다면, 이 중 대부분은 그들의 행동이 되며, 이는 대형 계정에 이 구조를 적용해야 할 또 다른 근거입니다.
FAQ
클라이언트가 소규모라면 하나의 플랜에서 여러 클라이언트를 운영할 수 있나요?
네, 각 클라이언트가 자체 서브계정을 가지고 있다면 가능합니다. 그러면 패널과 API가 각 클라이언트의 트래픽을 별도로 보고합니다. 공유 플랜이 할 수 없는 것은 한 클라이언트의 사용량에 상한을 두는 것이므로, 한 클라이언트의 사용량 급증은 여전히 다른 클라이언트들이 공유하는 대역폭을 소비합니다. 사용량이 많거나 예측 불가능한 클라이언트에게는 자체 플랜을 부여하십시오.
어떤 인프라를 사용하는지 클라이언트에게 알려야 하나요?
그것은 당신의 브랜딩이 아니라 계약에 달려 있습니다. 많은 클라이언트 DPA는 서브프로세서 공개와 변경 통지를 요구합니다. 당신이 서명한 계약을 확인하십시오.
하나의 에이전시 계정이 몇 명의 클라이언트를 감당할 수 있나요?
하나의 로그인은 사이드바에서 전환하면서 여러 워크스페이스에 속할 수 있습니다. 좌석 한도는 당신이 작업하는 워크스페이스 수가 아니라 워크스페이스별로 적용됩니다.
화이트라벨 결과물에는 무엇이 포함되어야 하나요?
데이터, 그리고 그것을 방어할 수 있을 만큼 충분한 출처 정보입니다. 시장, 관측 지점, 관측 타임스탬프, 방법 말입니다. 당신의 브랜드는 표지에 올라갑니다. 그 방법은 여전히 그 아래에 존재해야 합니다.
화이트라벨 데이터와 프록시 재판매의 차이는 무엇인가요?
화이트라벨 데이터는 당신의 브랜드로 완성된 데이터를 판매하고 네트워크가 당신의 생산 과정의 일부로 남아 있는 것을 의미합니다. 재판매는 고객이 당신이 제공하는 액세스를 통해 자신의 트래픽을 보내는 것을 의미하므로, 고객별 사용량 추적, 자체 한도 및 청구, 사용 정책이 필요합니다.
내 클라이언트가 내가 Shifter를 사용한다는 것을 알 수 있나요?
당신의 결과물을 통해서는 알 수 없습니다. 클라이언트는 당신이 워크스페이스에 초대하거나 자격 증명을 제공할 때만 Shifter를 보게 되며, 그렇기 때문에 클라이언트 담당자는 오직 자신의 워크스페이스에만 참여해야 합니다.
각 클라이언트에게 수집 비용을 어떻게 청구하나요?
각 클라이언트의 플랜, 또는 공유 플랜에서 각 클라이언트의 서브계정을 사용량 수치로 사용하고, 그 위에 결과물의 가격을 매기십시오. 인보이스에 놀라움이 없도록 매주 클라이언트별 사용량을 검토하십시오.
클라이언트가 떠나면 그들의 데이터는 어떻게 되나요?
당신의 계약이 말하는 대로입니다. 서명 시점에 합의하십시오: 인계, 일정 기간 보관, 또는 삭제. 그런 다음 위의 오프보딩 체크리스트를 따르십시오.
결론
화이트라벨링은 데이터가 당신이 책임질 수 있는 것이라는 약속입니다. 그 약속을 지키는 데 비용이 적게 들도록 계정을 구조화하십시오: 여러 워크스페이스에 걸친 하나의 에이전시 로그인, 모든 클라이언트를 위한 플랜 또는 서브계정, 클라이언트별로 분리된 자격 증명과 세션 식별자, 그리고 모든 결과물에 첨부된 출처 정보.
그런 다음 기가바이트가 아니라 결과물에 가격을 매기고, 매주 클라이언트별 사용량을 확인하며, 당신의 스택이 변경된 후가 아니라 변경되기 전에 클라이언트 DPA를 읽으십시오. 네트워크 자체는 레지덴셜 프록시 네트워크 페이지에 있습니다.