ניתוח משפך המרות: היכן חנות האינטרנט מאבדת קונים
ניתוח משפך המרות מתחיל לא מדוח, אלא משחזור המסלול האמיתי של הקונה: כיצד הגיע לאתר, מה צפה, ובאיזה שלב עצר. בחנות אינטרנט על 1С-Битрикс המסלול הזה מפורק לפי אירועים — צפייה בקטלוג, הוספה לסל, מעבר להשלמת הזמנה, שליחת הזמנה.
כל אירוע מתועד, ובאמצעות הפערים בין האירועים ניתן לראות היכן בדיוק הולך לאיבוד כסף, ולא היכן "משהו לא בסדר בעיצוב".
נקודות הניתוק האופייניות במשפך בפרויקטים כאלה חוזרות מחנות לחנות. הקונה ממלא את סל חנות האינטרנט, אך נוטש אותו בשלב בחירת המשלוח, משום שלא מצא את העיר או את זמן האספקה שלו. אחר מגיע לטופס ההזמנה ועוזב כאשר המערכת דורשת הרשמה לשם רכישה בודדת.
שלישי לא משלים את התשלום, משום שמודול התשלום החזיר שגיאה, והדף שתק בנוגע לכך. הפסדים בהשלמת ההזמנה כמעט תמיד מתרכזים בשני השלבים האחרונים — שם, שבו הקונה כבר מוכן לשלם.
קטגוריה נפרדת היא ניתוקים טכניים, אשר בדוחות נראים כ"המשתמש התחרט". תגובה איטית של הקטלוג בעת סינון, סשן שנפל, התנגשות בין הסל לבין המטמון, חישוב שגוי של עלות המשלוח — כל אלה מנתקים קונים לפני שהם רואים את כפתור האישור. ההמרה להזמנה יורדת, אך הסיבה אינה טמונה בשיווק ולא במחירים.
בדיוק משום כך אנו בונים את ניתוח משפך ההמרות על נתונים רוחביים: מקשרים בין ביקורים, פעולות בסל, הזמנות שננטשו והזמנות שהושלמו לבין לוגים טכניים והגדרות החנות.
כך נראה אילו נקודות ניתוק במשפך יוצרות את עיקר האובדן, ומה מהן מתוקן באמצעות הגדרה, ומה דורש שדרוג של לוגיקת השלמת ההזמנה. בהמשך נבחן כיצד זה נסגר בפרויקטים תחת 1С-Битрикс.
מה נותח ניתוח משפך: האפקט במספרים
ניתוח המשפך מתחיל לא בדוח, אלא בשחזור המסלול האמיתי של הקונה: אילו שלבים הוא עובר מהמגע הראשון ועד לתשלום, היכן בדיוק הוא עוצר ומה הוא רואה באותו רגע. ב-1С-Битрикс הנתונים האלה כבר קיימים — באירועי ביצוע ההזמנה, בסל, בהיסטוריית הסטטוסים, בלוגי התשלומים. אנחנו אוספים אותם לתמונה אחת, והיא כמעט תמיד שונה מהאופן שבו העסק מדמיין את התהליך.
התוצאה המדידה הראשונה — עלייה בהמרה להזמנה. כשנראה באיזה שלב אובד החלק העיקרי של הקונים, העבודה מתבצעת לא "על האתר בכלל", אלא ממוקדת: מסירים שדה מיותר, משנים את סדר השלבים, מתקנים את תרחיש התשלום. חלקם של ההזמנות שהושלמו עולה לא בזכות תנועה רבה יותר, אלא בזכות אלה שכבר הגיעו והיו מוכנים לקנות.
האפקט השני — ירידה בנטישות סל והאצת ביצוע ההזמנה. לעתים קרובות הסיבה לסל נטוש היא טכנית: חישוב משלוח איטי, שגיאה בהחלת הנחה, הרשמה חובה, עלות נסתרת בשלב האחרון. אנחנו מוצאים את המקומות האלה לפי הנתונים ומסירים את החיכוך — זמן ביצוע ההזמנה מתקצר, ומספר ההזמנות שהופסקו יורד.
השלישי — רכישות חוזרות וסכום קנייה ממוצע. המשפך מראה לא רק הפסדים, אלא גם את ההתנהגות של אלה שחזרו: מה הם קונים בפעם השנייה, אילו מוצרים גוררים אחריהם מכירה משלימה. על הנתונים האלה נבנים תרחישי החזרה והצעות נלוות, וסכום הקנייה הממוצע עולה על בסיס הלקוחות הקיים.
את כל המספרים מחשבים לפני השינויים ואחריהם, על אותן תקופות וסגמנטים, כדי שהאפקט ייראה בדינמיקה ולא בדוח חד-פעמי.
היכן בדיוק נשברת המשפך ב-1С-Битрикс
המשפך ב-1С-Битрикс נשבר לא בשלב של "הלקוח התחרט", אלא קודם לכן — ברמת התשתית. קטלוג עם מספר רב של הצעות מסחריות ומאפיינים רב-שכבתיים מתחיל להחזיר דפים תוך שניות, וחלק מהמבקרים עוזבים לפני שהדף מסיים להיטען. המדד בנקודה הזו משקר: הנטישה נראית כמו "לא התעניין", למרות שהאדם פיזית לא ראה את המוצר.
השבר הטיפוסי השני — סל הקניות. שגיאות בחישוב מחדש של הנחות, אי-התאמה בין המלאי למחסן בפועל, "מוצר אינו זמין" בשלב האחרון של ביצוע ההזמנה. הלקוח כבר עבר את הבחירה, הוסיף פריטים וקיבל סירוב — זו האבדה היקרה ביותר, כי המוטיבציה הייתה מקסימלית.
השכבה השלישית — החיבור למערכת החשבונאית. החלפת הנתונים עם 1С מתבצעת לפי לוח זמנים, ובין הייצואים המחירים והמלאי חיים בשתי מציאויות שונות. ההזמנה יוצאת לעיבוד עם נתונים לא מעודכנים, המנהל מתקשר חזרה עם התנצלויות, וחלק מהעסקאות פשוט לא מגיעות ליעד.
בנפרד יש לציין את אובדן הסשן: ניקוי אגרסיבי של קוקיז, קונפליקט הרשאה בין תת-דומיינים, איפוס הסל בעת מעבר בין מכשירים. האדם חוזר — וההזמנה שלו ריקה.
אנחנו עובדים על 1С-Битрикс ורואים את השברים האלה בלוגים, ולא בדוחות האנליטיקה. בודקים את זמן התגובה של הקטלוג תחת עומס, את יומני השגיאות של הסל, את לוח הזמנים והלוגים של החלפת הנתונים, את התנהגות הסשנים בתרחישים שונים — ומוצאים באיזה שלב הולך לאיבוד אחוז מסוים של מבקרים.
דרכי איסוף נתונים: השוואת גישות
דרך האיסוף קובעת אילו שלבים במשפך תראו בכלל. אנליטיקת ווב מובנית של הפלטפורמה מציגה במהירות מעברים בין מדורי הקטלוג וביצוע הזמנה, אך חלק מהאירועים הולכים לאיבוד: יש לה מודל סשן משלה, והנתונים נמצאים בתוך המערכת.
מוני צד שלישי מספקים תמונה רוחבית לפי ערוצים ותגיות פרסום, אולם הם נחסמים על ידי חוסמי פרסומות ואינם רואים מה קורה בצד השרת. לוגים של השרת מתעדים כל בקשה ללא אובדן, אך אינם יודעים מי בדיוק הגיע עד שמקשרים אותם למזהה סשן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אמצעים מובנים של הפלטפורמה | התחלה מהירה, דיווח על הזמנות וסל | סגורים בתוך המערכת, סגמנטציה מוגבלת, אירועים הולכים לאיבוד בלוגיקה מותאמת אישית |
| מוני צד שלישי | הערכת ערוצים, תגיות פרסום, התנהגות בעמודים | חוסמי פרסומות וסירוב למעקב מפחיתים את הנתונים, פער מול הזמנות |
| לוגים של השרת | ביקורת על כל הבקשות, ניתוח תקלות בשלבי תשלום | אין קישור למשתמש ללא הצלבה עם סשן, נפח גדול של רשומות גולמיות |
| גישה משולבת | חנויות עם משפך מורכב ומספר מקורות תנועה | דורשת מפתח סשן אחיד והצלבת מקורות באופן קבוע |
בפועל הפערים בין המערכות מגיעים לעשרות אחוזים, וההחלטה מתקבלת לא לפי דוח אחד אלא לפי הצלבה.
אנחנו מאחדים אירועים למזהה סשן משותף, משווים הזמנות מהפלטפורמה עם רשומות המונים והלוגים, ואת הפערים מפרקים לפי שלבים: היכן בדיוק המשתמש הולך לאיבוד — בפילטרים של הקטלוג, בסל או באישור התשלום.
גישה משולבת יקרה יותר בהגדרה, אבל דווקא היא מספקת משפך שאפשר להישען עליו בעת שינויים. אם התנועה מגיעה מערוץ אחד והמשפך פשוט, די באמצעים מובנים עם התאמות ממוקדות — נבחן איזו מערכת תסגור את המשימה שלכם בלי שכבות מיותרות.
כיצד אנו מבצעים ביקורת משפך: שלבי העבודה
ביקורת המשפך מתחילה לא מהשערות אלא מעובדות: אנו מודדים את המדדים הנוכחיים בכל שלב — מהכניסה לכרטיס המוצר ועד לביצוע ההזמנה. אנו בוחנים היכן בדיוק הולך לאיבוד חלק מהמשתמשים: במסנני הקטלוג, בעגלת הקניות, בטופס המשלוח או בשלב התשלום. בלי הנתונים האלה, כל תיקון הוא הימור עיוור ולא החלטה הנדסית.
לאחר מכן אנו עובדים לפי שלבים, שכל אחד מהם מסתיים בתוצר הניתן לבדיקה.
- מדידת מדדים. אנו מייצאים נתונים ממערכות האנליטיקה וממיומני השרת, ומצליבים את היעדים עם פעולות המשתמשים בפועל. התוצר — מפת משפך עם שיעור המרה בכל שלב ונקודות הקטיעה.
- פילוח תעבורה. אנו מחלקים את המבקרים לפי מקורות, מכשירים וסוג התנהגות: קונה חדש, חוזר, עגלה נטושה. אותו שלב יכול לאבד קבוצות שונות מסיבות שונות.
- בניית השערות. אנו מנסחים מה בדיוק מונע את המעבר לשלב הבא: תפוקת קטלוג איטית, שדות מיותרים בטופס, עלות משלוח לא שקופה. לכל השערה — מדד שלפיו נבדוק אותה.
- תעדוף. אנו בוחרים תיקונים לפי היחס בין ההשפעה על ההמרה למורכבות הביצוע. תחילה מה שסוגר הפסדים גדולים בשלבים העליונים.
- הטמעת תיקונים. אנו משנים תבניות, את לוגיקת העגלה, את סדר שלבי התשלום, ומחברים מטמון לשאילתות כבדות. כל שינוי — בְּרִילִיס נפרד, כדי שהאפקט יהיה מדיד.
- בדיקת התוצאה. אנו משווים את ההמרה לפני ואחרי על תעבורה דומה, ומסננים תנודות עונתיות. אם התיקון לא הניב שיפור — אנו מבטלים אותו וחוזרים להשערות.
- מסירת המלצות. אנו מוסרים את מפת המשפך, את רשימת השינויים שהוטמעו ואת תור ההשערות הבאות עם הערכת האפקט הצפוי.
מחזור כזה אנו חוזרים עליו: אחרי כל סבב המשפך מצטמצם בצווארי הבקבוק, וההחלטות נשענות על מדידות ולא על דעות. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מה מקבלים בסיכום הניתוח
בסיכום הניתוח מקבלים לא "המלצות" מופשטות, אלא ערכה עובדת שאפשר מיד לגשת איתה לתיקונים ולניטור. כל ארטיפקט מכסה את תחומו: האחד מראה היכן הולך לאיבוד כסף, השני — מדוע, השלישי — מה לעשות, הרביעי — כיצד לא לאבד את התוצאה בעוד חודש.
- דוח משפך — תמונה רוחבית של כל השלבים: מהכניסה לאתר ועד להזמנה שהושלמה, עם שיעור המרה של כל מעבר ופילוח לפי מקורות, מכשירים וקטגוריות מוצרים. רואים לא רק "היכן נחלש", אלא גם עד כמה הסטייה הזו חורגת מהנורמה לתעבורה שלכם.
- מפת נקודות הקטיעה — השלבים המדויקים שבהם משתמשים עוזבים: סל הקניות, טופס ההזמנה, בחירת משלוח, תשלום. לכל נקודה — שיעור האבדות והסיבה הטכנית: תגובה איטית, שגיאת ולידציה, שלב לא ברור, קטיעת סשן.
- רשימת תיקונים — רשימת שינויים מתועדפת: מה יניב אפקט מהיר ובמאמץ מועט, ומה דורש שיפור לוגיקה או אינטגרציה עם 1С. עם הערכת הגידול הצפוי בהמרה לכל סעיף.
- דוחות מוגדרים — חתכים מוכנים בפאנל: משפך לפי ימים, השוואת תקופות, דוח סלים נטושים, חתך לפי מקורות. אתם צופים בהם בעצמכם, בלי ייצוא והרכבה ידנית.
- נוהל ניטור — מסמך עם תדירות הבדיקות, ערכי סף ורשימת אחראים. סטייה של ההמרה בגודל מוגדר — אות, ולא גילוי כעבור רבעון.
- סכמת נתונים — כיצד אירועים מקושרים בין האתר, מערכות האנליטיקה והמערכת החשבונאית, כדי שהמספרים בדוחות יתאימו להזמנות בפועל.
- פרוטוקול בדיקת השערות — סדר ביצוע התיקונים ואופן מדידת התוצאה, כדי להפריד אפקט אמיתי מתנודות עונתיות.
את הערכה מעבירים עם פירוט: עוברים על כל ארטיפקט, מסבירים את לוגיקת החישובים ומראים כיצד לקרוא את הדוחות בהמשך באופן עצמאי. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.
במה שונה ניתוח משפך מניתוח רוחבי?
ניתוח משפך המרות עונה על השאלה "היכן בדיוק הולכים לאיבוד הקונים בתוך החנות". אנו מסמנים את שלבי הרכישה — צפייה בקטלוג, הוספה לסל, תחילת תהליך התשלום, תשלום — וסופרים את המעברים ביניהם.
צוואר הבקבוק נראה מיד: אם נוטשים את הסל בשלב הזנת פרטי המשלוח, הבעיה היא בטופס, ולא בפרסום. המשימות של הניתוח כאן הן מקומיות: להסיר חיכוך בשלב מסוים, לפשט את תהליך התשלום, לתקן את המסננים.
ניתוח רוחבי מסתכל רחב יותר — על מקורות התנועה ותרומתם להכנסות. הוא מקשר בין ערוץ הפרסום להזמנה דרך כל שרשרת הנקודות למגע: חיפוש, רשתות חברתיות, דיוורים, ביקורים חוזרים. השאלה נשאלת אחרת: איזה ערוץ מביא קונים, ואיזה שורף תקציב על אלה שעוזבים בלי רכישה. הכלים כאן שונים — מערכות לניתוח אינטרנט עם אינטגרציה של חשבונות פרסום ונתוני החשבונאות של החנות.
ההבדל בין הגישות הוא עקרוני. המשפך עובד עם ההתנהגות בתוך האתר ואינו רואה מאיפה הגיע האדם. ניתוח רוחבי רואה את המקור, אבל בלי סימון השלבים לא יראה באיזה שלב הערוץ מאבד את הלקוח.
לכן החזק ביותר הוא כשהם עובדים יחד: הניתוח הרוחבי אומר איזה ערוץ כדאי להרחיב, והמשפך — מה בחנות מונע מהערוץ הזה להביא הכנסות.
בפועל, אנו בונים תחילה משפך לפי שלבי הרכישה, מוצאים כשלים בתהליך התשלום, ורק אחר כך מחברים ניתוח רוחבי כדי לחלק את המאמצים לפי מקורות התנועה. סדר כזה חוסך זמן: אין טעם לתקן פרסום כל עוד הסל מאבד חצי מהקונים סתם כך.
מקרה בוחן: כיצד עלה שיעור ההמרה לאחר סילוק הקטיעות
מה היה לפני
חנות אינטרנטית על 1С-Битрикс עם מגוון של כמה אלפי פריטים ותנועה חיה. האנליטיקה הציגה תמונה אחידה: אנשים נכנסים, שמים מוצרים בעגלה — וזה הכל. שיעור ההזמנות שהושלמו עמד על כ-1.2%, ומכל עשר עגלות תשע נותרו נטושות.
מילוי הטופס ארך בממוצע 6 דקות ו-40 שניות: הקונה עבר דרך הרשמה עם אימות, שלב משלוח נפרד ותשלום במסך האחרון.
הבעלים ראה רק את נתון המכירות הסופי ותלה את הכישלון ב"תנועה חלשה". פירקנו את המשפך לשלבים וראינו שהבעיה אינה בהבאה: אנשים הגיעו לעגלה, אך לא שרדו את מילוי הטופס.
מה שינו
תחילה הרכבנו משפך מקצה לקצה לפי אירועים — מצפייה בכרטיס המוצר ועד להזמנה מאושרת, עם פילוח לפי מקורות וסוגי מכשירים. הקטיעות התרכזו בשני מעברים: בין העגלה לטופס הפרטים ובין בחירת המשלוח לתשלום.
לאחר מכן עבדנו ממוקד. את ההרשמה החליפו במילוי טופס ללא חשבון חובה — פרטי הקונה נשמרים בהזמנה, והחשבון נוצר אוטומטית. את שלבי המשלוח והתשלום איחדנו למסך אחד, השלמנו כתובות ואמצעי תשלום שמורים, והסרנו הקלדה חוזרת.
את העגלה הפכנו לניתנת לעריכה ישירות במהלך מילוי הטופס: עריכת הכמות אינה זורקת עוד לשלב הקודם. בנפרד הגדרנו החזרת עגלות נטושות — מכתב עם הרכב ההזמנה השמור נשלח כעבור שעה ושוב למחרת.
מה קרה בסופו של דבר
שיעור ההזמנות שהושלמו עלה מ-1.2% ל-2.1% — עלייה של כמעט פי שניים בהמרה על אותה תנועה. זמן מילוי הטופס הממוצע הצטמצם ל-2 דקות ו-10 שניות, ומספר העגלות הנטושות בתקופה דומה ירד בכ-40%. חלק מההחזרות נבעו מהמכתבים: קונים שעזבו בשלב התשלום חזרו והשלימו את ההזמנה עד הסוף.
תוצאת היישום אינה נשענת על תיקון חד-פעמי, אלא על מחזור מתמשך: המשפך מפורק לשלבים, לכל מעבר יש מדד ובעלים, והשינויים נבדקים על חלק מהתנועה. קו מתאר כזה מאפשר למצוא קטיעות חדשות לפני שהן טורפות את ההכנסה.
ספקות טכניים נפוצים
איסוף נתונים לניתוח משפך המרות כמעט תמיד נתקל בשלוש שאלות טכניות: האם זה ישבור את החנות הנוכחית, האם היא תעמוד בעומס, והאם זה ייצור סיכונים לנתונים האישיים של הקונים. להלן — כיצד אנו פותרים כל אחד מהספקות הללו בפועל.
האם זה תואם להגדרות הנוכחיות של החנות?
כן. אנו עובדים עם אירועים שהחנות כבר מייצרת: ביצוע הזמנה, הרשמה, הוספה לסל, מעברים בין שלבי ביצוע ההזמנה. בניית המשפך נשענת על התגיות והמודולים הקיימים, ללא כתיבה מחדש של לוגיקת הקטלוג, הסל וביצוע ההזמנה.
אם חלק מהאירועים אינם מתויגים או מתויגים חלקית — אנו מוסיפים את הנקודות החסרות, מבלי לפגוע בתרחישי העבודה של הקונה.
האם העומס על השרת יגדל והאתר יאט?
איסוף האירועים מתבצע באופן אסינכרוני ואינו חוסם את הגשת הדפים: הנתונים נשלחים בזרם נפרד, ולא ברגע רינדור הקטלוג. דוחות כבדים מחושבים על בסיס חתכים מצטברים, ולא על בסיס לוגים "גולמיים" לכל בקשה, לכן תעבורה בשיא אינה הופכת לתור בקשות לבסיס הנתונים. פרופיל העומס נלקח לפני ההטמעה ואחריה — ומשווים את זמן התגובה של דפי המפתח.
כיצד מובטחת אבטחת הנתונים של הקונים?
נתונים אישיים אינם יוצאים ממתחם החנות בצורה גלויה: לניתוח עוברים מזהים אנונימיים ואירועים, ולא שמות, טלפונים וכתובות. הגישה לדוחות מופרדת לפי תפקידים — השיווק רואה את המשפך, אך לא נתונים אישיים. כל השינויים מתועדים ביומן, כך שברור מי ומתי צפה או ייצא חתך.
כמה זמן אורכת ההטמעה והאם ניתן לחזור אחורה?
את המשפך הבסיסי אנו בונים באיטרציות: תחילה שלבי המפתח של ביצוע ההזמנה, לאחר מכן — תרחישים משניים. כל שלב מוטמע בנפרד ונבדק על תעבורה אמיתית, לכן התוצאה הביניימית נראית כבר לאחר האיטרציה הראשונה.
החזרה אחורה בטוחה: איסוף האירועים מושבת באופן בלתי תלוי בלוגיקת החנות, וההגדרות הקודמות נשמרות עד לאישור התוצאה.
בואו נדון במשימה שלכם
כדי לחזור עם הערכה ותוכנית יישום, אנחנו צריכים הקשר: איך החנות בנויה כיום והיכן בדיוק הולכים לאיבוד הקונים. ניתוח משפך ההמרות מתחיל לא מדוחות, אלא מהתיאור שלכם את המשימה — אילו שלבים עובר הלקוח מהכניסה ועד לתשלום, באיזה שלב ניכרת הנשירה, ומה כבר ניסיתם לשנות.
ככל שהנתונים הראשוניים מדויקים יותר, כך ההערכה של היקף העבודה מדויקת יותר ומספר סבבי התיאום קטן יותר.
תארו את המשימה — ואנחנו נחזור עם תוכנית יישום שבה יהיה ברור אילו נתונים אנחנו אוספים, אילו השערות אנחנו בודקים ובאיזה סדר. אם במהלך הניתוח יידרש ייעוץ של מהנדס בנושא שנוי במחלוקת — נצרף אותו לדיון, כדי שההחלטה תתבסס על עובדות ולא על ניחושים.
מה כדאי לשלוח בהודעה הראשונה:
- אילו שלבים במשפך כבר מתויגים וכיצד מחושבת ההמרה ביניהם;
- היכן, לפי התצפיות שלכם, הנשירה העיקרית — כניסה, סל, השלמת הזמנה, תשלום;
- אילו אירועים נרשמים והאם קיימת אנליטיקה רוחבית לפי מקורות;
- כיצד בנויים הסל והשלמת ההזמנה, והאם יש סלים נטושים;
- אילו אינטגרציות קשורות להזמנה — תשלום, משלוח, מחסן, CRM;
- מה כבר שיניתם ואיזו תוצאה זה הניב;
- אילו מגבלות בלוחות זמנים ובגישות למערכות.
זה מספיק כדי להעריך את היקף העבודה ולהציע תוכנית יישום לפי שלבים. בהמשך נתאם את הסדר: תחילה אוספים נתונים ובודקים השערות, אחר כך מבצעים שינויים ומודדים את האפקט על אותן מטריקות. תארו את המצב הנוכחי — נחזור עם הערכה ותוכנית.