דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

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

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

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

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

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

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

איך הלקוחות עובדים

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

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

דוגמה קצרה

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

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

הגדרת הטריגר

תג Google Analytics 4

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

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

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

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

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

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