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

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

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

พัฒนาคำค้นหาเกี่ยวกับข้อมูลแซนด์บ็อกซ์

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

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

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

พิจารณาผลการค้นหาที่ผ่านมาอย่างรอบคอบ

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

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

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

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

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

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

รูปภาพแสดงการผนวกรวมหลายประเภทผ่านแผนภาพเวนน์

รวมผลลัพธ์สุดท้ายใน 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)

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

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

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

บัญชีสําหรับ User-ID ที่เป็นศูนย์

แนวทางปฏิบัติแนะนํา: พิจารณา User-ID ที่มีเลข 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 ถูกต้องแต่อาจทำให้เกิดการกรองที่มากเกินไป ข้อความค้นหา Advisor จะแสดงคำแนะนำที่นำไปใช้ได้จริงระหว่างกระบวนการพัฒนาการค้นหาเพื่อ ช่วยหลีกเลี่ยงผลลัพธ์ที่ไม่พึงประสงค์

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

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

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