תיוג בצד השרת מאפשר להעביר את האינסטרומנטציה של תגי המדידה מהאתר או מהאפליקציה שלכם למאגר עיבוד בצד השרת ב-Google Cloud Platform (GCP), או לפלטפורמה אחרת לבחי��תכם. לתיוג בצד השרת יש כמה יתרונות על פני תגים בצד הלקוח:
- ביצועים משופרים: פחות תגי מדידה באתר או באפליקציה משמעותם פחות קוד שפועל בצד הלקוח.
- אבטחה משופרת: נתוני המבקרים מוגנים בצורה טובה יותר ומאובטחים יותר כשהם נאספים ומופצים בסביבה בצד השרת בניהול הלקוח. הנתונים נשלחים למכונה בענן, שם הם עוברים עיבוד וניתוב על ידי תגים אחרים.
כדי להתחיל לעבוד עם תיוג בצד השרת:
יצירת מאגר תגים בצד השרת של Tag Manager
כדי להשתמש בתיוג בצד השרת, יוצרים מאגר תגים חדש בצד השרת של Tag Manager:
- בחשבון Tag Manager, יוצרים מאגר תגים חדש.
- לוחצים על Accounts (חשבונות) >
לצד שם החשבון הרלוונטי. - בוחרים באפשרות יצירת מאגר תגים.
- לוחצים על Accounts (חשבונות) >
- בקטע Target platform (פלטפורמת היעד), בוחרים באפשרות Server (שרת).
- לוחצים על יצירה.
תופיע תיבת דו-שיח להגדרת שרת התיוג. התהליך הזה מפורט בקטע הבא.
הגדרת שרת תיוג
אחרי שיוצרים את מאגר התגים של השרת, צריך לפרוס שרת תיוג. הערה: כדי לחזור לנקודה הזו מאוחר יותר, לוחצים על מזהה מאגר התגים בסרגל העליון או עוברים לכרטיסייה ניהול > הגדרות מאגר התגים > הגדרת שרת התיוג.
אפשר לבחור באחת מאפשרויות הפריסה הבאות:
- הקצאה אוטומטית (מומלץ): אם בוחרים באפשרות הקצאה אוטומטית של שרת תיוג, מערכת Google Tag Manager מגדירה בשבילכם פרויקט חדש ב-GCP ושרת תיוג ב-Cloud Run. אם אתם רוצים להשתמש בפרויקט קיים ב-GCP, עליכם לפעול לפי מדריך ההגדרה של Cloud Run.
- הקצאה ידנית בתשתית שאינה של Google: אם אתם רוצים להשתמש בפתרון שרת משלכם, עליכם לפעול לפי השלבים שמפורטים במדריך להגדרה ידנית.
הגדרת דומיין השרת
לשרת התיוג החדש יש כתובת URL שמוגדרת כברירת מחדל ב-uc.a.run.app. כדי לשפר את הפרטיות והעמידות של קובצי ה-cookie, כדאי להפנות תת-דומיין של האתר לשרת התיוג.
כך שרת התיוג יכול לקרוא ולכתוב קובצי cookie שלא גלויים לסקריפטים בדף (קובצי cookie מסוג HttpOnly).
כך מגדירים דומיין מותאם אישית למיפוי לשרת התיוג.
הסבר על הפריסה שמוגדרת כברירת מחדל ב-GCP
כשיוצרים שרת תיוג באמצעות תהליך הקצאת המשאבים האוטומטי, השרת מקבל את הגדרות ברירת המחדל.
אילו משאבי GCP מוקצים כשמקצים באופן אוטומטי את שרת התיוג?
כשמקצים באופן אוטומטי את שרת התיוג, נוצר פרויקט GCP עם הקונטיינר בצד השרת שנפרס ב-Cloud Run. הפריסה מגבילה את כמות המשאבים הזמינים, ומומלצת לבדיקה של נפחי תנועה מוגבלים בלבד.
כשהקונטיינר בצד השרת מתחיל לקבל תנועה פעילה, כדאי להקצות מכונות נוספות לשירות כדי להבטיח יתירות ולהימנע מאובדן נתונים במקרה של הפסקות זמניות בשירות או מגבלות קיבולת. מומלץ להשתמש ב-3 מכונות לפחות בכל מאגר כדי להבטיח יתירות. איך משדרגים את הפריסה
מהו הדומיין של שרת התיוג שלי?
בפריסה שמוגדרת כברירת מחדל נעשה שימוש בתת-דומיין של Cloud Run. מומלץ מאוד להפנות תת-דומיין של האתר לשרת התיוג. פועלים לפי ההוראות האלה כדי למפות את תת-הדומיין של האתר לשרת התיוג.
מה העלות של פריסה שמוגדרת כברירת מחדל?
פריסת ברירת המחדל של פרויקט GCP עם שרת אחד היא ללא תשלום ברוב המקרים. עם זאת, יש כמה גורמים שיכולים לגרום לעלויות כשפורסים בשרת יחיד:
- החשבון לחיוב שמשמש לפריסה ב-GCP מקושר לפרויקטים אחרים שמוציאים את השרת מהתוכנית ללא תשלום של GCP.
- כמות התנועה שנשלחת מהשרת חורגת מהמגבלות של תוכנית התמיכה בחינם.
אחרי השדרוג של סביבת Cloud Run, העלות הצפויה היא 30-50$ לכל שרת בחודש. כמויות גדולות של תעבורת נתונים ברשת עלולות להגדיל את העלות הזו.
איך מוסיפים מכונות נוספות לפריסה?
במאמר מסמכי התיעוד של Cloud Run מוסבר איך מוסיפים עוד מכונות לפריסה.
שליחת הבקשה הראשונה
כדי ללמוד איך לשלוח את הבקשה הראשונה, אפשר לעיין במדריך לשליחת נתונים ל-Tag Manager בצד השרת.