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

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

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

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

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

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

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

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

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

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

คําค้นหาต่อไปนี้จะนําผลลัพธ์ของฮับข้อมูลโฆษณาแต่ละรายการ (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 ที่เป็น 0

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

คุณยกเว้นข้อมูลนี้จากผลการค้นหาได้โดยเพิ่ม 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