חלון שיוך בתוכנית שותפים: כללים, תרחישים ובדיקות
חלון שיוך הוא פרק הזמן שבו הפניה יכולה להיות זכאית לעמלה. צריך להגדיר גם את נקודת ההתחלה, כלל ההכרעה בין מקורות והטיפול בליד שנסגר מאוחר, ולבדוק את הכללים בתרחישים אמיתיים.
המדריך הוא חלק ממרכז ההדרכה לבניית תוכנית שותפים. הוא מתמקד בהחלטות ובבדיקות שצריך להתאים למודל העסקי שלכם.
מהו חלון שיוך, ומה הוא לא מבטיח?
חלון שיוך בתוכנית שותפים הוא פרק הזמן שבמהלכו אירוע מזכה, כגון רכישה או השארת פרטים, יכול להיות מיוחס להפניה קודמת. בתוכניות רבות הספירה מתחילה בלחיצה על קישור שותף, אך יש תוכניות המשתמשות גם בחשיפה לפרסום, בקוד קופון או במנגנון אחר.
נניח, לצורך המחשה, שהתוכנית מגדירה חלון של 30 יום ממועד הלחיצה. רכישה לאחר עשרה ימים עשויה לזכות בעמלה; רכישה לאחר 35 יום בדרך כלל לא תזכה מכוח אותה לחיצה. בשני המקרים צריך לבדוק אם התרחש אירוע נוסף ששינה את הזכאות.
חשוב להפריד בין שלושה מושגים: חלון השיוך קובע עד מתי הפניה יכולה להיחשב; מודל השיוך קובע למי נזקפת העסקה כשיש כמה הפניות; ותנאי הזכאות קובעים אם העסקה עצמה מזכה בתשלום.
גם הביטוי הנפוץ “עוגייה ל־30 יום” אינו הבטחה לעמלה במשך חודש. עוגייה היא מידע שהדפדפן שומר לצורכי זיהוי ומדידה. היא עשויה להימחק או להיחסם, ואילו מערכת אחרת עשויה לשמור את הקשר בין ההפניה לרכישה בשרת. התנאי המסחרי ואמצעי המדידה אינם אותו דבר.
לפני שבוחרים תוכנית: מגדירים את השעון
המשפט “חלון שיוך של חודש” נשמע ברור עד שמנסים לבדוק עסקה בקצה החלון. האם מדובר ב־30 יממות ממועד הלחיצה, בחודש קלנדרי או בסוף היום האחרון? באיזה אזור זמן משתמשים, והאם רגע הסיום עצמו נכלל?
בדוגמה היפותטית, לחיצה התרחשה ב־1 במאי בשעה 10:00 לפי UTC, והתוכנית מגדירה 30 יממות מדויקות. נקודת הסיום היא 31 במאי בשעה 10:00 באותו אזור זמן. השאלה אם רכישה בדיוק בנקודה הזאת נכללת צריכה לקבל תשובה מפורשת בכללים או במפרט המערכת.
צריך לברר גם מה מאפס את הספירה. לחיצה חוזרת על קישור של אותו שותף עשויה לפתוח חלון חדש, אך לא בכל תוכנית. כניסה ישירה לאתר אינה בהכרח מאריכה אותו, והוספת מוצר לסל יכולה להיות כפופה להסדר נפרד.
ההמלצה המעשית היא לתעד ארבעה דברים יחד: האירוע שפותח את החלון, משכו, האירוע שסוגר או מחליף אותו, והפעולה שצריכה להתרחש בתוכו. בלי ההגדרות האלה, גם דוח מפורט אינו מאפשר להכריע במחלוקת.
מי מקבל את העמלה כשהלקוח פגש כמה שותפים?
לקוח עשוי לקרוא סקירה באתר אחד, לחזור דרך השוואת מחירים ולפני התשלום לחפש קופון. כל אחד מהאתרים תרם משהו למסע, אבל תוכנית השותפים לא בהכרח מחלקת את העמלה ביניהם.
במודל “קליק אחרון”, ההפניה האחרונה שעומדת בתנאי התוכנית מקבלת את השיוך. במודל “קליק ראשון”, הקדימות ניתנת להפניה הראשונה בהתאם לכללים. קיימים גם הסדרים של חלוקת עמלה, הגנה על שותפי תוכן או קדימות לקופון ייעודי; אין להניח שהם קיימים בלי לראות זאת בתנאים.
הביטוי החשוב כאן הוא “עומדת בתנאים”. קליק אחרון בדוח התנועה אינו בהכרח הקליק האחרון הזכאי לעמלה. למשל, תוכנית עשויה להגביל שימוש בקופונים שלא אושרו או להחריג הפניות מסוג מסוים.
כדאי לבדוק גם אם מגע עם ערוץ אחר משנה את הזכאות. לקוח שחזר דרך מודעת חיפוש של המותג עשוי להישאר משויך לשותף במערכת העמלות, גם אם מערכת האנליטיקה מייחסת את הרכישה למודעה. זו אינה בהכרח תקלה: שתי המערכות עשויות לענות על שאלות שונות.
הלקוח חזר ישירות אחרי שבוע
נניח שלקוח לחץ על קישור שותף, חזר כעבור שבוע באמצעות הקלדת כתובת האתר ורכש. אם החלון עדיין פתוח, הזיהוי נשמר ולא התרחש אירוע שמבטל את הזכאות, העסקה עשויה להיזקף לשותף. עצם העובדה שהביקור האחרון היה ישיר אינה מכריעה.
שותף אחר הופיע רגע לפני התשלום
לקוח הגיע מסקירה מקצועית, אך ביום הרכישה לחץ על קישור באתר קופונים. בתוכנית המבוססת על הקליק האחרון הזכאי, אתר הקופונים עשוי לקבל את העמלה. חלון ארוך לשותף הראשון אינו מגן עליו מפני החלפת השיוך.
הקריאה הייתה בנייד והרכישה במחשב
הלקוח יכול להיות אותו אדם, אבל המערכת לא בהכרח יודעת זאת. בלי מנגנון מותר ומוגדר לזיהוי בין מכשירים, כגון התאמה באמצעות חשבון מחובר, הקשר עלול להיעלם. חלון של 90 יום לא מתקן חוסר יכולת לחבר בין הלחיצה לרכישה.
הליד הגיע בזמן, והעסקה נסגרה מאוחר
בתוכנית לשירות עסקי, לקוח עשוי להשאיר פרטים ביום ה־20 ולחתום על הסכם ביום ה־70. אם האירוע המזכה הוא ליד מאושר, הזכאות עשויה להיקבע כבר בשלב הפנייה. אם התשלום תלוי בעסקה שנסגרה, נדרשת הגדרה נפרדת של תקופת ההכרה ושל החיבור למערכת ניהול הלקוחות.
בדיקות שיוך: לא מסתפקים ברכישת ניסיון אחת
בדיקה שבה לוחצים על קישור ורוכשים מיד מוכיחה רק שהמסלול הפשוט עובד. היא אינה בודקת תפוגת חלון, החלפת שותף או טיפול באירוע שנשלח פעמיים. לפני הבדיקה, מגדירים לכל תרחיש תוצאה צפויה לפי התקנון.
רצוי להשתמש בסביבת בדיקות או בהזמנות שאושרו מראש לצורך זה. רכישות עצמיות עלולות להיות אסורות בתוכנית, ואין הצדקה לייצר עסקאות מלאכותיות רק כדי לבחון מדידה.
- בדיקת גבולות: המרה מעט לפני סיום החלון, בדיוק במועד הסיום ומעט אחריו.
- בדיקת קדימות: מעבר משותף א׳ לשותף ב׳, לחיצה חוזרת וחזרה ישירה.
- בדיקת מסלול: מעבר בין דומיינים, שימוש בסליקה חיצונית וחזרה לאתר.
- בדיקת מחזור חיים: אישור עסקה, ביטול, החזר חלקי ושליחה כפולה של אותו אירוע.
לכל בדיקה שומרים מועד לחיצה, מזהה הפניה, מזהה עסקה, מועד המרה, תוצאה צפויה ותוצאה בפועל. מזהה עסקה קבוע מאפשר לזהות כפילויות, במיוחד כאשר גם הדפדפן וגם השרת מדווחים על אותה רכישה.
בדיקות זמנים עדיף לבצע באמצעות כלים הנתמכים בסביבת הבדיקות, ולא באמצעות שינוי השעון במחשב. השעון הקובע עשוי להיות שעון השרת, ושינוי מקומי עלול ליצור מסקנה שגויה.
המספר חשוב; הכללים סביבו חשובים יותר
חלון שיוך טוב אינו בהכרח הארוך ביותר. הוא חלון שמתאים למחזור הרכישה, מוגדר באופן שאפשר לבדוק ומיושם במערכת מדידה אמינה. עבור שותף, הוא צריך להצדיק את ההשקעה בהבאת לקוחות; עבור מפרסם, הוא צריך לתמוך בכלכלה של התוכנית.
לפני שמשקיעים בעוד מאמר, מגדילים תקציב או משנים תנאים, כדאי לבחור כמה עסקאות מייצגות ולשחזר את הדרך מהלחיצה ועד להחלטת העמלה. שם מתברר אם התוכנית מתגמלת את הפעילות שרוצים לעודד — או רק נראית אטרקטיבית בטבלת התנאים.
על התוכן: מדריך מעשי של מערכת Aperio. דוגמאות מספריות הן להמחשה ואינן נתוני לקוחות או הבטחה לתוצאות. לפרטים על הפלטפורמה: מרכיבי המערכת · מי אנחנו · יצירת קשר.
לחלוק