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

הציגו הודעות ממוקדות למשתמשים בזמן שהם משתמשים באפליקציה שלכם. הודעות 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. מכיוון שהודעת HTML מריצה JavaScript שנכתב על ידי המחבר בתוך האפליקציה, ה־SDK לא יציג אותה אלא אם המפתחים הפעילו זאת במפורש (allowHtmlJsInAppMessages).

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

הודעות 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), ולכן אין לה גישה ישירה לעמוד שלכם או שלנו. במקום זאת Joryio מספקת לה גשר קטן.

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

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 - להודעות עם סקריפט משלהן

הודעה שכוללת <script> משלה יכולה לקרוא לגשר ישירות, וזו הדרך היחידה להעביר ארגומנטים:

<button id="save">שמור מידה</button>
<script>
  document.getElementById('save').addEventListener('click', function () {
    joryioBridge.setCustomUserAttribute('preferred_size', 'M');
    joryioBridge.logCustomEvent('size_selected', { size: 'M' });
    joryioBridge.closeMessage();
  });
</script>

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

שימו לב להבדל: addEventListener בתוך <script> משלכם תקין לחלוטין - רק המאפיין onclick מוסר.

אלה קיימים בווב בלבד. ב-iOS וב-Android הודעת HTML רצה ב-web view של האפליקציה והודעות native משתמשות בכפתורים של האפליקציה, ולכן שם יש לחבר CTA דרך הגדרות הכפתורים של הקמפיין ולא דרך ה-markup.

שלב 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 - כך שהאפשרויות הנפוצות מופיעות מעל תיבת החיפוש.

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.

התאמה אישית עם 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.

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%

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

התחילו עם Differential Sync

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

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

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

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

• מעורבות גבוהה - 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