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

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

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

• AB Tasty: בדיקה בצד השרת
• Optimizely: בדיקה בצד השרת
• VWO: בדיקות FullStack

תוצאות בדיקת 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, כדי לסנן את התוצאות לפי קבוצה.