הגדרת אנליטיקה מקצה לקצה לדיוורים ב-Bitrix24

אנליטיקת תפוצות דואר של Bitrix24: היכן נשברת שרשרת הנתונים

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

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

הסיבה היא שאנליטיקת התפוצות של Bitrix24 אוספת נתונים ממספר מקורות בלתי תלויים. יומני שליחה ומסירה מנוהלים על ידי שירות הדואר, פעילות באתר — על ידי מונה, עסקאות — על ידי ה-CRM. אין ביניהם ישות משותפת שמקשרת באופן חד-משמעי מייל, איש קשר ועסקה.

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

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

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

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

אפקטים מדידים של רישום רוחבי של מיילים

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

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

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

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

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

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

דרכים לאיסוף אירועים: השוואה של ארבעה מצבים

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית לפי המצב שיענה על השאלות שלכם בלי תשתית מיותרת.

סדר העבודה: מביקורת הסימון ועד למסירה

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

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

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

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

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

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

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

החבילה בסיום: סכימות, נהלים, הרשאות

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

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

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

מקרה בוחן: השוואת תפוצות לפני ואחרי הגדרה מחדש

חברה עם כמה תחומי פעילות ניהלה תפוצות מ-Bitrix24: סגמנטים לפי תחומי עניין, משפכים אוטומטיים לחימום, קמפיינים נפרדים למבצעים. הסטטיסטיקה של פתיחות ומעברים חיה בממשק התפוצות, התגובות והפניות — בכרטיסי העסקאות, והקשר ביניהם נשען על הזיכרון של המנהל. השוואת הדוחות ארכה 2–3 ימים, וחלק מהקמפיינים עד סוף החודש פשוט נשארו לא מאוחדים.

מה שינו ברישום

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

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

מטריקות לפני ואחרי

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

במה שונה הסטטיסטיקה המובנית מרישום רוחבי

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

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

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

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

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

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

ספקות טכניים שכדאי לסגור מראש

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

האם יהיה צורך לשנות את תבניות המייל הקיימות?

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

כיצד לבצע נסיגה אם הדוחות "יזוזו" לאחר התיקונים?

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

מה היקף העבודה והלוחות הזמנים, ומה נדרש מצדנו?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

מה שעוזר בהתחלה:

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

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

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