Data Manager API รองรับ call conversion ของ Google Ads ผลวินิจฉัยรายแถว และ lead_id

Google เพิ่มการรองรับ call conversion ของ Google Ads ใน Data Manager API เมื่อวันที่ 4 พฤศจิกายน 2569 ตามโพสต์บน Google Ads Developer Blog โดย Lindsey Volta ในนามทีม Data Manager API รุ่นเดียวกันนี้ยังเพิ่มฟิลด์ record_indices ในผลวินิจฉัยคำขอ ทำให้นักพัฒนาเห็นได้ว่าแถวไหนในไฟล์อัปโหลดล้มเหลวหรือมีคำเตือน และเพิ่มตัวระบุใหม่ชื่อ lead_id สำหรับคอนเวอร์ชันจากฟอร์มลีด แต่ Google ระบุว่าการระบุแหล่งที่มา (attribution) ด้วย lead_id และ match_id "isn't available yet"

อะไรเปลี่ยนในรุ่นวันที่ 4 พฤศจิกายน

โพสต์บน Google Ads Developer Blog อธิบายการเปลี่ยนแปลงสามเรื่อง แต่ละเรื่องเกี่ยวกับคนต่างกลุ่ม ได้แก่ ผู้ลงโฆษณาที่ปิดการขายทางโทรศัพท์ ทีมที่อัปโหลด offline conversion จำนวนมาก และผู้ลงโฆษณาที่ใช้ฟอร์มลีด

Call conversion: ส่งอย่างไร

Call conversion ใช้วัดว่าโฆษณาทำให้เกิดการโทรเมื่อไร และการโทรนั้นนำไปสู่การกระทำที่มีมูลค่าต่อธุรกิจหรือไม่ ที่ผ่านมาการอัปโหลดผลลัพธ์ของการโทรทำผ่าน Google Ads API ตอนนี้ Data Manager API รับข้อมูลนี้ได้ด้วย

ตามโพสต์บล็อก อีเวนต์จะมีฟิลด์ใหม่ชื่อ call_info ซึ่งมี start_timestamp เก็บเวลาที่เริ่มสาย และระบุตัวผู้โทรด้วยเบอร์โทรที่แฮชแล้วใน user_data คู่มือนักพัฒนาของ Google สำหรับการส่ง call event ให้รายละเอียดเพิ่มดังนี้

• ปลายทางคือ conversion action ของ Google Ads ประเภท UPLOAD_CALLS ซึ่ง Google ระบุว่าในหน้าจอ Google Ads จะแสดงแหล่งที่มาเป็น "Call from Ads"
• บัญชีที่รับข้อมูลคือบัญชี Google Ads ที่เป็นเจ้าของ conversion action ใส่เป็นรหัสลูกค้า 10 หลักโดยไม่มีขีด
• eventTimestamp เป็นฟิลด์บังคับ และต้องไม่เร็วกว่า callInfo.startTimestamp
• userData เป็นฟิลด์บังคับ ต้องมีเบอร์โทรของผู้โทรในรูปแบบ E.164 ที่แฮชด้วย SHA-256 และเข้ารหัสแล้ว ตัวอย่างของ Google ใช้แฮชแบบ hex
• conversionValue, currency, eventSource, customVariables และฟิลด์ consent ตาม DMA เป็นตัวเลือก ตัวอย่างตั้ง eventSource เป็น PHONE
• กรณีนี้ไม่รองรับการเข้ารหัส (encryption) จึงไม่ควรตั้งฟิลด์ encryptionInfo

คู่มือยังอธิบายเส้นทางสำหรับ data partner ด้วย คือใช้ข้อมูลรับรองจากบัญชี data partner ส่ง call conversion ให้บัญชีผู้ลงโฆษณาที่มี partner link ได้ หลังจาก Google อนุมัติ partner แล้ว

ขั้นตอนการทำงาน

ภาพรวมของ Google มีสี่ขั้น: เตรียมปลายทาง เตรียมข้อมูลอีเวนต์และตัวระบุ (ปรับรูปแบบและแฮชข้อมูลติดต่อด้วย SHA-256) สร้างและส่งคำขอ events.ingest จากนั้นตรวจสถานะการประมวลผลและผลวินิจฉัยด้วย requestStatus.retrieve Google แนะนำให้ส่งแบบ validateOnly เป็น true ก่อน เพื่อจับข้อผิดพลาดแบบ fast-fail ก่อนส่งข้อมูลจริง

ย้ายจาก Google Ads API: อะไรต่างกัน

บล็อกลิงก์ไปยังคู่มือ "Upgrade call conversions from the Google Ads API" ซึ่งเปรียบเทียบสอง API สำหรับ call conversion ความต่างเหล่านี้สำคัญกับใครก็ตามที่มีระบบเชื่อมต่ออยู่แล้ว

มีสองแถวที่เปลี่ยนการทำงานประจำวันจริง เรื่องแรก เบอร์โทรต้องถูกแฮชก่อนออกจากระบบของคุณ ระบบที่เคยส่งเบอร์ดิบจึงต้องเพิ่มขั้นตอนปรับรูปแบบและแฮช เรื่องที่สอง การจัดการรายการซ้ำกลับด้าน โค้ดที่เคยอาศัยข้อผิดพลาด CALL_CONVERSION_ALREADY_EXISTS เพื่อรู้ว่าส่งซ้ำ จะไม่ได้รับสัญญาณนั้นอีก เพราะรายการซ้ำจะถูกรับไว้แล้ว Google Ads ตัดออกเองหลังประมวลผล

คู่มือระบุว่าทั้งสอง API ใช้โควตาระดับโปรเจกต์และมีขีดจำกัดต่อคำขอ ทั้งบล็อกและคู่มือไม่ได้ระบุวันที่จะเลิกรองรับการอัปโหลด call conversion ผ่าน Google Ads API

record_indices: หาแถวที่ล้มเหลว

บล็อกของ Google ชี้ประเด็นที่ทีมนำเข้า offline conversion รู้กันดีว่า คำขอที่ส่งสำเร็จไม่ได้แปลว่าทุกเรคคอร์ดถูกประมวลผล ก่อนรุ่นนี้ ผลวินิจฉัยให้แค่จำนวนตามเหตุผล ตอนนี้ ErrorCount และ WarningCount แต่ละรายการมี record_indices ที่บอกตำแหน่ง (เริ่มนับจาก 0) ของเรคคอร์ดที่ได้รับผลกระทบในคำขอต้นฉบับ

ตัวอย่างของ Google: ค่า record_indices เป็น [0, 3] บน ErrorCount ที่มีเหตุผล PROCESSING_ERROR_REASON_CLICK_NOT_FOUND หมายความว่าอีเวนต์แรกและอีเวนต์ที่สี่ในคำขอล้มเหลวด้วยเหตุผลนั้น นักพัฒนาใช้ตำแหน่งนี้คู่กับเหตุผลเพื่อแก้เรคคอร์ดเหล่านั้นแล้วส่งใหม่ได้

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

สำหรับทีมที่เก็บล็อกการอัปโหลดแต่ละชุด สิ่งที่ต้องทำเพิ่มคือรักษาลำดับเรคคอร์ดตามที่ส่ง เพื่อให้ตำแหน่งจากผลวินิจฉัยย้อนกลับไปหาแถวใน CRM เลขที่คำสั่งซื้อ หรือบันทึกการโทรได้

lead_id: ตัวระบุใหม่ แต่ attribution ยังไม่มา

ฟิลด์ lead_id อยู่ใน ad_identifiers และเก็บ ID ที่ Google สร้างขึ้นเมื่อผู้ใช้ส่งฟอร์มลีด Google ระบุว่าใส่ lead_id และฟิลด์ match_id ที่มีอยู่แล้วเป็นตัวระบุอีเวนต์ได้ สำหรับอีเวนต์ offline และอีเวนต์จากหลายแหล่งที่ส่งไปยังปลายทาง Google Ads, Floodlight และ Google Analytics

ข้อจำกัดเขียนไว้ชัดในโพสต์ว่า attribution ด้วย lead_id และ match_id ยังใช้ไม่ได้ ระหว่างนี้ Google ให้ใส่ตัวระบุอื่นด้วยเพื่อให้อีเวนต์ถูกระบุแหล่งที่มา จากที่ Google เขียน การส่ง lead_id อย่างเดียวในตอนนี้จะไม่ทำให้คอนเวอร์ชันถูก attribute

สิ่งที่แหล่งข่าวไม่ได้บอก

• ไม่มีวันที่ที่ attribution ด้วย lead_id และ match_id จะใช้ได้
• ไม่มีวันที่เลิกรองรับการอัปโหลด call conversion ผ่าน Google Ads API
• บล็อกไม่ได้อธิบายว่า Google จับคู่สายที่อัปโหลดกับการคลิกหรือการเห็นโฆษณาอย่างไร คู่มืออธิบายเฉพาะฟิลด์ ไม่ได้อธิบายตรรกะการจับคู่
• ไม่มีการระบุข้อจำกัดด้านประเทศสำหรับการเปลี่ยนแปลงทั้งสามเรื่อง
• ไม่มีตัวเลขผลลัพธ์หรืออัตราการจับคู่

ใครได้รับผลกระทบ

ผู้ลงโฆษณาที่อัปโหลด call conversion ผ่าน Google Ads API อยู่แล้วได้รับผลกระทบโดยตรงที่สุด เพราะ Google เผยแพร่เส้นทางการย้ายแล้ว และกติกาเรื่องการแฮชกับรายการซ้ำต่างกัน ทีมที่อัปโหลด offline conversion ใด ๆ ผ่าน Data Manager API ได้ผลวินิจฉัยรายแถวทันที ไม่ต้องตั้งค่าอะไรเพิ่มนอกจากอ่านฟิลด์ใหม่ ผู้ลงโฆษณาที่ใช้ฟอร์มลีดเริ่มส่ง lead_id ได้ แต่ตอนนี้ควรมองเป็นตัวระบุเสริม ไม่ใช่ตัวแทนของตัวระบุที่ใช้ทำ attribution อยู่

ผู้ลงโฆษณาที่ติดตามการโทรผ่านรายงานการโทรของ Google อย่างเดียว โดยไม่ได้อัปโหลดผลลัพธ์จากระบบของตัวเอง ไม่ได้รับผลจากการเปลี่ยนแปลงเรื่อง call conversion

ความหมายสำหรับนักการตลาดไทย

ธุรกิจหาลีดในไทยจำนวนมาก เช่น คลินิก โครงการอสังหาริมทรัพย์ สถาบันการศึกษา และธุรกิจบริการ ปิดการขายทางโทรศัพท์ ถ้าสายที่มาจากโฆษณากลายเป็นการจองหรือยอดขาย การส่งผลลัพธ์นั้นกลับเข้า Google Ads จะให้สัญญาณกับ Smart Bidding ได้ดีกว่าการนับแค่ว่ามีสายเข้า ตอนนี้ Data Manager API เป็นอีกเส้นทางหนึ่งสำหรับงานนี้

• รูปแบบเบอร์โทร คู่มือกำหนดให้ใช้รูปแบบ E.164 ก่อนแฮช สำหรับเบอร์ไทยคือใส่รหัสประเทศ +66 และตัดเลข 0 ตัวแรกออก ถ้ารูปแบบก่อนแฮชไม่ตรง ค่าแฮชก็จะไม่ตรง
• ตรวจผลวินิจฉัยหลังอัปโหลดทุกครั้ง เมื่อมี record_indices แถวที่ล้มเหลวจะย้อนกลับไปหาการจองหรือคำสั่งซื้อที่เกี่ยวข้องได้ ถ้าเจอเหตุผล CLICK_NOT_FOUND ซ้ำ ๆ ควรตรวจหาสาเหตุ ไม่ควรปล่อยผ่าน
• ต้องใช้งานนักพัฒนา นี่คือการเปลี่ยนแปลงระดับ API ธุรกิจที่ใช้ตัวเชื่อม CRM หรือเครื่องมือจัดการแท็ก ควรถามผู้ให้บริการว่ามีแผนรองรับ call conversion ผ่าน Data Manager API หรือไม่
• อย่าพึ่ง lead_id ตอนนี้ ให้ส่งตัวระบุที่ใช้ทำ attribution อยู่ต่อไป

บริการดูแลโฆษณา Google Ads ของ Relevant Audience ครอบคลุมการตั้งค่าคอนเวอร์ชันและสัญญาณสำหรับการประมูล ส่วน บริการ Google Analytics 4 ครอบคลุมการเชื่อมข้อมูลวัดผลระหว่างเว็บไซต์ CRM และเครื่องมือของ Google

เช็กลิสต์สำหรับนักพัฒนาและเจ้าของบัญชี

1. ลิสต์ทุกจุดที่อัปโหลดผลลัพธ์การโทรอยู่ และใช้ API ตัวไหน
2. อ่านคู่มือการย้าย call conversion ของ Google และยืนยันขั้นตอนแฮชเบอร์โทร
3. ทบทวนโค้ดที่เคยพึ่งข้อผิดพลาด CALL_CONVERSION_ALREADY_EXISTS
4. ทดสอบด้วย validateOnly ก่อนส่งข้อมูลจริง
5. เก็บลำดับการอัปโหลดไว้ เพื่อให้ record_indices ย้อนกลับไปหาเรคคอร์ดต้นทางได้
6. ติดตามคำเตือนควบคู่กับข้อผิดพลาด
7. เพิ่ม lead_id เมื่อมี โดยส่งคู่กับตัวระบุที่ใช้อยู่แล้ว

คำถามที่พบบ่อย

ส่ง call conversion ของ Google Ads ผ่าน Data Manager API ได้หรือไม่

ได้ Google เพิ่มการรองรับ call conversion ใน Data Manager API ในรุ่นที่ประกาศเมื่อวันที่ 4 พฤศจิกายน 2569 อีเวนต์ใช้ฟิลด์ใหม่ call_info พร้อม start_timestamp และเบอร์ผู้โทรที่แฮชด้วย SHA-256 ส่งไปยัง conversion action ประเภท UPLOAD_CALLS

record_indices แสดงอะไร

record_indices แสดงตำแหน่ง (เริ่มนับจาก 0) ของเรคคอร์ดในคำขอต้นฉบับที่มีข้อผิดพลาดหรือคำเตือนนั้น ค่า [0, 3] บนข้อผิดพลาดหมายถึงเรคคอร์ดแรกและเรคคอร์ดที่สี่ล้มเหลวด้วยเหตุผลนั้น

lead_id ใช้ทำ attribution ได้แล้วหรือยัง

ยังไม่ได้ Google ระบุว่า attribution ด้วย lead_id และ match_id ยังไม่พร้อมใช้งาน นักพัฒนาควรส่งตัวระบุอื่นต่อไปเพื่อให้คอนเวอร์ชันถูก attribute

ต้องย้ายการอัปโหลด call conversion ออกจาก Google Ads API หรือไม่

แหล่งข่าวไม่ได้บอกว่าต้องย้าย Google เผยแพร่คู่มือการย้ายแล้ว แต่ทั้งโพสต์บล็อกและคู่มือไม่มีกำหนดเส้นตายหรือวันเลิกรองรับเส้นทาง Google Ads API

ใช้กับบัญชีในไทยได้หรือไม่

โพสต์บล็อกและคู่มือไม่ได้ระบุข้อจำกัดด้านประเทศ ฟิลด์ที่อธิบายใช้กับบัญชี Google Ads โดยทั่วไป แต่ Google ไม่ได้ให้รายชื่อประเทศ

สรุป

Data Manager API รุ่นวันที่ 4 พฤศจิกายน ย้ายการอัปโหลด call conversion มาอยู่บนท่อข้อมูลรุ่นใหม่ของ Google เพิ่มรายละเอียดข้อผิดพลาดและคำเตือนรายแถวที่ทีมนำเข้า offline conversion ขาดมานาน และเปิดตัว lead_id ก่อนที่ attribution จะพร้อม งานจริงอยู่ที่การแฮชเบอร์โทร การจัดการรายการซ้ำแบบใหม่ และการอ่านผลวินิจฉัยทีละแถว หากต้องการให้ช่วยทบทวนว่า offline conversion และ call conversion ส่งเข้าระบบประมูลของ Google Ads อย่างไร ทีม Relevant Audience ยินดีช่วยดู