ตรวจสอบความถูกต้องของการซื้อ GA4 กับตารางคำสั่งซื้อของคุณก่อนที่จะเชื่อถือผลการทดสอบ

รายงานข้อมูลทรัพย์สิน GA4 ของคุณระบุว่ามีการซื้อ 4,180 รายการในเดือนที่แล้ว แต่ตารางคำสั่งซื้อระบุว่า 4,690 รายการ หากถามว่าตัวเลขใดถูกต้อง คำตอบที่ตรงไปตรงมาคือไม่มีตัวเลขใดถูกต้อง จนกว่าคุณจะบอกได้ว่าคำสั่งซื้อที่หายไป 510 รายการนั้นหายไปไหน นี่ไม่ใช่ปัญหาเรื่องความเรียบร้อย ผลลัพธ์การทดลองทุกอย่างและคะแนนการจัดลำดับความสำคัญทุกคะแนนที่คุณสร้างขึ้นนั้นคำนวณจากตัวเลขที่ผิดพลาดด้วยจำนวนที่ไม่ทราบแน่ชัดและทิศทางที่ไม่ทราบแน่ชัด

Google ถือว่าข้อมูลส่วนใหญ่ที่ไม่ได้วัดนั้นเป็นเรื่องปกติ: การสร้างแบบจำลองพฤติกรรมสำหรับโหมดการขอความยินยอมจะไม่เปิดใช้งานจนกว่าจะมีการบันทึกข้อมูลของที่พัก อย่างน้อย 1,000 กิจกรรมต่อวัน พร้อมด้วย analytics_storage='denied' เป็นเวลาอย่างน้อย 7 วันนอกจากนั้นแล้ว ข้อมูลที่หายไปก็จะยังคงหายไป

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

การตรวจสอบความถูกต้องของการซื้อสินค้าวัดอะไรบ้าง

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

ขั้นตอนที่ 1: ดึงตารางสองตารางที่สามารถเชื่อมต่อกันได้โดยใช้รหัสคำสั่งซื้อ

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

• แบ็กเอนด์: รหัสคำสั่งซื้อ, เวลาที่สร้างในเขตเวลาการรายงานของที่พัก, มูลค่าคำสั่งซื้อตามหลักเกณฑ์ภาษีและการจัดส่งเดียวกันกับที่คุณกำหนดค่าไว้ใน GA4, วิธีการชำระเงิน, อุปกรณ์, ประเทศ, สถานะ
• GA4: การส่งออกข้อมูลไปยัง BigQuery ไม่ใช่ UI Query purchase กิจกรรมที่มี ecommerce.transaction_id, event_timestamp, ecommerce.purchase_revenueประเภทอุปกรณ์ และแหล่งที่มาของการรับส่งข้อมูล

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

จากนั้นใช้ Full Outer Join กับ Order ID ตอนนี้คุณมีสาม Bucket แล้ว ได้แก่ ในทั้งสองระบบ ใน Backend เท่านั้น และใน GA4 เท่านั้น Bucket ที่สามมีขนาดเล็กกว่า แต่มีความสำคัญในการวิเคราะห์มากที่สุด

ขั้นตอนที่ 2: แสดงช่องว่างนั้นออกมาในสามวิธี ไม่ใช่วิธีเดียว

การคิดเปอร์เซ็นต์รายเดือนเพียงอย่างเดียวเป็นการปกปิดทุกอย่าง ควรคำนวณทั้งสามค่า:

1. ช่องว่างจำนวนคำสั่งซื้อ: (คำสั่งซื้อจากระบบแบ็กเอนด์ ลบด้วย การซื้อที่ตรงกันใน GA4) / คำสั่งซื้อจากระบบแบ็กเอนด์ วิธีนี้จะช่วยแยกความคลาดเคลื่อนในการติดตามออกไป
2. ช่องว่างรายได้: การคำนวณมูลค่าก็เหมือนกัน หากช่องว่างจำนวนอยู่ที่ 3% และช่องว่างรายได้อยู่ที่ 11% แสดงว่าคุณไม่ได้มีปัญหาเรื่องการติดตาม แต่คุณมีปัญหาเรื่องการกำหนดมูลค่า (ภาษี ค่าจัดส่ง ส่วนลด อัตราแลกเปลี่ยน บัตรของขวัญ)
3. ความผันแปรของช่องว่างรายวัน: พล็อตแสดงช่องว่างของจำนวนคำสั่งซื้อรายวัน เส้นตรงราบหมายถึงสาเหตุเชิงโครงสร้าง เช่น การยินยอมหรือตัวบล็อก การพุ่งขึ้นหมายถึงการเปิดตัว การขยายแคมเปญ หรือปัญหาจากผู้ให้บริการชำระเงิน

ขั้นตอนที่ 3: แยกช่องว่างออกเป็นสาเหตุต่างๆ ที่ระบุชื่อไว้

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

สองคนนี้สมควรได้รับการดูแลเป็นพิเศษ transaction_id การลบข้อมูลซ้ำซ้อนใช้งานได้เฉพาะกับสตรีมเว็บเท่านั้น ไม่ใช่สตรีมแอป และ Google เตือนว่าการส่งสตริงว่างจะทำให้ Analytics ลบข้อมูลซ้ำซ้อน ทุกๆ กิจกรรมการซื้อที่จัดขึ้น transaction_id=''ข้อผิดพลาดเพียงจุดเดียวอาจทำให้เสียเวลาไปเกือบทั้งวัน นอกจากนี้ รายชื่อการอ้างอิงที่ไม่ต้องการยังถูกจำกัดไว้ที่ 50 โดเมนต่อสตรีมข้อมูล ซึ่งเป็นปัญหาหากคุณใช้ผู้รับชำระเงิน กระเป๋าเงิน และหน้าธนาคารหลายแห่ง

[ต้องการข้อมูลภายใน: การกระจายตัวที่สังเกตได้ของสาเหตุทั้งเก้าประการนี้ในการให้คำปรึกษาเพื่อการปรองดองของ Switas เพื่อให้ผู้อ่านเห็นว่าสาเหตุใดมักเป็นสาเหตุหลัก]

ขั้นตอนที่ 4: กำหนดค่าความคลาดเคลื่อนที่คุณสามารถพิสูจน์ได้

Google ไม่ได้ระบุตัวเลขความคลาดเคลื่อนที่ยอมรับได้ และคำกล่าวอ้างที่แพร่หลายว่า "5% ก็ใช้ได้" ก็ไม่ปรากฏในเอกสารใดๆ ของ Google ที่เราค้นพบ ดังนั้น ให้กำหนดค่าความคลาดเคลื่อนของคุณเอง โดยพิจารณาจากการแยกส่วนประกอบมากกว่าตัวเลขเพียงอย่างเดียว

นี่คือเกณฑ์การดำเนินงานของเรา ไม่ใช่มาตรฐานอุตสาหกรรม ประเด็นสำคัญอยู่ที่ว่า 3% ที่อธิบายไม่ได้นั้นแย่กว่า 8% ที่อธิบายได้

ขั้นตอนที่ 5: จัดเรียงลำดับการทำงานให้สามารถกู้คืนคำสั่งซื้อได้มากที่สุดต่อชั่วโมงการทำงาน

1. คำจำกัดความของค่าและเขตเวลา ไม่ใช่การออกแบบทางวิศวกรรม แต่เป็นการกำหนดค่า และโดยปกติจะใช้เวลาเพียงช่วงบ่าย
2. รหัสธุรกรรมที่ซ้ำกันและว่างเปล่า แก้ไขปัญหา dataLayer หนึ่งจุด
3. การส่งต่อข้ามโดเมนและการอ้างอิงที่ไม่พึงประสงค์ ตั้งค่าทั้งสองอย่าง จากนั้นทดสอบเส้นทางการคืนเงินจริงอีกครั้ง ไม่ใช่การทดสอบในระบบจำลอง
4. เหตุการณ์การซื้อฝั่งเซิร์ฟเวอร์ ส่งข้อมูลการซื้อจากระบบสั่งซื้อของคุณพร้อมกับโปรโตคอลการวัด โดยใช้ client_id แท็กเว็บของคุณถูกสร้างขึ้นแล้ว Google กำหนดให้ต้องส่งเหตุการณ์เหล่านี้ภายใน 48 ชั่วโมงนับจากเวลาประทับเหตุการณ์ฝั่งไคลเอ็นต์ดั้งเดิม มิฉะนั้น การระบุแหล่งที่มาอาจไม่ได้รับการประมวลผลตามที่คาดไว้ นี่คือสิ่งที่ช่วยกู้คืนคำสั่งซื้อที่สูญหายเนื่องจากตัวบล็อกและหน้ายืนยันที่ไม่แสดงผล
5. สถาปัตยกรรมแห่งความยินยอม ส่วนที่ช้าที่สุดและเกี่ยวข้องกับการเมืองมากที่สุด ให้ถือว่าส่วนที่เหลือเป็นช่องว่างที่ทราบขนาดและมีการบันทึกไว้แล้ว

จะเกิดอะไรขึ้นหากคุณขายสินค้าในตุรกีหรือสหภาพยุโรป

ปัจจัยระดับภูมิภาคสองประการส่งผลต่อตัวเลข

ในตุรกี การให้ความยินยอมเป็นแบบเลือกเข้าร่วมเองเช่นกัน แต่ไม่มีระบบคุ้มครองความปลอดภัยแบบที่ Google มีให้ หน่วยงานคุ้มครองข้อมูลของตุรกีได้ปรับผู้ประกอบการเว็บไซต์เป็นเงิน 300,000 ลีราตุรกี ในคำตัดสินที่ 2022/1358 (23 ธันวาคม 2022) ฐานใช้งานคุกกี้โฆษณาและการตลาดโดยไม่มีพื้นฐานทางกฎหมาย และกำหนดให้ต้องมีการขอความยินยอมอย่างชัดเจนสำหรับคุกกี้ที่ไม่จำเป็น เว็บไซต์ของตุรกีหลายแห่งจึงตอบโต้ด้วยการใช้แบนเนอร์ที่ปิดกั้นแท็กของ Google แทนที่จะส่งสัญญาณขอความยินยอม ความแตกต่างนี้มีค่าใช้จ่ายสูง: จำเป็นต้องมีการสร้างแบบจำลอง analytics_storage='denied' เหตุการณ์ต่างๆ จะเกิดขึ้นได้ แบนเนอร์ที่ไม่ทำงานจะไม่ให้ข้อมูลใดๆ แก่ Google เพื่อสร้างแบบจำลอง ดังนั้นข้อมูลจึงหายไปแทนที่จะเป็นการประมาณการ

สินค้า 3DS จากตุรกีจะถูกส่งคืนให้ผู้ซื้อทางไปรษณีย์ ด้วย iyzico ผู้ขายจะแสดงหน้าเว็บ 3DS ที่ถอดรหัสแล้ว และหลังจากยืนยัน OTP แล้ว iyzico จะเปลี่ยนเส้นทางไปยังหน้าของผู้ขาย callbackUrl สีสดสวย status, paymentId และ mdStatusการส่งคืนข้อมูลแบบ POST นั้นตรงกับสิ่งที่ Google เรียกว่าเป็นการทำลายการวัดข้ามโดเมน เนื่องจากรีไดเร็กต์สามารถลบข้อมูลบางส่วนออกไปได้ _gl ก่อนที่ปลายทางจะโหลดเสร็จ หากส่วนต่างระหว่างการชำระเงินด้วยบัตรกับการชำระเงินปลายทางมีค่าใกล้เคียงศูนย์ นี่คือสาเหตุ

มีข้อกล่าวอ้างที่ถูกกล่าวซ้ำกันอย่างแพร่หลายสองข้อที่เราไม่สามารถตรวจสอบได้

"Safari จำกัดการใช้งานคุกกี้ของเว็บไซต์เองไว้ที่ 7 วัน" ไม่แม่นยำ เอกสารของ WebKit ระบุว่า ITP จะลบคุกกี้ JavaScript และพื้นที่จัดเก็บข้อมูลที่สคริปต์สามารถเขียนได้อื่นๆ หลังจาก 7 วัน ไม่มีการโต้ตอบของผู้ใช้และจำกัดเวลาการใช้งานคุกกี้ JavaScript ไว้ที่ 24 ชั่วโมงเมื่อเข้าถึงหน้า Landing Page ผ่านการตกแต่งลิงก์จากโดเมนโฆษณา การทดสอบของ Simo Ahava พบว่าเวลาจะนับจากวันที่ใช้งานเบราว์เซอร์ ไม่ใช่จากวันตามปฏิทิน ดังนั้นลูกค้าที่กลับมาใช้บริการจึงสามารถเก็บรหัสประจำตัวไว้ได้นานกว่าหนึ่งสัปดาห์

"ความคลาดเคลื่อน 5% ถือว่ายอมรับได้" เราไม่พบแหล่งข้อมูลใด ๆ จาก Google สำหรับตัวเลขนี้ ตัวเลขนี้แพร่กระจายผ่านบล็อกของผู้ขายและคำตอบในฟอรัม โปรดใช้เป็นข้อมูลที่ไม่เป็นทางการ ไม่ใช่เกณฑ์มาตรฐาน

จุดที่วิธีการนี้ล้มเหลว

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

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

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

ทำไมไม่ใช้ส่วนต่อประสาน GA4 แทน BigQuery ล่ะ? อินเทอร์เฟซอาจรวมถึงผู้ใช้และเซสชันจำลองที่การส่งออกไม่ได้รวมไว้ ดังนั้นตัวเลขของ Google ทั้งสองจึงไม่ตรงกัน การเปรียบเทียบกับค่าประมาณทำให้ไม่สามารถแยกส่วนต่างนั้นได้

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

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

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

อะไรคือสิ่งที่ถือว่าเป็นช่องว่างที่ดี? ในโลกที่ทุกเปอร์เซ็นต์มีชื่อเรียก 8% ที่มีหลักฐานยืนยันย่อมดีกว่า 3% ที่ไม่มีที่มาที่ไป

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

เราสามารถทำการทดสอบ A/B ได้หรือไม่ ในขณะที่ส่วนต่างสูงกว่า 10%? เรียกใช้การทดสอบโดยใช้ตัวชี้วัดเชิงสัมพัทธ์ที่วัดได้ภายในเครื่องมือทดสอบ แต่ไม่ต้องรายงานผลกระทบด้านรายได้ที่แท้จริงจาก GA4 จนกว่าจะมีการวิเคราะห์ช่องว่างอย่างละเอียดแล้ว

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

แหล่งที่มา

• [GA4] การสร้างแบบจำลองพฤติกรรมสำหรับโหมดการขอความยินยอม, ความช่วยเหลือของ Google Analytics
• [GA4] ลดจำนวนเหตุการณ์คีย์ซ้ำด้วยรหัสธุรกรรม, ความช่วยเหลือของ Google Analytics
• [GA4] การอ้างอิงที่ไม่ต้องการ, ความช่วยเหลือจาก Google Analytics
• [GA4] การวัดผลข้ามโดเมน, ความช่วยเหลือของ Google Analytics
• ส่งเหตุการณ์ Measurement Protocol ไปยัง Google Analytics และ Google for Developers
• พารามิเตอร์โหมดการยินยอม เอกสารประกอบแพลตฟอร์ม Google Tag
• การป้องกันการติดตามใน WebKit
• ยกเลิกการจำกัดวันหมดอายุของคุกกี้ JavaScript ในเบราว์เซอร์ WebKit แล้ว โดย Simo Ahava
• KVKK Kurul karari 2022/1358, 23 ธันวาคม 2022
• การใช้งาน 3DS, เอกสารประกอบสำหรับนักพัฒนา iyzico