קמפיינים בתוך האפליקציה

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

סקירה

קמפייני In-App מאפשרים לכם:

• להדריך משתמשים חדשים בעזרת טיפים ומדריכים
• להכריז על יכולות חדשות ועדכוני מוצר
• להניע מעורבות עם קריאות לפעולה (CTA) והנחיות
• לקדם הצעות עם הודעות תלויות הקשר
• להריץ ניסויים עם וריאנטי A/B וקבוצות Control

יתרונות מרכזיים:

• ללא צורך בהרשאה (בניגוד לפוש)
• תוכן עשיר ואינטראקטיבי
• מותאם להקשר של הפעילות הנוכחית
• שיעורי מעורבות גבוהים יותר מ־Push או אימייל
• מוצג עם הגופנים, הצבעים ומצב הכהה של האפליקציה עצמה (הודעות Native)

דרישות מקדימות

ודאו ששילבתם קודם את ה־SDK:

• iOS SDK
• Android SDK
• Web SDK

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

סוגי הודעות

בחרו סוג הודעה שמתאים לתרחיש:

סוג	פריסה	מתאים ל
Modal	במרכז המסך מעל שכבת רקע	הכרזות חשובות, השקת יכולת חדשה
Banner	רצועה עליונה או תחתונה	טיפים קצרים, הצעות רגישות לזמן
Slide-up	מחליק מלמטה	הנחיות עדינות, פתיחת הישגים
Fullscreen	מכסה את כל המסך	הדרכת משתמשים חדשים, עדכונים גדולים
Custom	רינדור שמוגדר על ידי המפתח דרך ה־API	דרישות UI ייחודיות

יצירת קמפיין In-App

קמפייני In-App משתמשים באותו אשף בן שישה שלבים כמו כל ערוץ אחר - ראו יצירת קמפיינים לאשף המשותף. שני השלבים שמתנהגים אחרת הם Compose ו־Delivery.

שלב Compose

שלב Compose משתמש ב־VariantTabs עם בורר שלושה אריחים - אותו מנגנון כמו באימייל:

• Create with Drag & Drop - עורך חזותי שאינו דורש ידע בפיתוח.
• Create with HTML - תצוגה מפוצלת עם עורך קוד בצד אחד ותצוגה מקדימה חיה ב-iframe בצד השני.
• Create from Template - בחירה מתוך תבניות In-App שמורות.

בכל שיטה שתבחרו, ה־HTML שנוצר נשמר ב־customContent של הווריאנט. לאחר כתיבת וריאנט, הוא מתקפל לכרטיס AuthoredSummary עם תמונת iframe ממוזערת בגודל 200×220 של ההודעה שעברה רינדור - לחיצה עליה פותחת את העורך מחדש.

הודעות HTML מחייבות הסכמה מפורשת של האפליקציה

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

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

רוחב מקסימלי ו-HTML רספונסיבי

לModal או לSlide-up שנבנו ב-Drag & drop, ב-HTML או מתבנית יש הגדרת רוחב מקסימלי, בפיקסלים. היא מופיעה בכרטיס הווריאנט אחרי שההודעה נכתבה, בסרגל הכלים של העורך ליד רקע ההודעה, בעורך ה-HTML מעל הקוד, בשלב ה-In-App של מסע, ובתבנית ה-In-App עצמה. השאירו אותה ריקה לברירת המחדל - 600 px ל-Modal ו-400 px ל-Slide-up - או הזינו מספר שלם בין 240 ל-1200. Banner ו-Fullscreen פרוסים על כל המסך ואין להם רוחב מקסימלי; הודעות Native מציירות כרטיס משלהן.

ההודעה מקבלת את הרוחב שלה לפני שהתוכן נפרס: הקטן מבין הרוחב המקסימלי לבין רוחב המסך פחות שוליים קטנים (16 px מכל צד בדפדפן; השוליים של האפליקציה עצמה ב-iOS וב-Android). רק הגובה נקבע לפי התוכן. עיצוב ברוחב 680 px מוצג ב-680 px בדפדפן במחשב, ונכנס למסך בטלפון.

כתבו HTML רספונסיבי. שאילתות המדיה (media queries) שלכם רואות את הרוחב האמיתי של ההודעה, עד הרוחב המקסימלי: @media (max-width: 560px) בתוך ההודעה מתקיים כשההודעה עצמה ברוחב 560 px או פחות, בלי קשר לגודל הדפדפן. עצבו לרוחב המקסימלי כמקרה הרחב ביותר, ותנו לשאילתות המדיה לסדר את העמודות זו מתחת לזו מתחת לו. תנו למיכל החיצוני width: 100% או max-width ולא רוחב קבוע שרחב מטלפון קטן (כ-320 px).

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

מתי זה חל: בדפדפן ברגע שה-backend מתעדכן. ב-iOS וב-Android עם גרסת ה-SDK הבאה; עד אז האפליקציות שומרות על הפריסה הנוכחית (רוחב המסך פחות השוליים, כך שבטאבלט Modal מוצג ברוחב מלא). אפליקציות React Native ו-Unity מציירות את ההודעות בעצמן: מאותה גרסה הן מקבלות את הערך כ-maxWidth / MaxWidth כדי לקבוע לפיו את רוחב ה-web view.

הודעות Native

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

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

	Native	HTML
מוצג גם ללא הסכמת האפליקציה	כן	לא
מתאים לעיצוב של האפליקציה	כן	רק אם תשחזרו אותו ב־CSS
שליטה מלאה בפריסה	לא	כן
עובד היכן שאין WebView (למשל tvOS)	כן	לא

תוכן Native נכתב באריח App style בשלב Compose, לצד Drag & Drop ו-HTML. אם אתם יוצרים קמפיינים דרך ה־API, ראו את Campaigns API לפירוט השדות.

צבעים, גופן ו-CSS מותאם

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

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

שתי אפשרויות עובדות רק בווב:

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

מה אפשר לכוון אליו ב-CSS מותאם: הכרטיס עצמו, h2 (כותרת), p (הודעה), button.primary ו-button.secondary. שדות הצבע נחשפים גם כמשתני CSS - --joryio-inapp-bg, --joryio-inapp-fg, --joryio-inapp-primary, --joryio-inapp-primary-fg, --joryio-inapp-radius, --joryio-inapp-font - כך שאפשר להגדיר אותם מחדש בתוך media query.

אותן לשוניות של וריאנטי A/B זמינות גם ב-In-App, כולל קבוצות Control.

לגרום לכפתורים לעשות משהו

הודעת HTML מותאמת רצה בתוך מסגרת מבודדת (sandbox) בווב ובתוך ה-web view של האפליקציה ב-iOS וב-Android, ברגע שה-SDK של האפליקציה אישר הודעות HTML. אין לה גישה ישירה לעמוד שלכם או שלנו; במקום זאת Joryio מספקת לה גשר קטן.

עיצוב: מוטמע בלבד. שימו את ה-CSS בבלוק <style> בראש ה-HTML או במאפייני style. האפליקציות מציגות את ההודעה תחת מדיניות אבטחה מחמירה שמתירה עיצוב מוטמע, תמונות, גופנים ומדיה ב-https, ותו לא - גיליון סגנונות שנטען מ-CDN עם <link> לא נטען באף מכשיר, לכן העתיקו את מה שצריך לבלוק ה-<style>.

מה רץ במכשיר. Joryio שומרת את הקוד כפי שנכתב בעת שמירת ההודעה (רק <base> ו-<meta http-equiv="refresh"> מוסרים, וקוד פגום מתוקן), אבל האפליקציות מריצות אותו תחת מדיניות האבטחה הזו: בלוקי <script> שלכם, מטפלי onclick בתוך התגית והטמעות <iframe> (סרטון YouTube) לא רצים ב-web, ב-iOS או ב-Android. כפתורים, קישורים, מאפייני data-joryio-action וטפסי data-jry-form עובדים דרך הגשר של Joryio - ראו בהמשך - ואינם צריכים סקריפט. ערכי פרסונליזציה תמיד עוברים escape ל-HTML, כך ששדה בפרופיל לעולם לא יהפוך לקוד (הוסיפו | raw במכוון כשצריך markup משדה). התצוגה המקדימה של הקמפיין מציגה את הפריסה ומפרטת את פעולות הגשר שהכפתורים מפעילים; היא אינה מבטיחה שסקריפט ירוץ במכשיר.

data-joryio-action - הדרך הרגילה

<button data-joryio-action="requestPushPermission">אפשר התראות</button>
<button data-joryio-action="closeMessage">לא תודה</button>

פעולה	מה היא עושה
requestPushPermission	מציגה את בקשת ההתראות של הדפדפן
closeMessage	סוגרת את ההודעה
logConversion	רושמת המרה לקמפיין הזה

ל-logConversion אפשר להעביר שם דרך data-joryio-event; בלעדיו ההמרה נרשמת כ-in_app_conversion.

כל זה קיים גם בחלונית המאפיינים בעורך - On click, Conversion event (optional) ו-Click name (reports) - כך שברוב ההודעות אין צורך לגעת ב-HTML.

קליקים נרשמים אוטומטית

כל קליק על <a> או <button> מדווח מעצמו. כדי לתת שם לקליק בדוחות, הוסיפו data-action:

<a href="/pricing" data-action="pricing_cta">לתוכניות</a>

קישורי http(s) ויחסיים-לשורש נפתחים מהעמוד המארח; עוגנים, mailto: ו-tel: מתנהגים כרגיל.

window.joryioBridge - מה הכפתורים שלכם קוראים

מאחורי data-joryio-action עומד הגשר של ה־SDK, window.joryioBridge. הסקריפט של ה־SDK הוא הסקריפט היחיד שרץ בהודעה, והוא מבצע עבורכם את המתודות האלה:

מתודה	מטרה
logCustomEvent(name, properties)	רישום אירוע עבור המשתמש
setCustomUserAttribute(key, value)	כתיבת מאפיין לפרופיל
logConversion(event)	רישום המרה לקמפיין הזה
logClick(action)	רישום קליק לפי שם
changeUser(userId)	זיהוי המבקר
requestPushPermission()	הצגת בקשת ההתראות של הדפדפן
navigate(url, target)	פתיחת כתובת מהעמוד המארח
closeMessage()	סגירת ההודעה

data-joryio-action יכול לציין כל אחת מהן ולהעביר ארגומנט אחד ב־data-joryio-event - למשל data-joryio-action="logCustomEvent" data-joryio-event="size_selected". מתודה שצריכה שני ארגומנטים, כמו setCustomUserAttribute, לא ניתנת להפעלה מהמרקאפ. בלוק <script> או onclick="joryioBridge.closeMessage()" בתוך התגית שנכתבו בהודעה לא רצים, ולכן גם הם לא יכולים לקרוא לגשר.

הגשר המלא זמין בווב, ב-iOS וב-Android (מגרסאות ה-SDK שכוללות אותו - logCustomEvent, setCustomUserAttribute, changeUser, requestPushPermission, logConversion, logClick, navigate, closeMessage, submitForm; גרסאות נייטיב קודמות חושפות רק closeMessage, navigate ורישום קליקים). אפליקציות React Native ו־Unity מציגות הודעות דרך ה־SDK הנייטיבי של iOS ו־Android, ולכן אותו גשר חל עליהן. אפליקציה שמציירת הודעות ב־web view משלה (onInAppMessage ב־React Native, SetInAppMessageHandler ב־Unity) מחליטה בעצמה מה רץ שם, ושולחת טפסים עם submitInAppForm / SubmitInAppForm. הודעות native משתמשות בכפתורים של האפליקציה, לכן חברו את ה-CTA שלהן דרך הגדרת הכפתורים בקמפיין ולא דרך מרקאפ.

שלב Delivery

שלב Delivery בקמפייני In-App מותאם במיוחד - במקום בורר send-type שמשמש את שאר הערוצים, מוצג הממשק הבא:

בורר טריגר ראשי

שורת חמישה אריחים, On Event מסומן RECOMMENDED:

טריגר	מתי ההודעה מוצגת
Immediate	בסשן הזכאי הבא של המשתמש.
On Event (recommended)	כאשר אירוע שנמצא במעקב מתרחש אצל המשתמש.
Push Notification Tap	אחרי לחיצה על Push שהובילה לאפליקציה.
Attribute Change	כאשר מאפיין במעקב משנה את ערכו.
Attribute Threshold	כאשר מאפיין מספרי חוצה סף.

לכל אריח כותרת־משנה בשורה אחת ותיאור ארוך יותר. בחירה מציגה הגדרות ייעודיות בחלונית האפורה שמתחת:

• Immediate - אין הגדרות נוספות, מלבד Display delay המשותף.
• On Event - בורר אירועים עם חיפוש, אפשרות חלופית של + Create event ותנאי מאפיינים אופציונליים.
• Push Notification Tap - קטע קוד מוכן להעתקה שמראה איך לחבר את ה־SDK למזהה הקמפיין הזה.
• Attribute Change - בורר מאפיין ו־from-value / to-value.
• Attribute Threshold - בורר מאפיין, אופרטור (>, <, ≥, ≤, =) וערך סף.

Display delay

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

Schedule

בחרו תאריכי starts at ו־expires at עם אזורי זמן נפרדים. בורר אזור הזמן מציג בראש את ברירת המחדל של סביבת העבודה, אחריה את Recipient local time, ואז את כל רשימת IANA - כך שהאפשרויות הנפוצות מופיעות ראשונות. הקלידו בשדה כדי לחפש לפי עיר, מדינה או הפרש מ־UTC; מקשי החצים עוברים בין התוצאות ו־Enter בוחר.

השעה שבחרתם נקראת לפי אזור הזמן שבחרתם: 09:00 עם America/New_York מפעיל את הקמפיין ב-09:00 שעון ניו יורק, בלי קשר למקום שבו אתם נמצאים בעת השמירה, והעורך יציג את אותה 09:00 לכל מי שיפתח אותו אחר כך. Recipient local time קורא את השעה לפי מאפיין ה-timezone של כל אדם - הקמפיין מתחיל ב-09:00 עבור איש קשר בטוקיו, וכמה שעות אחר כך ב-09:00 עבור איש קשר בניו יורק; איש קשר ללא מאפיין אזור זמן משתמש באזור הזמן של סביבת העבודה. בורר הסיום עוקב אחרי אזור ההתחלה אלא אם נתתם לו אזור משלו.

Frequency capping

כרטיס אחד מרכז את פקדי התדירות:

• Max impressions per user - למשל 3 פעמים.
• Time window - 1h / 24h / 7d / 30d / 90d / lifetime, או חלון מותאם אישית.
• Min delay between impressions - מרווח מינימלי בין הצגות עוקבות.

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

מתחתיו, כרטיס Workspace touching rules נפרד מציע מתג Ignore Touching Rules. עקיפת כללי המגע של סביבת העבודה מתאימה להודעות תפעוליות או קריטיות, אך אינה אמורה להיות ברירת המחדל.

שיטות עבודה לתדירות

• אל תציפו משתמשים בכמה הודעות In-App באותו סשן
• שמרו על מרווח בין הצגות (לפחות 24 שעות הוא ברירת מחדל טובה)
• שמרו את "Ignore Touching Rules" להודעות באמת קריטיות

Evaluation Mode

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

מצב	זמן תגובה	מה מקבלים	על מה מוותרים
Differential Sync (מומלץ)	~80ms	קמפיינים ללא הגבלה. מיקוד מלא לפי סגמנטים, ישויות והתנהגות. נתוני ישויות בתבניות.	פנייה אחת הלוך ושוב לשרת בעת שינוי מאפיינים שבמעקב.
Session start only	<10ms	הערכה פעם אחת בתחילת סשן.	שינויים לא משתקפים עד שהמשתמש מתחיל סשן חדש.

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

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

רינדור בצד השרת

במצבי Differential Sync ו־Session start only, תוכן ההודעה עובר רינדור בצד השרת לפני שהוא מגיע למכשיר: טוקנים להתאמה אישית, בלוקי תוכן ונתוני קטלוג מוחלפים או נשלפים בצד השרת. כך הודעות In-App מקבלות את אותן יכולות רינדור כמו אימייל - נתוני ישויות, קטעי blocks.* ושליפות מקטלוג המוצרים זמינים בכולם.

השתמשו בכפתור בדיקת רינדור שרת (Server render test) בבונה קמפייני ה־In-App כדי לרנדר את ההודעה בצד השרת לפי נתוני משתמש נבחר ולראות בדיוק מה ה־SDK יקבל - ודאו שההתאמה האישית, הבלוקים ופלט הקטלוג תקינים לפני שהקמפיין עולה לאוויר.

Advanced Settings

חלונית מתקפלת מתחת לכרטיס ההערכה:

Watch mode - קובע מתי ה־SDK מעריך מחדש את זכאות הקמפיין לאחר שינוי מאפיינים:

• Auto (מומלץ) - ה־SDK מזהה אוטומטית באילו מאפיינים תלויים המיקוד והתבניות של הקמפיין ומעריך מחדש כשהם משתנים.
• Always - מעריך מחדש בכל שינוי מאפיין.
• Never - session-start only.

Priority tiebreaker - משמש כששני קמפיינים זכאים בעלי אותה רמת עדיפות:

• Newest (ברירת מחדל) - מציג קודם את הקמפיין הכי חדש.
• Oldest - מציג קודם את הקמפיין הכי ישן (FIFO).
• Random - בחירה אקראית מבין הזכאים.

הבדלים בשלב Audience

שלב Audience עובד כמו בכל ערוץ אחר - אותו בורר מצב, אותו בונה מסננים v2 - עם רכיב אחד מוסתר:

• כרטיס Sending options מוסתר. להודעות In-App אין סטטוס הרשמה; ה־SDK מציג אותן ללא קשר למצב ההסכמה לקבלת אימייל, SMS או Push.

גם ההתראה הכתומה של "Send to everyone" משתמשת בנוסח אחר: הסיכונים ב־In-App הם עומס מחלונות מודאליים ומיצוי תקרת התדירות, ולא פגיעה ביכולת המסירה. תגיות המסננים לדוגמה מתחלפות ל־last_seen within 7 days ול־plan = free.

הצגה ב. כשבסביבת העבודה יש יותר מאפליקציה אחת, שלב ה-Audience שואל גם באיזו אפליקציה ההודעה מוצגת: כל האפליקציות (ברירת המחדל) או אפליקציה אחת - למשל רק אפליקציית הווב של חנות ה-Magento, או רק אפליקציית ה-iOS. ה-SDK של כל אפליקציה אחרת לא מקבל אותה. לשלב ה-In-App במסע יש את אותה הגדרת הצגה ב.

התאמה אישית עם Liquid

תבניות In-App תומכות בכל תחביר Liquid. במצבי Differential Sync ו־Session start only התבנית עוברת רינדור בצד השרת, ולכן יכולה להשתמש גם בנתוני ישויות, בלוקי תוכן ונתוני קטלוג:

Hi {{ user.firstName | default: "there" }},

You've earned {{ user.points }} points!

{% if user.plan == 'free' %}
  <p>Upgrade to unlock more rewards.</p>
{% else %}
  <p>Thanks for being a {{ user.plan }} member!</p>
{% endif %}

Latest order: #{{ entities.order.id }} ({{ entities.order.total | currency }})

המסננים הזמינים כוללים את date_format, pluralize, currency, truncate ו-default. ראו Liquid Templates לתיעוד המלא.

מעקב קליקים על קישורים

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

כל קליק נושא גם את השם שההודעה נתנה לו: ה-data-action של האלמנט, קריאת logClick מהגשר, או link_click / cta_click של ה-SDK עצמו. פתחו גרסה מתוך אנליטיקת הקמפיין ועברו למפת קליקים: כל כפתור וקישור בהודעה מסומן במספר האנשים שהקישו עליו ובחלקם מתוך כל מי שראה אותה, והרשימה לצידה מדרגת את הקליקים לפי כפתור. הודעה נייטיב (ללא HTML) מציגה את הדירוג בלבד. השמות דורשים גרסאות SDK מ-26.09.2026 ואילך; SDK ישן יותר מדווח על כל הקשה כקליק אחד רגיל.

A/B testing

קמפייני In-App תומכים באותם וריאנטי A/B כמו כל ערוץ אחר, כולל קבוצות Control. הקצאת הווריאנט קבועה ועקבית: בפעם הראשונה שמשתמש מוערך, פונקציית גיבוב משייכת את מזהה המשתמש לקבוצת משקל וההקצאה נשמרת - כך שאותו משתמש תמיד רואה את אותו וריאנט.

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

Variant A: 45% - Show campaign
Variant B: 45% - Show alternative
Control:   10% - Show nothing

Variant A conversion: 5%
Control conversion:   2%
Lift: +150%

טפסים בתוך הודעות

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

כשמישהו שולח, ה-SDK שולח את הערכים עם הזהות שהוא מחזיק: פרופיל של משתמש מזוהה מתעדכן (אימייל או טלפון רק כשאין לפרופיל כאלה - טופס אף פעם לא מחליף אותם), מבקר אנונימי הופך לפרופיל ברגע שהטופס מזהה אותו (אימייל או טלפון), הרשימות שסומנו נרשמות, ונרשם האירוע In-App Form Submitted עם campaignId, campaignName, variantId, מפתחות השדות, listsSubscribed, וה-email וה-phone של הטופס עצמו עם phoneUpdated (false כשהפרופיל שמר טלפון אחר משלו), כך שמסעות, קמפיינים מופעלים וסגמנטים יכולים לפעול לפיו. השליחה מופיעה גם כקליק (form_submit) על ההודעה.

תבניות שומרות את הטופס שלהן עם התבנית; קמפיין שמשתמש בתבנית יורש אותו. נתמך ב-Web SDK, ומהגרסאות שכוללות את הגשר המלא גם ב-SDK של iOS ו-Android; אפליקציית React Native שמרנדרת את ה-HTML בעצמה קוראת ל-submitInAppForm; Unity מציג הודעות native בלבד.

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

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

התחילו עם Differential Sync

רוב הקמפיינים צריכים לפעול במצב Differential Sync - הוא מספק את האיזון הטוב ביותר בין יכולות לביצועים.### השתמשו ב־Watch Mode "Auto"

תנו ל־SDK לזהות את התלויות במאפיינים. עברו ל־Always רק אם צריך לעקוב אחר מאפיינים שאינם משמשים ישירות למיקוד; עברו ל־Never רק להודעות קבלת פנים סטטיות.

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

כברירת מחדל, כל משתמש רואה קמפיין פעם אחת. חזרה היא דבר שמפעילים: סמנו Allow this campaign to show more than once per user תחת Frequency Capping. אם תשאירו את התיבה כבויה, ההודעה תוצג פעם אחת לכל אדם, לתמיד - בלי חלון זמן ובלי תפוגה.

כשהאפשרות דלוקה, השאירו את המגבלה ריקה לבלתי מוגבל, או קבעו מספר וחלון זמן (דקות, שעות, ימים, שבועות או חודשים) כדי להגביל. חלון הזמן חל על הספירה בלבד; ה־Min Delay שמתחתיו הוא זמן צינון נפרד בין שתי הצגות.

מנעו עומס הודעות:

• מעורבות גבוהה - 3 הצגות ל־7 ימים
• בינונית - 2 הצגות ל־14 ימים
• תדירות נמוכה - הצגה אחת ל־30 ימים

בדקו עם וריאנטי A/B

כללו תמיד קבוצות Control כשאתם מודדים את ההשפעה על המרות. החלוקה המומלצת היא 45% / 45% / 10% control.

פתרון בעיות

הקמפיין לא מוצג

בדקו לפי הסדר:

1. סטטוס הקמפיין הוא active (לא draft)
2. טווח התזמון כולל את הזמן הנוכחי (בין startsAt ל־expiresAt)
3. המשתמש מתאים למסנני המיקוד
4. המשתמש לא חרג מתקרת התדירות
5. אין קמפיין בעדיפות גבוהה יותר שחוסם את הצגתו
6. המשתמש אינו בקבוצת Control

שגיאות תבנית Liquid

• מאפיינים חסרים - עטפו עם | default: "fallback"
• תחביר שגוי - בדקו {% endif %}, {% endfor %} תואמים

בעיות ביצועים

• פשטו את לוגיקת המיקוד
• פשטו תבניות Liquid (הימנעו מלולאות כבדות)
• השתמשו ב־Session start only להודעות סטטיות

In-App מול Push

יכולת	In-App	Push
הרשאה	לא נדרשת	נדרשת
מתי מוצג	בזמן שהאפליקציה פתוחה	בכל זמן
תוכן עשיר	כן	מוגבל
אינטראקטיביות	גבוהה	מוגבלת
תפוצה	משתמשים פעילים בלבד	כל המשתמשים שה־SDK מותקן אצלם
מתאים ל	מעורבות תלוית הקשר	חידוש מעורבות

השתמשו בשניהם יחד: Push כדי לעודד פתיחה של האפליקציה, ו-In-App כדי להעמיק את המעורבות של משתמשים פעילים.

צעדים הבאים

• יצירת קמפיינים - מדריך לאשף המשותף
• התראות Push
• בדיקות A/B
• תבניות Liquid