DataForSEO와 링크 전용 API: R 파이프라인에서의 변화

이러한 파이프라인에서 가장 비싼 실수

대부분의 파이프라인은 코드보다 비용에서 실패합니다. 행당 한 번씩 엔드포인트를 호출하는 루프는 저렴한 작업을 비싼 작업으로 바꿉니다.

저희 서비스에서는 10행이든 1,000행이든 호출 비용이 동일하므로 규칙이 바뀝니다: 사용할 수 있는 가장 큰 페이지를 요청하세요. per를 1000으로 설정하고 필요한 대로 정렬한 후, 질문이 해결되면 페이지네이션을 중단하세요.

깊은 페이지네이션은 50,000행으로 제한됩니다. 이는 모든 데이터를 끌어오고 싶은 분석가들에게는 기능입니다. 만약 도메인이 그 이상의 링크를 가지고 있다면, 대신 toppages나 anchors를 원할 것입니다.

축하하기 전에 기존 루프의 지출과 단일 호출 버전의 지출을 비교하세요. 기존 제공자가 이미 요청당 청구했기 때문에 절감 효과가 없을 수도 있습니다.

오류, 재시도 및 계획 가능한 실패

링크 전용 파이프라인과 광범위한 파이프라인은 실패 지점에서 가장 유사해 보입니다. 코드에서 실패 경로가 종종 미완성 상태로 남습니다. 오류가 논의되면 링크 전용 vs 광범위한 결정은 다르게 보일 수 있으므로 비교에 실패 경로를 포함하세요.

HTTP 401과 HTTP 402를 처리해야 합니다

두 가지 상태 코드가 가장 중요합니다. HTTP 401은 키가 없거나 잘못되었음을 의미하며, 수정은 데이터가 아닌 구성(Configuration)에서 이루어집니다. HTTP 402는 크레딧 잔고가 부족함을 의미하며, 수정은 코드 변경이 아닌 계정 페이지에서 충전(Top-up)을 통해 이루어집니다.

두 경우 모두 명시적인 분기(Branch)로 작성하세요. 상태 코드를 숨기고 빈 테이블을 작성하는 일반적인 캐치(Catch)는 부분적인 데이터 추출이 조용히 일어나는 원인이 됩니다.

타임아웃 및 부분 파일

타임아웃은 상태 코드가 아니므로 자체 코드에서 실패로 처리해야 합니다. 호출을 감싸서 타임아웃 시 출력 파일이 작성되기 전에 실행을 중단하세요.

임시 파일에 작성하고 성공 시 이름 변경을 하세요. 완료된 것처럼 보이는 반쯤 작성된 파일은 중단된 실행의 가장 나쁜 결과입니다. 사람들은 이를 의심하지 않기 때문입니다.

재시도 및 페이싱(Pacing)

이 페이지는 초당 요청 수를 인용하지 않으므로, 파이프라인은 주기당 호출 수를 기준으로 크기를 조정하세요. 이는 비용을 결정하는 수이며, 당신이 통제할 수 있는 수입니다.

네트워크 오류만 재시도하고 시도 사이에 일시 정지하세요. 401 또는 402는 다음 시도에서도 동일하게 실패하므로 재시도하지 마세요.

테스트 중 키의 위치

키를 로컬 환경 변수와 CI 시크릿 스토어에 보관하세요. 테스트가 읽는 파일에는 넣지 마세요. 무료 액션은 키가 필요 없으므로, 프로젝트를 복제하는 누구나 첫 번째 테스트 실행을 안전하게 할 수 있습니다.

접촉하는 모든 파이프라인에 동일한 질문을 하세요: 누가 키를 읽을 수 있으며, 키가 어디에 기록되어 있는가? 로그 파일에 키가 나타나면 노트북이 비공개라도 누출입니다.

각 호출 비용 로깅

인증된 호출의 모든 응답에는 credits 필드가 포함되어 비용과 남은 잔액을 보여줍니다. 타임스탬프와 액션 이름 옆에 이를 로그에 복사하세요. 그러면 메모리가 아닌 파일에서 비용 질문을 해결할 수 있습니다.

연 1회가 아닌 월 1회 로그를 읽으세요. 주기당 비용의 완만한 상승은 차트에서는 놓치기 쉽지만 숫자 열에서는 명확합니다.

실패한 실행도 로그를 남겨야 합니다. 상태 코드와 중단된 단계를 포함하세요. 성공만 기록하는 로그는 필요한 줄을 숨깁니다.

단계 간 행 수 세기

많은 비용이 많이 드는 파이프라인 버그는 카운트 버그입니다. 테이블이 조인, 필터링 또는 중복 제거 과정에서 행을 잃어도 차트는 여전히 타당해 보일 수 있습니다.

이관마다 카운트 기록

파이프라인을 테이블의 사슬로 생각하세요: API 응답, 구현된 tibble, 저장된 파일, 보고서. 각 이관 지점의 행 수는 어떤 단계에서 행이 손실되었는지(있다면) 보여줍니다.

분석가들은 종종 마지막에만 카운트를 합니다. 그때는 원인이 세 단계 전에 있으며, tibble은 이미 두 번 재구성되었습니다.

도메인당 1행, 링크당 1행

입자(Grain)는 액션에 따라 다릅니다. 참조 도메인 풀링은 링크 사이트당 1행을 반환하는 반면, 백링크 풀링은 링크당 1행을 반환하며, 한 사이트가 여러 링크를 보낼 수 있습니다. 잘못된 입자에서 카운트하면 두 개의 올바른 숫자가 서로 불일치하는 것처럼 보입니다.

입자를 저장된 파일 이름이나 헤더 주석에 넣으세요. 다음 사람이 추측하지 않도록 하세요. 액션 용어집은 각 액션의 입자를 나열합니다.

페이지네이션 및 50,000행 한도

page와 per를 사용한 페이지네이션은 페이지당 최대 5000행까지 작동하지만, 깊은 페이지네이션은 50,000행에서 중단됩니다. 그 이상을 기대하는 풀링은 제한된 값으로 반환되며, 카운트가 이상하게 반올림된 것처럼 보일 수 있습니다.

받은 수와 예상 총수를 비교하세요. 차이가 나면 소스를 탓하기 전에 액션, 정렬 및 페이지 크기를 확인하세요.

가상의 카운트 계산

가상의 풀링이 30개 대상 도메인에 대한 링크 사이트 수를 요청하고 30행의 카운트를 반환한다고 가정해 보세요. 점수 테이블과 조인하면 27행만 유지됩니다. 누락된 3행은 차트를 그리기 전에 확인해야 하며, 키부터 시작하세요.

이 3행을 카운트 alone이 아닌 이름으로 기록하세요. 카운트는 행이 누락되었음을 알려주지만, 이름은 정리가 필요한 키를 알려줍니다.

조용히 행을 삭제하는 조인

Left join은 왼쪽 테이블의 모든 행을 유지하므로 누락된 점수는 NA로 표시됩니다. Inner join은 행을 완전히 제거하여 동일한 문제를 숨깁니다.

의도적으로 조인 유형을 선택하고, 조인 후 NA 점수를 카운트하세요. 이 카운트는 credits 필드 옆 로그에 속합니다.

전환 전 짧은 테스트 계획

한 주기 동안 두 소스를 모두 실행하세요. 같은 도메인, 같은 날짜.

잘 아는 30개 도메인을 선택하세요. 현재 제공자와 CranSEO에서 참조 도메인 카운트를 추출하고 로그 축으로 대조하여 플롯하세요. 크롤링이 다르고 저희가 약 월간으로 갱신되므로 정확한 대각선이 아닌 대략적인 대각선이 보여야 합니다. DataForSEO, Ahrefs, Semrush는 각각 약간 다른 웹을 봅니다.

평균이 아닌 이상치를 읽으세요. 저희 카운트가 현저히 낮은 경우 도메인이 새로웠거나 최근 이동했는지 확인하세요. 현저히 높은 경우 서브도메인을 확인하세요. 용어집은 참조 도메인으로 카운트하는 기준을 정의하며, 런북은 두 풀링을 나란히 저장하는 방법을 보여줍니다.