กลยุทธ์การแบ่งกลุ่ม

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

รวบรวมรายงาน

เมื่อรวบรวมรายงานเพื่อรวมไว้ในกลุ่ม ให้คำนึงถึงสิ่งต่อไปนี้

ลองอัปโหลดรายงานอีกครั้ง

หมายเหตุ: เกณฑ์การลองอีกครั้งอาจมีการเปลี่ยนแปลง ในกรณีดังกล่าว เราจะอัปเดตข้อมูลในส่วนนี้

ทั้งบนแพลตฟอร์มเว็บและระบบปฏิบัติการ แพลตฟอร์มจะพยายามส่งรายงาน 3 ครั้ง แต่หากส่งรายงานไม่สำเร็จหลังจากพยายามครั้งที่ 3 ระบบจะไม่ส่งรายงาน ระบบจะเก็บค่าเดิม scheduled_report_timeไว้ไม่ว่าคุณจะส่งรายงานได้เมื่อใดก็ตาม ไทม์ไลน์สำหรับการลองใหม่จะแตกต่างกันไปตามแพลตฟอร์มดังนี้

• เว็บเบราว์เซอร์จะส่งรายงานเมื่อเบราว์เซอร์ออนไลน์ หากส่งรายงานไม่สำเร็จ ระบบจะรอ 5 นาทีเพื่อลองส่งครั้งที่ 2 และรอ 15 นาทีเพื่อลองส่งครั้งที่ 3 หากเบราว์เซอร์ ออฟไลน์ การลองใหม่ครั้งถัดไปจะเกิดขึ้น 1 นาทีหลังจากที่เบราว์เซอร์กลับมาออนไลน์ ไม่มีการหน่วงเวลาสูงสุด ในการส่งรายงานบนเว็บ ซึ่งหมายความว่าหากเบราว์เซอร์ออฟไลน์ ไม่ว่ารายงานจะสร้างขึ้นนานแค่ไหน เมื่อเบราว์เซอร์กลับมาออนไลน์อีกครั้ง เบราว์เซอร์จะพยายามส่งรายงานตาม นโยบายการลองใหม่
• โทรศัพท์ Android มีการเชื่อมต่อเครือข่ายที่สม่ำเสมอ ดังนั้น ระบบจะเรียกใช้งานเพื่อส่งรายงาน ทุกๆ ชั่วโมง ซึ่งหมายความว่าหากส่งรายงานไม่สำเร็จ ระบบจะลองส่งอีกครั้งในชั่วโมงถัดไป และอีกครั้งในชั่วโมงหลังจากนั้น หากอุปกรณ์ไม่มีการเชื่อมต่อ อุปกรณ์จะ ลองส่งรายงานอีกครั้งด้วยงานการรายงานถัดไปที่ทำงานหลังจากที่อุปกรณ์เชื่อมต่อกับ เครือข่ายอีกครั้ง ความล่าช้าสูงสุดคือ 28 วัน ซึ่งหมายความว่าอุปกรณ์จะไม่ส่งรายงานที่สร้างขึ้นนานกว่า 28 วันที่ผ่านมา

รอรายงาน

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

ภาพต่อไปนี้แสดงรายงานที่มาถึงล่าช้าซึ่งจัดเก็บไว้ในกลุ่มที่เหมาะสมตามเวลาของรายงานที่กำหนดไว้ Batch T แสดงถึง scheduled_report_time และ T+X แสดงถึงเวลารอ สำหรับรายงานที่ล่าช้า ซึ่งจะทำให้ได้รายงานสรุปที่มีรายงานส่วนใหญ่ซึ่งรวมอยู่ในกลุ่มที่สอดคล้องกับเวลาของรายงานที่กำหนดไว้

การบัญชีรายงานที่รวบรวมได้

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

หลังจากรวบรวมรายงานแล้ว ควรจัดกลุ่มรายงานในลักษณะที่รายงานทั้งหมดที่มี รหัสที่แชร์เดียวกันเป็นส่วนหนึ่งของกลุ่มเดียวกัน

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

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

รูปภาพต่อไปนี้แสดงshared_infoคอมโพเนนต์ที่แฮชร่วมกันเพื่อสร้างรหัสที่ใช้ร่วมกัน

รูปภาพต่อไปนี้แสดงให้เห็นว่ารายงาน 2 รายการที่แตกต่างกันจะมีรหัสที่แชร์เดียวกันได้อย่างไร

หมายเหตุ: scheduled_report_time จะถูกตัดทอนตามชั่วโมง และ source_registration_time จะถูกตัดทอนตามวัน นอกจากนี้ ระบบจะไม่ใช้ report_id ในการสร้างรหัสที่แชร์ ความละเอียดของเวลาอาจมีการอัปเดตในอนาคต

รายงานที่ซ้ำกันภายในกลุ่ม

ฟิลด์ shared_info ในรายงานที่รวบรวมได้มี UUID ในฟิลด์ report_id ซึ่งใช้เพื่อระบุรายงานที่ซ้ำกันภายในกลุ่ม หากมีรายงานมากกว่า 1 รายการที่มี report_id เดียวกันในกลุ่ม ระบบจะรวบรวมเฉพาะรายงานแรกเท่านั้น และรายงานอื่นๆ จะถือเป็น รายการที่ซ้ำกันและถูกทิ้งโดยไม่มีการแจ้งเตือน การรวบรวมจะดําเนินการตามปกติและจะไม่มีการส่งข้อผิดพลาด แม้จะไม่บังคับ แต่เทคโนโลยีโฆษณาก็อาจเห็นประสิทธิภาพเพิ่มขึ้นบ้างโดยการกรอง รายงานที่ซ้ำกันซึ่งมีรหัสรายงานเดียวกันก่อนการรวบรวม

report_id จะไม่ซ้ำกันในแต่ละรายงาน

รายงานที่ซ้ำกันในแต่ละกลุ่ม

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

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

รายงานเป็นชุด

ต่อไปนี้คือวิธีที่แนะนำในการจัดกลุ่มรายงานเพื่อหลีกเลี่ยงรายการที่ซ้ำกันและเพิ่มประสิทธิภาพการทำบัญชีรายงานรวม

จัดกลุ่มตามผู้ลงโฆษณา

หมายเหตุ: เราขอแนะนำให้ใช้กลยุทธ์นี้สำหรับการรวบรวมการรายงานการระบุแหล่งที่มาเท่านั้น

Private Aggregation ไม่มีฟิลด์ attribution_destination ซึ่งเป็นผู้ลงโฆษณา เราขอแนะนําให้จัดกลุ่มตามผู้ลงโฆษณา ซึ่งหมายถึงการรวมรายงานที่เป็นของผู้ลงโฆษณารายเดียวไว้ในกลุ่มเดียวกัน เพื่อหลีกเลี่ยงการเกินขีดจํากัดบัญชีรายงานที่รวบรวมได้สําหรับแต่ละกลุ่ม ผู้ลงโฆษณาเป็น ฟิลด์ที่พิจารณาในการสร้างรหัสที่แชร์ ดังนั้นรายงานที่มีผู้ลงโฆษณารายเดียวกันอาจมี รหัสที่แชร์เดียวกันด้วย ซึ่งจะต้องอยู่ในกลุ่มเดียวกันเพื่อหลีกเลี่ยงข้อผิดพลาด

จัดกลุ่มตามเวลา

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

ความถี่ของกลุ่มและสัญญาณรบกวน

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