สรุปสั้น ๆ (TL;DR)
- Microsoft เผยแพร่เอกสาร Conversions API บน Microsoft Learn ระบุ ms.date 4 สิงหาคม 2569 และอัปเดตล่าสุด 15 สิงหาคม 2569 โดย Search Engine Land หยิบมารายงานเมื่อ 18 สิงหาคม 2569
- อีเวนต์ส่งแบบ POST ไปที่ https://capi.uet.microsoft.com/v1/{tagId}/events พร้อม Bearer token ส่งได้ชุดละไม่เกิน 1,000 รายการ และ eventTime ต้องอยู่ภายใน 7 วันล่าสุด
- ทุกอีเวนต์ต้องมีตัวระบุอย่างน้อยหนึ่งค่าจาก anonymousId, externalId, em, ph, msclkid, idfa หรือ gaid อีเมลต้องแฮช SHA-256 หลังทำให้เป็นมาตรฐาน และเบอร์โทรใช้รูปแบบ E.164
- API อยู่ในสถานะเบตาและยังไม่เปิดให้ทุกบัญชี Microsoft วางตำแหน่งให้ทำงานคู่กับแท็ก UET ไม่ใช่มาแทนที่ โดยใช้ eventId ร่วมกันเพื่อตัดข้อมูลซ้ำ
Microsoft เผยแพร่เอกสารฉบับเต็มของ Microsoft Advertising Conversions API บน Microsoft Learn พร้อม endpoint ที่ใช้งานได้จริง วิธีสร้างโทเคนสองทาง เพดานส่งได้ 1,000 อีเวนต์ต่อชุด และข้อบังคับให้แฮชข้อมูลระบุตัวตนของลูกค้าด้วย SHA-256 เอกสารระบุ ms.date เป็นวันที่ 4 สิงหาคม 2026 และอัปเดตล่าสุด 15 สิงหาคม 2026 โดยแหล่งข้อมูลคือ Microsoft Learn ส่วน Search Engine Land เป็นผู้หยิบมารายงานเมื่อ 18 สิงหาคม 2026
มีสองเรื่องที่ต้องเคลียร์ก่อนใครจะเริ่มวางแผนงาน หนึ่งคือ API นี้อยู่ในสถานะเบตาและยังไม่เปิดให้ทุกบัญชี ขั้นแรกจึงเป็นการเข้าไปดูว่าบัญชีของตัวเองมีตัวเลือกนี้หรือยัง ไม่ใช่การเริ่มประเมินขอบเขตงานพัฒนา สองคือ Microsoft วางตำแหน่ง Conversions API ให้ทำงานคู่กับแท็ก UET ไม่ใช่มาแทนที่ ดังนั้นอย่าถอดแท็ก UET ออกเพราะข่าวนี้
Microsoft ปล่อยอะไรออกมา
Conversions API ของ Microsoft Advertising ตามเอกสารบน Microsoft Learn ที่อัปเดตล่าสุด 15 สิงหาคม 2026 รับอีเวนต์ Conversion แบบเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ที่ https://capi.uet.microsoft.com/v1/{tagId}/events โดยยืนยันตัวตนด้วยเฮดเดอร์ Authorization แบบ Bearer token
การสร้างโทเคนมีสองทาง ทางแรกคือผ่านหน้าจอ Microsoft Advertising ในส่วน UET โดยเข้าไปที่การตั้งค่าแท็ก เลือกตัวเลือกใช้งาน Conversions API แล้วคัดลอกโทเคนออกมา ทางที่สองคือผ่าน Campaign Management API ด้วยการเรียก POST /CampaignManagement/v13/UetTagAuthKey/Query ทางที่สองคือทางที่สำคัญกับงานอัตโนมัติ เพราะโทเคนที่คนคัดลอกด้วยมือจากหน้าจอคือโทเคนที่ต้องมีคนจำได้ว่าถึงเวลาต้องหมุนเปลี่ยน
ประเภทอีเวนต์ที่รองรับมีสองแบบคือ pageLoad และ custom ทุกอีเวนต์ต้องมี eventTime เป็น UNIX UTC timestamp และเวลานั้นต้องอยู่ภายใน 7 วันล่าสุด อีเวนต์ที่เก่ากว่านั้นอยู่นอกขอบเขตที่ API รับ ซึ่งเป็นเพดานตายตัวว่างานย้อนหลังหรือการส่งออกข้อมูลจาก CRM รอบกลางคืนจะดีเลย์ได้นานแค่ไหน
การระบุตัวตน อย่างน้อยหนึ่งค่า และต้องแฮชตามสูตรของ Microsoft เป๊ะ
เอกสาร Conversions API ของ Microsoft กำหนดให้ทุกอีเวนต์ต้องมีอ็อบเจ็กต์ userData ที่บรรจุตัวระบุอย่างน้อยหนึ่งค่าจาก anonymousId, externalId, em, ph, msclkid, idfa หรือ gaid หนึ่งค่าคือขั้นต่ำ ไม่ใช่เป้าหมายที่ควรตั้งไว้
การแฮชอีเมลมีลำดับการทำให้เป็นมาตรฐานก่อนแฮช และการข้ามขั้นตอนใดขั้นตอนหนึ่งจะได้ค่าแฮชที่ไม่มีวันจับคู่ได้เลย ขั้นตอนตามที่ Microsoft ระบุคือ ตัดช่องว่างหัวท้ายออก ลบจุดในส่วนชื่อผู้ใช้ ตัด alias ที่ตามหลังเครื่องหมายบวก แปลงทั้งหมดเป็นตัวพิมพ์เล็ก แล้วจึงแฮชด้วย SHA-256 และเข้ารหัสเป็นเลขฐานสิบหกตัวพิมพ์เล็ก ส่วนเบอร์โทรศัพท์ต้องแปลงเป็นรูปแบบ E.164 ก่อน
วิเคราะห์ ลำดับการทำให้เป็นมาตรฐานตรงนี้คือจุดที่การเชื่อมต่อฝั่งเซิร์ฟเวอร์มักพังแบบเงียบ ๆ อีเมลที่เข้ามาใน CRM เป็น First.Last+shop@example.com กับที่พิมพ์มาเป็น firstlast@example.com คือคนเดียวกัน และจะได้ค่าแฮชเดียวกันก็ต่อเมื่อทำครบทุกขั้นตามลำดับ ถ้าพลาดขั้นตอนลบจุด ค่าแฮชสองอันจะแยกจากกัน อีเวนต์ยังส่งสำเร็จ API ไม่คืนข้อผิดพลาดใด ๆ และอัตราการจับคู่ก็แย่อยู่เงียบ ๆ ไม่มีสัญญาณความล้มเหลวให้ตั้งการแจ้งเตือน โค้ดส่วนนี้จึงควรมีเทสต์ที่ทดสอบกับตัวอย่างขั้นตอนของ Microsoft เอง ไม่ใช่แค่ให้คนอ่านผ่านตา
เคสที่กระอักกระอ่วนคือธุรกิจที่เก็บได้แค่เบอร์โทรศัพท์ ซึ่งตรงกับผู้ลงโฆษณาสาย lead generation จำนวนมาก การมีตัวระบุหนึ่งค่าก็เพียงพอที่จะส่งอีเวนต์ได้ ธุรกิจที่มีแต่เบอร์จึงผ่านเงื่อนไข แต่สิ่งที่ไม่ควรคาดหวังคือคุณภาพการจับคู่เท่ากับผู้ลงโฆษณาที่ส่ง msclkid มาพร้อมอีเมลที่แฮชแล้ว เพราะเบอร์ที่แปลงเป็น E.164 จะจับคู่ได้เฉพาะกรณีที่ Microsoft มีเบอร์นั้นผูกกับผู้ใช้อยู่ การส่งตัวระบุน้อยกว่าทำได้ แต่ไม่ได้แปลว่าไม่มีต้นทุน
การส่งเป็นชุด และสิ่งที่เกิดขึ้นเมื่อมีอีเวนต์เดียวผิดรูปแบบ
Conversions API ของ Microsoft รับได้สูงสุด 1,000 อีเวนต์ต่อหนึ่งชุด และตามเอกสารที่เผยแพร่ในเดือนสิงหาคม 2026 ระบบจะปฏิเสธทั้งชุดถ้ามีอีเวนต์ใดไม่ผ่านการตรวจสอบ เว้นแต่คำขอนั้นตั้งค่า continueOnValidationError เป็น true
ค่าเริ่มต้นแบบทั้งหมดหรือไม่เอาเลยเป็นการตัดสินใจเชิงออกแบบที่ควรเคารพมากกว่าจะรีบปิด เพราะการล้มทั้งชุดแปลว่ามันดังพอให้มีคนได้ยิน ชุดพัง มีคนเห็น อีเวนต์ที่ผิดถูกแก้ ส่วนการตั้ง continueOnValidationError เป็น true ทำให้ท่อส่งข้อมูลใจดีขึ้นและความล้มเหลวมองไม่เห็น ฟิลด์ที่หยุดมีค่ามาตั้งแต่สามสัปดาห์ก่อนจะกินยอด Conversion ไปเรื่อย ๆ โดยไม่มีอะไรในล็อกสะดุดตา ถ้าจะเปิดใช้ ต้องเก็บจำนวนอีเวนต์ที่ถูกปฏิเสธและตั้งแจ้งเตือนไว้ ไม่อย่างนั้นแฟล็กนี้ก็เป็นแค่วิธีซ่อนข้อมูลที่หายไป
การตัดข้อมูลซ้ำ eventId ที่ใช้ร่วมกันคือชิ้นส่วนที่รับน้ำหนักทั้งหมด
Microsoft กำหนดให้ส่ง eventId ค่าเดียวกันผ่านทั้งแท็ก UET และ Conversions API สำหรับ Conversion เดียวกัน เพื่อให้สองเส้นทางถูกตัดข้อมูลซ้ำเหลือเป็น Conversion เดียวที่ถูกบันทึก
กลไกนั้นเรียบง่าย แต่ผลของการทำพลาดไม่เรียบง่ายเลย Conversion ที่ยิงฝั่งไคลเอนต์ผ่าน UET แล้วยังถูกส่งฝั่งเซิร์ฟเวอร์ผ่าน CAPI ด้วย คือการซื้อครั้งเดียวที่ถูกเห็นสองครั้ง ถ้าไม่มีคีย์ร่วมกัน แพลตฟอร์มไม่มีทางรู้ และบัญชีจะรายงานเป็นสอง ยอด Conversion ที่พองตัวไหลเข้าสู่ระบบประมูลโดยตรง กลยุทธ์การประมูลที่ปรับตามสัญญาณซึ่งถูกนับซ้ำจะจ่ายแพงเกินจริงในกลุ่มที่ทั้งสองเส้นทางทำงานสำเร็จพร้อมกัน ซึ่งมักเป็นกลุ่มผู้ใช้ที่ตั้งใจซื้อมากที่สุด eventId จึงไม่ใช่เรื่องความเป็นระเบียบ แต่เป็นสิ่งที่กันไม่ให้การแก้ปัญหาการวัดผลกลายเป็นปัญหาการประมูล
พิกเซล ID Sync และจุดที่มันเป็นข้อบังคับ
เอกสารของ Microsoft กำหนดให้ยิงพิกเซล ID Sync ฝั่งไคลเอนต์ไปที่ https://c.bing.com/c.gif พร้อมพารามิเตอร์ Red3 ในรูปแบบ BACID_<CID> และ VID สำหรับการทำ dynamic remarketing และแนะนำให้ใช้เพื่อคุณภาพการวัดผลโดยทั่วไป โดยค่า VID ต้องตรงกับ anonymousId ที่ส่งไปในอีเวนต์ของ Conversions API
นี่คือรายละเอียดที่มักเล่นงานทีมที่เข้าใจว่า API ฝั่งเซิร์ฟเวอร์จะตัดการพึ่งพาเบราว์เซอร์ออกไปได้ ในกรณีนี้มันไม่ได้ตัด dynamic remarketing บน Microsoft Ads ยังต้องมีการเรียกฝั่งไคลเอนต์ และสะพานเชื่อมตัวระบุระหว่างเบราว์เซอร์กับข้อมูลฝั่งเซิร์ฟเวอร์ต้องตรงกันทั้งสองด้าน โปรเจกต์ CAPI ที่ข้ามส่วนนี้จะใช้รายงาน Conversion ได้ แต่จะไม่รองรับ dynamic remarketing แบบเงียบ ๆ
สรุปข้อกำหนดในตารางเดียว
ตารางด้านล่างรวบรวมข้อจำกัดที่ Microsoft เผยแพร่ในคู่มือ Conversions API ฉบับวันที่ 15 สิงหาคม 2026 ทุกค่ามาจากเอกสารโดยตรง
| ข้อกำหนด | ค่าที่ Microsoft เผยแพร่ |
|---|---|
| Endpoint | POST ไปที่ https://capi.uet.microsoft.com/v1/{tagId}/events พร้อม Bearer token |
| ประเภทอีเวนต์ | pageLoad และ custom |
| อายุของอีเวนต์ | eventTime ต้องเป็น UNIX UTC timestamp ภายใน 7 วันล่าสุด |
| ขนาดชุดข้อมูล | 1,000 อีเวนต์ ล้มทั้งชุดหากมีรายการผิด เว้นแต่ตั้ง continueOnValidationError เป็น true |
| การจัดการตัวระบุ | ต้องมีอย่างน้อยหนึ่งค่าจาก anonymousId, externalId, em, ph, msclkid, idfa, gaid อีเมลแฮช SHA-256 เป็นเลขฐานสิบหกตัวพิมพ์เล็กหลังทำให้เป็นมาตรฐาน เบอร์โทรใช้ E.164 |
ทำไมต้องมี Conversions API ฝั่งเซิร์ฟเวอร์ตั้งแต่แรก
ส่วนนี้เป็นการวิเคราะห์ ไม่ใช่ข้อความจากเอกสารของ Microsoft การติดตาม Conversion ผ่านเบราว์เซอร์สูญเสียความครอบคลุมมาหลายปีด้วยเหตุผลสามข้อที่ทับซ้อนกัน Intelligent Tracking Prevention ของ Safari จำกัดอายุคุกกี้ที่เขียนด้วยสคริปต์ ผู้เข้าชมที่กลับมาซ้ำจึงถูกมองเป็นคนใหม่ ตัวบล็อกโฆษณาและตัวบล็อกการติดตามทำให้แท็กไม่ทำงานเลยกับผู้ใช้ส่วนหนึ่ง และส่วนนั้นเอียงไปทางกลุ่มที่มีความรู้ทางเทคนิคและรายได้สูง ซึ่งเป็นกลุ่มที่ผู้ลงโฆษณา B2B จำนวนมากไล่ตามอยู่พอดี ส่วนกรอบเรื่องความยินยอมทำให้แบนเนอร์ที่ถูกปฏิเสธห้ามแท็กยิงโดยชอบธรรม
API ฝั่งเซิร์ฟเวอร์เปลี่ยนจุดกำเนิดของอีเวนต์ แทนที่เบราว์เซอร์ของผู้เข้าชมจะเป็นผู้รายงาน Conversion ระบบของผู้ลงโฆษณาเองเป็นผู้รายงาน โดยใช้ข้อมูลที่ผู้ลงโฆษณาถืออยู่แล้วเพราะธุรกรรมเกิดขึ้นที่นั่น มันไม่ได้ลบล้างเรื่องความยินยอมและไม่ควรทำแบบนั้นด้วย อีเวนต์ที่ลูกค้าปฏิเสธความยินยอมไว้ไม่ควรถูกส่ง สิ่งที่มันกู้คืนคือสัญญาณที่หายไปเพราะปัญหาทางเทคนิค ไม่ใช่ที่หายไปเพราะการปฏิเสธโดยชอบ
เรื่องที่สองที่มันปลดล็อกคือ Conversion ที่ไม่เคยผ่านเบราว์เซอร์เลย ลีดที่ปิดการขายทางโทรศัพท์สามสัปดาห์หลังคลิก การจองที่ตกลงกันจบในแชท การซื้อหน้าร้านที่จับคู่กับเรกคอร์ดใน CRM ทั้งหมดนี้ไม่ได้ทำให้เกิดการโหลดหน้าเว็บ แท็กฝั่งไคลเอนต์จึงรายงานไม่ได้ ท่อฝั่งเซิร์ฟเวอร์คือทางเดียวที่ผลลัพธ์เหล่านั้นจะไปถึงระบบประมูลได้
ต้นทุนจริงของการทำให้ใช้งานได้
วิเคราะห์ งานนี้คืองานวิศวกรรม ไม่ใช่การกดสวิตช์ใน tag manager ต้องมีคนสร้างงานที่อ่าน Conversion ออกมาจากระบบต้นทาง ทำให้ตัวระบุเป็นมาตรฐานตามสเปกของ Microsoft แบบเป๊ะ แฮชค่าเหล่านั้น แบ่งเป็นชุดไม่เกิน 1,000 ส่งพร้อมโทเคนที่ถูกหมุนเปลี่ยนแทนที่จะแปะทิ้งไว้ จัดการกรณีที่ถูกปฏิเสธ และพก eventId ที่ไปถึงแท็ก UET ฝั่งไคลเอนต์ด้วย นั่นคือเซอร์วิสที่ต้องมีลอจิกลองใหม่และการมอนิเตอร์ และต้องมีเจ้าของหลังขึ้นระบบ เพราะรูปแบบความล้มเหลวของมันคือความเงียบ ไม่ใช่หน้าจอแจ้งข้อผิดพลาด
อีกทางคือซื้อท่อสำเร็จรูป Microsoft ระบุชื่อพาร์ตเนอร์ที่เชื่อมต่อพร้อมใช้แล้วไว้ ได้แก่ Segment (Twilio), Tealium, Stape.io, MetaRouter, Commanders Act, Freshpaint และ Invoca โดยมี Adobe Real-Time CDP และ Switch Growth ระบุว่ากำลังจะมา ทีมที่ใช้ customer data platform หรือคอนเทนเนอร์แท็กฝั่งเซิร์ฟเวอร์อยู่แล้วถือว่าทำงานส่วนใหญ่ไปแล้ว เหลือแค่การตั้งค่าและการตรวจสอบว่าการทำให้ตัวระบุเป็นมาตรฐานที่ผู้ให้บริการทำนั้นตรงกับที่ Microsoft กำหนดไว้จริง
สิ่งที่ Microsoft ไม่ได้พูด
เอกสาร Conversions API ของ Microsoft ระบุว่า API อยู่ในสถานะเบตาและยังไม่เปิดให้ทุกบัญชี และไม่ได้ให้วันที่เปิดใช้งานทั่วไป ไม่มีการประกาศไทม์ไลน์ไว้ ผู้ลงโฆษณาที่วันนี้ยังไม่เห็นตัวเลือกนี้จึงไม่มีวันที่ให้วางแผนอ้างอิง และต้องเข้าไปเช็กในบัญชีเอง แทนการรอประกาศ
Microsoft ยังไม่ได้เผยแพร่ประมาณการว่าผู้ลงโฆษณาควรคาดหวังจะกู้สัญญาณ Conversion กลับมาได้เท่าไร ตัวเลขเปอร์เซ็นต์ใด ๆ ที่ถูกผูกกับการเปิดตัวครั้งนี้คือการเดาของใครสักคน คำตอบที่ซื่อสัตย์คือปริมาณที่กู้ได้ขึ้นกับว่าเดิมทีบัญชีนั้นเสียทราฟฟิกให้ข้อจำกัดของเบราว์เซอร์ไปมากแค่ไหน ซึ่งต่างกันตามสัดส่วนอุปกรณ์ สัดส่วนเบราว์เซอร์ และกลุ่มผู้ชม ให้วัดก่อนและหลังกับบัญชีของตัวเอง และอย่าตั้งงบโดยอิงตัวเลขที่ไม่มีใครเผยแพร่
เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย
Microsoft Ads เป็นช่องทางเล็กในไทยมากกว่าจะเป็นช่องทางหลัก และเอกสารของ Microsoft ไม่มีตัวเลขส่วนแบ่งตลาดใด ๆ อยู่เลย จึงไม่ควรมีใครอ้างตัวเลขนั้น จุดที่มันน่าสนใจในทางปฏิบัติคือต้นทุน สำหรับผู้ลงโฆษณาไทยสาย B2B และท่องเที่ยว อินเวนทอรีของ Bing มักถูกกว่าการประมูลบน Google ที่เทียบเคียงกัน จึงเป็นช่องทางรองที่มีประโยชน์เมื่อมีวอลุ่มมากพอ
ส่วนที่เข้ากับบริบทไทยชัดที่สุดคือการรองรับอีเวนต์แบบออฟไลน์และจาก CRM ลีดในไทยจำนวนมากไม่ได้ปิดการขายในเบราว์เซอร์เลย คนคลิกเข้ามา บทสนทนาย้ายไปอยู่บน LINE แล้วดีลจบทางโทรศัพท์อีกหลายวันต่อมา แท็กฝั่งไคลเอนต์ไม่เคยเห็นผลลัพธ์นั้น การประมูลของบัญชีเหล่านั้นจึงปรับตัวตามการกรอกฟอร์มที่อาจเป็นหรือไม่เป็นลีดจริงก็ได้ ท่อฝั่งเซิร์ฟเวอร์คือสิ่งที่พาลีดที่ปิดได้จริงกลับเข้าไปในระบบ ข้อจำกัด eventTime 7 วันคือเงื่อนไขที่ต้องออกแบบรอบ ๆ มัน การส่งออกข้อมูลจาก CRM รอบกลางคืนหรือสัปดาห์ละสองครั้งอยู่ในกรอบสบาย ๆ ส่วนการกระทบยอดเดือนละครั้งไม่อยู่ในกรอบ
ในแง่วิธีสร้าง server-side GTM และ Stape.io เป็นของที่อยู่ในสแตกของเอเจนซีไทยอยู่แล้ว และ Stape.io ก็เป็นหนึ่งในพาร์ตเนอร์ที่ Microsoft ระบุชื่อไว้ จุดเริ่มต้นที่เป็นไปได้จริงสำหรับทีมไทยส่วนใหญ่จึงเป็นคอนเทนเนอร์ที่ใช้อยู่แล้ว ไม่ใช่การสร้างเซอร์วิสใหม่ทั้งชุด แต่งานเรื่องตัวระบุยังอยู่ครบ เบอร์โทรศัพท์ไทยที่เก็บเป็น 08x หรือ 06x ต้องแปลงเป็น E.164 โดยใส่รหัสประเทศ +66 และตัดเลขศูนย์นำหน้าออก และ CRM ที่เต็มไปด้วยเบอร์รูปแบบท้องถิ่นคือสาเหตุที่เป็นไปได้มากที่สุดว่าทำไมการเชื่อมต่อครั้งแรกถึงจับคู่ได้แย่
คำถามที่พบบ่อยเกี่ยวกับ Microsoft Advertising Conversions API
ใช้ได้เลยตอนนี้ไหม
อาจจะได้ เพราะ Microsoft ระบุว่า Conversions API อยู่ในสถานะเบตาและยังไม่เปิดให้ทุกบัญชี วิธีเช็กที่เชื่อถือได้ทางเดียวคือเข้าไปดูตัวเลือกในส่วน UET ของบัญชี Microsoft Advertising ของคุณเอง และ Microsoft ไม่ได้ประกาศวันเปิดใช้งานทั่วไปไว้ จึงไม่มีไทม์ไลน์ให้รอ
ถ้าใช้ Conversions API แล้วต้องถอดแท็ก UET ออกไหม
ไม่ต้อง Microsoft วางตำแหน่ง Conversions API ให้ทำงานคู่กับ UET ไม่ใช่มาแทนที่ และยังกำหนดให้ใช้ eventId ร่วมกันทั้งสองเส้นทางเพื่อให้ Conversion เดียวกันถูกตัดซ้ำเหลืออันเดียว ซึ่งจะทำงานได้ก็ต่อเมื่อทั้งสองทางยังทำงานอยู่
เปิดใช้ในประเทศไทยแล้วหรือยัง
เอกสารของ Microsoft ไม่ได้พูดถึงประเทศไทยหรือการเปิดใช้งานรายประเทศเลย จึงต้องบอกตรง ๆ ว่าแหล่งข้อมูลไม่ได้ระบุ สิ่งที่ระบุไว้คือการเปิดใช้งานเป็นรายบัญชีในช่วงเบตา ดังนั้นคำตอบคือให้เข้าไปเช็กบัญชีของตัวเอง ไม่ใช่ไปหารายชื่อประเทศ
จะได้ข้อมูล Conversion กลับมามากแค่ไหน
Microsoft ไม่ได้เผยแพร่ตัวเลขหรืออัตราการกู้คืนที่ควรคาดหวังไว้เลย เปอร์เซ็นต์ใด ๆ ที่เห็นคนอ้างจึงเป็นตัวเลขที่แต่งขึ้น ปริมาณที่ได้ขึ้นกับว่าทราฟฟิกของคุณเสียให้ข้อจำกัดของเบราว์เซอร์ไปเท่าไรอยู่ก่อนแล้ว และ Conversion ของคุณเกิดออฟไลน์มากแค่ไหน ซึ่งทั้งสองอย่างต่างกันระหว่างบัญชีมากเกินกว่าที่ตัวเลขกลาง ๆ จะมีความหมาย
tag manager ทำเรื่องนี้ได้เองโดยไม่ต้องมีนักพัฒนาไหม
ได้บางส่วน Microsoft ระบุชื่อ Segment (Twilio), Tealium, Stape.io, MetaRouter, Commanders Act, Freshpaint และ Invoca เป็นพาร์ตเนอร์ที่เชื่อมต่อพร้อมใช้แล้ว โดยมี Adobe Real-Time CDP และ Switch Growth กำลังจะมา ทีมที่ใช้ตัวใดตัวหนึ่งอยู่แล้วจึงเหลือแค่งานตั้งค่า ไม่ใช่งานสร้าง ส่วนทีมที่ไม่มีโครงสร้างฝั่งเซิร์ฟเวอร์เลยกำลังมองงานวิศวกรรมของจริง เพราะการทำตัวระบุให้เป็นมาตรฐาน การแฮช การแบ่งชุด และความสอดคล้องของ eventId ต้องถูกต้องทั้งหมด
ถ้ากำลังชั่งใจว่าการติดตาม Conversion ฝั่งเซิร์ฟเวอร์คุ้มกับงานพัฒนาในสแตกของคุณหรือไม่ ขั้นแรกที่ซื่อสัตย์ที่สุดคือวัดก่อนว่าตอนนี้เสียอะไรไปบ้าง ทีม วิเคราะห์ข้อมูลและการวัดผล ของเรารับตรวจว่าสัญญาณ Conversion ของคุณขาดตรงไหน และทีม โฆษณาบนเสิร์ช ของเราบอกได้ว่าสัญญาณที่กู้กลับมาจะเปลี่ยนวิธีประมูลของแคมเปญคุณจริงหรือเปล่า
