00 / Definition
요청한 값과 실제 저장값이 같고, 관리자 화면과 광고 상태를 확인했으며, 승인자와 확인 결과가 기록된 상태.
01 / Failure points
성공처럼 보이지만 실패할 수 있는 다섯 지점
객체는 생겼지만 옵션이 누락됨
지원되지 않거나 계정 조건이 맞지 않는 필드가 기본값으로 저장될 수 있습니다.
API 값과 화면 표현이 다름
기존 게시물, 협력광고, 소재 매핑은 관리자 화면에서 최종 형태를 확인해야 합니다.
상위 객체만 활성 상태
캠페인·광고세트·광고의 유효 상태를 계층별로 다시 읽어야 합니다.
활성이지만 전달되지 않음
심사, 일정, 결제, 타기팅 크기와 계정 제한 때문에 노출이 시작되지 않을 수 있습니다.
성과 기록이 끊김
픽셀·전환 API·UTM·주문 데이터가 맞지 않으면 운영 판단이 왜곡됩니다.
02 / Checklist
Awen 운영 성공 체크리스트
| 단계 | 확인할 증거 |
|---|---|
| 생성 | 객체 ID, OFF 상태, 요청 명세 해시 |
| Readback | 저장된 예산·일정·타기팅·소재 ID |
| 화면 검수 | 광고 관리자에서 보이는 게시물·옵션·미리보기 |
| 승인 | 승인자, 승인 시각, 변경 범위 |
| 전달 | 심사 결과, 유효 상태, 노출·지출 발생 |
| 측정 | 전환 이벤트와 실제 주문·매출 대조 |
03 / Human boundary
사람이 확인할 단계는 남겨둡니다
저장값 조회와 반복 비교는 자동화합니다. 하지만 예산 변경과 광고 ON처럼 비용이 발생하는 작업은 사람이 승인한 뒤 실행합니다.
04 / Evidence
운영 장부에는 결과보다 비교 근거를 남깁니다
단순히 ‘성공’이라고 기록하면 다음 운영자가 무엇을 확인했는지 알 수 없습니다. 요청 시각과 요청자, 생성된 객체 ID, 요청값과 readback 값의 차이, 관리자 화면 확인 시각, 승인자, 최종 유효 상태를 한 흐름으로 남겨야 재현 가능한 증거가 됩니다.
특히 기존 게시물 광고나 협력광고처럼 API 객체와 화면 표현이 한눈에 대응하지 않는 유형은 게시물 ID, 미리보기 URL, 화면에서 확인한 옵션을 함께 기록하는 편이 안전합니다. 이후 성과가 예상과 다를 때 설정 문제인지 전달 문제인지 빠르게 분리할 수 있습니다.
05 / Triage
노출이 없을 때는 계층 순서로 확인합니다
- 캠페인·광고세트·광고의 설정 상태와 유효 상태가 모두 활성인지 봅니다.
- 심사 거절, 계정 제한, 결제 오류와 예약 시작 시각을 확인합니다.
- 타기팅 규모, 입찰·예산 제약, 소재 연결 상태를 점검합니다.
- 노출이 생긴 뒤에는 UTM, 픽셀·전환 API 이벤트와 실제 주문을 대조합니다.
이 순서를 지키면 ‘API가 성공했으니 플랫폼 문제’라는 성급한 결론을 피할 수 있습니다. Awen의 성공 기준은 생성, 전달, 측정을 서로 다른 검증 단계로 취급합니다.