แนวทางปฏิบัติที่ดี

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ฮับข้อมูลโฆษณาจำกัดจำนวนครั้งทั้งหมดที่คุณสามารถค้นหาข้อมูลเดียวกัน ดังนั้น คุณควรพยายามจำกัดจำนวนครั้งที่เข้าถึงข้อมูลหนึ่งๆ

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

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

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

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

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

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

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

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

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

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

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

คุณรวมผลลัพธ์ (ใน BigQuery) จากการค้นหาการรวบรวมหลายรายการ (จากฮับข้อมูลโฆษณา) ได้ ผลลัพธ์ที่คำนวณโดยใช้การค้นหาทั่วไปจะแชร์สคีมาสุดท้าย

การค้นหาต่อไปนี้จะใช้ผลลัพธ์แต่ละรายการของ 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

แนวทางปฏิบัติแนะนำ: พิจารณา User-ID ที่เป็น 0 ในผลลัพธ์

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

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

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

หมายเหตุ: เหตุการณ์ที่มี User-ID เป็น 0 จะนับเป็นผู้ใช้รายเดียวในจำนวนผู้ใช้ขั้นต่ำ 50 รายต่อแถว ไม่ว่าจะมีผู้ใช้จริงที่สร้างเหตุการณ์เหล่านี้กี่รายก็ตาม

---

ประสิทธิภาพ

หลีกเลี่ยงการรวมข้อมูลอีกครั้ง

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

คำค้นหาที่รวมผลลัพธ์ที่รวบรวมไว้แล้ว เช่น ในกรณีของคำค้นหาที่มี 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

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

• ข้อมูลอินพุตและแหล่งข้อมูล (I/O): การค้นหาอ่านข้อมูลกี่ไบต์
• การสื่อสารระหว่างโหนด (การสับเปลี่ยน): การค้นหาของคุณส่งไบต์ไปยังขั้นตอนถัดไปกี่ไบต์
• การคำนวณ: คำค้นหาของคุณต้องใช้ CPU มากน้อยเพียงใด
• เอาต์พุต (การสร้างข้อมูล): การค้นหาเขียนไบต์กี่ไบต์
• รูปแบบการค้นหาที่ไม่ควรใช้: การค้นหาของคุณเป็นไปตามแนวทางปฏิบัติแนะนำของ SQL หรือไม่

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

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

ที่ปรึกษาด้านคำค้นหา

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

ทริกเกอร์มีรูปแบบต่อไปนี้

• การรวมคิวรีแบบรวม
• การรวมข้อมูลที่ไม่ได้รวบรวมกับผู้ใช้ที่อาจแตกต่างกัน
• ตารางชั่วคราวที่กำหนดแบบเรียกซ้ำ

วิธีใช้คำแนะนำในการค้นหา

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