ทำไมทีมสองคนอัปโหลด Offline Conversion เข้า Google Ads บัญชีเดียวกัน แล้วยอดถึงเพี้ยน

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

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

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

ทำไมยอดถึงเพี้ยนเมื่อมีมากกว่าหนึ่งคนอัปโหลด Offline Conversion

Google Ads ไม่มีกลไกที่มา 'ตัดสิน' ให้เองว่าไฟล์ที่อัปโหลดจากสองคนมีดีลซ้ำกันหรือไม่ ถ้าทั้งสองไฟล์ระบุ GCLID หรือ Enhanced Conversion Identifier ต่างกันเล็กน้อย หรือใช้รูปแบบวันที่ไม่ตรงกัน ระบบจะรับทั้งสองรายการเป็นคนละ Conversion แม้ว่าในความเป็นจริงมันคือดีลเดียวกัน ยอดที่เห็นในรายงานจึงสูงกว่ายอดขายจริงโดยที่ไม่มีการแจ้งเตือนใด ๆ ว่ามีความซ้ำซ้อนเกิดขึ้น

อีกสาเหตุที่พบบ่อยไม่แพ้กันคือการใช้ Conversion Action คนละตัวโดยไม่ตั้งใจ เช่น คนหนึ่งอัปโหลดเข้า Action ชื่อ 'Closed Sale LINE' ส่วนอีกคนสร้าง Action ใหม่ชื่อ 'Sales Confirmed' ขึ้นมาเองเพราะไม่รู้ว่ามีตัวเดิมอยู่แล้ว ผลคือยอดขายเดียวกันถูกนับสองครั้งใน Ads Manager ผ่านสอง Action ที่ไม่มีใครมองว่าเป็นตัวเดียวกัน และเมื่อดู Report แบบรวม ตัวเลขจะบวมขึ้นโดยไม่มีใครสังเกตจนกว่าจะมีคนไล่เทียบกับยอดขายจริงในบัญชี

กำหนดบทบาทให้ชัดก่อนแตะระบบ ไม่ใช่แก้ทีหลัง

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

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

ธุรกิจที่เพิ่งเริ่มผูกCustomer ID กับ LINE OAเพื่อเตรียมส่ง Offline Conversion กลับ ควรทำขั้นตอนกำหนดบทบาทนี้คู่ขนานไปพร้อมกัน เพราะถ้าเริ่มมีมากกว่าหนึ่งคนดูแลข้อมูลตั้งแต่ต้น การตั้งกฎตั้งแต่แรกจะง่ายกว่ามาไล่แก้ทีหลังมาก

เส้นทางข้อมูลจาก LINE ถึง Google Ads ที่ต้องทำแผนที่ให้ครบ

ก่อนจะออกแบบกฎ Governance ต้องเห็นภาพรวมก่อนว่าข้อมูลเดินทางผ่านจุดไหนบ้าง เริ่มจากลูกค้าคลิกโฆษณาที่มี GCLID ติดมา เข้าเว็บไซต์หรือ Tracking Link ไปยัง LINE เพิ่มเพื่อนและทักแชท กลายเป็น Lead ในระบบ CRM หรือชีตที่ทีมขายใช้ ผ่านการเจรจาจนปิดการขาย แล้วสถานะถูกอัปเดตเป็น Closed Sale พร้อมยอดเงิน จากนั้นข้อมูลชุดนี้ถึงจะถูกนำไปจัดรูปแบบเพื่ออัปโหลดกลับเข้า Conversion Action ที่ตั้งไว้ใน Google Ads

จุดที่ต้องระวังเป็นพิเศษคือทุกจุดต่อ (Handoff) ระหว่างระบบ เพราะแต่ละจุดต่อคือจุดที่ข้อมูลอาจหายหรือถูกแก้โดยไม่มีใครรู้ เช่น GCLID ที่ควรติดไปกับ Lead ตั้งแต่ต้น อาจหายไปตอนที่ทีมขายก็อปข้อมูลจากแชทมาพิมพ์ใหม่ในชีต หรือยอดเงินที่บันทึกในสกุลเงินและ Time Zone ต่างกันระหว่างระบบ ทำให้ตอนอัปโหลดกลับ Google Ads ตีความเวลาผิดจากที่เกิดจริง

กฎ Governance ที่ควรมีเมื่อมากกว่าหนึ่งคนดูแลระบบเดียวกัน

• กำหนดวันและช่วงข้อมูลที่แต่ละคนรับผิดชอบอัปโหลด ห้ามซ้อนทับช่วงกัน เช่น คนหนึ่งดูแลดีลที่ปิดวันจันทร์ถึงพุธ อีกคนดูแลพฤหัสถึงอาทิตย์
• ล็อกชื่อ Conversion Action ให้ใช้ตัวเดียวสำหรับ Closed Sale จาก LINE เท่านั้น ห้ามสร้าง Action ใหม่โดยไม่แจ้งทีมก่อน และตั้งสิทธิ์ให้แก้ไข Action ได้เฉพาะผู้ดูแลหลัก
• ใช้ Lead ID หรือ Order ID เดียวกันเป็น Deduplication Key ในทุกไฟล์ที่อัปโหลด ไม่ว่าใครเป็นคนอัป เพื่อให้ Google Ads ปฏิเสธรายการซ้ำได้เองตามกลไก Deduplication
• บันทึก Log ทุกครั้งที่มีการอัปโหลด ระบุวันเวลา คนอัป จำนวนแถว และช่วงข้อมูลที่ครอบคลุม เก็บไว้ในที่เดียวที่ทุกคนเข้าถึงได้ ไม่ใช่เก็บไว้ในเครื่องส่วนตัว
• ตกลงร่วมกันว่าใครมีสิทธิ์แก้ไขหรือลบ Conversion ย้อนหลัง เพราะการแก้ย้อนหลังโดยไม่แจ้งใคร อาจทำให้ Conversion Adjustment ไปกระทบรายงานของอีกฝ่ายโดยไม่รู้ตัว

ขั้นตอนวางระบบ Governance สำหรับทีมที่ยังไม่มีแผนกไอทีแยก

ทีมขนาดเล็กที่ไม่มีแผนกไอทีแยกไม่จำเป็นต้องมีระบบซับซ้อน แค่ทำตามลำดับนี้ก็เริ่มลดความเพี้ยนได้ทันที:

1. รวมรายชื่อทุกคนที่เคยหรือกำลังมีสิทธิ์เข้าถึง Conversion Action ที่เกี่ยวกับ LINE ใน Google Ads แล้วตรวจว่าจำเป็นต้องมีสิทธิ์นั้นจริงหรือไม่
2. สร้างเอกสารกลางหนึ่งไฟล์ระบุว่าใครรับผิดชอบช่วงข้อมูลไหน ใช้ Conversion Action ชื่ออะไร และ Deduplication Key ใช้ฟิลด์ไหน
3. ตั้งตารางเวลาอัปโหลดที่แน่นอน เช่น สัปดาห์ละครั้งทุกวันจันทร์ แทนที่จะให้แต่ละคนอัปตามใจเวลาว่าง เพื่อลดโอกาสอัปช่วงเดียวกันซ้ำ
4. ก่อนอัปโหลดทุกครั้ง ให้เทียบยอดรวมในไฟล์กับยอดขายที่บันทึกในระบบต้นทางก่อน ถ้าตัวเลขไม่ตรงกันให้หยุดตรวจก่อนอัป ไม่ใช่อัปไปก่อนแล้วค่อยแก้ทีหลัง
5. หลังอัปโหลดทุกครั้ง บันทึก Log ในเอกสารกลางทันที ไม่ปล่อยค้างไว้ทำทีหลังเพราะมักถูกลืม

ตัวอย่างสมมติ: ก่อนและหลังตั้ง Governance ต่างกันแค่ไหน

ตัวเลขต่อไปนี้เป็นตัวอย่างสมมติจากทีมมาร์เก็ตติ้งสองคนที่เคยอัปโหลด Offline Conversion แบบต่างคนต่างทำ แล้วเปลี่ยนมาใช้ Governance ตามที่อธิบายไว้ข้างต้นเป็นเวลาสองเดือน:

ข้อผิดพลาดที่พบบ่อยเมื่อหลายคนดูแลระบบเดียวกัน

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

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

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

รอบตรวจสอบที่ควรมี และใครควรเป็นคนตรวจ

Governance ที่ตั้งไว้ตอนแรกจะค่อย ๆ หลวมลงถ้าไม่มีรอบตรวจสอบสม่ำเสมอ ทีมที่ทำได้ผลดีมักกำหนดให้มีการตรวจสอบสองระดับ ระดับแรกคือตรวจทุกสัปดาห์แบบเร็ว ๆ ว่ายอดที่อัปโหลดสัปดาห์นั้นตรงกับยอดขายในระบบต้นทางหรือไม่ ใครเป็นคนอัป และมี Log บันทึกครบไหม ระดับที่สองคือตรวจทุกเดือนแบบละเอียดกว่า โดยดึงรายงาน Conversion ทั้งเดือนจาก Google Ads มาเทียบกับยอดขายสะสมในบัญชีธนาคารหรือระบบบัญชี เพื่อจับความเพี้ยนสะสมที่อาจไม่เห็นชัดในรายสัปดาห์

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

สรุป

ยอด Offline Conversion ที่เพี้ยนเมื่อหลายคนดูแลบัญชี Google Ads เดียวกัน ส่วนใหญ่ไม่ได้เกิดจากระบบผิดพลาด แต่เกิดจากไม่มีกฎว่าใครรับผิดชอบช่วงข้อมูลไหน ใช้ Conversion Action ตัวเดียวกันหรือไม่ และมี Deduplication Key ที่ทุกคนใช้ร่วมกันหรือเปล่า เมื่อกำหนดบทบาทและกฎเหล่านี้ให้ชัดตั้งแต่ต้น ความเพี้ยนของตัวเลขจะลดลงอย่างเห็นได้ชัดโดยไม่ต้องเปลี่ยนระบบใด ๆ

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

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

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