‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

דוגמה קצרה

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

אתר פשוט שמשתמש ב-gtag.js כדי לשלוח אירוע click למאגר תגים בצד השרת.
לקוח Google Analytics שמקבל את האירוע.
טריגר שמופעל באירוע click.
תג Google Analytics ששולח את נתוני האירועים ל-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

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

טריגר קליק

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

הגדרת הטריגר

תג Google Analytics

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

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

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

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

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

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