แนวทางปฏิบัติแนะนำต่อไปนี้จะทำให้คุณมีเทคนิคในการพัฒนาคำค้นหาที่มุ่งเน้นความเป็นส่วนตัวและมีประสิทธิภาพ
ความเป็นส่วนตัวและความถูกต้องของข้อมูล
พัฒนาการค้นหาในข้อมูลแซนด์บ็อกซ์
แนวทางปฏิบัติแนะนำ: ค้นหาข้อมูลเวอร์ชันที่ใช้งานจริงเฉพาะเมื่ออยู่ในเวอร์ชันที่ใช้งานจริงเท่านั้น
ใช้ข้อมูลแซนด์บ็อกซ์ในระหว่างการพัฒนาการค้นหาทุกครั้งที่ทำได้ งานที่ใช้ข้อมูลแซนด์บ็อกซ์จะไม่ทำให้มีโอกาสเพิ่มเติมในการตรวจสอบความแตกต่างในการกรองผลการค้นหา นอกจากนี้ เนื่องจากไม่มีการตรวจสอบความเป็นส่วนตัว การค้นหาแซนด์บ็อกซ์จึงทำงานได้เร็วขึ้น ทำให้สามารถทำซ้ำได้รวดเร็วขึ้นระหว่างพัฒนาการค้นหา
หากคุณต้องสร้างการค้นหาในข้อมูลจริง (เช่น เมื่อใช้ตารางการจับคู่) เพื่อลดโอกาสที่แถวจะทับซ้อนกัน ให้เลือกช่วงวันที่และพารามิเตอร์อื่นๆ ที่ไม่น่าจะทับซ้อนกันสําหรับการค้นหาซ้ำๆ แต่ละครั้ง สุดท้าย ให้เรียกใช้การสืบค้นข้อมูลกับช่วงข้อมูลที่ต้องการ
พิจารณาผลลัพธ์ที่ผ่านมาอย่างรอบคอบ
แนวทางปฏิบัติแนะนำ: ลดโอกาสการทับซ้อนของชุดผลลัพธ์ระหว่างการค้นหาที่ใช้งานล่าสุด
โปรดทราบว่าอัตราการเปลี่ยนแปลงระหว่างผลการค้นหาจะส่งผลต่อแนวโน้มที่ระบบจะไม่แสดงผลการค้นหาในภายหลังเนื่องจากการตรวจสอบด้านความเป็นส่วนตัว ชุดผลลัพธ์ที่ 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)
ใช้ข้อมูลสรุปแถวที่กรอง
แนวทางปฏิบัติแนะนำ: เพิ่มสรุปแถวที่กรองแล้วลงในคำค้นหา
สรุปแถวที่กรองจะรวมข้อมูลที่กรองเนื่องจากการตรวจสอบความเป็นส่วนตัว จะรวมข้อมูลจากแถวที่กรองแล้วเพิ่มลงในแถวที่รับทั้งหมด แม้ว่าจะวิเคราะห์ข้อมูลที่กรองเพิ่มเติมไม่ได้ แต่ก็จะแสดงข้อมูลสรุปว่ามีการกรองข้อมูลออกจากผลลัพธ์มากน้อยเพียงใด
บัญชีสำหรับรหัสผู้ใช้ที่ไม่มีรหัส
แนวทางปฏิบัติแนะนำ: พิจารณารหัสผู้ใช้ที่เป็น 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
โดยทั่วไปแล้ว คำค้นหาที่ประสิทธิภาพน้อยกว่าจะทำงานได้ดีกว่า จำนวนงานที่ต้องทำจะขึ้นอยู่กับปัจจัยต่อไปนี้เมื่อประเมินประสิทธิภาพของคำค้นหา
- ข้อมูลอินพุตและแหล่งข้อมูล (I/O): คำค้นหาอ่านได้กี่ไบต์
- การสื่อสารระหว่างโหนด (สับเปลี่ยน): การค้นหาจะผ่านไปยังขั้นตอนถัดไปกี่ไบต์
- การคำนวณ: การค้นหาของคุณต้องใช้ CPU มากเพียงใด
- เอาต์พุต (การทำให้เป็นรูปธรรม): คำค้นหาของคุณเขียนกี่ไบต์
- รูปแบบต่อต้านการค้นหา: คำค้นหาของคุณเป็นไปตามแนวทางปฏิบัติแนะนำสำหรับ SQL ไหม
หากการดำเนินการค้นหาไม่เป็นไปตามข้อตกลงระดับการให้บริการหรือคุณพบข้อผิดพลาดเนื่องจากการใช้ทรัพยากรมากเกินไปหรือหมดเวลา โปรดพิจารณาสิ่งต่อไปนี้
- การใช้ผลลัพธ์จากการค้นหาก่อนหน้าแทนการคำนวณใหม่ เช่น ยอดรวมรายสัปดาห์อาจเป็นผลรวมที่คำนวณใน BigQuery ของคำค้นหาแบบรวมใน 7 วัน
- การแยกการค้นหาเป็นการค้นหาย่อยเชิงตรรกะ (เช่น การแยกการผนวกหลายรายการเป็นการค้นหาหลายรายการ) หรือการจำกัดชุดข้อมูลที่กำลังประมวลผล คุณรวมผลลัพธ์จากแต่ละงานเป็นชุดข้อมูลเดียวใน BigQuery ได้ แม้ว่าวิธีนี้อาจทำให้ใช้ทรัพยากรจนหมด แต่ก็อาจทำให้การค้นหาช้าลง
- หากคุณพบว่าทรัพยากรมีข้อผิดพลาดใน BigQuery ให้ลองใช้ตารางชั่วคราวเพื่อแบ่งการค้นหาออกเป็นการค้นหา BigQuery หลายรายการ
- การอ้างอิงตารางจำนวนน้อยลงในคำค้นหาเดียว เนื่องจากใช้หน่วยความจำจำนวนมากและอาจทำให้การค้นหาล้มเหลวได้
- การเขียนคำค้นหาใหม่เพื่อให้รวมตารางผู้ใช้น้อยลง
- การเขียนคำค้นหาใหม่เพื่อหลีกเลี่ยงการรวมตารางเดียวกันกลับเข้าไปในตัวเอง
ผู้แนะนำการค้นหา
หาก SQL ถูกต้องแต่อาจทำให้มีการกรองมากเกินไป Query Advisor จะแสดงคำแนะนำที่นำไปใช้ได้จริงในกระบวนการพัฒนาการค้นหาเพื่อช่วยคุณหลีกเลี่ยงผลลัพธ์ที่ไม่พึงประสงค์
ทริกเกอร์มีรูปแบบต่อไปนี้
- การเข้าร่วมการค้นหาย่อยแบบรวม
- การรวมข้อมูลที่ไม่ได้รวมกับผู้ใช้ที่เป็นไปได้แตกต่างกัน
- ตารางชั่วคราวที่กำหนดซ้ำๆ
วิธีใช้ Query Advisor
- UI คำแนะนำจะแสดงในตัวแก้ไขคำค้นหาเหนือข้อความค้นหา
- API. ใช้เมธอด
customers.analysisQueries.validate