הגדרת יעדים ב-Яндекс Метрика על Битрикс: היכן נשבר המעקב
הגדרת יעדים ב-Яндекс Метрика על Битрикс כמעט תמיד נתקלת לא בממשק המונה, אלא באופן שבו האתר שולח אירועים. תקלה אופיינית: הטופס נשלח דרך AJAX, העמוד אינו נטען מחדש, והיעד מוגדר על ביקור ב"עמוד תודה".
האירוע אינו מתרחש — ובדוחות ההמרה בערוץ הזה אפסית, למרות שפניות באמת מגיעות. מקרה נפוץ שני — יעד על לחיצה על כפתור ללא הגנה מפני הפעלה חוזרת: המשתמש לוחץ פעמיים או חוזר אחורה, ופנייה אחת הופכת לשלוש המרות. שלישי — החלפת תבנית או עדכון רכיב, שבהם קריאת היעד נשארת בקוד הישן ומפסיקה לעבוד בשקט.
המחיר של תקלות כאלה — לא "מספר לא מדויק", אלא החלטות על נתונים שגויים. ערוץ שמביא פניות נראה מפסיד ומכבים אותו; אחר, שבו היעד משוכפל, מקבל תקציב.
אובדן נתוני האנליטיקה מצטבר בלי שמבחינים: הפער בין פניות ב-CRM להמרות ב-Метрика גדל במשך חודשים, עד שמישהו משווה את הייצואים ידנית.
מפרקים כיצד זה נסגר: היכן בדיוק ב-Битрикс למקם את קריאת היעד, כך שתפעל גם ב-AJAX וגם בשליחה רגילה, כיצד להפריד יעדים לפי סוגי אירועים וכיצד לבדוק את מעקב ההמרות ב-Битрикс לפני שהנתונים יוצאים לדיווח.
מה נותנת הגדרה נכונה של יעדים: האפקט במספרים
הגדרה נכונה של יעדים מתחילה בכך שכל יעד מקושר לפעולה אמיתית של המשתמש, ולא לעובדת טעינת העמוד.
ב-Bitrix המשמעות היא לרוב העברת אירוע מהטופס, מסל הקניות או מהאזור האישי אל Metrica באמצעות אירוע JS או קריאה בצד השרת — אז היעד מופעל בדיוק פעם אחת, ברגע התגובה המוצלחת של הבקאנד, ולא בלחיצה על הכפתור.
דיוק נתוני המדידה תלוי ישירות בכך: הפער בין מספר הפניות ב-CRM למספר השגת היעד מצטמצם מעשרות אחוזים לאחוזים בודדים.
ספירה כפולה של המרות — סוג נפרד של שגיאות שאוכל תקציבים בלי לשים לב. היא מופיעה כאשר היעד תלוי בעמוד ביניים מסוג "תודה", והמשתמש מרענן אותו או חוזר אליו דרך ההיסטוריה, או כאשר האירוע נשלח גם בצד הלקוח וגם בצד השרת.
אנחנו סוגרים זאת באמצעות שליחה אידמפוטנטית ובדיקת מקור האירוע, ולכן בדוחות נשארת המרה אחת לכל פעולה.
מהירות ההטמעה של יעדים אצלנו נמדדת לא בימים של תיאום, אלא בשעות של פריסה: תרחישים טיפוסיים — שליחת טופס, שיחה, הוספה לסל, ביצוע הזמנה, הרשמה — נסגרים באמצעות מטפלים תבניתיים, ותרחישים לא טיפוסיים נבנים בהתאמה למשפך ספציפי.
שקיפות המשפך מופיעה כאשר היעדים מסודרים לפי שלבים: ביקור, מעורבות, פנייה, עסקה. אז רואים באיזה שלב נושר התעבורה, והחלטות לגבי ערוצים מתקבלות לפי נתונים, ולא לפי תחושות.
דרכים להגדרת מטרות: השוואת גישות
ישנן שלוש דרכים מעשיות, והבחירה ביניהן נקבעת לא לפי נוחות, אלא לפי היכן בדיוק מתרחש האירוע. אם הפעולה מתרחשת בדפדפן — מתאימה הגדרה ידנית דרך הממשק או JavaScript.
אם האירוע נרשם בצד השרת (התשלום אושר על ידי מערכת התשלומים, ההזמנה הועברה לסטטוס, הייצוא ל-1С הושלם) — ייתכן שהדפדפן כלל אינו יודע עליו, ואז יש צורך במטרות שרת דרך API.
הגדרה ידנית דרך הממשק — ההתחלה המהירה ביותר: המונה כבר מותקן באתר, המטרה נוצרת לפי כתובת URL של העמוד או לפי לחיצה על כפתור, ולא נדרש קוד נוסף. המגבלה אחת, אך מהותית: מונה כזה נשבר בעת שינוי תבנית הכתובות, ואירועים ללא מעבר לעמוד חדש (שליחת טופס ללא רענון, שלב בסל) הוא לא יראה.
מטרות דרך אירועי JavaScript מכסות את הדינמיקה: המטפל קורא לשליחת אירוע ברגע הפעולה, ולכן נרשמים גם שלבים בסל, גם פתיחת טופס, וגם לחיצה על הטלפון. הדיוק גבוה יותר, אך מופיעה תלות בחוסמים ובכך שהמשתמש המתין לטעינת הסקריפטים — חלק מהאירועים הולכים לאיבוד בחיבורים איטיים.
מטרות שרת דרך API מסירות את התלות הזו: האירוע נשלח מהשרת, שבו כבר קיים עובדה מאושרת — סטטוס ההזמנה, תגובת שער התשלומים, סנכרון עם 1С. חוסמים ותקלות בצד הדפדפן אינם משפיעים על כך, והנתונים תואמים למערכת החשבונאית. המחיר — נדרש מזהה ביקור, שמועבר מהדפדפן לשרת ונשמר עד לרגע האירוע.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| הגדרה ידנית בממשק | מטרות פשוטות: צפייה בעמוד, מעבר בקישור, טופס סטטי | אינה רואה אירועים ללא מעבר; נשברת בעת שינוי כתובות |
| מטרות דרך אירועי JavaScript | ממשקים דינמיים, סל, שלבי השלמה, לחיצות | תלויה בטעינת סקריפטים ובחוסמים |
| מטרות שרת דרך API | תשלום, סטטוסי הזמנה, סנכרון עם 1С, התאמה עם המערכת החשבונאית | דורשת העברה ואחסון של מזהה ביקור |
בפועל משלבים בין הגישות: מטרות בסיסיות מגדירים ידנית, התנהגותיות — דרך אירועים, וכספים וסטטוסי הזמנות — רק מהשרת. אז הפער בין נתוני האנליטיקה למערכת החשבונאית נשאר בגבולות טעות מדידה, ולא פי כמה.
כיצד אנו מיישמים יעדים: שלבי העבודה
את העבודה מתחילים בביקורת של התגיות הנוכחיות: בודקים אילו אירועים כבר נאספים, היכן יש כפילויות, והיכן טפסים והסל נשארים "עיוורים". לעתים קרובות מתברר שחלק מהיעדים מוגדרים על מעבר בקישור ולא על עצם השליחה — נתונים כאלה נותנים משפך מעוות.
לאחר מכן מתכננים סכמת יעדים המתאימה ללוגיקה העסקית הספציפית: מה נחשב לפנייה, היכן מסתיים שלב ביצוע ההזמנה, ואילו אירועים נדרשים להערכת איכות התנועה. מאשרים את הרשימה עם הלקוח לפני תחילת העבודה, כדי שלא יהיה צורך לחזור עליה לאחר מכן.
- ביקורת תגיות: בודקים מונים קיימים, אירועים, כפילויות ויעדים "מתים", ומתעדים אי-התאמות.
- תכנון סכמת יעדים: קובעים אילו פעולות נחשבות כהמרה, באילו עמודים ובאילו תרחישים הן מופעלות.
- הגדרת איסוף: רושמים אירועים בתבניות וברכיבים, ומחברים העברת נתונים על הזמנות וטפסים.
- בדיקת הפעלה: מריצים תרחישי בדיקה — שליחת טופס, ביצוע הזמנה, שיחה — ובודקים שכל יעד נרשם בדיוק פעם אחת.
- אישור דיווח: מגדירים חיבור בין היעדים לדוחות, כדי שהנתונים יתאימו לפניות אמיתיות.
- מסירת תיעוד: מוסרים את סכמת היעדים, רשימת האירועים והוראות בדיקה — הצוות יכול לתחזק את התגיות באופן עצמאי.
כל שלב מסתיים בתוצאה ברורה: רשימת יעדים מאושרת, אירועים עובדים, ומשפך מאומת. אם בשלב כלשהו מתגלות בעיות בתבנית או באינטגרציה עם CRM — פותרים אותן לפני המעבר הלאה, ולא דוחים אותן למועד מאוחר יותר.
מדיניות גישה ותפקידים לעבודה עם מטרות
הרשאות על המונה והרשאות על מטרות הן שתי ישויות שונות, ואסור לבלבל ביניהן. בממשק של Метрика הגישה ניתנת למונה ספציפי עם תפקיד: צפייה בסטטיסטיקה, עריכה, ניהול גישה. בממשק הניהול של 1С-Битрикс ההרשאות קיימות בנפרד — על מודול הסטטיסטיקה, על אינפובלוקים, על האזור הניהולי.
אם תיתן הרשאת "מנהל" למי שפשוט צריך לראות את המשפך, הוא יקבל גם את היכולת לשבור את סימון הטפסים. לכן אנחנו מפרידים תפקידים לפי עקרון ההרשאות המינימליות הנדרשות ומקבעים זאת במטריצה.
מטריצת הגישה היא טבלה של "תפקיד × אובייקט × פעולה": המשווק רואה דוחות ולא נוגע בקוד, המפתח מתקן מטפלי אירועים ואין לו גישה לנתונים מסחריים, קבלן הקונטקסט מקבל רק קריאה על המטרות הנדרשות.
תקנון המטרות מתאר את מחזור החיים: מי יוזם מטרה חדשה, מי מאשר את הניסוח, מי בודק אותה במצב דיבאג לפני פרסום, היכן נשמרת היסטוריית השינויים.
הלקוח מקבל לידיו חבילה הכוללת:
- מטרות מוגדרות עם קישור לאירועים ולמשפכים, שנבדקו במצב דיבאג;
- סכמת אירועים: איזו פעולה באתר או ב-1С יוצרת איזו מטרה;
- תקנון להוספת מטרות חדשות — מבקשה ועד בדיקה לאחר פרסום;
- מטריצת גישה למונים ולאזור הניהולי;
- רשימת בדיקה לקבלת המטרה: הפעלה, היעדר כפילויות, ייחוס מקור תקין;
- הוראות חזרה לאחור: כיצד להסיר מטרה אם היא מעוותת את הסטטיסטיקה;
- יומן שינויים — מי, מתי ולמה תיקן את הסימון.
תיעוד המטרות מנוהל במאגר הקוד לצד הקוד, ולא בהתכתבות: כך בעת החלפת קבלן או עזיבת עובד ההקשר לא הולך לאיבוד. התקנון נבחן מחדש בכל שינוי גדול באתר — טופס חדש, מדור חדש, שינוי בלוגיקת ההזמנה מחייבים רענון של המטרות, אחרת המשפך מתרחק בשקט מהמציאות.
מקרה בוחן: כיצד ביטלנו ספירה כפולה של המרות ב-Битрикс
הלקוח — חנות מקוונת על 1С-Битрикс — התלונן שמספר ההזמנות בדוחות Метрики גבוה באופן עקבי ב-30% מהמספר בפועל. מחלקת השיווק קיבלה החלטות על בסיס נתונים מנופחים: הרחיבה קמפיינים שלמעשה לא היו רווחיים, בעוד שנקודות הצמיחה האמיתיות נותרו בצל.
מה מצאנו
פירקנו את שרשרת האירועים וראינו שלושה מקורות בלתי תלויים לכפילויות. מטרת שליחת הטופס הופעלה גם בלחיצה וגם עם קבלת התגובה מהשרת — בתגובה איטית המבקר הספיק ללחוץ פעמיים. בעמוד אישור ההזמנה המטרה הוצבה בתבנית שהוטמעה גם באתר הראשי וגם בגרסה הניידת — הזמנה אחת נספרה פעמיים. הסיבה השלישית — רענון עמוד «תודה» בעת רענון הדף: האירוע נשלח ל-Метрика שוב.
מה עשינו
איחדנו את כל נקודות ההמרה לאירוע שרתי יחיד: ההזמנה מאושרת בבסיס הנתונים, ורק לאחר מכן נשלח אות ל-Метрика — ללא תלות בממשק וללא פתיחות חוזרות של העמוד. עבור טפסים הוספנו הגנה מפני שליחה חוזרת בצד השרת, ולא רק בדפדפן.
המטרות הועברו למודול נפרד עם רשומה מאוחדת: מטרה חדשה מתוארת במקום אחד ומחוברת לעמודים הנדרשים ללא עריכות בתבניות.
תוצאה
| מדד | לפני | אחרי |
|---|---|---|
| שיעור המרות כפולות | 30% | פחות מ-1% |
| דיוק החשבונאות | ~70% | 99% |
| זמן להוספת מטרה חדשה | 2 ימים | שעה |
דיוק החשבונאות עלה ל-99% — הדוחות החלו לשקף הזמנות אמיתיות, וההחלטות בנוגע לערוצים החלו להתבסס על העובדות ולא על נתונים מנופחים. רשומת המטרות ביטלה את הצורך בעריכה ידנית של תבניות: המשווק מנסח את האירוע, והמהנדס מחבר אותו בשעה במקום ביומיים.
במה שונה מטרה "קליק על כפתור" ממטרה "שליחת טופס"?
אלו שני סוגים עקרוניים ושונים של מטרות, והבלבול ביניהם הוא הסיבה הנפוצה ביותר לכך שדוחות Яндекс.Метрики מציגים המרה שלא הייתה. מטרה "קליק על כפתור" היא מטרה על אירוע: המונה מופעל ברגע שהמבקר לחץ על האלמנט, ולא משנה מה קרה לאחר מכן.
מטרה "שליחת טופס" היא מטרה על השגה: היא נרשמת כאשר הדפדפן עבר לעמוד אישור לאחר עיבוד מוצלח של הנתונים בשרת. ההבדל בין המטרות הוא בדיוק בזה: האירוע מתרחש בממשק, ההשגה — לפי עובדת הפעולה שהושלמה.
מכאן גם ההתנהגות השונה. קליק על כפתור תופס כוונה, אבל לא תוצאה: המבקר לחץ על "שלח", הטופס נשלח עם שגיאת ולידציה, ההודעה לא הגיעה — אבל המטרה כבר נספרה. שליחת טופס תופסת תוצאה, אבל דורשת שאחרי העיבוד יהיה כתובת אישור נפרדת, אחרת אין על מה לרשום את ההשגה.
באתרים על 1С-Битрикс זה נפתר либо בהצגת עמוד "תודה" עם כתובת ייחודית, либо בשליחת אירוע באמצעות קריאה תוכנתית של המונה מתוך מטפל התגובה המוצלחת — האפשרות השנייה אמינה יותר, כי היא לא תלויה לאן המפתח החליט להפנות את המשתמש.
הפעלות שווא — זה כאב ראש נפרד. קליק על כפתור בקלות מוכפל בלחיצות חוזרות, מופעל על אנימציות גלילה ועל אלמנטים שנראים ויזואלית כמו כפתור שליחה, אבל אינם כאלה. מטרה על השגה מוגנת מזה: עמוד האישור נפתח פעם אחת.
לכן עבור טפסי בקשות, הזמנות ורישום לשירות נכון יותר להשתמש בהשגה, וקליק — רק במקום שבו לפעולה אין אישור שרת: פתיחת צ'אט, שיחה, מעבר למסנג'ר.
בפועל נוח לשלב: מטרה על השגה סופרת בקשות אמיתיות, ומטרה על קליק מראה כמה אנשים התחילו למלא את הטופס ובאיזה שלב נשרו. ההבדל בין המספרים האלה — אלו בדיוק האבדות בטופס, שנראות בלי כלים נוספים. אם הפער גדול, הבעיה בוולידציה, במהירות תגובת השרת או בטקסט של השדות עצמם, ולא בתעבורה.
בעת הגדרת מטרות על 1С-Битрикс אנחנו תמיד בודקים כל מטרה במצב דיבאג של המונה: האם האירוע עובר פעם אחת, האם הוא לא נתפס בשלבי ביניים, האם פרמטרי ההזמנה מועברים כראוי. מטרה שמופעלת לא במקום הנכון גרועה מהיעדרה — היא יוצרת תמונה כוזבת ומטה החלטות בנוגע לפרסום הצידה.
ספקות טכניים נפוצים בעת הגדרת מטרות
בפועל, הספקות כמעט תמיד מצטמצמים לארבעה תרחישים: התנגשות עם מונה שכבר מותקן, בדיקה ללא גישה לפאנל הניהול, מספר דומיינים בפרויקט אחד, ונכונות העברת הנתונים לאחר שיפורים. נבחן כל אחד מהם — כפי שזה נראה בפרויקט אמיתי.
באתר כבר מותקן מונה Metrica אחר — מה לעשות איתו?
שני מונים בעמוד אחד אינם מתנגשים: כל אחד מאותחל עם המזהה שלו וכותב לסטטיסטיקה משלו. הבעיה היא במקום אחר — מטרות שהוגדרו במונה הישן אינן מועברות אוטומטית, וחלק מהאירועים עלולים להיות כפולים אם שני המונים מאזינים לאותן פעולות.
אנחנו מעבירים את המטרות הנדרשות למונה הפעיל, מכבים קריאות כפולות ומשאירים את הישן במצב צפייה עד שנשתכנע שהנתונים תואמים.
איך לבדוק שהמטרות מופעלות אם אין גישה לאדמין?
מספיק מצב דיבוג בממשק Metrica ולשונית האירועים בזמן אמת: היא מציגה הפעלה של מטרה ברגע הפעולה, בלי להיכנס לפאנל הניהול של האתר. אנחנו עוברים את התרחיש כמו מבקר רגיל — שליחת טופס, שיחה, ביצוע הזמנה — ומתעדים שכל אירוע הגיע. אם משהו לא הופעל, הסיבה נראית לפי שרשרת הקריאות, ולא לפי סימנים עקיפים.
האם ניתן להגדיר מטרות במספר דומיינים?
כן, וזהו תרחיש תקני לפרויקטים עם תת-דומיינים או מראות. יש שתי אפשרויות: מונה אחד עם קישור צולב בין דומיינים, או מונים נפרדים לכל דומיין עם דוח מסכם. הבחירה תלויה בשאלה אם נדרש משפך רציף across כל הפלטפורמות או סטטיסטיקה נפרדת. אנחנו מגדירים את שתי האפשרויות ובודקים שהמעבר בין דומיינים אינו מנתק את הסשן.
מה יקרה למטרות לאחר עדכון האתר או החלפת תבנית?
מטרות שמקושרות לרכיבי ממשק נשברות בעת החלפת הפריסה — המטפל פשוט מפסיק למצוא את הרכיב הנדרש. אמין יותר לקשר אירועים לפעולה עסקית, ולא לכפתור: שליחת נתונים, שינוי סטטוס הזמנה, עצם התשלום. אז עדכון העיצוב אינו מחייב הגדרה מחדש, והסטטיסטיקה נשארת רציפה.
אם המקרה שלכם לא נכנס לרשימה — תארו את המשימה, נחזור עם הערכה ותוכנית עבודה.
בואו נדון במשימה שלכם להגדרת יעדים
הגדרת יעדים היא לא "לסמן וי בפאנל", אלא לקשר כל פעולה שהוגדרה כיעד באתר לאירוע ספציפי בממשק ולוודא שהוא מגיע לדוח ללא אובדן נתונים.
כדי לחזור עם הערכה ותוכנית יישום, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה: גישות לפאנל האנליטיקה ולחלק הניהולי של האתר, רשימת הפעולות שאתם מחשיבים כתוצאה (פנייה, שיחה, הזמנה שהושלמה, הורדת מחירון, הרשמה), ותיאור המשפך הנוכחי — מאיפה מגיע התנועה ובאיזה שלב הוא נקטע לרוב.
לאחר מכן אנחנו מצליבים את הרשימה הזו עם מה שבאמת קורה באתר: אילו טפסים נשלחים, איך מעובדות הזמנות ב-1С, היכן ממוקמים כפתורי השיחה והמסנג'רים, האם יש סל עם שלבי ביניים.
חלק מהיעדים מוגדרים על אירועי ממשק, חלק — על מעברים בין שלבי השלמת ההזמנה, וחלק — על אישור מצד הלוגיקה של השרת, כאשר ההזמנה הגיעה ל-1С. ניתוח כזה מראה מיד היכן הנתונים הולכים לאיבוד ואילו פעולות כלל לא נרשמות.
מה נכלל בעבודה על הגדרת יעדים כמקשה אחת:
- סימון הפעולות שהוגדרו כיעד באתר ובדיקת ההפעלה שלהן בתרחישים אמיתיים;
- הגדרת יעדים בפאנל האנליטיקה, כולל יעדים מורכבים ומשפכים לפי שלבי השלמת ההזמנה;
- קישור אירועי האתר לנתונים מ-1С, כדי שפנייה והזמנה לא יתפצלו בסטטוסים;
- בדיקת העברה מקצה לקצה: מהקליק ועד לרישום בדוח, עם מעברים לבדיקה;
- הגדרת דוחות וחתכים שלפיהם תקבלו החלטות, ולא רק תסתכלו על מספרים;
- תיעוד לכל יעד: מה הוא אומר, היכן הוגדר, איך לבדוק בעת תקלה.
הערכת העבודה תלויה במספר היעדים, במורכבות הטפסים ובעומק האינטגרציה עם 1С — לאחר ניתוח קצר אנחנו מוסרים לוחות זמנים והרכב השלבים.
מסירת התוצאה כוללת לא רק יעדים מוגדרים, אלא גם הוראות לצוות שלכם: איך להוסיף יעדים חדשים בעצמכם, איך להבדיל בין תקלה אמיתית לבין זינוק בתנועה ולאן להסתכל אם המדדים השתנו בפתאומיות.
תארו את המשימה — אילו פעולות אתם מחשיבים כיעד ומה כבר הוגדר — ואנחנו נחזור עם הערכה ותוכנית יישום.