מערכת בינה מלאכותית להתאמה אישית של דיוור דוא"ל למדיה

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע התאמה אישית של תפוצות email נשברת בקנה מידה

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

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

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

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

מה נותנת מערכת ההתאמה האישית: אפקטים מדידים

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

שיעור הנמענים הפעילים

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

פתיחות חוזרות

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

הפחתת נטישות ושליטה בתדירות המגעים

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

הסרת העבודה הידנית של צוות העריכה

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

מצבי עבודה: כללים, סגמנטים, מודל מתאמן

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

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

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

השוואת המצבים

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

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

שלבי ההטמעה: מביקורת נתונים ועד להשקה

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

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

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

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

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

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

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

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

מה אנחנו מוסרים לידיים: תצורות ותקנונים

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

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

מקרה בוחן: מדיה עם מהדורות יומיות וסגמנטים

ממה התחלנו

למוציא לאור «Городской вестник» יש כמה מהדורות יומיות: מבחר חדשותי בבוקר, תצוגות מקדימות בשעות היום, דייג'סט בערב. את הסגמנטים לכל מהדורה אסף העורך ידנית — ייצא מנויים לפי נושא, ניקה כפילויות, הצליב עם היסטוריית המעברים של השבוע.

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

מה שינו ומה יצא

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

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

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

מה לעשות אם כבר הוגדרו סגמנטים סטטיים

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

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

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

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

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

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

ספקות טכניים: נתונים, השהיות, נסיגות

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

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

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

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

מה קורה ברגע של מהדורה המונית?

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

האם אפשר להחזיר את הלוגיקה הקודמת של התפוצה?

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

מה אם הנתונים על המנוי מעטים או לא נקיים?

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

נדבר על המשימה: מה נדרש כדי להתחיל לעבוד

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

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

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