יצירת סגמנטים

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

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

יצירת סגמנט

שלב 1: פתיחת עורך הסגמנטים

לחצו Segments בסרגל הצד.
לחצו New Segment (או פתחו סגמנט קיים לעריכה).

שלב 2: Details

מלאו את כרטיס Details:

Name - שם תיאורי (למשל "Premium trial users - expiring this week").
Description - מה הסגמנט מייצג והיכן משתמשים בו.
Tags - הקלידו תג ולחצו Enter כדי להוסיף אותו. הערכים מופיעים כתגיות הניתנות להסרה מתחת לשדה. אין כפתור Add נפרד.

שלב 3: בניית קבוצות המסננים

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

Filter Groups - אזור ההכללה. משתמשים חייבים להתאים לתנאים האלה כדי להיכלל בסגמנט.

פרופילי סורקים

פרופילים שמסומנים כסורקים או בוטים מוחרגים מכל סגמנט כברירת מחדל, גם כשהם מתאימים למסננים שלכם - אותם פרופילים שדף הקהל כבר מסתיר. מתג Include crawler profiles בעורך מחזיר אותם לסגמנט אחד כשבאמת רוצים לבחון תעבורת בוטים. תצוגת הגודל, הספירה המדויקת, פירוט ה"ניתן להגיע לפי ערוץ" והקהל שקמפיין או מסע באמת שולחים אליו - כולם מכבדים את אותה הגדרה, כך שהמספר שאישרתם הוא המספר שיקבל הודעה.

Exclude filters - אזור ההחרגה. משתמשים שמתאימים לקבוצת החרגה כלשהי מוסרים מהסגמנט, גם אם הם מתאימים לקבוצת הכללה.

ממשק v2 במבט מהיר

תגי מספר צבעוניים לכל קבוצה - 1 ירוק, 2 ענבר, 3 כחול, 4 ורוד, 5 סגול - במקום הכותרת הישנה "Filter Group N". הצבעים מתחלפים לפי מספר הקבוצה, כך שקל לעקוב אחר הקבוצה שאתם עורכים.
AND/OR ConnectorChip בין שורות אחיות וגם בין קבוצות. הרכיב הוא הבורר - אין כותרת "Match ALL/ANY" לכל קבוצה ואין אפשרות "Match ALL groups" נפרדת בראש העמוד.
+ Add condition - כפתור מקווקו בתחתית כל קבוצה.
+ Add filter group - כפתור מקווקו מתחת לקבוצה האחרונה בבלוק.
חלון אישור לפני מחיקת קבוצה לא ריקה ("Remove this filter group? It contains N condition(s)…"). קבוצות ריקות נמחקות בשקט.
תג ספירה שמתעדכן בזמן אמת לכל קבוצה - מחושב מחדש כ־400 מילישניות לאחר הפסקת העריכה, כך שתמיד אפשר לראות לכמה משתמשים הקבוצה מתאימה.
בוררי האירועים והמאפיינים הם תיבות בחירה עם חיפוש (combobox). כשמקלידים שם שאינו קיים, הרשימה מציגה שורה נוספת + Create event "<query>" (או + Create attribute "<query>") שמוסיפה מיד את הרשומה לסכימה - שימושי לבניית סגמנטים לפני שמנגנון המעקב הוגדר.

שורות המסננים מוצגות ככרטיסים עם מסגרת, כך שכל שורה היא יחידה נפרדת. אין ידית גרירה - שינוי סדר המסננים בקבוצה אינו משפיע על חישוב ההתאמה (AND / OR הם חילופיים).

שלב 4: שמירה

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

סוגי מסננים

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

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

כל אחד מוסבר בהמשך.

User attribute

התאמה לפי מאפיין מותאם שהגדרתם לאנשי הקשר שלכם.

plan equals "premium"
mrr greater than 1000
signup_date within last 30 days

Default user attribute

התאמה לפי אחד משדות הפרופיל המובנים שיש לכל איש קשר: email, phone, firstName, lastName, country, language, timezone, createdAt, isBot, שדות המכשיר ומערכת ההפעלה, וציוני ה-ML (ml_engagement_score, ml_churn_score, ml_churn_risk, ml_channel_preference, predictive_event_score, predictive_event_likelihood). אותם אופרטורים כמו במאפיין מותאם; ההבדל הוא שהשדה מגיע מרשימה קבועה ולא מהסכימה שלכם, ולכן הבורר יודע מהו הטיפוס ומציע את שדה הערך הנכון - בורר מדינות במקום תיבת טקסט חופשי, כן/לא לערך בוליאני, ובורר low / medium / high / critical לסיכון נטישה.

אנשי קשר ללא ערך

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

תנאים שליליים תואמים אותו: אינו, אינו מכיל, אינו אחד מ ואינו קיים. "התוכנית אינה Free" כולל אנשי קשר ללא תוכנית.
תנאים חיוביים אינם תואמים: הוא, מכיל, אחד מ, קיים, וכל השוואה - כולל קטן מ ולכל היותר. ערך לא ידוע אינו ערך קטן, ולכן "ציון לכל היותר 5" אינו כולל אנשי קשר ללא ציון. כדי לכלול אותם, צרפו אינו קיים בקבוצת OR.
שדות כן/לא (כמו isBot) קוראים ערך ריק כלא.
ציוני ML: איש קשר שהמודל עדיין לא דירג הוא ללא ערך, ולכן אותו כלל חל - "סיכון נטישה אינו high" כולל אותו.
ספירות שונות: ספירת אירועים או הודעות מתחילה באפס, ולכן "ביצע לכל היותר 3 פעמים" כולל מי שמעולם לא ביצע את האירוע, ו"לפחות 0 פעמים" הוא כולם. מספר הפעמים חייב להיות מספר שלם, 0 ומעלה.
תאריכים: שדה תאריך שנשמר כטקסט (כמו lastEventTime) מושווה כתאריך - ב- או לפני יום כולל את כל אותו היום.

Event

התאמה לפי השאלה אם משתמש ביצע אירוע (וכמה פעמים), עם אפשרות להוסיף תנאים על מאפייני האירוע וטווח זמן.

Performed "purchase" within last 30 days
Performed "feature_used" at least 5 times
Did NOT perform "onboarding_completed"
Performed "purchase" with property amount >= 100

מי שהסירו את ההרשמה מקמפיין או ממסע

בחרו את האירוע message.unsubscribed, הוסיפו את המאפיין campaignId (או canvasId למסע) ובחרו את הקמפיין או המסע לפי השם, ואז קבעו את טווח הזמן - למשל ב-30 הימים האחרונים. בלי המאפיין תקבלו את כל מי שהסירו את ההרשמה ממשהו בטווח הזה. אותו בורר שמות עובד בכל אירוע הודעה: message.opened, message.clicked, message.delivered וכל השאר.

אותם ערכים, N פעמים

באופרטורי הספירה (לפחות / לכל היותר N פעמים) אפשר להוסיף עם אותם ערכים של - מאפיין אירוע אחד עד חמישה. הספירה נעשית אז לכל שילוב ערכים נפרד, והאדם מתאים כששילוב כלשהו מגיע ל-N.

Performed "hotel_viewed" at least 2 times in the last 2 days with the same hotel and check_in

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

Behavioral

קיצורים מבוססי פעילות: active_last_7_days, active_last_30_days, inactive_7_days, inactive_30_days. רק האירועים של איש הקשר עצמו נחשבים כפעילות - הודעות שנשלחו אליו, פתיחות ושלבי מסע אינם נחשבים.

Segment

שיוך לסגמנט שמור אחר. האופרטורים הם in_segment / not_in_segment. שימושי לסגמנטציה מקוננת:

In segment "VIP Customers"
NOT in segment "Churned Users"

Entity

התאמה לפי הקשר של המשתמשים לרשומות של ישויות מותאמות (הזמנות, הרשמות וכדומה).

App

האם המשתמש השתמש באפליקציה ספציפית (או באפליקציה כלשהי בפלטפורמה) ב־N הימים האחרונים.

Canvas execution

משתמשים שכרגע במסע / שהשלימו / שיצאו ממסע ספציפי (או ממסע כלשהו).

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

מתי הגיעו אליו לאחרונה. אחרי שבוחרים שלב, אפשרות זמן מצמצמת אותו לאנשים שהגיעו לאחרונה לשלב ב-N הימים האחרונים, או בין שני תאריכים (ברירת המחדל היא הגיע לאחרונה: בכל זמן). נספרת הפעם האחרונה שהאדם נכנס לשלב, כך שמי שהגיע אליו במרץ ושוב אתמול נספר לפי אתמול. מסנן מסע שנשמר בלי מסע לא מתאים לאף אחד.

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

Channel subscription

רשום / לא רשום לערוץ מסוים (אימייל / SMS / WhatsApp / Push), עם אפשרות לסנן לפי סטטוס.

List membership

משויך / לא משויך לרשימת הרשמה.

Bounce status

סטטוס תקפות האימייל: email_valid, email_bounced, email_hard_bounced, email_soft_bounced.

Wallet pass

האם למשתמש יש כרגע כרטיס ארנק (wallet pass) פעיל. אפשר להגביל את ההתאמה לתבנית כרטיס מסוימת ו/או לפלטפורמת ארנק (Apple / Google). אופרטורים: has_active / not_has_active.

E-Commerce

התאמה לסגמנט RFM, מסנני הזמנה / הוצאה / עגלה, זיקה לקטגוריה ולמותג, וציוני מחזור הרכישה החזויים - Predicted CLV (365 הימים הבאים), Predicted CLV tier, Predicted Next Order (ימים) ו-Purchase Overdue. שימושי ל"כל ה־Champions" או "משתמשים עם סך הוצאות ≥ $500".

מסנני הזמנות, הוצאה ועגלה

המסננים האלה קוראים נתונים שנשמרים על כל איש קשר ומחושבים מחדש מההזמנות שלו בכל פעם שהזמנה מגיעה או משתנה - מהחנות שלכם (Shopify, WooCommerce, Magento, PrestaShop), מ-Orders API, מה-SDK או מסביבת דמו. הזמנות שבוטלו או הוחזרו במלואן אינן נספרות; החזר חלקי מקוזז מסה״כ ההוצאות. הסכומים במטבע הדיווח של סביבת העבודה.

מסנן	איש קשר בלי הזמנות (או בלי עגלה)
סה״כ הזמנות, CLV היסטורי (סה״כ הוצאות), ערך עגלה	נספר כ-0. "סה״כ הזמנות ≥ 0" הוא כולם; "סה״כ הזמנות ≤ 2" כולל מי שמעולם לא קנה; "סה״כ הזמנות ≥ 1" הם אותם אנשים כמו ביצע רכישה.
ערך הזמנה ממוצע, ימים מאז ההזמנה האחרונה, ממוצע ימים בין רכישות	לעולם לא תואם, בשום כיוון - אין ממוצע, הזמנה אחרונה או קצב להשוות אליהם. "ימים מאז ההזמנה האחרונה ≥ 30" פירושו קנה, אבל לא ב-30 הימים האחרונים; הוסיפו מעולם לא רכש בקבוצת OR כדי לכלול גם מי שמעולם לא קנה.
דרגת CLV היסטורי, קונה קטגוריה / מותג, קטגוריה / מותג מובילים	לעולם לא תואם - אלה קיימים רק לקונים.

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

מסעות, הודעות In-App וקהלי קמפיינים מעריכים כל אחד מהמסננים האלה באותו אופן.

מסנני קופונים

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

מסנן	תואם ל
השתמש בקוד קופון	אנשים שהשתמשו בקוד הזה בהזמנה. ללא תלות באותיות גדולות או קטנות (`summer10` מוצא את `SUMMER10`).
השתמש בקופון כלשהו	אנשים שהשתמשו בקוד קופון אחד לפחות בהזמנה.
מעולם לא השתמש בקופון	אנשים שלא השתמשו בקוד קופון - כולל מי שמעולם לא קנה. עם חלון זמן: אין קופון ב-N הימים האחרונים.

הזמנות שבוטלו או הוחזרו במלואן לא נספרות כשימוש בקוד. המסננים קוראים את הקודים שנקלטו מהחנות או מ-Orders API (ראו הזמנות - קופונים); מסעות וקהלי קמפיינים מעריכים אותם באותו אופן.

מסנני חנות וערוץ

שני מסנני מסחר אלקטרוני עונים על השאלה "איפה הם קנו":

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

אפשר להגביל כל אחד מהם לב-N הימים האחרונים וללפחות N הזמנות (1 עד 20) - למשל "לפחות 2 הזמנות בקופה בחנות ב-90 הימים האחרונים". הזמנות שבוטלו או הוחזרו במלואן לא נספרות. מסעות וקהלי קמפיינים מחשבים אותם באותה דרך. ראו חנות וערוץ מכירה.

Warehouse synced list

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

Device

התאמה לפי המכשירים הרשומים של איש הקשר: האם בכלל אפשר להגיע אליו בפוש (Can receive a push / Cannot receive a push / Has a known device), או לפי שדה מכשיר שה-SDK מדווח - שווה, לא שווה, מכיל, בתוספת App version is at least / App version is below להשוואת גרסאות.

Random bucket number

כל איש קשר מקבל מספר אקראי בין 0 ל-9999 כשהפרופיל שלו נוצר. המספר מחושב מתוך המזהה של הפרופיל, ולכן הוא לעולם אינו משתנה עבור אותו אדם - לא כשהוא מתחבר, לא כשהוא מעדכן פרטים ולא כשהוא חוזר אחרי שנה - והמספרים מפוזרים באופן אחיד, כך שכל טווח שלהם הוא נתח קבוע מהקהל שלכם: 1,000 דליים הם 10%, ו-5,000 הם חצי.

לכן זה הכלי לקבוצות שחייבות להישאר זהות לאורך שליחות:

קבוצת ביקורת גלובלית (holdout). הוסיפו Random bucket number is between 0 and 999 כקבוצת החרגה בקהל של כל קמפיין ומסע. אותם 10% לעולם לא מקבלים הודעות שיווקיות, וכך אפשר להשוות אותם לכל השאר ולמדוד מה ההודעות שלכם באמת מוסיפות.
פיצול A/B יציב. כוונו גרסה אחת ל-is less than 5000 ואת השנייה ל-is at least 5000. כל אדם רואה את אותה גרסה בכל פעם, בכל ערוץ.
ניסוי שלא נוגע בקבוצת הביקורת. between 1000 and 5499 ו-between 5500 and 9999 מחלקים את 90% הנותרים לשניים בלי לגעת בדליים 0-999.

אופרטורים: is, is not, is less than, is at most, is greater than, is at least, ו-is between, שמקבל שני מספרים וכולל את שני הקצוות. הערכים חייבים להיות מספרים שלמים בין 0 ל-9999; כל ערך אחר נדחה בשמירה.

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

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

הגיע מייבוא

אנשי קשר שייבוא אנשי קשר - קובץ CSV או JSON ב-Data → Bulk Import - יצר או עדכן. בחרו ייבוא קודם אחד או יותר (כל ייבוא מוצג עם שם הקובץ, התאריך ומספר השורות) ובחרו:

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

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

איש קשר שומר את 50 הייבואים האחרונים שלו; הישנים ביותר נשמטים ראשונים. רק ייבואי אנשי קשר נחשבים - ייבואי אירועים, ייבואי ישויות וסנכרוני מחסן נתונים אינם מסמנים אנשי קשר (לסנכרון השתמשו ב-רשימה מסונכרנת ממחסן).

הערה

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

פעילות הודעות

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

[קיבל / נמסרה לו / פתח / לחץ / חזרה (bounce) / ביטל הרשמה / נכשלה] [מקמפיין / מקמפיינים עם תגית / מקמפיין כלשהו / ממסע / משלב במסע / ממסעות עם תגית / מכל הודעה] [בכל ערוץ / באימייל / ב-SMS / בפוש / ב-WhatsApp / בתוך האפליקציה / ב-Webhook / ב-Viber] [בכל זמן / ב-N הימים האחרונים / בין תאריכים / לפחות N פעמים / לכל היותר N פעמים / אבל לא ב-N הימים האחרונים]

קיבל פירושו שההודעה נשלחה - נמסרה לספק האימייל, ה-SMS, הפוש, WhatsApp, Viber או ה-Webhook (האירוע message.sent). נמסרה לו הוא אישור המסירה של הספק או של המכשיר.
רשימת הערוצים מציעה רק ערוצים שמדווחים על הפעולה: אין "פתח" ל-SMS, לפוש או ל-Webhook, ו"חזרה" קיימת רק באימייל. פתיחה ב-WhatsApp היא אישור קריאה; פתיחה בתוך האפליקציה היא הצגת ההודעה.
פתח באימייל (או בכל ערוץ) מתאים גם לאנשים שלחצו במייל: לחיצה מוכיחה שהמייל נפתח, גם כשהתמונות היו כבויות. פתיחות של בוטים ולחיצות של סורקי קישורים אינן נספרות לעולם. לפחות N פעמים ולכל היותר N פעמים משווים את הגדולה מבין שתי הספירות, פתיחות או לחיצות במייל.
הודעות בתוך האפליקציה נספרות רק כשבוחרים בערוץ בתוך האפליקציה; "בכל ערוץ" מכסה את שאר הערוצים.
קמפיינים / מסעות עם תגית משתמשים בתגיות שהקמפיינים או המסעות נושאים כעת - תייגו קמפיין מאוחר יותר והשליחות הקודמות שלו נספרות גם הן. שינוי שם התגית לא משנה מי מתאים.
אבל לא ב-N הימים האחרונים מתאים לאנשים שעשו זאת בעבר אבל לא לאחרונה; מי שמעולם לא עשה זאת לא נכלל. ל"מעולם לא" השתמשו במסנן אירוע עם לא ביצע.
המסנן קורא את אותם אירועים כמו מסנן האירוע, ולכן הוא סופר בדיוק את מה שמסנן האירוע המקביל סופר, והספירה החיה, הסגמנט השמור ותנאי במסע נותנים את אותה תשובה. ההבדל היחיד הוא פתח באימייל או בכל ערוץ, שקורא גם לחיצות במייל (ראו למעלה) - המקביל שם הוא מסנן אירוע על message.opened או מסנן על message.clicked באימייל.

מה רוצים	איך בונים
קיבלו את קמפיין X	קיבל - מקמפיין: X - בכל ערוץ - בכל זמן
קיבלו קמפיין כלשהו ב-7 הימים האחרונים	קיבל - מקמפיין כלשהו - בכל ערוץ - ב-7 הימים האחרונים
פתחו אימייל ב-30 הימים האחרונים	פתח - מכל הודעה - באימייל - ב-30 הימים האחרונים
לא פתחו אימייל 30 יום	פתח - מכל הודעה - באימייל - אבל לא ב-30 הימים האחרונים
לחצו על הודעת WhatsApp	לחץ - מכל הודעה - ב-WhatsApp - בכל זמן
קיבלו את ההודעה משלב במסע	קיבל - משלב במסע: מסע ושלב - בכל זמן
היו בשלב במסע	מסנן מסע: נמצא במסע - מסע - שלב
במסע כלשהו עם תגית	מסנן מסע: נמצא במסע כלשהו עם תגית - תגית

שילוב מסננים

AND / OR בתוך קבוצה

השתמשו ב־ConnectorChip בין שורות כדי לשנות את לוגיקת הקבוצה בין AND ל־OR. במצב AND כל התנאים חייבים להתקיים; במצב OR מספיק שתנאי אחד יתקיים.

Group 1 (AND between rows):
  plan = "trial"
  AND signup_date within last 14 days
  AND email_verified = true

התוצאה: משתמשי trial שנרשמו לאחרונה ושכתובת האימייל שלהם אומתה.

AND / OR בין קבוצות

השתמשו ב־ConnectorChip בין הקבוצות כדי לקבוע כיצד הן משתלבות. במצב AND המשתמש חייב להתאים לכל הקבוצות; במצב OR די בהתאמה לקבוצה אחת.

Group 1 (AND): plan = "trial" AND signup_date within last 14 days
OR
Group 2 (AND): performed "feature_used" >= 3 times AND performed "purchase_completed"

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

Exclude filters

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

ספירה חיה

סרגל הצד עוקב אחר גודל הסגמנט בזמן אמת:

מספר המשתמשים התואמים + האחוז שלהם מכלל המשתמשים בסביבת העבודה
ניתן להגיע לפי ערוץ - מתוך המשתמשים התואמים, לכמה מהם קמפיין בערוץ הזה באמת יכול להגיע: יש להם כתובת או מכשיר פעיל, הם לא הסירו את עצמם, והכתובת או הטוקן שלהם לא חזרו בכשל קבוע. זו הבדיקה של נתיב השליחה עצמו, לא רק דגל מנוי. ספר ה-STOP של הטלפונים ורשימות החסימה של הכתובות נבדקים שוב בזמן השליחה ואינם מוחלים כאן, ולכן שליחה אמיתית יכולה רק להיות קטנה מהמספר המוצג
מתעדכן באותה השהיה של כ־400 מילישניות כמו תגי הספירה של הקבוצות
מתעדכן בעת החלפת ConnectorChips של AND/OR

משוער כברירת מחדל, מדויק לפי דרישה

הספירה שמוצגת בזמן העריכה היא הערכה כברירת מחדל, ומופיעה עם הקידומת ≈ (לדוגמה ≈ 12,400). כך העורך נשאר מהיר גם בסביבות עבודה עם מיליוני משתמשים. כשתרצו את המספר המדויק, לחצו על Calculate exact - הסימן ≈ ייעלם והספירה מחושבת מחדש במדויק.

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

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

אנליטיקת צמיחה

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

Current size ו־trend indicator - גדל / יורד / יציב.
Average daily growth ו־peak size של הסגמנט.
תרשים של הגודל לאורך זמן.

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

דוגמאות לסגמנטים

הזדמנות להמרת trial

משתמשי trial שמתקרבים לסיום ולא המירו:

Group 1 (AND): plan = "trial" AND trial_ends_date within next 3 days AND did NOT perform "purchase_completed"

משתמשים פעילים במיוחד

משתמשים עם מעורבות גבוהה:

Group 1 (AND): performed "login" >= 20 times within last 30 days AND performed "feature_used" >= 50 times within last 30 days

לקוחות משלמים בסיכון

משתמשים משלמים שמציגים סימני נטישה:

Group 1 (AND): plan = "paid" AND inactive_30_days AND lifetime_value > 500

נשירה מתהליך ההצטרפות

התחילו ולא סיימו:

Group 1 (AND): performed "signup_completed" AND did NOT perform "onboarding_completed" AND signup_date within last 7 days

משתמשים חוצי פלטפורמות

פעילים בכמה פלטפורמות:

Group 1 (AND): used app on web AND used app on ios

שיטות עבודה מומלצות

שמרו על סגמנטים ממוקדים

"Premium users in US who haven't logged in for 7 days" "All users with various random criteria"

שמות תיאוריים

"Trial users - expiring this week" "Segment 1"

תעדו את המטרה

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

התחילו פשוט, התקדמו

שלב 1: plan = "premium" שלב 2: plan = "premium" AND active_last_30_days שלב 3: plan = "premium" AND active_last_30_days AND performed "feature_x" >= 5 times

שיוך דינמי

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

שמירת סגמנט מוכן לדוחות

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

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

שני דברים שכדאי לדעת לפני שמפעילים:

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

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

מגבלות

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