Skip to main content

사용자 계정과 광고 계정 비교

Ads API 사용에는 두 가지 종류의 계정이 관련됩니다: 광고 계정과 X 사용자 계정. Ads API 문서 전반에서 “계정”이라는 용어는 일반적으로 광고 계정을 의미합니다.
  • 광고 계정은 business.x.com에 등록되며 API에서 account_id로 식별됩니다. 광고 계정은 자금 조달원에 직접 연결되며, 하나 이상의 X 사용자 계정에서 “프로모션 가능한 사용자(promotable users)“로 콘텐츠를 활용합니다. 각 광고 계정은 하나 이상의 X 사용자 계정에 권한을 부여할 수 있습니다. 광고 계정, 즉 “current account”는 실행되는 거의 모든 URL에서 인라인 :account_id 파라미터로 표현됩니다.
  • X 사용자 계정(예: @AdsAPI)은 Ads API에서 user_id로 식별됩니다. 이러한 계정 중 하나 이상이 광고 계정과 연결될 수 있습니다. API에 요청하는 인증된 X 사용자 계정은 “current user”라고 합니다. 현재 사용자가 액세스할 수 있는 광고 계정 목록은 GET accounts로 확인할 수 있습니다. “프로모션 가능한 사용자”는 특정 광고 계정으로 프로모션할 수 있는 X 핸들입니다. 이에 대한 자세한 내용은 Obtaining Ads Account Access를 참고하세요.

광고 계정 액세스 방법

광고주의 계정에 대해 Ads API 요청을 하는 데 사용할 수 있는 두 가지 방법이 있습니다:
  1. 광고주를 대신하여 요청하기 (권장)
  2. 광고주 계정에 액세스 권한이 부여된 자신의 계정을 사용해 요청하기, 예를 들면 여러 계정을 지원하는 Agency.
이 문서는 이러한 옵션 간의 차이점에 대한 간략한 개요이며, multi-user login FAQ와 같은 다른 리소스와 함께 사용해야 합니다. Authorizing a request에서 설명한 대로, Ads API에 대한 모든 요청은 3-leggedOAuth 흐름을 통해 얻은 액세스 토큰을 사용하는 OAuth 1.0a Authorization 헤더가 필요합니다. 애플리케이션은 액세스 토큰을 얻기 위해 웹 기반 OAuth 흐름을 구현해야 합니다. Ads API 개발자는 X 광고주에게 로그인 자격 증명을 공유하도록 요청해서는 절대 안 됩니다. 기본적으로 각 X 개발자 애플리케이션에는 애플리케이션을 소유한 계정에 대해 Ads API 요청을 하는 데 사용할 수 있는 정적 액세스 토큰이 포함되어 있습니다. 이러한 자격 증명은 3-legged 또는 PIN 기반 OAuth 흐름 없이 단일 계정 사용 사례에 이상적입니다. 다른 X Ads 계정에 액세스하지 않는다면 다음 단계 대신 이러한 single-user 자격 증명을 사용하세요.

액세스 수준

앱 수준 권한

각 사용자는 Ads API 신청 시 요청한 액세스 수준을 가집니다: 참고: 2023년 7월 이전에 액세스를 요청한 Ads API 개발자는 다른 액세스 수준과 권한을 가질 수 있으며, OAuth 토큰이 5개로 제한될 수 있습니다. 기존 애플리케이션에 대한 추가 엔드포인트 액세스나 토큰 제한 해제에 대해서는 액세스 확대 가이드를 참조하세요.

광고 계정 수준 권한

Ads 계정에 액세스할 수 있는 각 사용자는 특정 계정 수준 권한을 가집니다: Account administrator, Ad manager, Campaign analyst, Organic analyst, Creative Manager. 계정 수준 권한에 대한 최신 문서는 business.x.com을 참조하세요. 애플리케이션은 Authenticated User Access API 엔드포인트를 통해 현재 인증된 사용자의 권한을 가져와서 액세스할 수 있는 API 엔드포인트 및 Ads 기능을 결정해야 합니다. 참고: Conversion API에 사용되는 모든 사용자 토큰은 Account administrator 또는 Ad manager 계정 수준 권한을 가진 사용자의 것이어야 합니다.

액세스 토큰 획득 방법

1. 광고주의(User) 액세스 토큰 획득

광고주의 액세스 토큰을 얻는 방법은 두 가지가 있습니다. 가장 일반적인 방법은 웹 UI 내에서 직접 3-legged OAuth 흐름을 사용하는 것입니다. 광고주에게 공개적으로 접근할 수 있는 UI를 노출하지 않는 애플리케이션은 PIN 기반 OAuth 프로세스를 구현할 수 있습니다. 사용자가 3-legged 흐름을 완료하면 애플리케이션은 API를 통해 해당 Ads 계정에 대한 요청을 할 자격 증명을 갖게 됩니다. OAuth 흐름을 통해 사용자 자격 증명을 얻는 것은 대부분의 Ads API 개발자가 광고주 계정에 액세스하기 위해 강력히 권장하는 방법입니다. 이를 통해 사용자를 대신하여 API를 호출하고 해당 사용자로 작업을 수행할 수 있습니다. 이러한 토큰은 만료되지 않지만 사용자가 언제든지 취소할 수 있습니다.

2. 자신의(개발자) 액세스 토큰 획득

이 옵션은 광고주가 business.x.com의 X UI를 통해 자신의 X Ads 계정에 자신의 @username에 대한 액세스를 부여해야 합니다(또는 @usernames). 자신의 계정에 대해 3-legged OAuth 흐름을 통해 얻은 액세스 토큰은 광고주의 X Ads 계정에 액세스할 수 있게 됩니다. 이를 통해 광고주의 OAuth 토큰이 아닌 자신의 @username의 OAuth 토큰을 사용해 API를 호출할 수 있습니다. 이 옵션의 중요한 차이점은 Post 위임/작성 권한이 자신의 @username에 부여된 경우에만 Promoted-Only Post를 만들 수 있다는 것입니다. 계정의 FULL promotable user를 대신하여 Promoted-Only Post를 만들 수 있는 액세스를 얻으려면 이 흐름에서 Post 생성 액세스도 부여받아야 합니다. 이렇게 하면 GET accounts/:account_id/authenticated_user_access 엔드포인트의 TWEET_COMPOSER 권한을 통해 액세스가 가능합니다.

이러한 방법 간의 차이

참고: 자세한 내용은 위의 자신의(개발자) 액세스 토큰 획득 섹션을 참고하세요.

샘플 사용 사례

OAuth 3-legged 웹 흐름을 통한 광고주의 액세스 토큰

표준 흐름은 웹 기반이며 3-legged 인증 OAuth 흐름을 사용합니다. 여기에 소개된 스크린샷은 https://github.com/xdevplatform/twauth-web에서 소스를 볼 수 있는 샘플의 일부입니다. 애플리케이션에서 어느 시점에 애플리케이션을 승인하기 위해 X로 리디렉션하고 싶을 것입니다.
image0
request 토큰과 함께 X로 리디렉션하면 사용자는 애플리케이션을 승인하라는 메시지를 받게 됩니다.
image1
애플리케이션을 승인하면 사용자는 request 토큰을 생성할 때 제공한 콜백 URL로 리디렉션됩니다. 이를 사용해 이 사용자에 대한 영구 액세스 토큰을 얻고 로컬에 저장하세요!
image