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

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

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

פיתוח שאילתות על נתוני ארגז חול

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

במידת האפשר, השתמש בנתוני ארגז חול במהלך פיתוח השאילתה. משימות שמשתמשות בנתונים מ-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)

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

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

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

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

שיטה מומלצת: כדאי להביא בחשבון את אפס מזהי משתמשים בתוצאות.

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

יועץ שאילתות

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

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

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

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