שיטות מומלצות

השיטות המומלצות הבאות יספקו לכם טכניקות לפתח שאילתות שמתמקדות בשמירה על הפרטיות ושמניבות ביצועים טובים. לקבלת שיטות מומלצות ספציפיות לגבי שמריצים שאילתות במצב רעש, אפשר לעיין בקטעים על תמיכה או תמיכה לא נתמכים דפוסים של שאילתות בהחדרת רעש.

פרטיות ודיוק הנתונים

פיתוח שאילתות על נתונים ב-Sandbox

שיטה מומלצת: שליחת שאילתות על נתונים רק בסביבת הייצור.

כשהדבר אפשרי, השתמשו בנתונים מארגז החול במהלך פיתוח השאילתות. משימות שמשתמשות בנתונים מ-Sandbox לא כוללות הזדמנויות נוספות לבדיקות שונות לסינון תוצאות השאילתות. בנוסף, עקב היעדר בדיקות לאימות הפרטיות, השאילתות ב-Sandbox פועלות מהר יותר ואיטרציה מהירה יותר במהלך פיתוח השאילתות.

אם אתם צריכים לפתח שאילתות לגבי הנתונים עצמם (למשל, כשאתם משתמשים בטבלאות התאמה), כדי להקטין את הסבירות לחפיפה בין שורות, כדאי לבחור טווחי תאריכים ופרמטרים אחרים שלא סביר שיהיה חפיפה בכל איטרציה של השאילתה. לבסוף, מריצים את השאילתה על טווח הנתונים הרצוי.

חשוב לבחון תוצאות היסטוריות

שיטה מומלצת: הקטנת הסיכוי לחפיפה בין קבוצות תוצאות בין שאילתות שהופעלו לאחרונה.

חשוב לזכור ששיעור השינוי בין תוצאות השאילתה ישפיע על הסבירות שהתוצאות יושמטו מאוחר יותר עקב בדיקות לאימות הפרטיות. סביר להניח שהמערכת תשמיט קבוצה שנייה שדומה מאוד לקבוצת תוצאות שהוחזרה לאחרונה.

במקום זאת, כדי לצמצם את הסבירות לחפיפה משמעותית, כדאי לשנות פרמטרים מרכזיים בשאילתה, כמו טווחי תאריכים או מזהי קמפיינים.

אל תריץ שאילתות על נתוני היום

שיטה מומלצת: לא כדאי להריץ כמה שאילתות כשתאריך הסיום חל היום.

הרצה של כמה שאילתות עם תאריכי סיום שווים להיום תגרום בדרך כלל לסינון שורות. ההנחיות האלה רלוונטיות גם לשאילתות שפועלות זמן קצר לאחר חצות על הנתונים של אתמול.

לא מומלץ לשלוח שאילתות על אותם נתונים יותר מהנדרש

שיטות מומלצות:

  • בוחרים תאריכי התחלה וסיום קרובים מאוד.
  • במקום להריץ שאילתות על חלונות חופפים, מריצים את השאילתות על קבוצות נתונים נפרדות ואז צוברים את התוצאות ב-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 אם הסכימות תואמות.

אופטימיזציה והבנה של שאילתות איחוד (join)

שיטה מומלצת: השתמשו ב-LEFT JOIN במקום ב-INNER JOIN כדי לצרף קליקים או המרות לחשיפות.

לא כל החשיפות משויכות לקליקים או להמרות. לכן, אם מקבלים INNER JOIN קליקים או המרות מחשיפות, חשיפות שלא קשורות לקליקים או להמרות יסוננו מהתוצאות.

תמונה שמראה כמה סוגי איחוד (join) באמצעות דיאגרמות ון

מצטרפים לכמה תוצאות סופיות ב-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) שלא מופיעים בתוצאות החיפוש.

יש כמה סיבות אפשריות לכך שהמזהה של משתמש קצה מוגדר ל-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

באופן כללי, שאילתות שמניבות ביצועים נמוכים יותר. כשמעריכים את ביצועי השאילתות, כמות העבודה הנדרשת תלויה בגורמים הבאים:

אם הפעלת השאילתה לא עומדת בהסכמי רמת השירות (SLA) שלכם, או אם נתקלתם בשגיאות בגלל מיצוי של המשאבים או שתם הזמן הקצוב לתפוגה, כדאי לבדוק:

  • אנחנו משתמשים בתוצאות משאילתות קודמות במקום לחשב מחדש. לדוגמה, הסכום הכולל השבועי יכול להיות הסכום שמחושב ב-BigQuery עבור 7 שאילתות מצטברות ביום אחד.
  • פירוק שאילתות לשאילתות משנה לוגיות (למשל, פיצול של מספר שאילתות איחוד (join) למספר שאילתות), או הגבלה אחרת של קבוצת הנתונים שמעובדת. אפשר לשלב תוצאות ממשימות נפרדות למערך נתונים אחד ב-BigQuery. למרות שזה יכול לעזור למיצוי המשאבים, זה עלול להאט את השאילתה שלך.
  • אם המשאבים חורגים משגיאות ב-BigQuery, כדאי לנסות להשתמש בטבלאות זמניות כדי לפצל את השאילתה למספר שאילתות BigQuery.
  • הפניית פחות טבלאות בשאילתה אחת, כי הפעולה הזו צורכת כמויות גדולות של זיכרון ועלולה לגרום לשאילתה להיכשל.
  • שכתוב השאילתות כך שיצטרכו פחות טבלאות משתמשים.
  • לשכתב את השאילתות כדי להימנע מצירוף של אותה טבלה לעצמה.

יועץ שאילתות

אם ה-SQL תקין אבל יכול להפעיל סינון יתר, השאילתה avisor מציע ייעוץ פרקטי בתהליך פיתוח השאילתה, יעזרו לכם למנוע תוצאות לא רצויות.

הטריגרים כוללים את הדפוסים הבאים:

כדי להשתמש ביועץ השאילתות:

  • ממשק משתמש. המלצות יוצגו בעורך השאילתות שלמעלה את טקסט השאילתה.
  • API. משתמשים בשיטה customers.analysisQueries.validate.