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

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

ดูประโยชน์ของการใช้ Noise Injection

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

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

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

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

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

การตรวจสอบความแตกต่าง: Noise Injection ไม่ได้อาศัยการตรวจหาข้อมูลที่ต่างกันที่มีอยู่ใน Ads Data Hub เมื่อใช้ Noise Injection ระบบจะปิดใช้การตรวจหาข้อมูลที่ต่างกัน

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

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

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

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

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

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

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

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

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

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

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 จะแสดงข้อความการตรวจสอบต่อไปนี้ "การรวมรองรับกลุ่มสาธารณะและไม่ต้องใช้เกณฑ์การรวม"

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

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;

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

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

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 จะไม่ได้รับสัญญาณรบกวนและอนุญาตให้ใช้ฟังก์ชันใดก็ได้ การรวบรวมระดับผู้ใช้ที่ไม่ได้จัดกลุ่มอย่างชัดเจนตาม 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 จึงเป็นวิธีแก้ปัญหาทั่วไปในการรวบรวมผลลัพธ์เหล่านี้แยกกันและ การผนวกภายในตารางก่อนที่จะรวบรวมอีกครั้ง การค้นหาเหล่านี้รองรับในโหมด Noise Injection และมักจะมีประสิทธิภาพดีกว่าในโหมดการตรวจหาข้อมูลที่ต่างกัน เนื่องจากข้อกำหนดด้านความเป็นส่วนตัวได้รับการแก้ไขก่อนหน้านี้

ตัวอย่าง

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

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

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

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

การค้นหาที่รวมวันนี้

การค้นหาในโหมด Noise Injection ไม่รองรับการค้นหาข้อมูลของวันนี้ (เราไม่แนะนำให้ทำเช่นนี้ในโหมดตรวจสอบความแตกต่าง) คุณเลือกวันที่ปัจจุบันสำหรับคำค้นหาที่ใช้ 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 ที่ไม่ได้เข้าร่วม

คําค้นหาในโหมด Noise Injection ต้องไม่รวมข้อมูลจากผู้ใช้ที่แยกกันไว้ในแถวเดียว ยกเว้นเมื่อทําการรวมข้อมูลที่มีสัญญาณรบกวน ด้วยเหตุนี้ การรวมข้อมูล 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 ไม่รองรับข้อกำหนดการสรุปแถวที่กรองแล้ว ฟีเจอร์นี้มักไม่จำเป็นเมื่อมีสัญญาณรบกวนเนื่องจากอัตราการกรองที่ต่ำกว่าและไม่มีการกรองจากการตรวจสอบความแตกต่าง

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

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 ก่อน)