Khi xử lý hàng loạt các báo cáo có thể tổng hợp, bạn cần tối ưu hoá chiến lược xử lý hàng loạt để không vượt quá giới hạn về quyền riêng tư. Sau đây là một số chiến lược được đề xuất để gửi các lô báo cáo đến Dịch vụ tổng hợp.
Thu thập báo cáo
Khi thu thập các báo cáo để đưa vào một lô, hãy lưu ý những điều sau:
Thử tải báo cáo lên lại
Lưu ý: Các tiêu chí thử lại có thể thay đổi. Trong trường hợp đó, thông tin trong phần này sẽ được cập nhật.
Trên cả nền tảng web và nền tảng hệ điều hành, một nền tảng sẽ cố gắng gửi báo cáo 3 lần, nhưng nếu không gửi được báo cáo sau lần thứ 3, thì báo cáo sẽ không được gửi. Giá trị scheduled_report_time ban đầu được giữ nguyên bất kể thời điểm có thể gửi báo cáo. Tiến trình thử lại sẽ khác nhau tuỳ theo nền tảng:
- Trình duyệt web sẽ gửi báo cáo khi có kết nối mạng. Nếu không gửi được báo cáo, hệ thống sẽ đợi 5 phút để thử lại lần thứ hai, sau đó đợi 15 phút để thử lại lần thứ ba. Nếu trình duyệt chuyển sang chế độ ngoại tuyến, lần thử lại tiếp theo sẽ là một phút sau khi trình duyệt chuyển sang chế độ trực tuyến. Không có độ trễ tối đa khi gửi báo cáo trên web; điều này có nghĩa là nếu trình duyệt chuyển sang chế độ ngoại tuyến, bất kể báo cáo được tạo cách đây bao lâu, khi trình duyệt chuyển sang chế độ trực tuyến trở lại, trình duyệt sẽ cố gắng gửi báo cáo theo chính sách thử lại.
- Điện thoại Android có kết nối mạng ổn định. Do đó, công việc này sẽ chạy để gửi báo cáo mỗi giờ một lần. Điều này có nghĩa là nếu không gửi được báo cáo, hệ thống sẽ thử lại vào giờ tiếp theo và một lần nữa vào giờ sau đó. Nếu không có kết nối, thiết bị sẽ thử lại việc gửi báo cáo trong lần chạy tác vụ báo cáo tiếp theo sau khi thiết bị kết nối lại với mạng. Độ trễ tối đa là 28 ngày, tức là thiết bị sẽ không gửi báo cáo được tạo cách đây hơn 28 ngày.
Chờ báo cáo
Bạn nên đợi các báo cáo đến muộn khi thu thập báo cáo để gộp thành lô. Bạn có thể xác định báo cáo trễ bằng cách kiểm tra giá trị scheduled_report_time so với thời điểm nhận được báo cáo. Khoảng thời gian chênh lệch giữa các báo cáo đó sẽ giúp xác định khoảng thời gian bạn có thể muốn cân nhắc chờ các báo cáo đến muộn. Ví dụ: khi thu thập báo cáo bị trễ, hãy kiểm tra trường scheduled_report_time và lưu ý độ trễ tính bằng giờ khi nhận được 90%, 95% và 99% báo cáo. Bạn có thể sử dụng dữ liệu đó để xác định khoảng thời gian chờ các báo cáo đến muộn.
Bạn có thể sử dụng báo cáo tổng hợp tức thì để giảm khả năng báo cáo bị chậm trễ.
Hình ảnh sau đây cho thấy các báo cáo đến muộn được lưu trữ trong các lô thích hợp theo thời gian báo cáo theo lịch. Lô T biểu thị scheduled_report_time và T+X biểu thị thời gian chờ đối với các báo cáo bị trì hoãn. Điều này dẫn đến một báo cáo tóm tắt bao gồm phần lớn các báo cáo có trong lô tương ứng với thời gian báo cáo theo lịch của chúng.
Hạch toán báo cáo tổng hợp
Dịch vụ tổng hợp duy trì quy tắc"không trùng lặp". Quy tắc này bắt buộc tất cả các báo cáo có thể tổng hợp có cùng mã nhận dạng được chia sẻ phải được đưa vào cùng một lô.
Sau khi thu thập, các báo cáo phải được nhóm theo cách sao cho tất cả báo cáo có cùng mã nhận dạng dùng chung đều nằm trong một nhóm.
Nếu một báo cáo đã được xử lý trong một lô khác, thì quá trình xử lý có thể dẫn đến lỗi hết hạn mức quyền riêng tư. Việc nhóm báo cáo đúng cách giúp ngăn chặn các lô bị từ chối do quy tắc "không có dữ liệu trùng lặp".
Mã nhận dạng dùng chung là một khoá được tạo cho mỗi báo cáo để theo dõi việc hạch toán báo cáo có thể tổng hợp. Mã nhận dạng được chia sẻ đảm bảo rằng các báo cáo có cùng mã nhận dạng được chia sẻ chỉ đóng góp vào một báo cáo tóm tắt. Điều này có nghĩa là tất cả các báo cáo ánh xạ đến một mã nhận dạng được chia sẻ đều phải được đưa vào một lô duy nhất. Ví dụ: nếu Báo cáo X và Báo cáo Y đều có cùng mã nhận dạng dùng chung, thì bạn phải đưa cả hai báo cáo vào cùng một lô để tránh trường hợp báo cáo bị loại bỏ do trùng lặp.
Hình ảnh sau đây minh hoạ các thành phần shared_info được băm cùng nhau để tạo ra một giá trị nhận dạng dùng chung.
Hình ảnh sau đây minh hoạ cách 2 báo cáo khác nhau có thể có cùng một mã nhận dạng dùng chung:
Lưu ý: scheduled_report_time được rút gọn theo giờ và source_registration_time được rút gọn theo ngày. Ngoài ra, report_id không được dùng trong quá trình tạo mã nhận dạng dùng chung. Độ chi tiết về thời gian có thể được cập nhật trong tương lai.
Báo cáo trùng lặp trong các lô
Trường shared_info trong một báo cáo có thể tổng hợp chứa một UUID trong trường report_id. UUID này được dùng để xác định các báo cáo trùng lặp trong một lô. Nếu có nhiều báo cáo có cùng report_id trong một lô, thì chỉ báo cáo đầu tiên được tổng hợp, còn các báo cáo khác sẽ được coi là trùng lặp và bị loại bỏ âm thầm; quá trình tổng hợp sẽ diễn ra như bình thường và không có lỗi nào được gửi.
Mặc dù không bắt buộc, nhưng công nghệ quảng cáo có thể mong đợi một số lợi ích về hiệu suất bằng cách lọc ra các báo cáo trùng lặp có cùng mã báo cáo trước khi tổng hợp.
report_id là riêng biệt cho từng báo cáo.
Báo cáo trùng lặp trên các lô
Mỗi báo cáo được chỉ định một mã nhận dạng dùng chung, là mã nhận dạng được tạo từ các điểm dữ liệu kết hợp đến từ trường shared_info của báo cáo. Nhiều báo cáo có thể có cùng một mã nhận dạng dùng chung và mỗi lô có thể chứa nhiều mã nhận dạng dùng chung. Tất cả báo cáo có cùng mã nhận dạng được chia sẻ phải nằm trong cùng một lô. Nếu các báo cáo có cùng mã nhận dạng dùng chung nằm trong nhiều lô, thì chỉ lô đầu tiên sẽ được chấp nhận và các lô khác sẽ bị từ chối vì trùng lặp. Để ngăn chặn điều này, các lô phải được tạo một cách thích hợp.
Hình ảnh sau đây cho thấy một ví dụ về trường hợp các báo cáo có cùng mã nhận dạng dùng chung trên các lô có thể khiến lô sau không thành công. Trong hình ảnh, bạn có thể thấy rằng hai hoặc nhiều báo cáo có cùng mã nhận dạng dùng chung e679aa được phân thành các lô khác nhau (lô 1 và lô 2). Vì ngân sách cho tất cả báo cáo có mã nhận dạng được chia sẻ e679aa sẽ được sử dụng trong quá trình tạo báo cáo tóm tắt Lô 1, nên Lô 2 không được phép và sẽ gặp lỗi.
Báo cáo theo lô
Sau đây là những cách được đề xuất để tạo báo cáo theo lô nhằm tránh trùng lặp và tối ưu hoá việc hạch toán báo cáo tổng hợp.
Theo lô của nhà quảng cáo
Lưu ý: Chiến lược này chỉ được đề xuất cho hoạt động tổng hợp Báo cáo phân bổ.
Tính năng Tổng hợp riêng tư không có trường attribution_destination, tức là nhà quảng cáo. Bạn nên gộp theo nhà quảng cáo, tức là đưa các báo cáo thuộc một nhà quảng cáo duy nhất vào cùng một nhóm để tránh vượt quá giới hạn tài khoản báo cáo có thể tổng hợp cho mỗi nhóm. Nhà quảng cáo là một trường được xem xét trong quá trình tạo mã nhận dạng dùng chung, vì vậy, những báo cáo có cùng nhà quảng cáo cũng có thể có cùng mã nhận dạng dùng chung. Điều này đòi hỏi các báo cáo đó phải nằm trong cùng một lô để tránh lỗi.
Lô theo thời gian
Bạn nên cân nhắc thời gian báo cáo theo lịch (shared_info.scheduled_report_time) khi xử lý hàng loạt. Thời gian báo cáo định kỳ được rút gọn thành giờ trong quá trình tạo mã nhận dạng dùng chung, vì vậy, tối thiểu các báo cáo phải được xử lý theo lô theo khoảng thời gian là giờ. Điều này có nghĩa là tất cả báo cáo có thời gian báo cáo định kỳ trong cùng một giờ phải nằm trong cùng một lô để tránh trường hợp các báo cáo có cùng mã nhận dạng dùng chung nằm trong nhiều lô, dẫn đến lỗi công việc.
Tần suất và độ nhiễu của lô
Bạn nên cân nhắc tác động của nhiễu đến tần suất xử lý các báo cáo có thể tổng hợp. Nếu báo cáo tổng hợp được xử lý theo lô thường xuyên hơn (ví dụ: báo cáo được xử lý mỗi giờ một lần), thì sẽ có ít sự kiện chuyển đổi hơn và nhiễu sẽ có tác động tương đối lớn hơn. Nếu tần suất giảm và báo cáo được xử lý mỗi tuần một lần, thì độ nhiễu sẽ có tác động tương đối nhỏ hơn. Để hiểu rõ hơn về tác động của nhiễu đối với các lô, hãy thử nghiệm với Noise Lab.