หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ทำความเข้าใจว่าการแทรกสัญญาณรบกวนส่งผลต่อผลลัพธ์อย่างไร

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

การแทรกสัญญาณรบกวนใน Ads Data Hub จะเปลี่ยนผลการค้นหาดังนี้

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

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

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

การแทรกสัญญาณรบกวนใน 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

เรียกใช้การค้นหาโดยใช้การแทรกสัญญาณรบกวน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

นอกเหนือจากการรองรับผู้รวบรวมข้อมูลทั่วไปแล้ว 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_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: ตัวอักษรตัวเลขที่แสดงค่าที่ใหญ่ที่สุดที่จะรวมไว้ในการรวม

คำนวณ 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 ผลลัพธ์ของคําค้นหาที่ลบข้อมูลระบุตัวบุคคลออกจะได้รับการรวบรวมในกลุ่มต่างๆ ระบบจะใช้เกณฑ์การรวมเพื่อให้มั่นใจว่ามีผู้ใช้จำนวนเพียงพอในกลุ่มเพื่อปกป้องข้อมูลผู้ใช้แต่ละราย กระบวนการพิจารณากลุ่มที่เผยแพร่ได้เรียกว่า "การเลือกพาร์ติชัน"

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

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

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

โดยมาจากตารางสาธารณะ (ตารางหรือSELECT ที่ไม่มีข้อมูลผู้ใช้ Ads Data Hub)
โดยมี SELECT DISTINCT เพื่อบังคับใช้ค่าที่ไม่ซ้ำ
โดยจะรวมเข้ากับคำค้นหาด้วย OUTER 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 คอลัมน์ตารางสาธารณะเดียวกันจะปรากฏใน ข้อความ GROUP BYage_group_id

ในทำนองเดียวกัน ในตัวอย่างที่ 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;

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

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

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

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

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

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

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

ตัวอย่าง

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)

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

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

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

การค้นหาในโหมดสัญญาณรบกวนไม่รองรับการค้นหาข้อมูลของวันนี้ (เราไม่แนะนำให้ทำเช่นนี้ในโหมดตรวจสอบความแตกต่าง) คุณเลือกวันที่ปัจจุบันสำหรับคำค้นหาที่ใช้การแทรกสัญญาณรบกวนไม่ได้

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

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

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

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

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

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

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

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

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

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

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

ระบบจะใช้ 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

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

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

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)

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

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

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

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

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

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

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