מעקב אחר ביצועים

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

מדידת הביצועים של הדף

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

כדי להתחיל למדוד את הביצועים, מומלץ לשלב בין הגישות הבאות:

• מעקב סינתטי

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

• מעקב אחרי משתמשים אמיתיים (RUM)

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

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

בחירת המדדים

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

מלבד ביצועי הדף, מומלץ גם למדוד ערכים עסקיים ספציפיים למודעות. אפשר לקבל מידע כמו חשיפות, קליקים ונתוני צפייה לפי מיקום מודעה בדוחות של Google Ad Manager.

בדיקת השינויים

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

בדיקות אוטומטיות

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

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

• מעקב אחר ביצועים באמצעות Lighthouse CI
• בדיקות של Publisher Ads Audits לשימוש באינטגרציה רציפה (CI) של Lighthouse

בדיקת A/B

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

במהלך בדיקת A/B, וריאנטים שונים של דף מוצגים למשתמשים באופן אקראי. אפשר להשתמש בשיטה הזו כדי להציג גרסה שונה של הדף לאחוז קטן מתנועת הגולשים הכוללת, בזמן שהרוב ימשיכו לראות את הגרסה הלא שונה. בשילוב עם RUM, אפשר להעריך את הביצועים היחסיים של שתי הקבוצות כדי לקבוע איזו מהן מניבה ביצועים טובים יותר, בלי לסכן 100% מתנועת הגולשים.

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

כלים כמו Optimizely ו-Google Optimize יכולים לעזור לכם להגדיר ולהריץ בדיקות A/B. עם זאת, חשוב לשים לב שבדיקת A/B מבוססת-תגים (הגדרת ברירת המחדל של הכלים האלה) עלולה בעצמה להשפיע לרעה על הביצועים ולספק תוצאות מטעות. לכן מומלץ מאוד לבצע שילוב בצד השרת:

• Google Optimize: ניסויים בצד השרת
• אופטימיזציה: בדיקה בצד השרת

תוצאות של בדיקות A/B

כדי למדוד את ההשפעה של שינוי באמצעות בדיקת A/B, אתם אוספים מדדים מקבוצת הבקרה וגם מקבוצת הניסוי ומשווים אותם זה לזה. כדי לעשות זאת, צריך לדעת איזו תנועה שייכת לאיזו קבוצה.

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

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

// On control group (A) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'a');

// On experimental group (B) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'b');

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