이 가이드에서는 Google Play Developer API를 사용하여 앱을 만들고 Play 앱의 제품 카탈로그를 관리하는 방법을 알아보겠습니다.
Google Play 결제 시스템을 통해 앱에서 제품을 판매하려면 다음이 필요합니다. 판매하려는 모든 제품이 포함된 카탈로그를 설정할 수 있습니다. 알 수 있습니다. 이 작업은 Play Console을 통해 할 수도 있고 카탈로그 관리를 자동화합니다. 자동화는 카탈로그를 항상 최신 상태로 유지하고 필요한 경우 수동 조정은 비현실적입니다. 이 가이드에서는 Play Developer API를 사용하여 Play 앱의 제품 카탈로그를 만들고 관리하는 방법을 알아봅니다. 설정 방법에 대한 안내는 준비하기 가이드를 검토하세요. 백엔드 통합을 위해 Google Play Developer API를 설정합니다.
카탈로그 관리 API
Google Play의 결제 시스템, 읽기 인앱 상품 유형 및 카탈로그 고려사항을 이해합니다. Google은 Play의 카탈로그 관리를 위해 두 가지 기본 API 세트를 제공합니다. 두 가지 주요 제품 카테고리인
- 일회성 제품
- 정기 결제 제품
일회성 제품
inappproducts 엔드포인트를 사용하면 일회성으로
백엔드에서 지원합니다 여기에는 생성, 업데이트, 삭제가 포함됩니다.
제품, 가격 및 재고 관리 등이 포함됩니다
일회성 제품 구매를 처리하는 방식에 따라
소비성 제품 (원하는 횟수만큼 구매할 수 있음) 또는 영구 제품
사용 권한 (동일한 사용자가 두 번 부여할 수 없음) 특정 광고 단위를
일회성 제품은 소비성인지
아니어야 합니다
정기 결제 제품
monetization.subscriptions 엔드포인트를 사용하여 구독을 관리할 수 있습니다.
제품 관리 서비스를 받을 수 있습니다 계정을 만들고, 업데이트하고,
구독을 삭제하거나 지역별 재고 및 가격을 관리할 수 있습니다
monetization.subscriptions 엔드포인트 외에도
monetization.subscriptions.basePlans 및
각각을 관리할 monetization.subscriptions.basePlans.offers
구독' 기본 요금제 및 혜택입니다.
일괄 메서드
inappproducts 및 monetization.subscriptions
엔드포인트는 클러스터 내에서 데이터를 검색하거나 관리할 수 있는
항목을 동시에 100개까지 만들 수 있습니다.
사용 설정된 지연 시간 허용 오차와 함께 사용하면 일괄 처리 메서드가 처리량이 많은 대규모 카탈로그 개발자에게 특히 유용하며 카탈로그 생성이나 카탈로그 조정이 포함됩니다.
업데이트 전파 지연 시간 및 처리량 비교
제품 제작 또는 수정 요청이 완료된 후에는 변경사항이 적용되지 않을 수 있습니다.
네트워크 또는 백엔드로 인해 기기의 최종 사용자에게 즉시 표시됩니다.
처리 지연 시간이 단축됩니다
기본적으로 모든 제품 수정 요청은 지연 시간에 민감합니다. 다시 말해
일반적으로 백엔드 시스템을 통한 빠른 전파에 최적화되어 있습니다.
몇 분 이내에 최종 사용자 기기에 반영됩니다. 시간 제한이 있습니다.
확인할 수 있습니다.
많은 제품을 만들거나 업데이트해야 하는 경우 (예:
초기 대규모 카탈로그 생성), 일괄 메서드를 사용하여
latencyTolerance필드가 다음으로 설정됨
PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
이렇게 하면 업데이트 처리량이 크게 증가합니다. 지연 시간 허용 업데이트
최종 사용자 기기에 적용되는 데 최대 24시간이 걸립니다.
할당량 구성
Play 개발자를 사용할 때 알아야 할 몇 가지 할당량 한도가 있습니다. API를 사용하여 제품 카탈로그를 관리합니다.
- Google Play Developer API의 기본 한도는 쿼리당 쿼리 200,000개 있습니다. 이 할당량 한도는 모든 엔드포인트의 사용량 집계에 적용되며 여기에는 카탈로그 관리 API가 포함됩니다.
- 또한 제품 수정 엔드포인트는 쿼리당 쿼리 7,200개로 시간 일회성 제품과 정기 결제 모두에 적용되는 단일 한도입니다. 생성, 업데이트, 활성화, 수정 등 수정 요청을 할 때 삭제합니다. 일괄 수정 메서드 호출은 이 할당량의 쿼리 1회로 집계되며, 포함된 개별 요청의 수나 지연 시간에 관계없이 지정할 수 있습니다.
- 지연 시간에 민감한 수정 또한 7,200회 수정으로 제한됩니다. 입니다 일괄 메서드의 경우 중첩된 모든 수정 요청이 계산됨 이 할당량의 용도로 별도로 사용되어야 합니다. 이 할당량은 실제로 지연 시간에 민감한 일괄 API 수행 사용자에게만 미치는 영향 다른 경우와 같이 할당량 2가 업데이트되기 전에 또는 같은 시간에 이 할당량으로 계산됩니다
다음은 Cloud Functions의 할당량 사용을 이해하기 위한 몇 가지 예시 예시입니다. 다음과 같습니다.
- 항목 1개를 가져오는 단일
get요청은 할당량 1 토큰 1개를 소비하고 할당량 2 및 3의 토큰 없음 (수정 엔드포인트에만 해당됨). - 최대 100개의 항목을 가져오는
get일괄 요청에서도 토큰 1개를 사용합니다. 할당량 1과 할당량 2와 3의 토큰이 없습니다. - 항목 1개에 대한 단일
modification요청은 할당량 1 토큰 1개를 사용합니다. , 할당량 토큰 1개 2. 요청이 지연 시간에 민감한 경우 할당량 3의 토큰 1개를 사용합니다. 할당량 C에는 할당량 2와 동일한 한도가 있으므로 한 번의 수정만 사용하는 사용자에게 실질적인 영향을 미치지 않습니다. 메서드를 참조하세요. - 지연 시간 허용 항목 100개에 대한 일괄
modification요청은 1을 소비합니다. 할당량 1의 토큰 1, 할당량 토큰 2의 토큰 1. 이 할당량 설정은 카탈로그를 최신 상태로 유지할 수 있는 여유가 될 수 있지만 알고리즘이 이 할당량을 초과하고 추가 호출당 오류가 발생할 수 있습니다. - 지연 시간에 민감한 항목 100개에 대한 일괄
modification요청은 할당량 1 토큰 1개, 할당량 2 토큰 1개, 할당량 3 토큰 100개입니다.
Catalog Management API 사용 권장사항
이 가이드라인을 준수하면 API와의 상호작용을 최적화할 수 있으며, 원활하고 효율적인 카탈로그 관리 환경 보장
사용량 모니터링
사용량이 많은 프로세스에 주의해야 합니다. 예를 들어 통합 카탈로그 관리 엔드포인트에서 전체 초기 카탈로그를 만들 수 있는 할당량이 늘어나며 이로 인해 다른 엔드포인트의 프로덕션 사용(예: 구매 상태 API) 전체 사용량 한도에 가까워집니다 할당량 소모를 모니터링하여 API 할당량을 초과할 수 있습니다 사용량을 모니터링하는 방법에는 여러 가지가 있습니다. 예를 들어 Google Cloud API 할당량 대시보드나 서드 파티 API 모니터링 도구를 사용하기만 하면 됩니다
API 할당량 사용 최적화
요율 소비를 최적화하여 API 오류입니다. 이를 효과적으로 구현하려면 다음과 같이 하는 것이 좋습니다.
- 적절한 카탈로그 관리 전략을 선택합니다. API를 이해하고 나면 애플리케이션에 적합한 전략을 선택해야 합니다. 카탈로그 관리 목표를 효율적으로 달성하는 데 도움이 됩니다.
- 변경사항을 반영하는 데 필요한 최소한의 호출량만 실행합니다.
- 중복되거나 불필요한 수정 호출을 API에 전송하면 안 됩니다. 이 백엔드 카탈로그에 변경 로그를 유지해야 할 수 있습니다.
- 제품 수정의 시간당 쿼리 7,200개 한도를 유지하세요. 다음을 수행할 수 있습니다. 많은 수의 제품을 생성해야 하는 동기화 프로세스를 빌드하려는 경우 단기간에 수정 (예: 초기 카탈로그) 생성). 이러한 프로세스가 시간당 한도를 초과할 것으로 예상되는 경우 사용을 안전한 수준으로 늦추기 위해 필요한 만큼 대기를 구현합니다. 다음과 같은 방법을 사용해 보세요. 배치 메서드를 사용하여 더 높은 처리량을 달성할 수 있습니다.
- 사전에 확장을 준비하세요. 애플리케이션이 커지면 API 및 다양한 엔드포인트의 사용량을 늘립니다 Google Play Developer API 할당량 문서에서 자세히 알아보세요. 최대 사용량에 가까워지면 할당량을 늘리는 것이 좋습니다.
- 대규모 프로세스의 일정을 전략적으로 예약합니다. 대량 카탈로그를 예약해 보세요. 예를 들어 사용량, 메모리 또는 사용량이 정상적으로 발생할 때 전체 카탈로그 동기화를 지원합니다.
할당량 오류 처리 로직 추가
카탈로그 관리 로직을 아무리 효율적으로 구축하더라도
일일 할당량이 너무 많기 때문에 예상치 못한 할당량 한도에 대한
통합의 독립적인 모듈에서 사용되는 엔드포인트에서 공유됩니다.
오류 처리에 할당량 제한 오류를 포함하고
기다려야 합니다
Google Play Developer API를 호출할 때마다 응답이 생성됩니다.
발생하면 다음과 같은 실패 응답을 받게 됩니다.
HTTP 응답 상태 코드 및 errors 객체로, 추가 세부정보 제공
오류 도메인 및 디버그 메시지 정보
예를 들어 일일 한도를 초과하면 오류가 발생할 수 있습니다.
다음과 비슷합니다.
{
"code" : 403,
"errors" : [ {
"domain" : "usageLimits",
"message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
"reason" : "dailyLimitExceeded",
"extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
} ],
}
카탈로그 관리 구현
개발자는 Google Play Developer API 제품 게시 엔드포인트를 사용하여 카탈로그를 백엔드와 Google Play 간에 동기화 상태로 유지합니다. 만들기 백엔드 카탈로그를 사용하여 Google Play 카탈로그를 항상 최신 상태로 유지 최신 정보는 더 나은 사용자 환경을 만드는 데 도움이 됩니다. 예를 들면 다음과 같습니다.
- 사용 가능한 제안의 전체 목록을 참고하고 자격 요건에 영향을 미치고 혜택 표시에 영향을 줄 수 있는 혜택 및 기본 요금제 태그 제공합니다.
- 사용자의 다양한 가격대와 제품 세부정보를 확인할 수 있습니다. 일관성을 유지해야 합니다
- 신규를 처리할 때 백엔드에서 제품 세부정보를 바로 확인할 수 있습니다. 지연 시간을 늘리고 실패 위험을 증가할 필요 없이 사용자 중요한 플로우 중에 Google Play Developer API를 추가로 호출할 수 있습니다.
지켜야 할 특정 한도 및 고려사항이 있습니다. 몇 가지 권장사항을 고려해 보시기 바랍니다 이해했으면 카탈로그를 어떻게 구조화할지 알았다면 동기화 전략을 결정합니다
카탈로그 동기화 전략
Google Play Developer API 게시 엔드포인트를 사용하면 카탈로그를 자동으로 변경할 수 있습니다 경우에 따라 업데이트 접근 방식을 사용하는 것이 일반적입니다. 각 접근 방식은 다른 설계 선택이 필요합니다 각 동기화 전략은 일부 사용 사례에 더 잘 맞으며, Google Cloud의 둘 다 요청해야 합니다 때로는 예를 들어 새 변경사항을 인지하는 즉시 제품을 업데이트할 수 있습니다. 긴급 제품 업데이트를 처리해야 합니다 (즉, 잘못된 가격을 수정해야 함). 가능한 한 빨리) 그 외의 경우에는 주기적 백그라운드 동기화를 사용하여 백엔드와 Play 카탈로그는 항상 일관성이 있어야 합니다. 일반적인 용도 읽기 다양한 카탈로그 관리를 구현하고자 하는 경우 있습니다.
현지 카탈로그 변경사항에 따라 업데이트를 전송해야 하는 경우
백엔드의 속성이 변경되는 즉시 업데이트가 이루어지는 것이 이상적입니다. 불일치를 최소화하는 것이 중요합니다
이러한 유형의 업데이트는 다음과 같은 경우에 적합합니다.
- 제품이 항상 최신 상태인지 확인해야 합니다.
- 매일 제품에 몇 가지 변경사항을 적용해야 합니다.
- 이미 프로덕션 및 판매 중인 제품을 업데이트해야 합니다.
이 접근 방식은 구현이 더 간단하며 카탈로그를 동기화된 상태로 유지할 수 있습니다. 가장 낮은 금액의 불일치 기간으로 지정할 수 있습니다
주기적인 업데이트를 사용해야 하는 경우
주기적 업데이트는 백엔드의 제품 버전에 대해 비동기식으로 실행됩니다. 다음과 같은 경우에 적합합니다.
- 갑작스러운 공지에 제품이 업데이트되도록 할 필요는 없습니다.
- 일괄 업데이트 또는 조정 프로세스를 계획해야 하는 경우
- 카탈로그를 지속적으로 업데이트하는 디지털 제품
대규모 카탈로그의 경우 지연 시간을 허용하는 일괄 메서드 사용 고려 업데이트하여 최대 처리량을 달성할 수 있습니다
제품 카탈로그 만들기
Google Play에 업로드할 대규모 카탈로그가 있는 경우 초기 로드에 적합합니다 이러한 유형의 고부하 프로세스는 지연 시간 허용 배치 메서드와 결합한 것이 뒤따릅니다
일회성 제품 만들기
일회성 제품의 대규모 카탈로그를 처음 만들 때는
allowMissing 필드가 다음과 같이 설정된 inappproducts.batchUpdate 메서드
true 및 latencyTolerance 필드가 다음과 같이 설정됨
PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT:
이렇게 하면 할당량 한도 내에서 카탈로그를 만드는 데 걸리는 시간이 최소화됩니다.
작은 카탈로그의 경우 inapp_products.insert 메서드를 사용할 수 있습니다.
또는 inappproducts.update 메서드를 다음과 함께 사용할 수 있습니다.
allowMissing 매개변수를 사용합니다.
이 접근 방식은 스크립트를 다시 표시할 필요 없이
문제가 발생할 경우 처음부터 다시 시작할 수 있습니다.
정기 결제 제품 만들기
정기 결제 대규모 카탈로그를 처음 만들 때는
monetization.subscriptions.batchUpdate 메서드
allowMissing 필드가 true로 설정되고 latencyTolerance 필드가 설정됨
수신자: PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT
이렇게 하면 할당량 한도 내에서 카탈로그를 만드는 데 걸리는 시간이 최소화됩니다.
소규모 정기 결제 카탈로그의 경우 Play Developer API는 다음을 제공합니다.
monetization.subscriptions.create 메서드를 사용하여 지도 가장자리에
패딩을 추가할 수 있습니다.
또는 다음을 사용하여 구독을 만들 수 있습니다.
monetization.subscriptions.update 메서드를
allowMissing 매개변수를 사용합니다.
앞의 모든 메서드는 기본 요금제와 함께 정기 결제를 만듭니다.
(Subscription 객체 내에서 제공됨) 이러한 기본 요금제는
비활성 상태입니다. 기본 요금제 관리 상태이면
monetization.subscriptions.basePlans 엔드포인트(예:
사용할 수 있도록 했습니다.
또한 monetization.subscriptions.basePlans.offers 엔드포인트
오퍼를 만들고 관리할 수 있습니다.
제품 업데이트
다음 방법을 사용하면 기존 제품을 효율적으로 수정할 수 있습니다. 추천사항이 최신 조정사항에 부합하는지 확인하세요
일회성 제품 업데이트
기존의 일회성 제품을 업데이트하는 데 세 가지 방법을 사용할 수 있습니다.
inappproducts.patch드림 패치 엔드포인트는 리소스를 부분적으로 업데이트하는 데 사용됩니다. 다시 말해 요청 본문에서 지정하는 특정 필드를 업데이트할 수 있습니다. 패치 엔드포인트는 일반적으로 엔드포인트의 일부 필드만 업데이트해야 할 때 리소스도 제공합니다inappproducts.update드림 업데이트 엔드포인트는 리소스 전체를 업데이트하는 데 사용됩니다. 다시 말해 요청 본문에서 전체 리소스 객체를 전송해야 합니다. 이 업데이트 엔드포인트는 일반적으로 리소스도 제공합니다allowMissing매개변수가true로 설정되어 있고 제공된 제품 ID가 없으면 엔드포인트에서 제품을 삽입합니다. 할 수 있습니다inappproducts.batchUpdate드림 업데이트 엔드포인트의 일괄 버전이며, 검색할 수 있습니다. 다음과 함께 사용하세요.latencyTolerance필드가 다음으로 설정됨PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT더 높은 처리량을 달성할 수 있습니다
정기 결제 제품 업데이트
기존 정기 결제를 업데이트하려면
monetization.subscriptions.patch 메서드를 사용하여 지도 가장자리에
패딩을 추가할 수 있습니다. 이 방법
다음과 같은 필수 매개변수가 사용됩니다.
packageName: 정기 결제가 속한 앱의 패키지 이름입니다.productId: 정기 결제의 고유한 제품 ID입니다.regionsVersion: 리전 구성 버전입니다.
allowMissing 매개변수를 사용하여 새 정기 결제를 만들지 않는 경우
updateMask 매개변수를 제공해야 합니다. 이 매개변수는
업데이트할 필드의 쉼표로 구분된 목록입니다.
예를 들어 정기 결제 제품의 등록정보만 업데이트하려는 경우
updateMask 매개변수에 listings 필드를 지정합니다.
monetization.subscriptions.batchUpdate를 사용하면 여러 구독을 동시에 업데이트할 수 있습니다.
다음과 같이 설정된 latencyTolerance 필드와 함께 사용합니다.
PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT 목표 달성
더 높은 처리량을 제공하도록
설계되었습니다
기본 요금제를 활성화, 비활성화, 삭제하거나 정기 결제 사용자를
최신 기본 요금제 가격 버전은 monetization.subscriptions.basePlans 엔드포인트를 사용합니다.
또한 기본 요금제를 업데이트할 수 있습니다. 을
monetization.subscriptions.basePlans.offers.patch 드림
메서드를 사용하여 축소하도록 요청합니다.
카탈로그 조정
백엔드의 콘텐츠가 바뀔 때마다 Google Play 카탈로그를 정기적으로 카탈로그를 변경하거나, 카탈로그를 관리하고, Google Play 카탈로그 외부의 데이터베이스에 액세스하는 경우가 Play의 앱 구성에 있는 카탈로그와 동기화되지 않는 경우 Console에서 긴급 수동 카탈로그 변경, 서비스 중단이 원인일 수 있습니다. 최신 데이터가 손실되었을 수도 있습니다
카탈로그 조정 프로세스를 구축하여 지속적인 불일치를 방지할 수 있습니다. 창
diff 시스템 고려사항
불일치 시스템을 감지하고 두 가지 시스템을 갖추게 되었습니다. 다음은 비교 시스템을 구축할 때 고려해야 할 몇 가지 사항으로 동기화된 카탈로그:
- 데이터 모델 이해: 첫 번째 단계는 데이터를 이해하는 것입니다. 개발자 CMS 및 Google Play Developer API의 모델을 모두 다룹니다. 여기에는 각 시스템에 저장되는 다양한 유형의 데이터를 아는 것, 그리고 어떻게 서로 다른 데이터 요소가 매핑됩니다.
- 차이점 규칙 정의: 데이터 모델을 이해했다면 diff 규칙을 정의합니다. 이 규칙은 두 줄의 데이터가 시스템을 비교합니다 예를 들어 제품 ID와 정기 결제 및 연결된 기본 요금제의 주요 속성을 비교하고 제공합니다
- diff 알고리즘 구현: diff 규칙을 정의한 후에는
diff 알고리즘을 구현해야 합니다. 이 알고리즘은
정의한 규칙에 따라 비교할 수 있습니다. 얻기 위해
Google Play의 카탈로그 데이터를 가져오는 경우
inappproducts.list님,inappproducts.batchGet,monetization.subscriptions.list및monetization.subscriptions.batchGet메서드. - 차이점 보고서 생성: 비교 알고리즘이 차이점 보고서를 생성합니다. 이 보고서는 두 시스템의 차이점을 보여줍니다.
- 차이 조정: 비교 보고서를 생성한 후에는 차이를 해결할 수 있습니다 이때 CMS의 데이터를 업데이트하거나 Developer API를 사용해 Google Play 측에서 데이터를 업데이트해야 할 수도 있습니다. GCP 서비스 계정을 통상적으로 업데이트하는 방법에 따라 확인할 수 있습니다 동기화되지 않은 제품을 조정하려면 다음에 설명된 대로 업데이트 엔드포인트를 사용하세요. 제품 업데이트 섹션을 확인할 수 있습니다
제품 지원 중단
Google Play Developer API는 개발자가 Google Play에서
제품을 지원 중단하기로 결정했습니다.
inappproducts.delete 및
inappproducts.batchDelete
일회성 제품 및
monetization.subscriptions.delete
구독 서비스를 제공합니다 다양한 시나리오에서 제품을 지원 중단해야 할 수 있음
예:
- 실수로 생성한 경우
- 기능 또는 서비스 중단
제품 지원 중단을 카탈로그 관리에 통합하는 것이 좋습니다. 전략입니다.
일회성 제품 지원 중단
Google Play Developer API로 일회성 제품을 삭제하려면 다음을 사용해야 합니다.
inappproducts.delete 드림
또는
inappproducts.batchDelete
메서드를 사용하여 축소하도록 요청합니다.
정기 결제 제품 지원 중단
구독을 삭제하려면
monetization.subscriptions.delete 드림
메서드를 사용하여 축소하도록 요청합니다. 기본 요금제를 하나 이상 설정한 후에는 정기 결제를 삭제할 수 없습니다.
활성화됨.