מעקב בצד השרת בלי GTM: לשלוח אירועים מהשרת ולבדוק שהם הגיעו

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

בקצרה

• מעקב בצד השרת שולח המרות מהשרת לפלטפורמה, ולכן חסימת דפדפן או חוסם פרסומות לא מונעים את השליחה.
• בלי GTM כותבים בקוד קריאה ל-⁠API של הפלטפורמה בכל אירוע המרה, עם מזהה משותף לדפדפן ולשרת.
• ב-⁠Google Ads חזרה על אותה פעולה עם אותו transaction ID מדולגת; ב-⁠Meta הדדופליקציה לפי שם אירוע ו-⁠event_id.
• ב-⁠GA4 המסלול הוא Measurement Protocol, והוא שולח ל-⁠GA4 ולא ישירות ל-⁠Google Ads.
• יותר המרות בדוח אחרי המעבר אינן הוכחה שהדדופליקציה עובדת. זו נקודת פתיחה לבדיקה.

מה זה מעקב בצד השרת ולמה הוא נחוץ

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

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

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

למה לא להסתפק בפיקסל ובתג בדפדפן

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

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

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

איך מיישמים מעקב בצד השרת בלי GTM

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

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

שלבים ביישום

1. מגדירים איזה אירוע באמת נחשב המרה. לא כל לחיצה ולא כל צפייה, אלא פעולה שיש לה משמעות עסקית, כמו הזמנה, ליד או רכישה.
2. מייצרים מזהה ייחודי לאירוע בדפדפן, למשל event_id או מספר הזמנה, ומעבירים אותו לשרת יחד עם שאר הנתונים.
3. שומרים בשרת את הפרטים שהגיעו מהדפדפן, כולל המזהה, לפני שהאירוע נשלח הלאה.
4. כותבים בקוד קריאה ל-⁠API של הפלטפורמה, עם שדות החובה שהיא דורשת ועם המזהה המשותף.
5. שומרים תיעוד של כל שליחה, כולל תשובת ה-⁠API, כדי שאפשר יהיה לבדוק מה קרה כשמשהו לא מסתדר.
6. בודקים את האירועים בדוחות הפלטפורמה ומשווים למה שהשרת שלח.

ההבדל בין Google Ads ל-⁠Meta

ב-⁠Google Ads המסלול הוא API של Google Ads או Data Manager, והאירוע נשלח עם transaction ID או order ID שמזהה אותו. ב-⁠Meta המסלול הוא Conversions API, והדדופליקציה מול הפיקסל מתבצעת לפי התאמה של שם האירוע ו-⁠event_id. אין מתג שמפעיל את הדדופליקציה, היא קורית כשהשדות מתאימים.

ל-⁠GA4 יש מסלול נפרד, Measurement Protocol. הוא שולח אירועים ל-⁠GA4 ולא ישירות ל-⁠Google Ads, וזה לא אותו דבר כמו העברת המרות ל-⁠Google Ads. אם אתם צריכים שההמרה תגיע לקמפיין ב-⁠Google Ads, צריך מסלול שמדבר עם Google Ads, לא רק עם GA4. על ההבדל הזה כדאי לקרוא בהרחבה במדריך על המרות API: מה זה נותן ומה זה לא מחליף.

איפה נכנס מזהה עקבי

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

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

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

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

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

איך בודקים שהמעקב מדווח נכון

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

מה לבדוק בפועל

1. האם כל אירוע שהשרת שלח מופיע בדוח הפלטפורמה.
2. האם אותו מזהה מופיע גם בשליחה מהדפדפן וגם בשליחה מהשרת.
3. האם יש אירועים שנשלחו פעמיים עם מזהים שונים.
4. האם חסרים שדות חובה באחד האירועים.
5. האם האירועים משויכים למקור הנכון ולא נופלים לשיוך כללי.

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

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

טעויות נפוצות במעקב בצד השרת

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

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

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

טעות רביעית היא ערבוב בין מסלולים. Measurement Protocol שולח ל-⁠GA4, ו-⁠API של Google Ads שולח ל-⁠Google Ads. מי שמערבב ביניהם ומצפה לראות המרה בקמפיין מגלה שהאירוע הגיע למקום אחר. על אותו עיקרון, כשההמרות מגיעות אבל לא מתחברות למערכת הניהול, הבעיה נמצאת בשיוך: מספרי חשבון הפרסום לא תואמים ל-⁠CRM: איך מאתרים ומתקנים.

מתי כדאי בכלל לעבור למעקב בצד השרת

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

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

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

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

איך בודקים את האירועים בלי לכתוב הכל מאפס

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

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