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