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

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

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

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

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

כשהדבר אפשרי, כדאי להשתמש בנתונים של 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 אם הסכמות התאימו.

אופטימיזציה והבנה של צירופי טבלאות

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

לא כל החשיפות משויכות לקליקים או להמרות. לכן, אם INNER 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)

שימוש בסיכומי שורות מסוננות

שיטה מומלצת: מוסיפים לשאילתות סיכומי שורות מסוננות.

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

התייחסות למזהי משתמשים שהועברו לאפס

שיטה מומלצת: צריך להביא בחשבון מזהי משתמשים שהועברו לאפס בתוצאות.

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

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

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

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