แนวทางปฏิบัติแนะนำ

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

ความเป็นส่วนตัวและความถูกต้องของข้อมูล

พัฒนาการค้นหาในข้อมูลแซนด์บ็อกซ์

แนวทางปฏิบัติแนะนำ: ค้นหาข้อมูลการใช้งานจริงเมื่อคุณอยู่ในสภาพแวดล้อมการใช้งานจริงเท่านั้น

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

หากต้องพัฒนาการค้นหาในข้อมูลจริง (เช่น เมื่อใช้ตารางการจับคู่) ให้เลือกช่วงวันที่และพารามิเตอร์อื่นๆ ที่ไม่น่าจะทับซ้อนกันสำหรับการทำซ้ำการค้นหาแต่ละครั้ง เพื่อลดโอกาสที่แถวจะทับซ้อนกัน สุดท้าย ให้เรียกใช้การค้นหาในช่วงข้อมูลที่ต้องการ

พิจารณาผลลัพธ์ที่ผ่านมาอย่างรอบคอบ

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

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

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

อย่าค้นหาข้อมูลของวันนี้

แนวทางปฏิบัติแนะนำ: อย่าเรียกใช้การค้นหาหลายรายการที่มีวันที่สิ้นสุดเป็นวันนี้

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

อย่าค้นหาข้อมูลเดียวกันมากเกินความจำเป็น

แนวทางปฏิบัติแนะนำ:

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

Ads Data Hub จำกัดจำนวนครั้งทั้งหมดที่คุณสามารถค้นหาข้อมูลเดียวกัน ดังนั้น คุณควรพยายามจำกัดจำนวนครั้งที่เข้าถึงข้อมูลชิ้นหนึ่งๆ

อย่าใช้การรวมมากกว่าที่จำเป็นในการค้นหาเดียวกัน

แนวทางปฏิบัติแนะนำ:

  • ลดจำนวนการรวมในการค้นหา
  • เขียนการค้นหาใหม่เพื่อรวมการรวมเมื่อเป็นไปได้

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

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

ควรเขียนการค้นหาที่นับเหตุการณ์โดยอิงตามชุดฟิลด์เดียวกันใหม่โดยใช้คำสั่ง GROUP BY

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

คุณสามารถรวมผลลัพธ์ใน BigQuery ด้วยวิธีเดียวกัน

ควรเขียนการค้นหาที่สร้างคอลัมน์จากอาร์เรย์แล้วรวมคอลัมน์เหล่านั้นในภายหลังใหม่เพื่อผสานขั้นตอนเหล่านี้

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

คุณสามารถเขียนการค้นหาก่อนหน้าใหม่ได้ดังนี้

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

การค้นหาที่ใช้ชุดฟิลด์ต่างๆ ในการรวมต่างๆ สามารถเขียนใหม่เป็นการค้นหาที่เฉพาะเจาะจงมากขึ้นหลายรายการ

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

คุณสามารถแยกการค้นหาก่อนหน้าออกเป็น

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

และ

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

คุณสามารถแยกผลลัพธ์เหล่านี้ออกเป็นการค้นหาที่แยกกัน separate queries สร้างและรวมตารางในการค้นหาเดียว single query หรือรวมผลลัพธ์เหล่านี้ด้วย UNION หากสคีมาเข้ากันได้

เพิ่มประสิทธิภาพและทำความเข้าใจการรวม

แนวทางปฏิบัติแนะนำ: ใช้ LEFT JOIN แทน INNER JOIN เพื่อรวมการคลิกหรือ Conversion กับการแสดงผล

การแสดงผลบางรายการไม่ได้เชื่อมโยงกับการคลิกหรือ Conversion ดังนั้น หากคุณใช้ INNER JOIN การคลิกหรือ Conversion กับการแสดงผล ระบบจะกรองการแสดงผลที่ไม่ได้เชื่อมโยงกับการคลิกหรือ Conversion ออกจากผลลัพธ์

แผนภาพเวนน์ 4 แผนภาพที่แสดงการรวมด้านซ้าย การรวมด้านขวา การรวมภายใน และการรวมด้านนอกทั้งหมด

รวมผลลัพธ์สุดท้ายบางรายการใน BigQuery

แนวทางปฏิบัติแนะนำ: หลีกเลี่ยงการค้นหา Ads Data Hub ที่รวมผลลัพธ์ที่รวมแล้ว ให้เขียนการค้นหา 2 รายการแยกกัน แล้วรวมผลลัพธ์ใน BigQuery

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

คุณสามารถรวมผลลัพธ์ (ใน BigQuery) จากการค้นหาการรวมหลายรายการ (จาก Ads Data Hub) ผลลัพธ์ที่คำนวณโดยใช้การค้นหาทั่วไปจะมีสคีมาสุดท้ายเหมือนกัน

การค้นหาต่อไปนี้จะใช้ผลลัพธ์ Ads Data Hub แต่ละรายการ (campaign_data_123 และ campaign_data_456) แล้วรวมผลลัพธ์เหล่านั้นใน BigQuery

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

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

แนวทางปฏิบัติแนะนำ: เพิ่มข้อมูลสรุปแถวที่กรองในการค้นหา

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

พิจารณารหัสผู้ใช้ที่ตั้งค่าเป็น 0

แนวทางปฏิบัติแนะนำ: พิจารณารหัสผู้ใช้ที่ตั้งค่าเป็น 0 ในผลลัพธ์

ระบบอาจตั้งค่ารหัสของผู้ใช้ปลายทางเป็น 0 ด้วยเหตุผลหลายประการ เช่น การเลือกไม่รับการปรับโฆษณาตามโปรไฟล์ของผู้ใช้ เหตุผลด้านกฎระเบียบ เป็นต้น ดังนั้น ระบบจะใช้ user_id เป็นคีย์สำหรับข้อมูลที่มาจากผู้ใช้หลายราย

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

คุณสามารถยกเว้นข้อมูลนี้จากผลลัพธ์ได้โดยเพิ่ม WHERE user_id != "0" ในการค้นหา


ประสิทธิภาพ

หลีกเลี่ยงการรวมซ้ำ

แนวทางปฏิบัติแนะนำ: หลีกเลี่ยงการรวมหลายระดับในผู้ใช้

การค้นหาที่รวมผลลัพธ์ที่รวมแล้ว เช่น ในกรณีของการค้นหาที่มี GROUP BY หลายรายการหรือการรวมที่ซ้อนกัน จะต้องใช้ทรัพยากรมากขึ้นในการประมวลผล

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

คุณควรหลีกเลี่ยงรูปแบบต่อไปนี้

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

ควรเขียนการค้นหาที่ใช้การรวมหลายระดับใหม่ให้ใช้การรวมระดับเดียว

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

ควรแยกการค้นหาที่แยกได้ง่าย คุณสามารถรวมผลลัพธ์ใน BigQuery ได้

เพิ่มประสิทธิภาพสำหรับ BigQuery

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

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

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

เครื่องมือแนะนำการค้นหา

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

วิธีใช้เครื่องมือแนะนำการค้นหา

  • UI คำแนะนำจะปรากฏในเครื่องมือแก้ไขการค้นหาเหนือข้อความค้นหา
  • API ใช้เมธอด customers.analysisQueries.validate