การฉีดเสียงรบกวน

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

ดูประโยชน์ของการใช้การแทรกสัญญาณรบกวน

การแก้ปัญหาทำได้ง่ายขึ้น: ระบบจะละเว้นแถวเนื่องจากข้อกำหนดในการรวบรวมเท่านั้น ทำให้การแก้ปัญหาและการปรับคำค้นหาทำได้ง่ายขึ้น

ไม่ต้องเรียนรู้ไวยากรณ์ใหม่: คุณไม่จำเป็นต้องเรียนรู้ไวยากรณ์การค้นหาใหม่หรือมีความรู้เกี่ยวกับแนวคิดด้านความเป็นส่วนตัวเพื่อใช้ Noise

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

ดูว่าเสียงรบกวนส่งผลต่อข้อกำหนดด้านความเป็นส่วนตัวอย่างไร

ข้อกำหนดในการรวบรวมข้อมูล: Noise Injection จะแสดงข้อมูลการแสดงผลที่แสดงโดยผู้ใช้ที่ไม่ซ้ำกันประมาณ 20 รายขึ้นไป และข้อมูล Conversion ที่แสดงโดยผู้ใช้ที่ไม่ซ้ำกันประมาณ 10 รายขึ้นไป

การตรวจสอบแบบคงที่: ไม่มีผลกระทบ

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับการตรวจสอบด้านความเป็นส่วนตัว

ทำความเข้าใจว่า Noise Injection ส่งผลต่อผลลัพธ์อย่างไร

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

Noise Injection ใน Ads Data Hub จะเปลี่ยนผลการค้นหาดังนี้

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

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

เกี่ยวกับการแคลมป์การรวม

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

การจำกัดโดยนัย

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

การยึดอย่างชัดเจน

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

Ads Data Hub มีADH.ANONฟังก์ชันการรวมเพิ่มเติมสำหรับการจำกัดอย่างชัดเจน หากต้องการใช้ การจำกัดที่ชัดเจน ให้ตั้งค่าขอบเขตสำหรับฟังก์ชันการรวมที่รองรับแต่ละฟังก์ชันโดย การเพิ่มจำนวนเต็มที่แสดงถึงขอบเขตล่างและขอบเขตบน เช่น

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

เรียกใช้การค้นหาโดยใช้ Noise Injection

  1. เปิดรายงาน
  2. คลิกปุ่มเปิด/ปิดการตั้งค่าข้อผิดพลาดเกี่ยวกับความเป็นส่วนตัวไปที่ตำแหน่งใช้ข้อผิดพลาด
  3. เรียกใช้การค้นหา
  4. ตรวจสอบผลกระทบของเสียงรบกวนที่เพิ่ม
  5. ไม่บังคับ: ปรับคำค้นหาเพื่อลดผลกระทบจากสัญญาณรบกวน

ตรวจสอบผลกระทบจากเสียงรบกวน

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

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

% ของผลการค้นหาที่ได้รับผลกระทบ สีของตัวบ่งชี้ ผลลัพธ์
<5% เขียว ผลกระทบต่ำ
5%-15% เหลือง ผลกระทบปานกลาง
15%-25% Orange ผลกระทบสูง
มากกว่า 25% แดง มีผลกระทบสูงมาก

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

ปรับการค้นหา

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

หลักเกณฑ์ทั่วไปมีดังนี้

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

ฟังก์ชันการรวมข้อมูลที่รองรับ

ฟังก์ชันการรวมต่อไปนี้รองรับการเพิ่มสัญญาณรบกวน

  • SUM(...)
  • COUNT(*)
  • COUNT(...)
  • COUNTIF(...)
  • COUNT(DISTINCT ...)
  • APPROX_COUNT_DISTINCT(...)
  • AVG(...)

ระบบรองรับคีย์เวิร์ด DISTINCT เฉพาะกับฟังก์ชัน COUNT เท่านั้น เมื่อใช้ กับการอ้างอิงโดยตรงไปยังคอลัมน์ user_id จากตาราง Ads Data Hub หรือนิพจน์ที่แสดงผลเป็น user_id หรือ NULL เช่น COUNT(DISTINCT IF(..., user_id, NULL)) ฟังก์ชัน COUNT DISTINCT และ APPROX_COUNT_DISTINCT(...) จะคำนวณโดยการจำกัดการมีส่วนร่วมต่อผู้ใช้แต่ละรายไว้ที่ 1 เมื่อ COUNT DISTINCT อ้างอิงคอลัมน์ที่ไม่ใช่ user_id ระบบจะประมาณค่าโดยใช้ APPROX_COUNT_DISTINCT พร้อมการจำกัดค่าโดยนัย

ฟังก์ชันรวมข้อมูลเสริม

นอกเหนือจากการรองรับผู้รวบรวมข้อมูลทั่วไปแล้ว Ads Data Hub ยังเปิดตัวADH.ANONฟังก์ชันการรวมข้อมูลเสริมที่รองรับการจำกัดอย่างชัดเจน ตัวรวบรวมเหล่านี้ใช้ไวยากรณ์เดียวกับฟังก์ชันการรวมแบบส่วนตัวเชิงอนุพันธ์ของ BigQuery แต่ไม่จำเป็นต้องมีคําสั่ง WITH DIFFERENTIAL_PRIVACY

  • ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

  • ADH.ANON_COUNT_DISTINCT( ..., [ max_contributions_per_group => upper_bound ] )

พารามิเตอร์ ADH.ANON_SUM, ADH.ANON_COUNT และ ADH.ANON_AVG

  • contribution_bounds_per_group: ระบบจะจำกัดจำนวนการมีส่วนร่วมต่อผู้ใช้สำหรับแต่ละพาร์ติชันที่กำหนดโดยคีย์ GROUP BY ขอบเขตบนและขอบเขตล่างจะ ใช้กับค่าต่อกลุ่มหลังจากที่ระบบรวบรวมค่าต่อผู้ใช้แล้ว
  • lower_bound: ค่าตัวเลขที่แสดงค่าที่เล็กที่สุดที่จะรวมไว้ ในการรวม
  • upper_bound: ตัวอักษรตัวเลขที่แสดงค่าที่ใหญ่ที่สุดที่จะรวมไว้ในการรวม

ADH.ANON_PERCENTILE_CONT พารามิเตอร์

  • percentile: เปอร์เซ็นไทล์ที่จะคำนวณ ค่าคงที่ในช่วง [0, 1]
  • contribution_bounds_per_row: ระบบจะจำกัดการมีส่วนร่วมต่อผู้ใช้ตาม ต่อแถว (ต่อระเบียน) โปรดทราบว่าต้องระบุขอบเขตการจำกัดที่ชัดเจน สำหรับเปอร์เซ็นไทล์ จึงรองรับเป็นฟังก์ชันเสริมเท่านั้น
  • lower_bound: ค่าตัวเลขที่แสดงค่าที่เล็กที่สุดที่จะรวมไว้ ในการรวม
  • upper_bound: ค่าตัวเลขที่แสดงค่าที่ใหญ่ที่สุดที่จะรวมไว้ในการรวม

ADH.ANON_COUNT_DISTINCT พารามิเตอร์

  • max_contributions_per_group: ระบบจะจำกัดจำนวนการมีส่วนร่วมต่อผู้ใช้สำหรับแต่ละพาร์ติชันที่กำหนดโดยคีย์ GROUP BY ขอบเขตบนจะจำกัดการมีส่วนร่วมของผู้ใช้สูงสุดต่อกลุ่มหลังจากที่ระบบรวบรวมค่าต่อผู้ใช้แล้ว
  • upper_bound: ค่าตัวเลขที่แสดงค่าที่ใหญ่ที่สุดที่จะรวมไว้ในการรวม

คำนวณ MIN และ MAX

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

หากมีค่า MIN หรือ MAX ที่ใช้เป็นคีย์การจัดกลุ่มได้ เช่น วันที่ของเหตุการณ์ คุณสามารถ GROUP BY ค่าดังกล่าวก่อน แล้วจึงคำนวณ MIN/MAX ในภายหลัง ซึ่งจะแสดงค่าต่ำสุดหรือสูงสุดที่ผ่านเกณฑ์การรวม

ตัวอย่าง

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

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

ตัวอย่าง

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

เกี่ยวกับผลลัพธ์ที่เป็นจำนวนเต็ม

แม้ว่า Ads Data Hub จะแทรกสัญญาณรบกวนโดยอัตโนมัติสำหรับฟังก์ชันการรวมเหล่านี้ แต่ลายเซ็นของฟังก์ชันจะไม่เปลี่ยนแปลง เนื่องจากฟังก์ชันอย่าง COUNT หรือ SUM ของ INT64 จะแสดงผลเป็น INT64 ส่วนทศนิยมของผลลัพธ์ที่มีการเพิ่มสัญญาณรบกวนจึงจะ ปัดเศษ โดยปกติแล้วค่านี้จะถือว่าไม่มีนัยสำคัญเมื่อเทียบกับขนาดของผลลัพธ์และ สัญญาณรบกวน

หากต้องการความละเอียดของทศนิยมในผลลัพธ์ ให้หลีกเลี่ยงการเขียนฟังก์ชันที่ส่งคืน INT64 เช่น โดยใช้ SUM กับอินพุตที่ส่งไปยัง FLOAT64

เกี่ยวกับผลลัพธ์เชิงลบ

ในทางทฤษฎีแล้ว ความผันผวนที่มีค่าต่ำมากอาจส่งผลให้เกิดตัวเลขติดลบ แม้ว่าในเชิงความหมายแล้วการค้นหาไม่ควรเป็นไปได้ก็ตาม เพื่อให้คงลักษณะการทำงานตามที่คาดไว้ ระบบจะจำกัดรูปแบบทั้งหมดของ COUNT และ COUNTIF เป็น 0 โดยอัตโนมัติ เพื่อให้ไม่เคยให้ผลลัพธ์เป็นลบ หากต้องการให้ฟังก์ชันอื่นมีลักษณะการทำงานแบบเดียวกันนี้ เช่น SUM คุณสามารถจำกัดผลลัพธ์ด้วยตนเองโดยใช้ GREATEST(0, SUM(...))

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

กลุ่มสาธารณะ

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

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

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

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

  • โดยมาจากตารางสาธารณะ (ตารางหรือSELECT ที่ไม่มีข้อมูลผู้ใช้ Ads Data Hub)
  • โดยมี SELECT DISTINCT เพื่อบังคับใช้ค่าที่ไม่ซ้ำกัน
  • โดยจะรวมเข้ากับคําค้นหาด้วย OUTER JOIN ในคอลัมน์แต่ละรายการ

เมื่อคําค้นหามีสิทธิ์สําหรับกลุ่มสาธารณะ UI ของ Ads Data Hub จะแสดงข้อความการตรวจสอบต่อไปนี้ "Join รองรับกลุ่มสาธารณะและไม่ต้องใช้เกณฑ์การรวม"

ตัวอย่างการค้นหากลุ่มสาธารณะ

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT age_group_id FROM adh.age_group)
ON demographics.age_group = age_group_id
GROUP BY age_group_id
SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT * FROM UNNEST([1, 2, 3]) AS age_group_id)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

ในตัวอย่างแรก ระบบจะรวม adh.google_ads_impressions table ที่ได้รับการปกป้องเข้ากับตาราง adh.age_group ที่ไม่มีข้อมูลผู้ใช้ในคอลัมน์ age_group_id คอลัมน์ age_group_id ตารางสาธารณะเดียวกันจะปรากฏใน ข้อความ GROUP BY

ในทำนองเดียวกัน ในตัวอย่างที่ 2 adh.google_ads_impressions ตารางที่ได้รับการป้องกันจะเข้าร่วมกับตารางสาธารณะ ซึ่งระบุอย่างชัดเจนเป็น UNNEST([1, 2, 3]) โปรดทราบว่าในทั้ง 2 ตัวอย่าง คีย์การจัดกลุ่ม age_group_id มาจากตารางสาธารณะ

นอกจากนี้ คุณยังระบุรายการการจัดกลุ่มหลายรายการได้ด้วย เช่น

SELECT campaign_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT campaign_id, customer_id FROM adh.google_ads_campaign)
USING (campaign_id, customer_id)
GROUP BY campaign_id, customer_id
SELECT p.campaign_id, p.browser, COUNT(*) FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
  SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
  CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
  ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY campaign_id, browser;

หากต้องการจัดโครงสร้าง RIGHT OUTER JOIN อย่างถูกต้องด้วยการใช้คิวรีย่อยที่กำหนดกลุ่มสาธารณะ ให้ตรวจสอบว่าคำสั่ง SELECT DISTINCT ภายในคิวรีย่อยมีเฉพาะฟิลด์ที่ใช้ใน อนุประโยค ON ของ JOIN เท่านั้น ฟิลด์เดียวกันนี้ต้องอยู่ในเมนเคียวรีด้วย GROUP BY ตัวอย่างเช่น การค้นหาต่อไปนี้ จะไม่มีสิทธิ์สำหรับกลุ่มสาธารณะ

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (
  SELECT DISTINCT * -- Incorrect: May include fields not in the JOIN/GROUP BY
  FROM adh.age_group
)
  ON demographics.age_group = age_group_id
GROUP BY age_group_id

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

ข้อควรระวัง:

  • หากตารางสาธารณะมีค่าคีย์การจัดกลุ่มจํานวนมาก คุณอาจได้รับหลายแถวที่มีข้อมูลน้อยหรือไม่มีข้อมูลเลย และแถวเหล่านี้ทั้งหมด จะได้รับการรายงานว่ามีผลกระทบจากสัญญาณรบกวนสูง ในกรณีนี้ คุณควรพิจารณา ระบุรายการคีย์ที่เล็กลงอย่างชัดเจนโดยมีเฉพาะค่าที่คุณ สนใจ
  • แม้ว่ากลุ่มสาธารณะจะไม่ระงับแถว แต่ผลลัพธ์ที่คำนวณแล้วอาจแสดงเป็น null เนื่องจากการจำกัดโดยนัยเมื่อมีข้อมูลไม่เพียงพอที่จะคำนวณ ขอบเขต โดยปกติแล้วปัญหานี้จะเกิดขึ้นเมื่อค่าอินพุตทั้งหมดเป็น 0 หรือ Null หรือเมื่อมีผู้ใช้เพียงไม่กี่รายที่ส่งค่าที่ไม่ใช่ Null หากต้องการแก้ไขข้อบกพร่องนี้ เราขอแนะนําให้ เพิ่มCOUNT(DISTINCT user_id)การรวบรวมเพื่อยืนยันจํานวนผู้ใช้ ที่ทําให้เกิดพาร์ติชัน โปรดทราบว่า COUNT(DISTINCT user_id) ใช้การจำกัดที่ชัดเจน ซึ่งทำให้มีประโยชน์ในการระบุพาร์ติชันแบบกระจัดกระจาย

GROUP BY ROLLUP

GROUP BY ROLLUP ขยายเงื่อนไข GROUP BY เพื่อรวมแถวเพิ่มเติม ซึ่งแสดงผลรวมย่อยและผลรวมทั้งหมดตามลำดับชั้นที่กำหนดไว้ใน รายการจัดกลุ่ม ใน Ads Data Hub GROUP BY ROLLUP จะใช้ได้เมื่อใช้ Noise Injection เท่านั้น ไวยากรณ์เป็นไปตามข้อกำหนดของ BigQuery มาตรฐาน

ยอดรวมที่สอดคล้องกันในกลุ่มสาธารณะ

เมื่อใช้ Noise Injection ระบบจะใช้สัญญาณรบกวนแยกกันในแต่ละระดับของการรวม ซึ่งหมายความว่ายอดรวมอาจไม่สอดคล้องกันอย่างสมบูรณ์ ดังนั้น ยอดรวมย่อยจึงอาจไม่เท่ากับยอดรวมทั้งหมด (เช่น ผลรวมของจำนวนเมืองอาจ ไม่ตรงกับยอดรวมของภูมิภาค)

เมื่อใช้ GROUP BY ROLLUP ร่วมกับกลุ่มสาธารณะ Ads Data Hub จะขจัดความไม่สอดคล้องนี้ในผลลัพธ์ ซึ่งเป็นไปได้ เนื่องจากไม่มีการกรองผลลัพธ์ออกเนื่องจากมีการกำหนดเกณฑ์ ซึ่งหมายความว่าจำนวนของเมืองจะรวมกันเป็นจำนวนของภูมิภาคที่เกี่ยวข้อง (หมายเหตุ: สำหรับผลลัพธ์ที่เป็นจำนวนเต็ม อาจมีความแตกต่างเล็กน้อยเนื่องจากข้อผิดพลาดในการปัดเศษจุดลอยตัว)

ประโยชน์ของการใช้กลุ่มสาธารณะกับ ROLLUP

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

เราขอแนะนำเป็นอย่างยิ่งให้ใช้ GROUP BY ROLLUP กับกลุ่มสาธารณะทุกครั้งที่ เป็นไปได้เพื่อรับประโยชน์จากข้อดีเหล่านี้

ตัวอย่างของ ROLLUP ที่มีกลุ่มสาธารณะ

ROLLUP ด้วยแป้นเดียว

การใช้ตาราง

SELECT country_code, COUNT(1) AS count
FROM adh.google_ads_impressions
RIGHT OUTER JOIN
 (SELECT DISTINCT country_code FROM adh.city)
 ON location.country = country_code
GROUP BY ROLLUP (country_code);

วิธีใช้รายการแบบอินไลน์

SELECT country_code, COUNT(1) AS count
FROM adh.google_ads_impressions
RIGHT OUTER JOIN
 (SELECT DISTINCT * FROM UNNEST(['US', 'CA', 'CN', 'MX']) AS country_code)
 ON location.country = country_code
GROUP BY ROLLUP (country_code);

ตัวอย่างผลลัพธ์

country_code count
CN 6155
CA 16439
สหรัฐอเมริกา 256695
MX 10780
Null 290067

แถวที่มี NULL สำหรับ country_code แสดงยอดรวม ผลรวมของ จำนวนประเทศแต่ละประเทศ ซึ่งเท่ากับ 290069 ใกล้เคียงกับแถวผลรวมทั้งหมด 290067 มาก โดยความแตกต่างเล็กน้อยเกิดจากการปัดเศษ

ROLLUP ที่มีคีย์การจัดกลุ่มหลายรายการ

SELECT p.campaign_id, p.browser, COUNT(*) as count
FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY ROLLUP (campaign_id, browser);

ตัวอย่างผลลัพธ์

campaign_id browser count หมายเหตุ
1 Chrome ...
1 อื่นๆ ...
2 Chrome ...
2 อื่นๆ ...
1 Null ... ยอดรวมย่อยสำหรับ campaign_id = 1
2 Null ... ยอดรวมย่อยสำหรับ campaign_id = 2
Null Null ... รวมทั้งหมด

ROLLUP ที่มีชุดสินค้าที่จัดกลุ่มได้

หากต้องการถือว่าหลายคอลัมน์เป็นหน่วยเดียวภายในลําดับชั้นการสะสม ให้ใส่วงเล็บ ครอบคอลัมน์เหล่านั้น เช่น ROLLUP ((column1, column2), column3) ซึ่งจะ สรุปตามคู่ (campaign_id, browser) เป็นเอนทิตีเดียว

GROUP BY ROLLUP ((campaign_id, browser)) จะสร้างผลรวมย่อยสำหรับรายการต่อไปนี้

  • (campaign_id, browser) - แบบละเอียด
  • () - ยอดรวม

ระบบจะไม่สร้างผลรวมย่อยระดับกลางสำหรับ (campaign_id) เท่านั้น

SELECT p.campaign_id, p.browser, COUNT(*) AS count
FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY ROLLUP ((campaign_id, browser));

ตัวอย่างผลลัพธ์

campaign_id browser count หมายเหตุ
1 Chrome ...
1 อื่นๆ ...
2 Chrome ...
2 อื่นๆ ...
Null Null ... รวมทั้งหมด

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


รูปแบบการค้นหาที่รองรับ

สำคัญ: แนวทางปฏิบัติแนะนำมาตรฐานส่วนใหญ่ของ Ads Data Hub ยังคงใช้ได้กับคําค้นหาที่ใช้ Noise Injection โดยเฉพาะอย่างยิ่ง เราขอแนะนำ ให้คุณอ่านคำแนะนำเกี่ยวกับการค้นหาข้อมูลเดียวกันซ้ำๆ

ส่วนนี้อธิบายรูปแบบการค้นหาที่รองรับเมื่อเรียกใช้การค้นหาโดยใช้ Noise Injection

การรวบรวมข้อมูลระดับผู้ใช้

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

การจัดกลุ่มตาม external_cookie ไม่เพียงพอ แม้ว่าจะใช้ external_cookie เพื่อ รวมตาราง *_match กับตารางที่ลูกค้าเป็นเจ้าของได้ แต่การรวบรวมข้อมูลผู้ใช้รายเดียว ควรจัดกลุ่มตามคอลัมน์ user_id อย่างชัดเจน ไม่ใช่แค่คอลัมน์ external_cookie

ตัวอย่างฟังก์ชันรวมข้อมูล

WITH user_paths AS (
  # Grouping by user_id, no noise needed, all functions allowed
  SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;

ตัวอย่างฟังก์ชันการวิเคราะห์

WITH events AS (
  # Partitioning by user_id, no noise needed, all functions allowed
  SELECT
    campaign_id,
    ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
  FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;

การรวมข้อมูลแบบคู่ขนาน

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

ตัวอย่าง

WITH result_1 AS (
  # Noise applied here to num_impressions
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
  GROUP BY 1
), result_2 AS (
  # Noise applied here to num_clicks
  SELECT campaign_id, COUNT(*) AS num_clicks
  FROM adh.google_ads_creative_conversions
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

ข้อมูลรวมที่รวมกับข้อมูลแบบไม่รวม

เนื่องจาก Ads Data Hub รองรับเฉพาะกรอบเวลาวิเคราะห์ที่แบ่งพาร์ติชันตาม user_id จึงเป็นวิธีแก้ปัญหาทั่วไปในการรวบรวมผลลัพธ์เหล่านี้แยกกันและ การผนวกภายในตารางก่อนที่จะรวบรวมอีกครั้ง

ตัวอย่าง

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

โหมดเสียงรบกวนไม่แนะนำให้รวมผลลัพธ์รวมอีกครั้ง เช่น AVG(campaign_imps)


รูปแบบการค้นหาที่ไม่รองรับ

ส่วนนี้จะอธิบายรูปแบบการค้นหาที่ไม่รองรับเมื่อเรียกใช้การค้นหาโดยใช้ Noise Injection

ผลการค้นหาที่ซ้ำกัน

ในโหมด Noise Injection Ads Data Hub จะจำกัดความถี่ที่คุณสามารถทำซ้ำการรวมข้อมูลเดียวกัน หากถึงขีดจำกัดดังกล่าว การค้นหาในโหมด Noise Injection จะเสียสิทธิ์เข้าถึงวันที่ที่มีการค้นหาบ่อยในชุดข้อมูล ตัวอย่างกรณีที่อาจเกิดขึ้นมีดังนี้

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

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

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

ในกรณีนี้ คุณควรเรียกใช้การค้นหาในกลุ่มวันที่ที่แยกกัน

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

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

ในกรณีนี้ คุณควรเรียกใช้คิวรีนี้เพียงครั้งเดียวเนื่องจากผลลัพธ์จะไม่เปลี่ยนแปลง

การทำซ้ำการรวมจะเกิดขึ้นเมื่อมีการทำซ้ำการรวมเดียวกัน หลายครั้งภายในคําค้นหา

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

ในกรณีนี้ คุณควรนำการทำซ้ำออก 1 รายการ

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

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

หากมีเงื่อนไขที่คล้ายกันมากสำหรับผู้ใช้บางกลุ่ม คุณอาจ พิจารณาเขียนคำค้นหาใหม่ให้มีเพียง COUNT รายการเดียว

การทำซ้ำแถวเกิดขึ้นเมื่อมีการรวมตาราง Ads Data Hub กับตาราง BigQuery ในลักษณะที่แต่ละแถวจากตาราง Ads Data Hub ตรงกับหลายแถวในตาราง BigQuery ตัวอย่างเช่น การค้นหาต่อไปนี้จะสร้างการทำซ้ำหากมีหลายแถวที่มีรหัสแคมเปญเดียวกันใน bq_table

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

ในกรณีนี้ คุณควรปรับโครงสร้างคำค้นหาเพื่อให้ bq_table มี เพียง 1 แถวต่อค่าคีย์การรวม (campaign_id ในกรณีนี้)

โปรดทราบว่าการเลิกซ้อนอาร์เรย์จากตาราง Ads Data Hub อาจทำให้เกิดผลลัพธ์เดียวกันหากผู้ใช้ส่วนใหญ่มีอาร์เรย์ของค่าเหมือนกัน

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

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

ดูข้อมูลเกี่ยวกับแนวทางปฏิบัติแนะนำอื่นๆ สำหรับการค้นหา

เกี่ยวกับกรอบเวลามองย้อนกลับ

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

ตัวอย่างเช่น หากคุณกำลังสร้างรายงานเมตริกตามวันที่ซึ่งรีเฟรชทุกวัน

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

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

คุณยังคงคำนวณช่วงวันที่ก่อนหน้าใหม่เพื่อรีเฟรชผลลัพธ์ได้ (เช่น เพื่อ พิจารณาข้อมูลที่มาถึงช้า) แต่ควรหลีกเลี่ยงการคำนวณผลลัพธ์เดียว ซ้ำหลายครั้ง ดังที่อธิบายไว้ก่อนหน้านี้

การรวบรวมข้อมูลเดิมซ้ำโดยตรง

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

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

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

หากหลีกเลี่ยงการรวบรวมข้อมูลหลายชั้นไม่ได้ คุณสามารถแก้ไขคำเตือนได้โดย ส่งออกผลลัพธ์จากชั้นแรกโดยตรงแทน หากต้องการดำเนินการนี้ภายในงานเดียวโดยไม่เปลี่ยนผลลัพธ์ของสคริปต์ ให้สร้างตารางชั่วคราว (หรือตารางที่ส่งออกไปยังโปรเจ็กต์ BigQuery) ด้วยไวยากรณ์ OPTIONS(privacy_checked_export=true) เช่น

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

ดูข้อมูลเพิ่มเติมเกี่ยวกับตารางชั่วคราว

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

User-ID ที่ไม่ได้เข้าร่วม

คําค้นหาในโหมดสัญญาณรบกวนต้องไม่รวมข้อมูลจากผู้ใช้ที่แยกกันไว้ในแถวเดียว ยกเว้นเมื่อทําการรวมที่มีสัญญาณรบกวน ด้วยเหตุนี้ การรวมข้อมูล Ads Data Hub ที่ไม่ได้รวบรวมจึงควรรวมในคอลัมน์ user_id อย่างชัดเจน

การค้นหานี้ไม่ได้รวมคอลัมน์ user_id อย่างชัดเจน ซึ่งส่งผลให้เกิด คำเตือนการตรวจสอบ:

SELECT 
FROM adh.google_ads_impressions
JOIN adh.google_ads_creative_conversions USING(impression_id)

การรวมเช่นนี้อาจทํางานไม่เป็นไปตามที่คาดไว้ เนื่องจากจะมีเฉพาะแถวที่มีค่า user_id เดียวกันเท่านั้นที่จะตรงกัน คุณแก้ไขปัญหานี้ได้โดยปรับแก้USINGให้ระบุuser_idอย่างชัดเจน เช่น USING(impression_id, user_id)

โปรดทราบว่าข้อจำกัดนี้มีผลกับการรวมระหว่างตาราง Ads Data Hub เท่านั้น (ยกเว้นตารางมิติข้อมูล) โดยจะไม่มีผลกับตารางที่ลูกค้าเป็นเจ้าของ ตัวอย่างเช่น เราอนุญาตให้ทำดังนี้

SELECT 
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

การรวมด้านขวาของ Ads Data Hub กับ BigQuery

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

ทั้ง 2 คำค้นหานี้จะทำให้เกิดคำเตือนการตรวจสอบ เนื่องจากอนุญาตให้มี แถวที่ไม่ตรงกันซึ่งไม่มีตัวระบุผู้ใช้ในฝั่ง Ads Data Hub

SELECT 
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)
SELECT 
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)

โปรดทราบว่าการรวมทั้ง 2 แบบจะใช้ได้หากมีการกลับลำดับของตาราง นอกจากนี้ ยังมีข้อยกเว้นสำหรับตาราง RDID ที่เข้าร่วมโดยตรงใน device_id_md5 ด้วย ตัวอย่างเช่น การค้นหาต่อไปนี้จะทำงานโดยไม่มีคำเตือน

SELECT 
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)

ข้อมูลสรุปแถวที่กรอง

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

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

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

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

ตารางที่สร้างในโหมดผสม

ตารางที่ไม่ได้ส่งออกใน Ads Data Hub จะใช้ได้เฉพาะกับโหมดความเป็นส่วนตัวเดียวกันกับที่สร้างตาราง คุณไม่สามารถสร้างตารางในโหมดการรวบรวมปกติและใช้ในโหมด Noise Injection หรือในทางกลับกัน (เว้นแต่จะส่งออกตารางนั้นไปยัง BigQuery ก่อน)