การเข้าถึง Google Ads API ในปี 2026: โปรเจกต์ Cloud มาแทนที่ Developer Token

ตั้งแต่วันที่ 9 กันยายน 2026 การเข้าถึง Google Ads API ถูกกำหนดตามโปรเจกต์ Google Cloud แทนที่จะกำหนดตาม Developer Token บทความนี้อธิบายสิ่งที่เปลี่ยนไป วิธีตั้งค่าการเข้าถึงในปัจจุบัน และเนื้อหาในคู่มือการตั้งค่าเดือนมิถุนายน 2026 ที่ยังคงใช้ได้

สิ่งที่เปลี่ยนไปเมื่อวันที่ 9 กันยายน 2026

คู่มือเดือนมิถุนายน 2026 เรื่องการตั้งค่า การยืนยันตัวตน และการอ่านและเขียนข้อมูลของ Google Ads API ของเราสร้างขึ้นโดยมี Developer Token เป็นแกนหลัก คือขอโทเค็นใน API Center ของบัญชี Manager ยื่นขอสิทธิ์ระดับ Basic ที่นั่น และส่งโทเค็นไปกับทุกการเรียก เมื่อสามเดือนผ่านไป รากฐานนี้ก็เปลี่ยนไป เอกสารของ Google เองระบุไว้อย่างชัดเจนในปัจจุบันว่า "Developer tokens were sunset on September 9, 2026."

การตัดสินใจเรื่องการเข้าถึงไม่ได้หายไป แต่ย้ายที่ ระดับการเข้าถึง API ของคุณถูกกำหนดโดยโปรเจกต์ Google Cloud ที่ใช้สร้างข้อมูลรับรอง OAuth และสิทธิ์การเข้าถึงที่มีอยู่เดิมถูกย้ายไปยังโปรเจกต์ Cloud โดยอัตโนมัติ การยื่นคำขอไม่ทำที่ API Center อีกต่อไป Google ขอให้นักพัฒนาไม่สมัครขอ Developer Token ที่นั่น และให้ขอสิทธิ์การเข้าถึงจากหน้า Google Ads API Overview ใน Google Cloud Console แทน คำขอระดับ Basic ที่ยังค้างอยู่ใน API Center ถูกปิดไปแล้วและต้องยื่นใหม่จาก Cloud Console

คู่มือเดือนมิถุนายนยังคงเผยแพร่ตามเดิม โดยมีหมายเหตุระบุวันที่ไว้ด้านบน บทความต่อเนื่องนี้ครอบคลุมสิ่งที่แตกต่างในปัจจุบัน และอ้างอิงกลับไปยังคู่มือในจุดที่เนื้อหาเดิมยังใช้ได้

ระดับการเข้าถึงตอนนี้เป็นของโปรเจกต์ Cloud

ระดับต่าง ๆ ยังคงคุ้นเคย โดยมีเพิ่มเข้ามาหนึ่งข้อ ขีดจำกัดด้านล่างนี้นำมาจากเอกสารระดับการเข้าถึงของ Google ณ เดือนตุลาคม 2026:

ระดับการเข้าถึง	บัญชีใช้งานจริง	จำนวนการดำเนินการต่อวัน
Test	ไม่ได้ ใช้ได้เฉพาะบัญชีทดสอบ	15,000
Explorer	ได้	2,880 สำหรับบัญชีใช้งานจริง
Basic	ได้	15,000
Standard	ได้	ไม่มีเพดานทั่วไป (บริการแต่ละรายการอาจยังถูกจำกัดได้)

Explorer เป็นจุดเริ่มต้นที่ใช้งานได้จริง ตามที่ Google ระบุ คำขอที่ยื่นจาก Cloud Console จะได้รับการตรวจสอบอัตโนมัติ และในกรณีส่วนใหญ่จะได้รับการยกระดับเป็นสิทธิ์ Explorer ซึ่งเพียงพอสำหรับรายงานภายในและระบบอัตโนมัติขนาดเล็กบนบัญชีของคุณเอง ส่วน Basic และ Standard ยังต้องผ่านการตรวจสอบ และทั้งสองระดับมีข้อกำหนดเบื้องต้นใหม่ คือการยืนยันแบรนด์ของโปรเจกต์ Google Cloud นอกจากนี้ Standard ยังมีการตรวจสอบด้วยตนเองเพิ่มเติม

ปัญหาคือการยืนยันแบรนด์มักถูกมองข้ามเมื่อการตั้งค่าทางเทคนิคใช้งานได้แล้ว สคริปต์ที่ทำงานด้วยสิทธิ์ Explorer จะทำงานได้ถูกต้องจนกว่าจะถึงขีดจำกัดรายวัน ดังนั้นควรวางแผนการยืนยันไว้ก่อนที่ปริมาณการใช้งานจะมาถึง ไม่ใช่หลังจากนั้น

การตั้งค่าการเข้าถึงในปัจจุบัน

ขั้นตอนสั้นกว่าเดิม เพราะโปรเจกต์ Cloud เป็นที่เดียวที่ใช้กำหนดการเข้าถึง:

สร้างโปรเจกต์ Google Cloud หรือเลือกโปรเจกต์ที่จะเป็นเจ้าของการเชื่อมต่อ Google Ads ของคุณ ขั้นตอนนี้ไม่จำเป็นต้องเปิดการเรียกเก็บเงิน
เปิดใช้งาน Google Ads API ใน API Library ของโปรเจกต์
สร้างข้อมูลรับรองในโปรเจกต์เดียวกันนี้ ได้แก่ OAuth client สำหรับการเข้าถึงแบบอิงผู้ใช้ หรือบัญชีบริการที่มีคีย์ JSON
ยื่นขอสิทธิ์การเข้าถึงที่หน้า Google Ads API Overview ใน Cloud Console และดำเนินการยืนยันแบรนด์ให้เสร็จสิ้นหากต้องการสิทธิ์ Basic หรือ Standard

ขั้นตอนที่ 3 คือจุดสำคัญ เนื่องจากสิทธิ์การเข้าถึงตามโปรเจกต์ที่ออกข้อมูลรับรอง OAuth ข้อมูลรับรองจากโปรเจกต์อื่นที่ไม่เกี่ยวข้องจึงไม่ได้รับระดับการเข้าถึงที่คุณยื่นขอไว้ ทีมที่สร้าง test client แยกในหลายโปรเจกต์มาตลอดหลายปีควรรวมให้เป็นโปรเจกต์เดียวก่อนจะพึ่งพาสิทธิ์การใช้งานจริง

รายละเอียด OAuth จากคู่มือเดือนมิถุนายน ได้แก่ scope adwords การเข้าถึงแบบออฟไลน์เพื่อรับ refresh token และสาเหตุที่ refresh token หยุดทำงาน ไม่เปลี่ยนแปลงและยังใช้ได้

การยืนยันตัวตนและการกำหนดค่า

ในทางปฏิบัติ Developer Token กลายเป็นตัวเลือกเสริม Google ระบุว่าคุณยังสามารถส่งโทเค็นนี้ในส่วนหัวของคำขอได้ แต่เซิร์ฟเวอร์จะเพิกเฉยต่อโทเค็น และคาดว่า API เวอร์ชันหลักในอนาคตจะปฏิเสธโทเค็นนี้ ไลบรารี Python ทางการเวอร์ชัน 32.0.0 ได้นำการตรวจสอบที่บังคับให้มีโทเค็นในไฟล์กำหนดค่าออกแล้ว

ดังนั้น google-ads.yaml ขั้นต่ำสำหรับ OAuth แบบอิงผู้ใช้จึงเป็นดังนี้:

client_id: YOUR_CLIENT_ID.apps.googleusercontent.com
client_secret: YOUR_CLIENT_SECRET
refresh_token: YOUR_REFRESH_TOKEN
login_customer_id: "1234567890"
use_proto_plus: true

สำหรับบัญชีบริการ json_key_file_path จะมาแทนคีย์ OAuth ทั้งสามรายการ และอาจใช้ร่วมกับ impersonated_email ได้ ทุกคีย์ยังตั้งค่าเป็นตัวแปรสภาพแวดล้อมที่มีคำนำหน้า GOOGLE_ADS_ ได้ด้วย เช่น GOOGLE_ADS_JSON_KEY_FILE_PATH ซึ่งเป็นตัวเลือกที่เหมาะสมกว่าบนเซิร์ฟเวอร์ เพราะไฟล์กำหนดค่ามักไปอยู่ในข้อมูลสำรองและรีโพซิทอรี

login_customer_id ยังคงมีความหมายเดิม เมื่อเข้าถึงบัญชีลูกค้าผ่านบัญชี Manager ค่านี้จะระบุบัญชี Manager นั้น (ตัวเลขเท่านั้น ไม่มีขีดกลาง) หากไม่มีค่านี้ การเรียกดังกล่าวจะล้มเหลวด้วย USER_PERMISSION_DENIED

เวอร์ชันและไลบรารี Python

การตรึงเวอร์ชันควรได้รับความสนใจมากกว่าที่เป็นอยู่โดยทั่วไป คู่มือเดือนมิถุนายนใช้ version="v22" และเวอร์ชันนั้นไม่มีให้ใช้งานแล้ว เพราะไลบรารี Python google-ads รุ่น 33.0.0 ได้นำ v21 และ v22 ออก ณ เดือนตุลาคม 2026 API เวอร์ชันปัจจุบันคือ v26 (เปิดตัวเมื่อวันที่ 14 ตุลาคม 2026) และไลบรารี 34.0.0 เพิ่มการรองรับเวอร์ชันนี้

from google.ads.googleads.client import GoogleAdsClient

client = GoogleAdsClient.load_from_storage("google-ads.yaml", version="v26")

การตรึงเวอร์ชันอย่างชัดเจนยังคงเป็นค่าเริ่มต้นที่ถูกต้อง ในความเป็นจริง client ที่ไม่ได้ตรึงเวอร์ชันจะเปลี่ยนพฤติกรรมโดยไม่แจ้งเมื่อมีการอัปเกรดไลบรารีครั้งถัดไป และ Google เลิกใช้ API เวอร์ชันต่าง ๆ ตามกำหนดการที่ประกาศไว้ การตรึงเวอร์ชันอย่างน้อยก็ทำให้การเลิกใช้งานนั้นเป็นการเปลี่ยนแปลงที่วางแผนไว้ ไม่ใช่เรื่องที่น่าประหลาดใจ

การประกาศโฆษณาทางการเมืองในสหภาพยุโรป

มีข้อกำหนดหนึ่งที่ส่งผลกระทบต่อการเชื่อมต่อที่มีอยู่เดิมจำนวนมาก คือฟิลด์ contains_eu_political_advertising บนทรัพยากร Campaign ใน API เวอร์ชันก่อน v26 แคมเปญใหม่ทุกแคมเปญต้องประกาศฟิลด์นี้ ตั้งแต่วันที่ 1 เมษายน 2026 การเรียก mutate จะล้มเหลวด้วย EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED เมื่อบัญชียังมีแคมเปญที่ไม่ได้ประกาศ เวอร์ชัน 26 ผ่อนคลายข้อกำหนดนี้: ฟิลด์เป็นตัวเลือกสำหรับแคมเปญที่ไม่ได้กำหนดเป้าหมายสหภาพยุโรปโดยตรง

การประกาศอย่างชัดเจนใช้เพียงหนึ่งบรรทัด และช่วยให้โค้ดสร้างแคมเปญใช้ได้ในทุกเวอร์ชัน:

campaign.contains_eu_political_advertising = (
    client.enums.EuPoliticalAdvertisingStatusEnum.DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING
)

สิ่งที่ยังใช้ได้จากคู่มือเดือนมิถุนายน

เนื้อหาส่วนใหญ่ของคู่มือเดิมเป็นเรื่องการทำงานกับ API ไม่ใช่การเข้าถึง API และส่วนนั้นยังคงใช้ได้ดี การอ่านข้อมูลด้วย GAQL รูปแบบ validate_only สำหรับทดสอบการเขียนข้อมูลอย่างปลอดภัย การจัดการ update_mask อย่างชัดเจน และการแยกบัญชี Manager โปรเจกต์ Cloud และบัญชีเป้าหมายออกจากกัน ล้วนใช้ได้ตามที่อธิบายไว้ สิ่งที่ใช้ไม่ได้แล้วคือเส้นทางการเข้าถึง ได้แก่ API Center การยื่นขอ Developer Token และแผนภาพสถาปัตยกรรมที่อิงโทเค็น

การเชื่อมต่อที่ดี ไม่ว่าจะเป็นสคริปต์ภายในหรือเครื่องมือสำหรับลูกค้า จะถือว่าการเข้าถึงเป็นการกำหนดค่าที่เป็นของโปรเจกต์ Cloud ที่ตั้งชื่อชัดเจนเพียงโปรเจกต์เดียว นั่นเป็นแนวปฏิบัติที่สมเหตุสมผลมาก่อนเดือนกันยายน 2026 และนับจากนั้น นี่คือวิธีที่ Google กำหนดการเข้าถึงตั้งแต่ต้น