트러블슈팅: 크리테오 상품 피드 검수 탈락("이미지 규격 미달", "가격 정보 누락") 사유 분석 및 피드 파일 소스코드 즉각 정정 가이드

피드 오류 대응을 전적으로 개발팀에만 맡기면, 마케터는 반려 이유를 이해하지 못한 채 캠페인 규모가 왜 줄었는지도 모르고 지나칠 수 있습니다. 오류 유형과 원인을 마케터 스스로 1차로 판단할 수 있어야, 개발팀에 문의할 때도 정확한 정보를 전달해 해결 속도를 앞당길 수 있습니다.

반려 사유를 봤을 때 성급하게 피드 파일 전체를 뜯어고치기보다, 먼저 반려된 상품이 몇 개인지, 특정 카테고리나 특정 시점에 등록된 상품에 몰려 있는지부터 파악해야 원인 범위를 좁힐 수 있습니다.

3강·6강에서 다룬 상품 피드 문제는 크게 두 층위로 나뉩니다. 하나는 피드 파일 자체를 크리테오가 정상적으로 읽어내지 못하는 수집(ingestion) 오류이고, 다른 하나는 파일은 정상적으로 읽었지만 개별 상품의 데이터가 규격에 맞지 않아 그 상품만 반려되는 검수 오류입니다. 이 둘을 구분하지 못하면, 상품 몇 개의 사소한 오류를 고치는 데 시간을 쓰다가 정작 피드 파일 전체의 구조적 문제를 놓칠 수 있습니다.

상품 카탈로그 피드를 설정하거나 갱신할 때 크리테오가 피드 파일에 접근·다운로드·파싱하지 못하는 경우 수집 오류가 발생합니다. 이런 오류는 대개 서버 접근 권한, 파일 형식 오류, 인코딩 문제에서 비롯됩니다. 이 경우는 크리테오 대시보드에서 상품 몇 개가 아니라 피드 전체가 "처리 실패"로 표시되므로, 개별 상품 오류와는 다른 화면에서 확인해야 합니다.

필수 필드(id, title, description, link, image_link, price)가 비어있는 상품이 있으면 "필수 필드 누락" 경고가 표시됩니다. 이 오류는 단순히 필드 자체가 존재하지 않는 경우뿐 아니라, 필드는 있지만 값이 빈 문자열이거나 공백만 있는 경우에도 발생합니다. 특정 상품군(예: 신상품 등록 초기 단계에서 설명이 아직 작성되지 않은 상품)에서 이 오류가 몰려서 나타난다면, 상품 등록 프로세스 자체를 점검해야 할 신호입니다.

이미지는 최소 800×800픽셀, 16MB 미만이어야 하며 PNG·JPEG·GIF 형식과 HTTPS URL만 허용됩니다. 반려 사유가 이미지 규격이라면, 먼저 이미지 URL이 실제로 접근 가능한지(404 오류가 나지 않는지), HTTPS로 시작하는지부터 확인하고, 그다음 실제 이미지 파일의 해상도와 용량을 확인하는 순서로 점검하는 것이 효율적입니다. 이미지 URL 자체는 정상인데 CDN 설정 변경으로 접근이 막힌 경우도 실무에서 종종 발생합니다.

최소 규격을 충족해도 이미지 화질이 낮거나 워터마크가 있으면 검수에서 별도로 반려될 수 있어, 최소 규격 충족이 승인을 자동으로 보장하지는 않습니다. 이런 경우는 오류 메시지가 구체적인 수치 기준을 제시하지 않을 수 있어, 크리테오 지원팀에 직접 문의해 어떤 부분이 문제인지 확인하는 것이 필요할 수 있습니다.

피드 파일을 수정해 다시 업로드했다고 해서 곧바로 배너에 반영되는 것은 아니며, 크리테오가 새 피드를 다시 수집·검수하는 데 일정 시간이 소요됩니다. 정정 직후 곧바로 배너를 확인했는데 여전히 반영되지 않았다고 해서 정정이 실패했다고 성급히 판단하지 말고, 일정 시간을 두고 재확인하는 것이 순서입니다.

같은 유형의 오류(예: 특정 카테고리 상품의 이미지 규격 미달)가 반복된다면, 그 원인이 되는 상품 등록·이미지 업로드 프로세스 자체를 개선해야 근본적으로 재발을 막을 수 있습니다. 매번 반려된 상품을 사후에 하나씩 고치는 것보다, 애초에 등록 단계에서 규격을 자동 검증하는 장치를 두는 것이 장기적으로 훨씬 효율적입니다.

가격은 필수 필드 중에서도 DCO 배너에 직접 노출되는 핵심 정보이므로, 가격 정보가 누락된 상품은 애초에 배너 후보에서 제외됩니다. 세일 시즌처럼 대량의 가격 변경이 발생하는 시기에 가격 필드 형식 오류(통화 기호 누락, 잘못된 소수점 표기)가 집중적으로 생길 수 있어, 이런 시기에는 평소보다 짧은 주기로 반려 현황을 점검하는 것이 안전합니다.

크리테오 대시보드의 반려 사유를 마케팅팀만 확인하고 있으면, 원인이 상품관리시스템이나 개발팀 쪽에 있을 때 조치가 늦어집니다. 반려 상품 수와 주요 사유를 정기적으로 관련 팀에 공유하는 체계를 만들어두면, 65강 11강에서 다룬 정기 점검 원칙과 마찬가지로 문제를 방치하지 않고 빠르게 대응할 수 있습니다.