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

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

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

לקוח Google Analytics 4

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

הפעלה בלחיצה

בשלב הבא, יוצרים טריגר שיופעל באירוע click. יוצרים Custom Trigger (טריגרים בהתאמה אישית) שיופעל כשהמשתנה המובנה Event Name שווה ל-"click".

הגדרת טריגר

תג Google Analytics 4

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

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

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

כשמרוצים מהשינויים, צריך לפרסם את מאגר התגים של השרת.

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

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