Google Ads ข้ามคอนเวอร์ชันออฟไลน์ที่อัปโหลดช้ากว่า 7 วัน ในโมเดลแอตทริบิวชัน

คอนเวอร์ชันออฟไลน์ที่อัปโหลดเข้า Google Ads ช้ากว่าเจ็ดวันนับจากวันที่เกิดเหตุการณ์ จะไม่ถูกส่งเข้าโมเดล Data-driven Attribution เลย ขณะที่คอลัมน์รายงานมาตรฐานยังบันทึกคอนเวอร์ชันเหล่านั้นครบถ้วน ผลคือบัญชีเดียวกันแสดงยอดคอนเวอร์ชันสองตัวเลขจากชุดเหตุการณ์เดียวกัน กฎนี้อยู่ในหน้าเอกสารช่วยเหลือของ Google Ads ว่าด้วยรายงานแอตทริบิวชัน ถูกพบโดย Hana Kobzova และถูกเผยแพร่ในวงกว้างโดย Adriaan Dekker ที่ปรึกษาด้าน Google Ads ผ่านโพสต์ LinkedIn เมื่อวันที่ 22 สิงหาคม 2569 ซึ่ง PPC Land รายงานเมื่อวันที่ 23 สิงหาคม 2569

เอกสารของ Google ระบุไว้ว่าอย่างไร

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

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

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

คณิตศาสตร์ของลีดเพียงรายเดียว

ตัวอย่างในรายงานคือวิธีที่ชัดที่สุดในการเห็นช่องว่างนี้ ลีดคลิกโฆษณาบนการค้นหาในวันที่หนึ่งของเดือน ดีลปิดในวันที่สิบสอง และคอนเวอร์ชันถูกอัปโหลดในวันที่สิบห้า ซึ่งห่างจากวันคลิกสิบสี่วัน

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

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

ถ้อยคำอธิบายกฎเดียวกันสองแบบ และสองแบบนั้นไม่เท่ากัน

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

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

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

แต่ละการตีความมีนัยอย่างไร

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

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

สิ่งที่เอ็นจิน Model Comparison ตัดออกไป

เงื่อนไขเจ็ดวันไม่ใช่ข้อยกเว้นเดียว ภายใต้หัวข้อว่าด้วยข้อยกเว้นด้านเครือข่ายและประเภทแคมเปญ เอกสารระบุว่าเอ็นจิน Model Comparison ถูกออกแบบให้ตัดคอนเวอร์ชันที่มาจาก Search Partner Network, Gmail และแคมเปญ App ออกอย่างชัดเจน ขณะที่คอลัมน์รายงานมาตรฐานของบัญชีรวมคอนเวอร์ชันจากเครือข่ายเหล่านั้นไว้เป็นค่าเริ่มต้น

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

เวลาที่เกิดคอนเวอร์ชัน กับเวลาที่เกิดการค้นหา

แหล่งความต่างที่สามไม่เกี่ยวกับข้อมูลออฟไลน์เลย รายงานแอตทริบิวชันนับตามเวลาที่เกิดคอนเวอร์ชัน ส่วนหน้า Campaigns นับตามเวลาของการค้นหาที่นำไปสู่คลิกที่นำไปสู่คอนเวอร์ชันนั้น

สองอย่างนี้เป็นคนละวันสำหรับคอนเวอร์ชันใดก็ตามที่ไม่ได้เกิดทันทีหลังคลิก ซึ่งคือคอนเวอร์ชันส่วนใหญ่ในหมวดสินค้าที่ต้องใช้เวลาตัดสินใจ เอกสารระบุวิธีแก้ไว้ตรง ๆ คือการเพิ่มคอลัมน์แบบ by conversion time เข้าไปในหน้า Campaigns จะทำให้กติกาการนับของทั้งสองฝั่งตรงกัน นี่เป็นการเปลี่ยนการตั้งค่ารายงาน ไม่ใช่การเปลี่ยนข้อมูล และมันตัดหนึ่งในสี่แหล่งความต่างออกไปโดยไม่ต้องแตะอย่างอื่นเลย

ความต่างเชิงโครงสร้างสี่ด้าน วางเทียบกัน

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

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

เงื่อนไขเจ็ดวันส่งผลถึง Smart Bidding อย่างไร

นอกจากใช้ดูรายงานแล้ว ผลลัพธ์ของ Data-driven Attribution ยังถูกป้อนเข้าสู่ Smart Bidding ด้วย และเอกสารก็เชื่อมโยงเรื่องนี้เอง เมื่อมันผูกความหน่วงของการอัปโหลดเข้ากับความแม่นยำของโมเดลและประสิทธิภาพของการประมูลอัตโนมัติไว้ในประโยคเดียวกัน

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

เรื่องนี้เกิดขึ้นท่ามกลางการเปลี่ยนแปลงต่อเนื่องยาวนานเกี่ยวกับวิธีที่ข้อมูลออฟไลน์เข้าสู่ระบบโฆษณาของ Google ทั้ง enhanced conversions for leads ในเดือนมีนาคม 2565 การบังคับใช้พารามิเตอร์ conversion environment สำหรับการอัปโหลดออฟไลน์เมื่อวันที่ 6 กุมภาพันธ์ 2568 การเปิดตัว Data Manager API เป็นจุดรับข้อมูลรวมเมื่อวันที่ 9 ธันวาคม 2568 และการที่ Google ปิดทางไม่ให้ผู้เริ่มใช้การนำเข้าคอนเวอร์ชันออฟไลน์รายใหม่ใช้เส้นทาง Google Ads API แบบเดิมตั้งแต่วันที่ 15 มิถุนายน 2569 ทุกการเปลี่ยนแปลงเหล่านั้นว่าด้วยวิธีที่ข้อมูลออฟไลน์เข้าสู่ระบบ ไม่มีอันใดพูดถึงว่าโมเดลแอตทริบิวชันทำอะไรกับข้อมูลนั้นหลังเข้าไปแล้ว

ข้อจำกัดของรายงานที่ควรรู้ก่อนสรุป

มีข้อจำกัดอีกสองเรื่องที่ควรรู้ก่อนจะสรุปอะไรจากแท็บแอตทริบิวชัน ช่วงวันที่ย้อนหลังได้สองปี และข้อมูลรายงานเส้นทางกับเครดิตแอตทริบิวชันที่เก่ากว่าสองปีจะถูกลบและกู้คืนไม่ได้ ส่วนตัวควบคุมหน้าต่างย้อนหลังปรับได้ที่ 30, 60 หรือ 90 วัน โดยรายงานส่วนใหญ่เปิดมาที่ 30 วัน และรายงาน Model Comparison มีตัวเลือกเพิ่มคือค่า Default ที่จับหน้าต่างย้อนหลังให้ตรงกับหน้าต่างคอนเวอร์ชันที่ตั้งไว้ของแต่ละการกระทำที่นับเป็นคอนเวอร์ชัน

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

ต้องตรวจอะไรในบัญชีของตัวเอง

สี่ข้อต่อไปนี้มาจากกฎที่เอกสารระบุไว้ และไม่มีข้อใดต้องเดาว่าการตีความแบบไหนถูกต้อง

1. วัดความหน่วงของการอัปโหลดจริง ดึงส่วนต่างระหว่างเวลาที่เกิดเหตุการณ์กับเวลาที่อัปโหลด สำหรับข้อมูลหนึ่งเดือนล่าสุดของฟีดคอนเวอร์ชันออฟไลน์ แล้วดูการกระจายตัว ไม่ใช่ดูค่าเฉลี่ย ถ้ามีสัดส่วนที่มีนัยสำคัญเลยเจ็ดวัน แปลว่าโมเดลกำลังทำงานจากข้อมูลน้อยกว่าที่รายงานแสดง
2. เลิกเทียบสองรายงานราวกับว่ามันควรตรงกัน ถ้าการรีวิวผลงานวางตัวเลข Model Comparison ไว้ข้างตัวเลขหน้า Campaigns ความต่างนั้นเป็นสิ่งที่ออกแบบมาให้ต่างกันในสี่มิติ ให้เพิ่มคอลัมน์แบบ by conversion time เข้าไปในหน้า Campaigns เพื่อตัดมิติเรื่องเวลาออก แล้วถือว่าที่เหลือเป็นความต่างเชิงโครงสร้าง
3. ประเมินว่าทราฟฟิกจาก Search Partners, Gmail และ App มีนัยสำคัญกับคุณหรือไม่ คอนเวอร์ชันจากช่องทางเหล่านั้นถูกตัดออกจากเอ็นจิน Model Comparison แต่รวมอยู่ในคอลัมน์มาตรฐาน ถ้าเป็นสัดส่วนใหญ่ของปริมาณ รายงานแอตทริบิวชันย่อมเป็นฐานที่ไม่ดีในการโยกงบระหว่างเครือข่าย
4. ถือว่าการอัปโหลดย้อนหลังเป็นงานรายงาน ไม่ใช่ข้อมูลฝึกโมเดล ไม่ว่าจะตีความกฎแบบใด การอัปโหลดคอนเวอร์ชันเก่าเป็นชุดใหญ่มีโอกาสน้อยที่จะถึงโมเดล จึงไม่ควรคาดหวังว่ามันจะทำให้ประสิทธิภาพการประมูลของ Google Ads ดีขึ้น

เรื่องนี้หมายความว่าอย่างไรกับนักการตลาดไทย

ทั้งเอกสารของ Google และรายงานของ PPC Land ไม่ได้กล่าวถึงประเทศไทย ส่วนต่อไปนี้จึงเป็นการวิเคราะห์บริบทในประเทศ ไม่ใช่สิ่งที่แหล่งข่าวระบุ

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

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

ประเด็นที่สามคือวินัยในการรายงาน ในกรณีที่ทีมภายในกับพาร์ตเนอร์ภายนอกต่างดึงตัวเลขเอง คนสองคนที่ดูบัญชีเดียวกันสามารถได้ตัวเลขคนละชุดโดยที่ทั้งคู่ซื่อสัตย์ การตกลงกันล่วงหน้าว่ารายงานใดเป็นตัวอ้างอิงสำหรับการตัดสินใจเรื่องผลงาน และตั้งค่าหน้า Campaigns ด้วยคอลัมน์แบบ by conversion time จะตัดข้อถกเถียงที่ไม่มีผู้ชนะออกไปได้

ประเด็นที่สี่คือสุขอนามัยของระบบวัดผล ก่อนจะโทษแอตทริบิวชันว่าเป็นต้นเหตุของช่องว่าง ควรยืนยันก่อนว่าการติดตามพื้นฐานทำงานถูกต้อง เพราะระบบวัดผลที่พังหรือย้ายมาได้ครึ่งทางสร้างความคลาดเคลื่อนที่หน้าตาเหมือนกับกรณีนี้ทุกประการ การมี ระบบ Google Analytics 4 ที่ตั้งค่าถูกต้อง ไม่ได้แก้เงื่อนไขเจ็ดวัน แต่มันตัดคำอธิบายอื่นที่แข่งกันอยู่ออกไป

สิ่งที่รายงานยังไม่มีคำตอบ

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

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

คอนเวอร์ชันออฟไลน์ของเราหายไปหรือเปล่า

ไม่หาย คอนเวอร์ชันที่อัปโหลดช้ากว่าเจ็ดวันนับจากเหตุการณ์ยังถูกบันทึกครบถ้วนโดยคอลัมน์รายงานมาตรฐานของ Google Ads ซึ่งบันทึกคอนเวอร์ชันออฟไลน์ที่อัปโหลดเข้ามาย้อนหลังไม่ว่าจะมาถึงเมื่อใด สิ่งที่มันไปไม่ถึงคือโมเดล Data-driven Attribution ดังนั้นมันหายไปจากรายงานแอตทริบิวชันรวมถึง Model Comparison ไม่ใช่หายไปจากบัญชี

ทำไมยอดใน Model Comparison ถึงไม่ตรงกับยอดในหน้า Campaigns

เพราะทั้งสองนับด้วยกติกาคนละชุด และ Google อธิบายว่าความต่างนี้เป็นเรื่องปกติ ไม่ใช่ความผิดพลาด ความต่างที่เอกสารระบุครอบคลุมสี่มิติพร้อมกัน คือรายงานแอตทริบิวชันนับตามเวลาที่เกิดคอนเวอร์ชันขณะที่หน้า Campaigns นับตามเวลาของการค้นหา รายงานแอตทริบิวชันตัดคอนเวอร์ชันจาก Search Partner Network, Gmail และ App ออก ความครอบคลุมของประเภทแคมเปญและรูปแบบวิดีโอต่างกัน และคอนเวอร์ชันออฟไลน์ที่อัปโหลดช้ากว่าเจ็ดวันถูกข้ามจากการคำนวณของโมเดล

ขีดจำกัดเจ็ดวันนับจากวันที่คอนเวอร์ชันเกิด หรือวันที่เราอัปโหลด

เอกสารเขียนไว้ทั้งสองแบบและไม่ได้บอกว่าแบบไหนคือเกณฑ์ที่ใช้จริง ข้อความหนึ่งผูกกฎไว้กับคอนเวอร์ชันที่เกิดขึ้นภายในเจ็ดวันล่าสุด อีกข้อความหนึ่งผูกไว้กับคอนเวอร์ชันออฟไลน์ที่อัปโหลดช้ากว่าเจ็ดวันนับจากเหตุการณ์ตั้งต้น สองเงื่อนไขนี้ให้คำตอบต่างกันสำหรับคอนเวอร์ชันที่เกิดเมื่อสิบสี่วันก่อนแต่อัปโหลดทันที และแหล่งข่าวไม่ได้คลี่คลายความไม่สอดคล้องนี้

การอัปโหลดคอนเวอร์ชันเก่าย้อนหลังจะช่วยให้ Smart Bidding ดีขึ้นไหม

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

ควรเริ่มทำอะไรก่อน

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