תיוג בצד השרת

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

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

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

  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 שמוגדרת כברירת מחדל ב-uc.a.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 בצד השרת.