מבוא לתיוג בצד השרת

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

בתצורת תיוג רגילה ללא תיוג בצד השרת, המערכת מסתמכת על מאגר (container) בדף כדי לשלוח נתוני מדידה לשרתים שונים לאיסוף נתונים. באיור 1 מוצגת דוגמה לאופן שבו מאגר תגים באינטרנט של Tag Manager שפועל בדפדפן אינטרנט שולח נתונים למספר שרתים.

תרשים של אתר שנוסף לו מאגר תגים באינטרנט של Google Tag Manager

איור 1: תרשים של אתר שנוסף לו מאגר תגים באינטרנט של Google Tag Manager.

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

תרשים של אתר שנוסף לו תיוג באמצעות מאגר תגים בצד השרת.

איור 2: דוגמה להגדרת תיוג שמשתמשת במאגר תגים בצד השרת.

השרת פועל בפרויקט שלכם ב-Google Cloud Platform – או בסביבה אחרת לבחירתכם – ורק לכם יש גישה לנתונים בשרת עד שתבחרו לשלוח אותם למקום אחר. יש לכם שליטה מלאה על אופן היצירה של הנתונים האלה ועל המקום שאליו הם מנותבים מהשרת. התגים נוצרים באמצעות הטכנולוגיה של JavaScript בסביבת חול. ההרשאות מאפשרות לכם לראות מה התג יכול לעשות, והמדיניות מאפשרת לכם להגדיר גבולות סביב המאגר.

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

המודל הזה מציג שתי שאלות חשובות לגבי קונטיינרים של שרתים:

  • איך נתוני המדידה עוברים מהמכשיר של המשתמש למאגר התגים בצד השרת?
  • איך נתוני מדידה שנשלחים למאגר תגים בצד השרת הופכים לאירוע?

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

איך פועלים לקוחות

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

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

תרשים של אתר שנוסף לו תיוג באמצעות מאגר תגים בצד השרת.

איור 3: כל מקור נתונים מטופל על ידי לקוח אחר.

לקוחות מקבלים נתוני מדידה ממכשיר. נניח שאתם רוצים למדוד את פעילות המשתמשים בשלושה מקומות: אתר, אפליקציה לטלפון וטוסטרים חכמים. באתר שלכם נעשה שימוש ב-Google Analytics, באפליקציה של הטלפון נעשה שימוש ב-Firebase Analytics ובתנור המאפה נעשה שימוש בפרוטוקול קנייני שנקרא 'ToastMeasure'.

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

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

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

אירועים הם דברים שקורים ואתם רוצים למדוד. הם יכולים להיות כל דבר: start_toasting, finish_toasting או buy_bread. יש כמה המלצות לגבי המבנה של האירועים שהלקוח יוצר, אבל הדרישה היחידה היא ששאר הרכיבים בקונטיינר יבינו אותם.

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

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

למרבה המזל, Tag Manager מטפל בחלק גדול מהמשימות האלה בשבילכם. מאגרי תגים בצד השרת כוללים 2 לקוחות: Google Analytics 4 ו-Measurement Protocol. הלקוחות האלה מספקים את הכלים הנדרשים כדי להתחיל להטמיע את האפליקציה ברגע שיוצרים את הקונטיינר.

דוגמה קצרה

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

  1. אתר פשוט שמשתמש ב-gtag.js כדי לשלוח אירוע click למאגר תגים בצד השרת.
  2. לקוח Google Analytics 4 שמקבל את האירוע.
  3. טריגר שמופעל באירוע click.
  4. תג של Google Analytics 4 ששולח את נתוני האירועים ל-Google Analytics לצורך עיבוד.

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

הגדרת gtag.js

קודם צריך להגדיר את gtag.js כך שישלח את הנתונים למאגר התגים בצד השרת. כשמשתמשים ב-gtag.js, שליחת נתונים למאגר התגים בצד השרת פועלת בדיוק כמו שליחת נתונים ל-Google Analytics, עם שינוי אחד. בדומה לדף הדוגמה שבהמשך, מגדירים את אפשרות התצורה server_container_url כך שתצביע על מאגר השרת.

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'TAG_ID', {
    server_container_url: 'https://analytics.example.com',
  });
</script>

מחליפים את TAG_ID במזהה התג. מחליפים את https://analytics.example.com בכתובת ה-URL של מאגר התגים של השרת.

בשלב הבא מוסיפים פונקציית sendEvent() לטיפול באירועי click:

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'TAG_ID', {
    server_container_url: 'https://analytics.example.com',
  });

  function sendEvent() {
    gtag('event', 'click');
  }
</script>

<button onclick="javascript:sendEvent()">Send Event</button>

מחליפים את TAG_ID במזהה התג. מחליפים את https://analytics.example.com בכתובת ה-URL של מאגר התגים של השרת.

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

לקוח Google Analytics 4

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

טריגר של קליק

בשלב הבא, יוצרים טריגר שיתעד את האירוע click. יוצרים טריגר בהתאמה אישית שפועל כשהמשתנה המובנה שם האירוע שווה ל-'קליק'.

הגדרת הטריגר

תג Google Analytics 4

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

הצגת תצוגה מקדימה של ה-container

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

אחרי שמסיימים לבצע את השינויים, מפרסמים את מאגר התגים של השרת.

הגדרת השרת למצב ייצור עם הצגת מודעות מהדומיין הנוכחי

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