תיוג בצד השרת

תיוג בצד השרת מאפשר להעביר אינסטרומנטציה של תגי מדידה מהאתר או מהאפליקציה למאגר תגים לעיבוד בצד השרת ב-Google Cloud Platform ‏(GCP) או בכל פלטפורמה אחרת שתבחרו. לתיוג בצד השרת יש כמה יתרונות בהשוואה לתגים בצד הלקוח:

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

הערה: קונטיינרים של שרתים פועלים ב-Cloud Run. השבתה של Cloud Run לא משפיעה על הביצועים של האתר שלכם.

כדי להתחיל לעבוד עם תיוג בצד השרת:

1. יוצרים מאגר תגים בצד השרת ב-Tag Manager.
2. [הגדרת שרת תיוג ב-GCP].

לסקירה כללית, אפשר לקרוא את המאמר מבוא לתיוג בצד השרת

יצירת מאגר תגים בצד השרת ב-Tag Manager

כדי להשתמש בתיוג בצד השרת, צריך ליצור מאגר תגים חדש ב-Tag Manager בצד השרת:

1. בחשבון Tag Manager, יוצרים מאגר תגים חדש.
   1. לוחצים על Accounts (חשבונות) > לצד שם החשבון הרלוונטי.
   2. בוחרים באפשרות יצירת מאגר תגים.
2. בקטע פלטפורמת היעד, בוחרים באפשרות שרת.
3. לוחצים על יצירה.

מופיעה תיבת דו-שיח להגדרת שרת התיוג. התהליך הזה מפורט בקטע הבא.

הגדרת שרת תיוג

אחרי שיוצרים את מאגר התגים בצד השרת, צריך לפרוס שרת התיוג. הערה: כדי לחזור לנקודה הזו בהמשך, לוחצים על מזהה מאגר התגים בסרגל העליון או עוברים לכרטיסייה Admin (ניהול) > Container Settings (הגדרות מאגר התגים) > Set up your tagging server (הגדרת שרת התיוג).

אפשר לבחור באחת מאפשרויות הפריסה הבאות:

• הקצאת משאבים אוטומטית (מומלץ): אם בוחרים באפשרות הקצאת משאבים אוטומטית של שרת תיוג, מערכת Google Tag Manager מגדירה בשבילכם פרויקט חדש ב-GCP ושרת תיוג ב-Cloud Run. אם אתם רוצים להשתמש בפרויקט קיים ב-GCP, פועלים לפי מדריך ההגדרה של Cloud Run.

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

הגדרת דומיין השרת

לשרת התיוג החדש יש כתובת URL שמוגדרת כברירת מחדל בכתובת run.app. כדי לשפר את הפרטיות ועמידות קובצי ה-Cookie, צריך להפנות דומיין משנה של האתר לשרת התיוג. כך, שרת התיוג יכול לקרוא ולכתוב קובצי Cookie שלא גלויים לסקריפטים בדף (קובצי Cookie מסוג HttpOnly). כאן מוסבר איך להגדיר דומיין מותאם אישית למיפוי לשרת התיוג.

הסבר על פריסת ברירת המחדל ב-GCP

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

אילו משאבים ב-GCP מוקצים כשמפעילים הקצאת שרת תיוג באופן אוטומטי?

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

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

מה הדומיין של שרת התיוג שלי?

הפריסה שמוגדרת כברירת מחדל משתמשת בתת-דומיין של Cloud Run. מומלץ מאוד להפנות דומיין משנה של האתר לשרת התיוג. פועלים לפי ההוראות האלה כדי למפות את תת-הדומיין של האתר לשרת התיוג.

כמה עולה פריסת ברירת המחדל?

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

1. החשבון לחיוב שמשמש לפריסה ב-GCP מקושר לפרויקטים אחרים שמוציאים את השרת מהתוכנית בחינם של GCP.
2. כמות התנועה שנשלחת מהשרת חורגת מהמגבלות של התוכנית החינמית.

אחרי שמשדרגים את סביבת Cloud Run, ההוצאה החודשית צפויה להיות 30-50$ לכל שרת. נפח גדול של תנועה ברשת עלול להגדיל את העלות הזו.

איך מוסיפים עוד מכונות לפריסה?

במאמרי העזרה של Cloud Run מוסבר איך מוסיפים עוד מופעים לפריסה.

שליחת הבקשה הראשונה

כדי ללמוד איך לשלוח את הבקשה הראשונה, קוראים את המדריך לשליחת נתונים אל Tag Manager בצד השרת.