화이트라벨 데이터 수집이란 클라이언트가 귀하의 브랜드로, 귀하의 조건으로, 청구서에 귀하의 이름이 적힌 채로 데이터를 받는다는 뜻입니다. 클라이언트는 기저의 인프라와 계약하지 않고, 그것을 보지도 않으며, 대부분의 경우 보고 싶어하지도 않습니다.
이 방식은 상업적으로는 단순하지만, 대부분의 대행사가 예상하는 것보다 더 많이 귀하의 책임을 바꿔놓습니다. 데이터셋에 귀하의 브랜드를 붙이는 순간, 귀하는 프록시 네트워크를 사용하는 회사에서 벗어나 공식 데이터 제공자가 됩니다. 신뢰성, 출처, 컴플라이언스, 연속성 모두 귀하가 책임져야 할 사안이 됩니다.
이 가이드는 그것이 실제로 무엇을 의미하는지, 그리고 여러 클라이언트가 서로 접촉하지 않으면서도 하나의 계정으로 운영되도록 구조화하는 방법을 다룹니다.
”하나의 계정”은 하나의 로그인을 의미하지, 하나의 통을 의미하지 않습니다
이 부분은 즉시 정리해둘 가치가 있습니다. 이 문구는 모호하며, 잘못 해석하면 실질적인 피해로 이어지기 때문입니다.
효과가 있는 방식은 대행사용 Shifter 계정 하나, 하나의 로그인, 하나의 공급업체 관계, 모든 것을 한 곳에서 볼 수 있는 구조이되, 각 클라이언트는 그 아래에서 각자의 워크스페이스와 각자의 플랜으로 분리되는 것입니다.
효과가 없는 방식은 모든 클라이언트의 수집 작업이 하나의 공유 플랜을 통해 돌아가는 것입니다. 이 방식으로는 각 클라이언트에게 실제로 얼마의 비용이 들었는지 알 수 없고, 한 클라이언트의 사용량 급증이 다른 클라이언트의 할당량을 잠식하며, 온보딩 해제 시 수동으로 얽힌 것을 풀어야 하는 작업이 됩니다.
첫 번째 방식의 세부 사항, 즉 워크스페이스, 역할, 사이드바 전환기, 플랜별 사용량 추적은 여러 클라이언트를 위한 서브계정과 사용량 추적에서 다룹니다. 요약하면 클라이언트당 하나의 플랜은 예외 없이 지키고, 청구나 클라이언트 접근이 정당화되는 경우 클라이언트당 워크스페이스를 두는 것입니다.
귀하의 브랜드가 데이터에 붙을 때 떠안게 되는 것
다섯 가지가 귀하의 책임 영역으로 넘어옵니다.
신뢰성. 포털이 어젯밤에 마크업을 바꿨든 아니든 클라이언트의 보고서는 예정대로 나가야 합니다. 모니터링, 알림, 대체 계획이 필요합니다. “공급업체에 문제가 있었다”는 화이트라벨 제공자가 쓸 수 있는 말이 아니기 때문입니다.
출처. 클라이언트가 어떤 수치에 이의를 제기하면, 그것이 어디서, 언제 관측되었는지 말할 수 있어야 합니다. 즉 모든 산출물에는 시장, 관측 지점, 타임스탬프, 수집 방법이 함께 붙어야 합니다. 이를 1급 필드로 취급해야 하는 근거는 관측 지점 표준에 나와 있습니다.
컴플라이언스. 클라이언트의 의무는 귀하의 브랜드에서 멈추지 않습니다. 클라이언트가 데이터 컨트롤러이고 귀하가 그들을 대신해 처리하는 입장이라면, 그 책임은 귀하에게로 흘러옵니다.
연속성. 데이터 소스, 시장, 계약 중 하나를 잃으면 클라이언트는 그것을 귀하의 서비스 중단으로 경험합니다.
지원. 귀하가 1선입니다. 클라이언트는 왜 수치가 변했는지 귀하에게 물으며, 그 답이 전달된 티켓이어서는 안 됩니다.
이 중 어느 것도 화이트라벨을 하지 말아야 할 이유는 아닙니다. 오히려 그것을 제대로 가격 책정해야 할 이유이며, 이는 마지막 섹션에서 다룹니다.
컴플라이언스는 브랜드 뒤로 사라지지 않습니다
이 부분은 가장 자주 간과되는 부분이며, 귀하의 자체 계획보다는 클라이언트의 조달 검토 과정에서 표면화될 가능성이 큽니다.
클라이언트가 컨트롤러이고 귀하가 프로세서라면, 데이터 처리 계약(DPA)은 대개 하위 처리자를 공개하고 변경 전에 통지할 것을 요구합니다. 데이터 수집을 위해 의존하는 인프라도 이 정의에 포함될 수 있습니다. 화이트라벨 브랜딩은 상업적 배치일 뿐 법적 방패가 아닙니다. 계약이 만든 공개 의무를 없애주지 않습니다.
실질적인 결과는 두 가지입니다. 클라이언트 DPA에 서명하기 전에 하위 처리자, 통지 기간, 감사 권리에 대해 무엇이 명시되어 있는지 읽어보십시오. 이 조항들이 귀하 자신의 스택을 얼마나 자유롭게 바꿀 수 있는지를 결정합니다. 그리고 귀하의 수집 작업이 무엇에 의존하는지에 대한 최신 내부 기록을 유지하여, 클라이언트가 물었을 때 답이 일주일이 아니라 몇 분 만에 나올 수 있도록 하십시오.
이와 관련이 있으면서도 자주 혼동되는 것으로, 요청이 나가는 지점이 곧 귀하의 데이터가 처리되거나 저장되는 곳은 아닙니다. “우리 데이터가 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로 지속 시간을 설정하십시오. 이 트레이드오프는 고정형 대 로테이팅 레지덴셜 프록시에, 요청 페이싱은 속도 제한과 요청 스로틀링에 나와 있습니다.
기가바이트가 아니라 산출물 단위로 가격을 매기십시오
가장 흔한 화이트라벨 가격 책정 실수는 대역폭을 원가에 마진을 붙여 재판매하는 것입니다. 클라이언트는 대역폭을 사는 것이 아닙니다. 클라이언트는 보고서, 피드, 대시보드를 사는 것입니다. 그들에게는 기가바이트당 가격을 평가할 방법이 없고 그것을 배우고 싶은 관심도 없습니다.
산출물 단위로 가격을 매기고, 실제로 비용을 좌우하는 지표, 즉 사용 가능한 레코드당 기가바이트에서 귀하 자신의 마진을 관리하십시오. 전송량은 적지만 차단되거나 지리적으로 잘못된 데이터를 반환하는 워크플로는, 전송량이 많지만 제대로 작동하는 워크플로보다 전달된 레코드당 비용이 더 높습니다. 예측 방법은 레지덴셜 프록시 대역폭 예측에 나와 있습니다.
마진을 지키는 세 가지 습관이 있습니다. 청구 시점이 아니라 매주 클라이언트별 소비량을 검토하십시오. 범위 변경은 범위 변경으로 취급하십시오. 클라이언트는 가격 협의를 예상하지 않은 채 이메일 한 통으로 시장이나 빈도를 추가하는 일이 흔하기 때문입니다. 그리고 클라이언트별로 초과 사용량을 흘려보낼지 아니면 작업을 일시 중지할지를 미리 결정하십시오.
연속성과 온보딩 해제
필요해지기 전에 둘 다 계획해두십시오.
연속성을 위해서는, 클라이언트별 소스별로 수집 성공률을 모니터링하여 저하되는 소스가 클라이언트가 알아채기 전에 보이도록 하십시오. 귀하의 어떤 산출물이 단일 소스에 의존하는지 파악하십시오. 그것들이 가장 크게 무너지는 부분이기 때문입니다.
온보딩 해제를 위해서는, 클라이언트 제거가 조사가 아니라 체크리스트가 되도록 하십시오. 모든 작업에서 해당 클라이언트의 자격 증명을 폐기하고, 그들의 플랜을 종료하거나 이전하고, 워크스페이스에서 그들의 사람들을 제거하고, 과거 데이터를 어떻게 할지 계약서에 합의해두십시오. 클라이언트가 자신의 워크스페이스를 소유하고 있다면 이는 대체로 그들의 작업이 되며, 이는 대형 계정에 대해 그러한 구조를 두어야 할 추가적인 근거입니다.
자주 묻는 질문
클라이언트들이 소규모라면 한 플랜에 여러 클라이언트를 돌려도 될까요?
가능하기는 하지만, 그중 누구에게 얼마의 비용이 들었는지, 어떤 사용량 급증이 있었는지 알 수 없게 됩니다. 물량이 정말로 미미하다면, 절약되는 비용은 작고 귀속 손실은 영구적입니다.
어떤 인프라를 사용하는지 클라이언트에게 알려야 하나요?
이는 귀하의 브랜딩이 아니라 계약에 달려 있습니다. 많은 클라이언트 DPA는 하위 처리자 공개와 변경 통지를 요구합니다. 서명한 계약서를 확인하십시오.
하나의 대행사 계정으로 몇 명의 클라이언트를 담당할 수 있나요?
하나의 로그인은 여러 워크스페이스에 속할 수 있으며, 사이드바에서 전환합니다. 좌석 제한은 워크스페이스별로 적용되지, 귀하가 관여하는 워크스페이스의 수에 적용되지 않습니다.
화이트라벨 산출물에는 무엇이 포함되어야 하나요?
데이터에 더해, 그것을 방어할 수 있을 만큼의 출처 정보, 즉 시장, 관측 지점, 관측 타임스탬프, 방법입니다. 브랜드는 표지에 올라갑니다. 방법은 여전히 그 밑에 존재해야 합니다.
결론
화이트라벨링은 그 데이터를 귀하가 책임지고 뒷받침하겠다는 약속입니다. 그 약속을 지키는 데 비용이 적게 들도록 계정을 구조화하십시오. 여러 워크스페이스에 걸친 하나의 대행사 로그인, 예외 없이 클라이언트당 하나의 플랜, 클라이언트별로 분리된 자격 증명과 세션 식별자, 그리고 모든 산출물에 붙는 출처 정보가 그것입니다.
그런 다음 기가바이트가 아니라 산출물 단위로 가격을 매기고, 매주 클라이언트별 사용량을 지켜보고, 스택이 바뀐 후가 아니라 그 전에 클라이언트 DPA를 읽으십시오. 네트워크 자체는 레지덴셜 프록시 네트워크 페이지에, 요금은 가격 페이지에 나와 있습니다.