דלג לתוכן הראשי

ניהול הרשמות

מסמך זה מתאר את המערכת המקיפה של Joryio לניהול הרשמות והסכמות. המערכת מטפלת בהרשמות לפי ערוץ, בהרשמות לפי רשימה או נושא, בכותרות List-Unsubscribe לפי RFC 8058, בהחזרות וביכולות תאימות.

תוכן העניינים​

  1. סקירה כללית
  2. מודלי נתונים
  3. הרשמות לערוץ
  4. אינטגרציה עם Web SDK
  5. רשימות הרשמה
  6. אישור הרשמה כפול (Double opt-in)
  7. קבוצות הרשמה לפי מספר (SMS ו־WhatsApp)
  8. כותרת List-Unsubscribe (RFC 8058)
  9. דף ההעדפות המתארח וביטול הרשמה
  10. דף העדפות (עיצוב מותאם אישית)
  11. טיפול בהחזרות
  12. משתני תבניות Liquid
  13. מסנני סגמנטים
  14. הפניית API
  15. תצורה
  16. תאימות

סקירה כללית​

מערכת ניהול ההרשמות של Joryio מספקת:

  • הרשמות לפי ערוץ: מעקב אחר מצב Opt-In/Opt-Out באימייל, ב־SMS, ב־WhatsApp, בהודעות Push וב־Viber
  • הרשמות לפי רשימה: מאפשרות למשתמשים להירשם לנושאים או לרשימות דיוור מסוימים
  • תאימות ל־RFC 8058: כותרות לביטול הרשמה בלחיצה אחת, לשיפור יכולת מסירת האימייל
  • טיפול בהחזרות: טיפול אוטומטי בהחזרות רכות וקשות
  • יומן ביקורת: היסטוריה מלאה של שינויי הרשמה לצורכי תאימות
  • מסנני סגמנטים: התמקדות במשתמשים לפי מצב ההרשמה

מודלי נתונים​

הרשמה לערוץ (לכל משתמש)​

לכל משתמש יש סטטוס הרשמה לכל ערוץ תקשורת:

interface ChannelSubscription {
status: 'optedIn' | 'subscribed' | 'unsubscribed';
optInDate?: Date;
optOutDate?: Date;
optInSource?: string; // 'api', 'web_form', 'import', 'manual'
consentText?: string; // Consent text shown at opt-in
}

interface EmailSubscription extends ChannelSubscription {
bounceType?: 'soft' | 'hard' | null;
bounceCount?: number;
lastBounceAt?: Date;
isValid?: boolean; // false if hard bounced
}

interface UserSubscriptions {
email?: EmailSubscription;
sms?: ChannelSubscription;
whatsapp?: ChannelSubscription;
push?: ChannelSubscription;
viber?: ChannelSubscription;
}

רשימת הרשמה​

רשימות הן נושאים או קטגוריות שמאפשרים למשתמשים להירשם אליהן:

interface SubscriptionList {
id: string;
organizationId: string;
workspaceId: string;
name: string;
description?: string;
channels: ('email' | 'sms' | 'whatsapp' | 'push' | 'viber')[];
isPublic: boolean; // Show in preference center
type: 'marketing' | 'transactional';
requireDoubleOptIn: boolean;
archivedAt?: Date;
createdAt: Date;
updatedAt: Date;
}

חברות ברשימה​

המודל עוקב אחר הרשימות שאליהן כל משתמש רשום:

interface ListSubscription {
contactId: string;
listId: string;
channel: 'email' | 'sms' | 'whatsapp' | 'push' | 'viber';
status: 'optedIn' | 'subscribed' | 'unsubscribed';
subscribedAt?: Date;
unsubscribedAt?: Date;
optInSource?: string;
}

הרשמות לערוץ​

סוגי סטטוסים​

סטטוסתיאור
optedInהמשתמש השלים אישור double opt-in
subscribedהמשתמש מנוי (single opt-in)
unsubscribedהמשתמש ביטל הרשמה
pendingממתין לאישור: ביקש להצטרף ועדיין לא אישר את ה-double opt-in. לא ניתן לשלוח אליו עד שיאשר; האישור הופך אותו ל-subscribed. נקבע על ידי תהליך אישור (למשל double opt-in של Delivyr), אף פעם לא על ידי ה-SDK.

עדכון סטטוס ערוץ​

// Via API
await subscriptionsApi.updateChannelSubscription(userId, 'email', {
status: 'unsubscribed',
source: 'preference_center',
reason: 'User requested via preference center'
});

אירוע ההרשמה​

בכל פעם שאדם נרשם, Joryio רושמת את אירוע הפלטפורמה message.subscribed - המקבילה של message.unsubscribed. אפשר להשתמש בו כטריגר של מסע (למשל סדרת קבלת פנים אחרי הרשמה לניוזלטר) או בסגמנט ("ביצע message.subscribed ב-7 הימים האחרונים").

  • פעם אחת לכל שינוי אמיתי. האירוע נרשם כשערוץ או רשימה עוברים מללא סטטוס, unsubscribed או pending ל-subscribed / optedIn. שמירה חוזרת של אותה הסכמה, או איש קשר שכבר רשום, לא רושמים דבר. באישור כפול (double opt-in) הוא נרשם כשהאדם מאשר, לא כשהוא מתבקש לאשר.
  • מאפיינים: channel, scope (channel / list), listId, source, platform, optInSource, status, previousStatus, resubscribe. listId מופיע ברשימה; platform מציין את החנות בהרשמה מחנות; resubscribe הוא true אחרי ביטול הרשמה קודם.
  • source - איך זה קרה: store_newsletter, store_checkout, store_registration, store_customer_record, landing_page_form, in_app_form, website_form, api, dashboard, sdk, preference_center, double_opt_in, keyword, push_permission, journey. keyword היא תשובת START, push_permission הוא טוקן הפוש הראשון, journey הוא צעד עדכון משתמש במסע, double_opt_in הוא אישור של הרשמה ממתינה.
  • לא נרשם עבור היסטוריה. ייבוא אנשי קשר, סנכרון ממחסן נתונים, הוספה גורפת לרשימה, וסנכרון ראשוני או התאמה מתוזמנת של חנות כותבים את סטטוס ההרשמה אבל לא אירוע: האנשים האלה כבר היו רשומים, הם לא נרשמו עכשיו, וייבוא גדול לא אמור להפעיל אלפי מסעות קבלת פנים. אותות חיים מחנות - הרשמה לניוזלטר, תיבה בקופה, עדכון לקוח - כן נרשמים.
  • כללי ההסכמה לא משתנים. הרשמה מחדש חלה רק על איש הקשר הזה, ותלונת ספאם או החזרה קשה יכולים להיות מוסרים רק על ידי צוות Joryio - הרשמה מחדש שנדחתה לא רושמת דבר. כמו כל אירוע, הוא שייך לסביבת עבודה אחת.

אירוע ביטול ההרשמה. message.unsubscribed מתעד כל ביטול הרשמה: קישור או כותרת לביטול הרשמה, עמוד ההעדפות, תשובת STOP ו - מאז 2026-11-02 - חבר צוות בלוח הבקרה (unsubscribeSource admin), ה-API (api), ה-SDK (sdk) וביטול שמגיע מחנות (store_sync). הוא תיעוד של הביטול לסגמנטים, לתנאים ול-Data Streaming; מסע לא מתחיל בו.

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

  • תעדו תמיד את המקור של שינויי ההרשמה
  • שמרו את טקסט ההסכמה כאשר משתמשים מבצעים opt-in
  • לצורך תאימות ל־GDPR, השתמשו ב־double opt-in עבור משתמשים באירופה

אינטגרציה עם Web SDK​

ה־Web SDK של Joryio מאפשר לכם לנהל העדפות הרשמה ישירות מהאתר או מאפליקציית האינטרנט שלכם.

התקנה​

<!-- Via script tag (served from the Joryio API) -->
<script src="https://sdk.joryio.com/web/1/joryio.min.js"></script>

<!-- Or via npm -->
npm install @joryio/web-sdk

סוגי סטטוס הרשמה​

ה-SDK מספק שלושה ערכי סטטוס:

סטטוסתיאור
SubscriptionStatus.OPTED_INהמשתמש ביצע opt-in מפורש (למשל, אישר double opt-in)
SubscriptionStatus.SUBSCRIBEDהמשתמש מנוי אך לא ביצע opt-in מפורש
SubscriptionStatus.UNSUBSCRIBEDהמשתמש ביטל הרשמה

הגדרת הרשמות לערוצים​

import { JoryioSDK, SubscriptionStatus } from '@joryio/web-sdk';

// Initialize SDK
const sdk = new JoryioSDK({ sdkKey: 'jry_sdk_web_...' });

// Set subscription for a single channel (write-only for security - no getters)
sdk.user.setSubscription('email', SubscriptionStatus.OPTED_IN);
sdk.user.setSubscription('sms', SubscriptionStatus.SUBSCRIBED);
sdk.user.setSubscription('push', SubscriptionStatus.UNSUBSCRIBED);
sdk.user.setSubscription('whatsapp', SubscriptionStatus.SUBSCRIBED);

// Set multiple channels at once
sdk.user.setSubscriptions({
email: SubscriptionStatus.OPTED_IN,
sms: SubscriptionStatus.UNSUBSCRIBED,
whatsapp: SubscriptionStatus.SUBSCRIBED,
push: SubscriptionStatus.OPTED_IN
});

ניהול קבוצות הרשמה (רשימות)​

// Add user to a subscription group/list
sdk.user.addToSubscriptionGroup('newsletter-list-id', 'email');
sdk.user.addToSubscriptionGroup('product-updates-id', 'push');

// Remove user from a subscription group/list
sdk.user.removeFromSubscriptionGroup('newsletter-list-id', 'email');

// The channel parameter is optional, defaults to 'email'
sdk.user.addToSubscriptionGroup('weekly-digest-id');

הערות אבטחה​

אובייקט המשתמש ב־SDK הוא לכתיבה בלבד מטעמי אבטחה:

  • אין שיטת getSubscriptions() - מונע מאתרים או מסקריפטים אחרים לקרוא נתוני הרשמה
  • אין שיטות קריאה - כל הפעולות הן כתיבה חד־כיוונית לצד השרת
  • אימות באמצעות מפתח SDK - כל הבקשות מאומתות באמצעות מפתח ה־SDK
  • ה־SDK תמיד פועל בשם "המשתמש הנוכחי" - setSubscription / addToSubscriptionGroup אינם מקבלים מזהה יעד; הם חלים על מי שה־SDK מזוהה כמותו כרגע (המזהה של מבקר אנונימי, או המשתמש שהעברתם ל־identify()). אין דרך שמבקר אחד ישנה את ההרשמות של אחר דרך ה־SDK.
  • כאשר SDK Authentication מופעל, שינוי הרשמה שמציין משתמש חייב לשאת את ה־token של אותו משתמש. שינוי של מבקר אנונימי עבור עצמו מתקבל - אין לו token להציג - אבל anonymousId שכבר שייך למשתמש מזוהה נדחה, כך שאי אפשר לשנות את ההסכמה של אדם אחד דרך מזהה ישן של אחר. כאשר Strict SDK identity פעיל, גם שינויי הרשמה אנונימיים נדחים - קראו קודם ל־identify(userId). החריג הוא ביטול הרשמה, שמתקבל תמיד (ראו להלן).
  • ביטולי הרשמה נמסרים תמיד. סטטוס ערוץ unsubscribed וביטול הרשמה לקבוצה מתקבלים עבור כל מי שה־SDK פועל בשמו - מבקר אנונימי, אדם שהסיר את עצמו ממעקב או סירב להסכמת מעקב, וגם תחת Strict SDK identity. ה־SDKs שומרים אותם בתור ומנסים שוב גם אחרי optOut(), הסכמה שנדחתה ו־wipeData(); כל השאר (הרשמה, מאפיינים, אירועים) נעצר. הכלל היחיד שעדיין חל: תחת SDK Authentication, anonymousId ששייך למשתמש מזוהה לא יכול לשנות את ההסכמה של אותו משתמש בלי ה־token שלו. פרטים: ביטולים נמסרים תמיד. הן מתקבלות גם כשקליטת האירועים בחשבון מושהית בגלל חיוב.
  • הרשמה ראשונה פתוחה; הרשמה מחדש של מי שביטל - לא. כמו בכל SDK בצד הלקוח, המפתח ציבורי, ולכן בלי SDK Authentication ה-userId הוא רק טענה. הרשמה ראשונה (ערוץ או רשימה שהאדם מעולם לא ביטל) מתקבלת לכל משתמש. הרשמה מחדש של אדם שביטל במפורש - ביטול שלו או ביטול מרשימה, תשובת STOP, או ביטול על האימייל או הטלפון שלו שנעשה על ידי איש קשר אחר - מתקבלת רק למשתמש שאומת ב-SDK Authentication או לפרופיל האנונימי של המבקר עצמו; אחרת הבקשה מקבלת 403 עם code: "verified_identity_required" (רשמו אותו מחדש מהשרת שלכם דרך ה-API). anonymousId ששייך לאדם מזוהה נחשב כמו userId לא מאומת: הרשמה ראשונה של אותו אדם מתקבלת, הרשמה מחדש אחרי ביטול - לא. מומלץ: הפעילו אישור כפול לרשימות שמוזנות מטפסים או מאפליקציות ציבוריים - הרשמה דרך ה-SDK לרשימה כזו שולחת את אימייל האישור במקום לרשום.
  • ההרשמות עוברות עם האדם בהתחברות. כשמבקר אנונימי מזדהה והפרופיל האנונימי שלו ממוזג לפרופיל קיים, גם הרשמות הערוצים וגם החברות ברשימות עוברות אליו. כשהשניים לא מסכימים, ביטול הרשמה בצד כלשהו גובר. מיזוג לעולם לא מוחק סטטוס שכבר קיים בפרופיל שנשאר; סטטוס שהוא מעביר (ביטול הרשמה) נכתב להיסטוריית המינויים של אותו פרופיל עם המקור identity_merge.

תמיכה ב-TypeScript​

import {
JoryioSDK,
SubscriptionStatus,
SubscriptionChannel,
SubscriptionPreferences
} from '@joryio/web-sdk';

const sdk = new JoryioSDK({ sdkKey: 'jry_sdk_web_...' });

// Type-safe subscription updates
const preferences: SubscriptionPreferences = {
email: SubscriptionStatus.OPTED_IN,
sms: SubscriptionStatus.UNSUBSCRIBED,
};

sdk.user.setSubscriptions(preferences);

// Type-safe channel selection
const channel: SubscriptionChannel = 'email';
sdk.user.setSubscription(channel, SubscriptionStatus.OPTED_IN);

דוגמה: דף העדפות​

// On your settings page
function handleSubscriptionToggle(channel, isEnabled) {
sdk.user.setSubscription(
channel,
isEnabled ? SubscriptionStatus.SUBSCRIBED : SubscriptionStatus.UNSUBSCRIBED
);
}

// Usage
handleSubscriptionToggle('email', true); // Subscribe to email
handleSubscriptionToggle('sms', false); // Unsubscribe from SMS

דוגמה: הרשמה לניוזלטר​

function subscribeToNewsletter(email) {
// First identify the user
sdk.identify(email);
sdk.setAttributes({ email: email });

// Then subscribe to the newsletter list
sdk.user.setSubscription('email', SubscriptionStatus.OPTED_IN);
sdk.user.addToSubscriptionGroup('newsletter-list-id', 'email');
}

רשימות הרשמה​

יצירת רשימה​

const list = await listsApi.create({
name: 'Weekly Newsletter',
description: 'Our weekly digest of product updates',
channels: ['email'],
isPublic: true, // Show in preference center
type: 'marketing',
requireDoubleOptIn: false
});

ניהול חברים​

// Subscribe a user to a list
await subscriptionsApi.subscribeToList(userId, listId, 'email', {
source: 'api',
consentText: 'Weekly newsletter signup'
});

// Unsubscribe a user
await subscriptionsApi.unsubscribeFromList(userId, listId, 'email');

// Bulk operations (never re-subscribe contacts who opted out)
await listsApi.bulkAddMembers(listId, contactIds, 'email');
await listsApi.bulkRemoveMembers(listId, contactIds, 'email');

רשימות ציבוריות מול פרטיות​

  • רשימות ציבוריות (isPublic: true): מוצגות במרכז ההעדפות והמשתמשים יכולים לנהל את ההרשמה אליהן בעצמם
  • רשימות פרטיות (isPublic: false): מנוהלות רק בידי מנהלים ואינן מוצגות למשתמשים

אישור הרשמה כפול (Double opt-in)​

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

ברירת המחדל של סביבת העבודה​

הגדרות > הרשמות > Double opt-in מכיל שני פקדים:

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

הדריסה לכל רשימה​

לכל רשימה יש תיבת סימון משלה דרוש double opt-in (הרשמות > רשימות, בחלון היצירה והעריכה; טבלת הרשימות מציגה אותה כ"נדרש" או "אופציונלי"). היא תמיד גוברת על ברירת המחדל של סביבת העבודה - בחירה מפורשת ברשימה לעולם אינה נדרסת על ידי ההגדרה. דרך ה-API השדה הוא requireDoubleOptIn; השמיטו אותו מבקשת היצירה כדי לקבל את ברירת המחדל של סביבת העבודה, או העבירו true / false כדי להחליט עבור אותה רשימה.

איך נראית הרשמה ממתינה​

כאשר שליחת טופס מציינת רשימה שדורשת אישור:

  • פרופיל האדם נוצר או מתעדכן עם ערכי הטופס כרגיל, אבל החברות ברשימה אינה נכתבת - שום דבר לא נשמר עבור הרשימה עד שהוא לוחץ. אין שורת חבר "ממתין" שאפשר למצוא ברשימה.
  • להודעת התודה של הטופס מתווסף "בדקו את תיבת הדואר כדי לאשר את ההרשמה." בשפת הדף.
  • אירוע שליחת הטופס נושא listsSubscribed (רשימות שהצטרפו אליהן מיד) ו-listsPending (רשימות שממתינות לאישור), כך שמסע יכול להבחין בין השניים.
  • אימייל אישור אחד נשלח עבור כל הרשימות הממתינות יחד, כאימייל טרנזקציוני דרך הגדרות האימייל של סביבת העבודה עצמה. אותו אדם שמבקש את אותן רשימות שוב בתוך אותה שעה אינו מקבל אימייל שני.
  • הקישור תקף למשך 7 ימים. לחיצה עליו רושמת את האדם לכל רשימה שהקישור מציין עם המקור double_opt_in ומציגה דף אישור קטן בשפת הטופס. קישור שפג תוקפו או ששונה מציג "קישור האישור הזה כבר אינו תקף. מלאו את הטופס שוב כדי לקבל קישור חדש."

אימייל האישור​

בלי תבנית נבחרת, Joryio שולחת את אימייל האישור המובנה שלה בשפת הדף (אנגלית, עברית, ספרדית, יוונית או ערבית; כל שפה אחרת נופלת לאנגלית): שורת נושא "אישור ההרשמה", שמות הרשימות, כפתור "אישור ההרשמה" ושורה שאומרת לנמען להתעלם מהאימייל אם זה לא היה הוא.

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

משתנהערך
{{ confirm_url }}קישור האישור החתום. חובה - תבנית שאינה מפנה ל-confirm_url אינה בשימוש ובמקומה נשלח האימייל המובנה, כי אימייל אישור בלי הקישור שלו לעולם לא יוכל להיות מאושר.
{{ list_names }}שמות הרשימות הממתינות, מופרדים בפסיקים ("Weekly Newsletter, Product Updates").
{{ lists }}הרשימות הממתינות כאובייקטים עם id ו-name, ללולאה.
{{ brand }}שם סביבת העבודה (או "us" כשאין לה שם).
{{ language }}קוד השפה של דף הטופס, למשל en.

שורת הנושא של התבנית מרונדרת עם אותם משתנים; תבנית בלי נושא משתמשת בנושא המובנה. התבנית מדולגת גם, עם אזהרה ביומנים, כשהיא כבר לא קיימת או נכשלת ברינדור - האדם עדיין מקבל את האימייל המובנה. משתני אדם ({{ user.first_name }} והשאר) זמינים כמו בכל אימייל טרנזקציוני.

<p>You asked to receive updates from {{ brand }}:</p>
<ul>
{% for list in lists %}
<li>{{ list.name }}</li>
{% endfor %}
</ul>
<p><a href="{{ confirm_url }}">Confirm subscription</a></p>
<p>If this was not you, ignore this email and nothing changes.</p>

אישור הרשמה כפול ב־SMS​

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

הפעלה​

הגדרות > הרשמות > אישור הרשמה כפול ב־SMS:

  • לדרוש אישור מנרשמים חדשים ל־SMS - מופעל או כבוי לסביבת העבודה.
  • שם המותג - מחליף את {{brand}} בהודעות. ריק = שם סביבת העבודה.
  • הודעת האישור - ברירת מחדל: {{brand}}: Reply YES to receive texts. Msg & data rates may apply. Reply STOP to opt out. השמירה נדחית אם ההודעה לא מציינת את המותג ({{brand}} או שם המותג), לא מבקשת להשיב YES (או מילת הצטרפות אחרת מרשימת מילות המפתח, למשל START, SI או כן) ולא מסבירה איך להסיר (STOP או מילת הסרה אחרת). עד 320 תווים.
  • מענה לאחר אישור - מופעל כברירת מחדל: {{brand}}: You're subscribed to texts. Msg & data rates may apply. Reply STOP to opt out. גם הוא חייב לציין את המותג ואת דרך ההסרה.
  • תפוגה אחרי - מספר הימים שבקשה נשארת פתוחה, 1-30, ברירת מחדל 7.
  • לשלוח תזכורת אחת - כבוי כברירת מחדל; כשמופעל, נשלחת תזכורת אחת (אותה הודעת אישור) אחרי מספר השעות שקבעתם, לפני שהבקשה פגה.

מה קורה לנרשם חדש ל־SMS​

כשההגדרה מופעלת, הרשמה חדשה ל־SMS מכל מקור שאינו האישור של איש הקשר עצמו - טופס או דף נחיתה, ה־API, ה־SDK, סנכרון חנות, ייבוא אנשי קשר או סנכרון מחסן נתונים - נשמרת כממתין לאישור (pending) במקום רשום, ואיש הקשר מקבל הודעת אישור אחת:

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

אישור, סירוב ותפוגה​

  • YES (או כל מילת הצטרפות מרשימת מילות המפתח המשותפת - START, YES, SI, SÍ, OUI, JA, ΝΑΙ, نعم, כן והתוספות שלכם) מהטלפון של איש הקשר למספר שלכם הופכת אותו לרשום, עם מקור הרשמה double_opt_in. רק אנשי קשר שממתינים לאישור בסביבת העבודה שאליה שייך המספר המקבל מאושרים. אם "מענה לאחר אישור" מופעל, הם מקבלים את המענה פעם אחת. YES ממי שאינו ממתין לאישור פועל לפי כללי START הרגילים.
  • STOP בזמן ההמתנה לאישור הופך אותו ללא רשום; לא נשלח דבר נוסף.
  • ללא תשובה, הבקשה פגה אחרי מספר הימים שנקבע: סטטוס ה־SMS חוזר להיות ריק (לעולם לא "לא רשום" - אף אחד לא ביקש הסרה) וההיסטוריה מציגה "האישור פג". סנכרון חנות או מחסן נתונים לא שואל שוב אחרי תפוגה; הרשמה חדשה דרך טופס, ה־API או ה־SDK כן.

אנשי קשר שביקשו הסרה​

כשאישור הרשמה כפול ב־SMS מופעל, רישום מחדש של איש קשר שביקש הסרה - ב־STOP או בכל הסרה אחרת מ־SMS, דרך ה־API, לוח הבקרה, ה־SDK או ייבוא עם עקיפת ביטולי הרשמה - מטופל כמו הרשמה חדשה: איש הקשר עובר לממתין לאישור ומקבל הודעת אישור אחת, ונרשם רק אחרי שהוא משיב YES. בקשה נוספת בזמן ההמתנה לא שולחת דבר. אם הוא לא משיב, הבקשה פגה והוא חוזר להיות לא רשום; לא נשלח דבר נוסף (אין תזכורת). איש קשר ששלח STOP עדיין מקבל את האזהרה הרגילה (בתגובת ה־API כ־sms_stop_provider_block, בדף איש הקשר ובסיכום הייבוא): ספק ה־SMS עלול לחסום את הודעת האישור עד שהוא ישלח START, ואם הספק דוחה את ההודעה עם קוד ה־STOP שלו (למשל Twilio 21610, Delivyr קוד 1) איש הקשר חוזר להיות לא רשום עם ההערה בהיסטוריה "provider still blocks: re-opted out". ייבוא בלי תיבת העקיפה וסנכרון חנות לעולם לא רושמים מחדש איש קשר שביקש הסרה, ולכן לא נשלחת אליו הודעה.

ייבוא​

דף הייבוא מציין מתי אישור הרשמה כפול ב־SMS מופעל. כל הרשמה חדשה ל־SMS בקובץ הופכת אז ל"ממתין לאישור" ומקבלת הודעת אישור אחת (בתוך כדקה מהייבוא). עם עקיפת ביטולי הרשמה, אנשי קשר בקובץ שביקשו הסרה מ־SMS מטופלים באותו אופן - הודעה אחת, רישום רק אחרי YES, וחזרה ללא רשום אם לא ישיבו (ראו למעלה); בלעדיה הם נשארים מוסרים ולא מקבלים הודעה. סמנו כבר אושר (יש לי הוכחה) רק אם יש בידכם הוכחה שהאנשים בקובץ כבר אישרו את ההרשמה ל־SMS; הם יירשמו אז כרשומים בלי הודעה. שתי התיבות דורשות את הרשאת הציות.

חשבונות Delivyr​

ל־Delivyr יש אישור הרשמה כפול משלה. כשמספר ה־SMS של סביבת העבודה נמצא בחשבון Delivyr, Joryio לא שולחת אישור שני: הרשמות חדשות ל־SMS נרשמות כרגיל, ו־Delivyr מעכבת כל הודעה למספר שלא אושר (סיבת הכישלון "Not confirmed yet") ושואלת את איש הקשר בעצמה עד שישיב YES אצלה. איש קשר ש־Delivyr מדווחת שהוא ממתין לאישור מאושר ב־Joryio כשה־YES שלו מגיע דרך ה־webhook של Delivyr.


קבוצות הרשמה לפי מספר (SMS ו־WhatsApp)​

רשימת הרשמה שמשויכת לשולח מסוים - כלומר, רשימה שנושאת senderId - משמשת כקבוצת הרשמה לפי מספר. ב־SMS הקבוצה היא לפי מספר; ב־WhatsApp הקבוצה היא לפי WABA (חשבון WhatsApp Business). כך איש קשר יכול לבטל את ההרשמה להודעות ממספר או מ־WABA מסוימים ולהישאר רשום לאחרים.

כיצד ביטולי הרשמה מוגבלים ונשמרים​

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

תיחום STOP / START נכנס​

כשנמען משיב במילת מפתח, היא מוחלת על המספר המסוים (SMS) או ה־WABA המסוים (WhatsApp) שאליהם הגיעה ההודעה:

  • STOP (וכל מילת opt-out אחרת מלבד STOPALL) מוגבלת לקבוצה לפי מספר או לפי WABA - היא מבטלת לאיש הקשר את ההרשמה להודעות מאותו מספר או WABA בלבד.
  • STOPALL חלה על הערוץ כולו - היא מבטלת לאיש הקשר את ההרשמה לכל מספר או WABA באותו ערוץ.
  • START רושמת מחדש את איש הקשר לקבוצה של אותו מספר או WABA.
כתובת webhook נכנס קשורה לסביבת עבודה אחת

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

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

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

מילות מפתח​

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

בסיס באנגלית (פועל תמיד ואי אפשר להסירו)

מילים אלה נדרשות לתאימות ל־FCC ול־CTIA ואי אפשר להשבית אותן:

סוגמילות מפתח
Opt-outSTOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT, REVOKE, OPTOUT, OPT OUT, OPT-OUT
Opt-inSTART, YES, UNSTOP, SUBSCRIBE, OPTIN
HelpHELP, INFO
בסיס FCC אפריל 2025

REVOKE ו־OPTOUT הן חלק מבסיס ה־opt-out (כלל ה־FCC לביטול הסכמה ל־SMS מאפריל 2025). הן מכובדות תמיד - אין צורך להוסיף או להפעיל אותן.

ברירות מחדל מקומיות (פעילות כברירת מחדל ונוספות לבסיס)

מילות opt-out,‏ opt-in ועזרה נפוצות בשפות אחרות מזוהות מראש, כך שאיש קשר יכול לבטל הרשמה בשפתו. לדוגמה:

שפהOpt-outOpt-inHelp
עבריתהסר, הסרה, עצור, ביטול, הפסקהתחל, הצטרף, כןעזרה, מידע
ספרדיתPARE, BASTA, CANCELAR, ALTOSI, ALTAAYUDA
צרפתיתARRET, ARRÊT, DESABONNEROUIAIDE
גרמניתSTOPP, ABBESTELLENJAHILFE
פורטוגזיתPARAR, SAIR--

תוספות מותאמות (לכל ארגון)

תחת Settings → SMS / Subscriptions תוכלו להוסיף מילות opt-out,‏ opt-in ועזרה משלכם (וכן מילות opt-out משלכם שחלות על הערוץ כולו). הבסיס וברירות המחדל המקומיות מוצגים לקריאה בלבד לצד הרשימה המותאמת שניתנת לעריכה, כך שאתם מנהלים רק את התוספות שלכם. מילות המפתח ל־SMS מוגדרות ברמת הארגון. הן חלות על כל סביבות העבודה בארגון, ולכן שינוי שלהן דורש את ההרשאה ברמת החברה org_settings:write; חברי סביבת עבודה בלעדיה רואים את הרשימה לקריאה בלבד.

WhatsApp

סוגמילות מפתח
Opt-outSTOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT, OPTOUT, OPT-OUT
Opt-inSTART, UNSTOP, SUBSCRIBE, YES, OPTIN, OPT-IN

רק STOPALL חלה על הערוץ כולו; כל מילת opt-out אחרת שלמעלה מוגבלת לקבוצה לפי מספר או לפי WABA. אותו הדבר חל על כל מילת opt-out מותאמת ל־SMS שתגדירו כחלה על הערוץ כולו - היא מתנהגת כמו STOPALL, ואילו מילות opt-out רגילות נשארות מוגבלות למספר שאליו הגיעה ההודעה.

כיצד ההתאמה סובלנית ל"שינויים זניחים" (de minimis)​

ההתאמה של הודעות נכנסות אינה רגישה לרישיות וסובלת הבדלי פיסוק ורווחים, בהתאם להנחיית CTIA שלפיה יש לכבד גם הבדלים קטנים ("זניחים"). לפני ההתאמה, גם המילה הראשונה וגם גוף ההודעה כולו מנורמלים: סימני פיסוק ורווחים מסביב מוסרים ואותיות ASCII מומרות לאותיות גדולות. לכן Stop, STOP!, " stop " ו־STOP. נחשבות כולן ל־STOP.

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

הרשמה מחדש לאחר ביטול הרשמה​

אופן ההרשמה מחדש תלוי בדרך שבה איש הקשר ביטל את ההרשמה:

  • שלח STOP בהודעה (או מילת opt-out אחרת). איש הקשר יכול לשלוח START (או מילת opt-in אחרת) מאותו טלפון, וזה מסיר את הביטול עבור המספר. אפשר גם לרשום מחדש במפורש את איש הקשר הזה בלבד - דרך ה־API, SDK, דף איש הקשר, דף ההעדפות או הטפסים של האדם עצמו, או ייבוא עם "Override unsubscribes" מסומן; ראו אנשי קשר שחולקים אימייל או טלפון. ב־SMS הספק (למשל Twilio) בדרך כלל משאיר חסימה משלו על המספר, ששום API אינו מסיר: עד שאיש הקשר ישלח START, הספק עלול להמשיך לדחות את ההודעות שלכם.
  • הסכמה מחנות. רק במקרים שבהסכמה שיווקית מחנויות - למשל לקוח מחובר שמסמן את תיבת השיווק ב-checkout אחרי שביטל את ההרשמה דרך קישור.
  • ביטל הרשמה בדף מתארח או במרכז ההעדפות → יכול להירשם מחדש באתר. איש קשר שביטל הרשמה דרך קישור או מרכז העדפות (ולא בהודעת טקסט) יכול להירשם מחדש באותה דרך - למשל באמצעות {{ resubscribe_url }} או הפעלה מחדש של SMS במרכז ההעדפות.

קדימות ורשת ביטחון​

  • ביטול הרשמה גלובלי מהערוץ גובר על קבוצות. ביטול הרשמה גלובלי מהערוץ - למשל כשכל ערוץ ה־SMS או ה־WhatsApp של איש הקשר מוגדר כ־unsubscribed - הוא מתג השבתה קשיח שגובר על הרשמה לקבוצה כלשהי. אם ההרשמה לערוץ בוטלה באופן גלובלי, אף קבוצה לפי מספר אינה יכולה לחדש את השליחות לאותו איש קשר.
  • ברירת מחדל בטוחה לכל הערוץ. אם אי אפשר לזהות את הקבוצה לפי מספר או לפי WABA, המערכת פועלת באופן בטוח ומחילה את ביטול ההרשמה על הערוץ כולו, במקום להסתכן בהמשך שליחת הודעות לאיש קשר שניסה לבטל הרשמה.

אבטחת תעבורה נכנסת​

  • הודעות Webhook נכנסות מאומתות באמצעות חתימה; הודעות STOP או START מזויפות נדחות.
  • ספקים שאינם תומכים באימות חתימה להודעות נכנסות אינם מתקבלים לעיבוד מילות מפתח נכנסות.
מספר אחד שייך למרחב עבודה אחד

מספר שליחה - מספר SMS, מספר WhatsApp או שולח Viber - יכול להיות מחובר למרחב עבודה אחד בלבד בארגון שלכם. ארגונים אחרים לעולם אינם משפיעים על המספרים שלכם: הודעה נכנסת מותאמת רק למספרים של הארגון שחשבון הספק שלו קיבל אותה, ומספרי WhatsApp מאומתים מול Meta בעת החיבור. חיבור מספר שכבר מחובר במקום אחר נדחה; נתקו אותו שם קודם. STOP, START, HELP ותשובות נכנסות מוחלים במרחב העבודה שאליו שייך המספר, והודעה שנמסרה עבור מרחב עבודה אחר נדחית במקום לנחש. שמות שולח אלפאנומריים אינם יכולים לקבל תשובות, ולכן אינם מוגבלים כך.

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

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

שמות שולח אלפאנומריים אינם יכולים לקבל STOP

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

היקף קישור ביטול ההרשמה בצמתי SMS ו־Viber במסע​

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

בצמתי הודעת SMS ו־Viber, הבורר "קישור ביטול ההרשמה מסיר מ:" מציע:

בחירההתנהגות
רשימת השולח הזה (ברירת מחדל)קישור ביטול ההרשמה מבטל את הרשמת איש הקשר מרשימת המספר/השולח השולח בלבד - בהתאמה לאופן שבו STOP שנשלח בהודעה ממוקד.
כל ה־SMS / כל ה־Viber (גלובלי)קישור ביטול ההרשמה מבטל את הרשמת איש הקשר מהערוץ כולו - שקול ל־STOPALL.

ברירת המחדל (רשימת השולח) היא הבחירה הצפויה והממוקדת ביותר, והיא שומרת על עקביות בין קישור ביטול ההרשמה לבין היקף STOP הנכנס. הרחיבו אותו לגלובלי רק כאשר צומת אכן מייצג ביטול הרשמה בכל הערוץ. זה משקף את מודל הגלובלי־מול־רשימה של ביטול ההרשמה באימייל (List-Unsubscribe) - אותו מודל, מיושם לכל צומת עבור SMS ו־Viber.


ביטולי הרשמה באימייל חלים לפי הכתובת (אנשי קשר כפולים)​

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

מה זה אומר​

  • ביטול הרשמה מכסה כל כפילות. כשאדם מבטל הרשמה - באמצעות קישור ביטול ההרשמה, כותרת List-Unsubscribe בלחיצה אחת, דף העדפות או תלונת ספאם - כל אנשי הקשר באותה סביבת עבודה ובעלי אותה כתובת אימייל נחסמים, לא רק איש הקשר שאליו נשלחה ההודעה.
  • גלובלי מול רשימה. ביטול הרשמה גלובלי משתיק את הכתובת בכל הערוץ (כל קמפיין ומסע). ביטול הרשמה מרשימה/נושא משתיק את הכתובת עבור אותה רשימה בלבד - האדם נשאר בר-השגה ברשימות אחרות.
  • גם החזרות קשות חלות לפי הכתובת. החזרה קשה חוסמת את הכתובת בכל סביבת העבודה, כך שאיש קשר כפול לא ימשיך לשלוח לתיבת דואר שאינה פעילה. היא אינה מוסרת על ידי הרשמה מחדש, ה־API או ייבוא - רק על ידי התמיכה של Joryio (או החלפה אמיתית של כתובת האימייל). ראו אנשי קשר שחולקים אימייל או טלפון.
  • מוגבל לסביבת העבודה. החסימה משויכת לסביבת העבודה ששלחה לכתובת. ביטול הרשמה בסביבת עבודה אחת אינו חוסם את הכתובת בסביבת עבודה אחרת באותו חשבון.
  • עקיפה טרנזקציונית. שליחה המוגדרת להגיע לכל אנשי הקשר (העדפת all / טרנזקציונית) עדיין עוקפת ביטולי הרשמה מסוג הסכמה, אך כתובת שהוחזרה בהחזרה קשה לעולם לא תקבל דיוור - אין טעם לשלוח לתיבת דואר מתה.
  • תלונות ספאם עוצרות גם דיוור טרנזקציוני. כשמישהו מסמן את האימייל שלכם כספאם, הכתובת מפסיקה לקבל אימייל שיווקי וגם טרנזקציוני (קבלות, איפוס סיסמה) במרחב העבודה הזה - אלא אם התמיכה של Joryio הפעילה שליחה טרנזקציונית עבור הארגון שלכם, ואז תלונות עוצרות רק דיוור שיווקי. אם תרצו בכך, שלחו דיוור טרנזקציוני מתת-דומיין שליחה נפרד ופנו לתמיכה. ביטול הרשמה לעולם לא עוצר דיוור טרנזקציוני; החזרה קשה תמיד עוצרת.

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


אנשי קשר שחולקים אימייל או טלפון​

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

  • ביטול הרשמה מגיע לכל איש קשר עם אותו אימייל או טלפון. מכל מקור - קישור ביטול הרשמה, כותרת הלחיצה האחת, דף ההעדפות, שינוי בדף איש הקשר, ה־API, SDK, ייבוא, תשובת STOP או תלונת ספאם - כל איש קשר בסביבת העבודה עם אותו אימייל (לאימייל) או טלפון (ל־SMS, WhatsApp ו־Viber) מבוטל גם הוא. סטטוס ההרשמה שלו (או, בביטול מרשימה, החברות שלו ברשימה) מתעדכן, ונרשמת אצלו רשומת היסטוריה: בוטל דרך איש קשר אחר עם אותו אימייל (או טלפון).
  • החסימה נשארת גם לאנשי קשר שנוצרים אחר כך. הביטול נשמר על הכתובת או המספר, כך שאיש קשר שנוצר מאוחר יותר עם אותו אימייל או טלפון חסום גם הוא.
  • הרשמה מחדש חלה רק על איש הקשר שבו היא נעשתה. אם אחד האנשים נרשם מחדש, רק איש הקשר הזה זמין שוב; האחרים נשארים מבוטלים, כי ייתכן שמדובר באנשים שונים. איש הקשר שומר על ההרשמה מחדש שלו עד שאיש קשר כלשהו על הכתובת או המספר מבטל שוב - ואז כולם חסומים שוב.
  • שמירת דף ההעדפות ללא שינוי אינה משנה דבר. רק מתג שהאדם שינה בפועל מוחל, ורק על איש הקשר הזה.
  • אפשר לעקוף תשובת STOP עבור איש קשר אחד. ביטול ב־SMS, WhatsApp או Viber שהגיע ממילת STOP (מכל ספק, כולל Delivyr) ניתן לרישום מחדש דרך ה־API (עדכון הרשמה רגיל - ללא דגל נוסף), SDK, דף איש הקשר, דף ההעדפות או הטפסים של האדם עצמו, וייבוא רק עם "Override unsubscribes" מסומן. זה חל על איש הקשר הזה בלבד - אנשי הקשר האחרים על המספר נשארים חסומים - ותשובת START עדיין מסירה את הביטול עבור המספר כמו קודם. היסטוריית איש הקשר מתעדת שהשינוי עקף STOP ומי ביצע אותו (מפתח ה־API, משימת הייבוא, חבר הצוות או דף ההעדפות).
  • SMS בלבד: הספק עשוי עדיין לחסום. רישום מחדש של איש קשר SMS ששלח STOP מציג אזהרה בכל מקום שבו זה קורה (בדף איש הקשר לפני השמירה, בדף הייבוא ובסיכום שלו, ובתשובת ה־API): This contact opted out by texting STOP. Your SMS provider may keep blocking messages until they text START. ל־WhatsApp ול־Viber אין אזהרה כזו.
  • כשספק ה־SMS עדיין חוסם. שליחה שספק ה־SMS דוחה בגלל חסימת STOP משלו (למשל שגיאת Twilio 21610 או דחיית opted-out של Delivyr) מוצגת כחסום על ידי הספק (ביטל הרשמה), לא ככישלון, ואינה נספרת בהתראות שיעור החזרות או כישלונות. הביטול מוחל שוב, והיסטוריית איש הקשר אומרת provider still blocks: re-opted out.
  • החזרות קשות ותלונות ספאם מוסרות רק על ידי התמיכה של Joryio. הרשמה מחדש, ה־API או ייבוא לעולם אינם מנקים אותן. פנו לתמיכה כשמאושר שהכתובת פועלת שוב.
  • סביבת עבודה אחת בכל פעם. כל זה קורה בתוך סביבת העבודה שבה נעשה הביטול; סביבות עבודה ומותגים אחרים שלכם אינם מושפעים לעולם.
  • מסעות פועלים לפי אותם כללים כמו קמפיינים. ביטול הרשמה לרשימת אימייל עוקב אחרי הכתובת גם במסעות: שלב אימייל במסע שמשתמש ברשימת הרשמה מדלג על כל איש קשר שכתובתו עזבה את הרשימה.

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

הזמנה או checkout בחנות לעולם לא מחליפים את הטלפון הקיים של איש קשר (הם רק ממלאים טלפון חסר) - רק נתוני חשבון הלקוח בחנות מחליפים אותו, וב-Magento גם הזמנה של לקוח מחובר. הסכמה ל-SMS שניתנה עם מספר אחר לא רושמת את המספר של איש הקשר. ראו איך נתוני החנות מעדכנים איש קשר ב-Shopify, ב-WooCommerce וב-Magento.

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

מה החנות שולחתמה Joryio עושה
סימון הסכמה ב-checkout של אורחרושם איש קשר שעדיין אין לו מינוי בערוץ הזה. אלא אם ההגדרה של החנות שלמטה מופעלת, לעולם לא רושם מחדש מי שביטל את המינוי - ב-checkout כאורח כל אחד יכול להקליד כל כתובת אימייל.
הסכמה של לקוח מחובר (WooCommerce: הזמנה שבוצעה כשהלקוח מחובר, תוסף 1.6.1 ואילך; Magento: הזמנה של לקוח מחובר), עם תאריך מאוחר מהביטול האחרון של איש הקשררושם מחדש גם איש קשר שביטל את המינוי דרך קישור הסרה או כפתור ההסרה בלחיצה אחת, דף ההעדפות, ה-API, חבר צוות, או ביטול שנעשה באותה חנות.
כל הסכמה מ-Shopify (ההגדרה כבויה)נחשבת כסימון של אורח. Shopify משייכת checkout של אורח ללקוח הקיים עם אותו אימייל ולא מודיעה אם הקונה היה מחובר, ולכן הסכמה מ-Shopify לעולם לא רושמת מחדש מי שביטל את המינוי.
הסכמה ב-checkout או ברשומת הלקוח, כשההגדרה של החנות לאפשר לסימון הסכמה בקופה לרשום מחדש אנשים שהסירו את עצמם מופעלת (כבויה כברירת מחדל; Shopify, WooCommerce, Magento ו-PrestaShop)רושם מחדש איש קשר שביטל את המינוי - גם אחרי checkout כאורח - כשהזמן שהחנות רשמה להסכמה מאוחר מהביטול האחרון שלו. הסיכון: checkout כאורח לא יכול להוכיח מי הקונה, כך שמי שמקליד את האימייל של אדם אחר יכול לרשום אותו מחדש; תמיד אפשר לבטל שוב בלחיצה אחת.
תיבה לא מסומנתאין שינוי - זה אף פעם לא ביטול מינוי.
ביטול בחנותמבטל את המינוי, אלא אם Joryio תיעדה שינוי מאוחר יותר לאיש הקשר הזה.
לעולם לא מתבטל בהסכמה מחנות, כשההגדרה מופעלת או כבויהתלונת ספאם, החזרה קשה (hard bounce), חסימה ברמת הארגון, סביבת עבודה אחרת, ביטול שנרשם באיש קשר אחר עם אותו אימייל או טלפון, ו-STOP ב-SMS.
  • ההגדרה היא לכל חיבור חנות, ב-הגדרות → אינטגרציות → <חנות>, כבויה כברירת מחדל; רק מנהלים יכולים לשנות אותה, וכל שינוי נרשם ביומן הביקורת. כשאישור כפול של רשימת אימייל או אישור כפול ב-SMS מופעל, נשלח קודם האישור ואיש הקשר נשאר בהמתנה עד שיאשר.
  • רישום מחדש חל רק על איש הקשר הזה; אנשי קשר אחרים עם אותו אימייל או טלפון נשארים ללא מינוי. היסטוריית איש הקשר מציינת מדוע, למשל נרשם מחדש ב-checkout של החנות (לקוח מחובר) אחרי שביטל דרך דף ההעדפות.
  • SMS: כשאישור כפול (double opt-in) ל-SMS פעיל, רישום מחדש שולח הודעה אחת "השיבו YES" ואיש הקשר נשאר בהמתנה עד שישיב. איש קשר ששלח STOP חוזר רק בדרך הזו - כשאישור כפול ל-SMS כבוי, הסכמה מחנות לעולם לא רושמת אותו מחדש.
  • הסכמה מחנות רושמת לערוץ, לא לרשימה: רשימה שדורשת אישור כפול עדיין שולחת את אימייל האישור כשהאדם מצטרף אליה.

ההסכמה ב-PrestaShop היא המינוי של הלקוח לניוזלטר, לאימייל בלבד. ראו גם PrestaShop: הסכמה לשיווק.

  • רשומת הלקוח. הדגל newsletter רושם את איש הקשר לאימייל, עם התאריך newsletter_date_add של PrestaShop. ביטול המינוי בחנות (בדף החשבון או בממשק הניהול) הוא ביטול מפורש בחנות ומבטל את המינוי, אלא אם Joryio תיעדה שינוי מאוחר יותר לאיש הקשר הזה. שינוי שנשמר על הלקוח מחזית החנות על ידי מי שאינו מחובר כאותו לקוח יכול לבטל מינוי, אבל לעולם לא רושם.
  • בלוק הניוזלטר (ps_emailsubscription) הוא טופס אנונימי: כל אחד יכול להקליד כל כתובת אימייל. הרשמה דרך הבלוק נחשבת להסכמה רק עבור בעל החשבון הרשום, כשהוא מחובר, עם אותו אימייל, או אחרי אישור האימייל של PrestaShop כשאימיילי האימות מופעלים בחנות; כל הרשמה אחרת דרך הבלוק לא מוחלת. ביטול מינוי דרך הבלוק מוחל לפי כתובת האימייל.
  • הסנכרון הראשוני מייבא מנויים כהסכמות בלבד: הוא לעולם לא מבטל מינוי של אף אחד ולעולם לא רושם מחדש איש קשר שביטל את המינוי.
  • אחרי ביטול מינוי, הסכמה לניוזלטר מ-PrestaShop לא רושמת מחדש את איש הקשר - כלל הלקוח המחובר שלמעלה לא חל על PrestaShop. החריג היחיד: תיבת הניוזלטר שסומנה כש-checkout כאורח יוצר את חשבון האורח של הקונה, כשההגדרה לאפשר לסימון הסכמה בקופה לרשום מחדש אנשים שהסירו את עצמם מופעלת.
  • הצעות שותפים (optin) אינן הסכמה שיווקית ולא נלקחות בחשבון.

פרטים לכל חנות: Shopify, WooCommerce, Magento, PrestaShop.


ביטול הרשמה הוא לפי ערוץ​

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

  • קישור ביטול ההרשמה באימייל וכותרת הלחיצה האחת. האדם מפסיק לקבל אימייל (וכשלקמפיין יש נושא הרשמה, הוא גם יוצא מהנושא הזה באימייל). ההרשמות שלו ל-SMS, WhatsApp, פוש ו-Viber לא משתנות. הדף אומר לו: "ההרשמה שלך לאימיילים בוטלה. עדיין תקבל/י הודעות SMS/WhatsApp שנרשמת אליהן."
  • ביטול הרשמה מכל הערוצים. אחרי זה הדף מציע כפתור מפורש ביטול הרשמה מכל הערוצים. רק הכפתור הזה מבטל את כל הערוצים והנושאים; הפעולה נרשמת כביטול הרשמה עם scope global, ומשויכת לאותו קמפיין ווריאנט.
  • SMS, WhatsApp ו-Viber. STOP וקישור ביטול ההרשמה משפיעים רק על הערוץ הזה (או רק על רשימת השולח); STOPALL מתרחב לכל המספרים בערוץ הזה, אף פעם לא לערוצים אחרים.
  • קישורים שנשלחו לפני 2026-10-04. קישורי ביטול הרשמה שכבר נמצאים בתיבות הדואר ממשיכים לעשות את מה שעשו כשנשלחו: קישור באימייל ישן עדיין מבטל הרשמה מהכול.
  • דף ההעדפות. נשאר לפי ערוץ ולפי נושא.

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


כותרת List-Unsubscribe (RFC 8058)​

סקירה​

RFC 8058 מגדיר דרך תקנית שבה לקוחות אימייל יכולים לספק ביטול הרשמה בלחיצה אחת. Joryio מוסיפה את הכותרות האלה אוטומטית לאימיילים יוצאים.

מופעל כברירת מחדל. הכותרת מופעלת בכל סביבת עבודה, גם בסביבת עבודה שמעולם לא שמרה את הגדרות המינויים - כל אימייל שיווקי (קמפיינים ומסעות) נושא אותה. היא מוסרת רק כשמכבים את מתג List-Unsubscribe בהגדרות המינויים, או כשקמפיין טרנזקציוני מגדיר לעצמו את העקיפה ללא ביטול הרשמה - טרנזקציוני בלבד. Gmail ו-Yahoo מחייבים ביטול הרשמה בלחיצה אחת משולחים בכמויות גדולות, לכן השאירו אותה מופעלת באימייל שיווקי.

כותרות שנוספות​

List-Unsubscribe: <https://api-eu1.joryio.com/api/u/{token}>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

תצורה​

נשמר בהגדרות סביבת העבודה (אובייקט listUnsubscribe חסר, או כזה בלי enabled, פירושו מופעל; רק enabled: false מכבה):

subscriptionSettings: {
listUnsubscribe: {
enabled: true,
includeMailto: true, // Include mailto: link (recommended for Gmail)
scope: 'global' // 'global' or 'list'
}
}

אפשרויות טווח​

טווחהתנהגות
globalביטול הרשמה בלחיצה אחת מסיר את המשתמש מכל תקשורת האימייל
listמבטל הרשמה רק מהרשימה הספציפית שממנה נשלח האימייל

פקד ברמת הקמפיין​

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

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

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

ל-SMS / WhatsApp אין כותרת RFC 8058, ולכן שלב ה-Compose שלהם מציג במקום זאת פקד נושא ביטול הרשמה (גלובלי לעומת נושא מסוים) עם אותה משמעות של היקף; אין אפשרות "ללא ביטול הרשמה" מכיוון שביטול הרשמה באמצעות STOP תמיד מכובד.

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

campaign.channelConfig = {
// omit listUnsubscribe entirely to inherit the workspace policy (= Global)
listUnsubscribe: {
enabled: false, // "No unsubscribe": suppress the header for this campaign
},
};
// Topic scope is stored separately as the campaign's subscriptionCategoryId.

תאימות: בחרו "ללא ביטול הרשמה" רק עבור הודעות טרנזקציוניות או הודעות על מערכת יחסים קיימת. אימיילים בתפוצה רחבה ואימיילים שיווקיים חייבים לכלול כותרת List-Unsubscribe (בהתאם לכללי השולחים בתפוצה רחבה של Gmail ו־Yahoo).


דף ההעדפות המתארח וביטול הרשמה​

כל הודעה כוללת קישור לדף המתארח: קישור ביטול ההרשמה (/u/:token) וקישור ניהול ההעדפות (/preferences/:token). הסעיף הזה מסביר מה הנמען רואה שם.

אילו ערוצים מוצגים​

הדף מציג רק ערוצים שרלוונטיים לאדם הזה:

  • הערוץ מוגדר בסביבת העבודה שלכם (מוגדרים לו ספק או שולח), וגם
  • אפשר להגיע לאדם בערוץ: כתובת אימייל עבור Email; מספר טלפון עבור SMS, WhatsApp ו-Viber; לפחות מכשיר פוש פעיל אחד או הרשמה ל-Web Push עבור Push.

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

קישור ההסרה: לחיצה אחת בדף, וביטול הפעולה​

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

  1. הוא אומר מה יפסיק להגיע וממי - למשל "לא יישלחו אליך יותר אימיילים מ-Acme." - ואת הכתובת שאליה נשלחה ההודעה.
  2. האדם לוחץ על הסרה. רק לחיצה אמיתית או הקשה במקלדת על הכפתור הזה שולחת את ההסרה: הדף אף פעם לא מסיר מעצמו, לא משנה כמה זמן הוא פתוח. אפשר לבחור סיבה אופציונלית ממש מעל הכפתור.
  3. לשנות העדפות במקום זאת פותח את הפקדים המלאים של הערוצים והרשימות במקום להסיר.

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

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

אחרי ההסרה, ראש הדף אומר הוסרת מהרשימה ומה הוסר, ומציע:

  • ביטול הפעולה (Undo) - מוצג במשך 10 דקות. הוא רושם מחדש בדיוק את מה שהוסר, דרך אותו מסלול מתועד של שמירת העדפות (נרשם כ-undo_unsubscribe), ומחזיר את הקישור לפעולה.
  • ניהול העדפות - חושף מתחת את המתגים לערוצים ולרשימות.

התוצאה של כל פעולה (הסרה, הסרה מהכול, שמירה, הרשמה מחדש) מוצגת בראש הדף, והדף גולל אליה. זה עובד גם בדף בעיצוב מותאם אישית (השאלה והפקדים מוצבים במקום של {{ preferences_form }}) וגם במצב הפניה (האדם לוחץ קודם על הסרה, וההסרה נרשמת לפני שהוא מועבר לכתובת שלכם).

בין 2026-10-11 ל-2026-10-15 הדף הסיר מעצמו אחרי שהיה גלוי כשנייה. זה כבר לא קורה - ראו את הסעיף הבא.

למה הדף מבקש לחיצה​

למה זה חשוב. חברות רבות מפעילות מערכות אבטחת דואר ארגוניות שפותחות כל קישור בהודעה (סריקת קישורים, "safe links") עוד לפני שהאדם קרא אותה. חלק מהסורקים פותחים קישורים בדפדפן אמיתי, שבעיני השרת נראה בדיוק כמו אדם. לכן דף שהסיר מעצמו ברגע שנפתח הסיר אנשים שמעולם לא ביקשו לעזוב - במקרה אחד 48 שניות אחרי השליחה, מיד אחרי שהסורק לחץ על כל הקישורים במייל.

מה Joryio עושה.

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

כפתור ההסרה של אפליקציית המייל נשאר בלחיצה אחת. Gmail, Yahoo ו-Apple Mail מציגים כפתור Unsubscribe משלהם לפי תקן הלחיצה האחת (RFC 8058, הכותרת List-Unsubscribe-Post). הוא נדרש משולחים בכמויות גדולות, נשלח על ידי ספק תיבת הדואר רק כשהאדם לוחץ על הכפתור, ואינו מופעל על ידי סורקי קישורים. הוא פועל בדיוק כמו קודם (ראו כותרת List-Unsubscribe). הוא משתמש בכתובת אחרת מזו של כפתור הדף, ולכן השניים נרשמים בנפרד.

היכן מוצגות סיבות ביטול ההרשמה​

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

  • פרופיל איש הקשר - הכרטיס היסטוריית הרשמות מציג את הסיבה בכל ביטול הרשמה ותג ייתכן שאוטומטי ברשומות המסומנות.
  • אנליטיקת קמפיין - כרטיס ביטולי הרשמה לפי סיבה ליד מספר ביטולי ההרשמה: שורה לכל אדם לפי הסיבה האחרונה שלו, הסיבות המובילות ועוד "אחרות", ו"לא ניתנה סיבה". ביטולי הרשמה שנרשמו לפני אוקטובר 2026 אינם כוללים סיבה באנליטיקה ונספרים כ"לא ניתנה סיבה".
  • Settings > Subscriptions > Unsubscribe reasons - רשימת סביבת העבודה של ביטולי הרשמה אחרונים עם סיבה או סימון: מתי, איש הקשר (מידע אישי מוסתר לחברים ללא ההרשאה pii:view), ערוץ או רשימה, סיבה וקמפיין, עם מסנן רק ייתכן שאוטומטי.

איך קרתה כל הסרה. מאז 2026-10-15 כל הסרה רושמת גם איך הגיעה - כפתור ההסרה של אפליקציית המייל, כפתור הסרה בדף, מרכז ההעדפות, הסרה מהכול, ה-API, חבר צוות בלוח הבקרה, ה-SDK, ייבוא, תגובת STOP, תלונת ספאם, הסרה דרך ספק המייל או סנכרון חנות - וגם את הדפדפן (דפדפן ומערכת הפעלה בלבד, אף פעם לא המחרוזת המלאה או כתובת ה-IP) וכמה זמן אחרי השליחה זה קרה. היסטוריית ההרשמות של איש הקשר מציגה זאת בכל הסרה תחת איך. הסרות שהדף ביצע בלי לחיצה בין 2026-10-11 ל-2026-10-15 מוצגות כ"דף ההסרה נפתח, בלי לחיצה".

שאלות נפוצות: ביטולי הרשמה אוטומטיים​

האם סורק קישורים יכול לבטל הרשמה של אנשי הקשר שלי? לא מהדף: פתיחת הקישור לא משנה דבר, והדף מסיר רק כשאדם לוחץ על הסרה בלחיצה אמיתית או בהקשה במקלדת. הסרות שהדף ביצע מעצמו בין 2026-10-11 ל-2026-10-15 מוצגות כ"דף ההסרה נפתח, בלי לחיצה" בהיסטוריית ההרשמות של איש הקשר.

אני רואה גל פתאומי של ביטולי הרשמה. מה לעשות? פתחו את Settings > Subscriptions > Unsubscribe reasons, הפעילו רק ייתכן שאוטומטי, ובדקו את הרשומות המסומנות ואת הקמפיין שלהן. רשמו אדם מחדש רק בהסכמתו (למשל הוא אומר לכם שזו הייתה טעות, או נרשם שוב). לעולם אל תרשמו אנשים מחדש בכמות: ביטול הרשמה הוא משיכת הסכמה עד שהאדם אומר אחרת.

האם זה משנה את כפתור ביטול ההרשמה ב-Gmail, Yahoo או Apple Mail? לא. כפתור הלחיצה האחת הוא מנגנון תקני נפרד, והוא לא השתנה.

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


דף העדפות (עיצוב מותאם אישית)​

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

היכן: Settings → Subscriptions → Preference page.

העמוד הוא לכל סביבת עבודה ויש לו שלושה מצבים:

  • Built-in default - מרכז ההעדפות הרגיל של Joryio (מתגים לערוצים ולרשימות). פועל תמיד ואינו דורש הגדרה.
  • Custom HTML - עורך HTML/Liquid מלא עם תצוגה מקדימה חיה שמוצגת באמצעות נתונים לדוגמה. מתואר בהמשך.
  • Redirect to URL - מדלג לחלוטין על הדף שלנו ושולח את הנמען לדף שלכם. בקישור ביטול ההרשמה אנחנו רושמים תחילה את ביטול ההרשמה, ואז מפנים לכתובת שלכם עם ?email=…&status=unsubscribed מצורף; הקישור לניהול העדפות מפנה עם ?token=…, שבו הדף שלכם יכול להשתמש כדי לקרוא ולכתוב העדפות דרך ה־API הציבורי. התאימות נשמרת בשני המקרים.

איך זה עובד​

  • אתם כותבים את גוף הדף ב־HTML. אפשר להשתמש בו ב־Liquid: התאמה אישית ({{ firstName }}, {{ email }}), רכיבי תוכן ({{ blocks.<slug> }}) ותגיות כתובות ההרשמה שלהלן.
  • הציבו את התגית {{ preferences_form }} במקום שבו צריכים להופיע פקדי ההרשמה הפעילים (מתגים לערוצים ולרשימות, Save, Unsubscribe from all) - Joryio תעבד את הטופס הפעיל במקום הזה.
  • אם תשמיטו את התגית, הפקדים יצורפו אוטומטית בסוף, כך שהנמען תמיד יוכל לבטל הרשמה (העורך מזהיר אתכם כשהתגית חסרה).
  • הדף מעובד בצד השרת עבור כל נמען (כך שכתובות ביטול ההרשמה וההתאמה האישית אמיתיות), ולאחר מכן עובר ניקוי לפני שהוא מגיע לדפדפן: הפריסה, התמונות, הסגנונות המוטבעים ורכיב <style> בעל היקף מוגבל נשמרים; סקריפטים, מטפלי אירועים, מסגרות iframe, רכיבי <form> ו־CSS שמסוגל להריץ סקריפטים מוסרים.

תגיות זמינות​

תגיתתיאור
{{ preferences_form }}פקדי ההרשמה הפעילים (הציבו פעם אחת)
{{ unsubscribe_url }}ביטול הרשמה גלובלי
{{ preferences_url }}קישור חזרה לעמוד זה
{{ resubscribe_url }}קישור להרשמה מחדש
{{ firstName }} / {{ email }}התאמה אישית של הנמען
{{ blocks.<slug> }}רכיב תוכן לשימוש חוזר

הערות​

  • מבנה עמוד מלא (<html>/<head>/<body>) מתקבל; העמוד הוא מסך עצמאי, ולכן תוכן הגוף והסגנונות שלו הם מה שמוצג.
  • אותו דף משמש גם לקישור ביטול ההרשמה בלחיצה אחת (/u/:token) וגם לקישור ניהול ההעדפות (/preferences/:token).
  • דף ברירת המחדל המובנה מציע גם פעולה "Re-subscribe to all"; הכתובת {{ resubscribe_url }} (שמוסיפה ?action=resubscribe) מבצעת הרשמה מחדש עם פתיחתה. "reason for unsubscribing" האופציונלי (נרשם ביומן הביקורת ובאירוע message.unsubscribed) נשאל רק בשאלת ההסרה, אף פעם לא ליד Save או Re-subscribe to all.

טיפול בהחזרות​

סוגי החזרות​

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

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

תצורה​

subscriptionSettings: {
bounceHandling: {
softBounceRetryHours: 24, // Window in which soft bounces are counted
softBounceMaxRetries: 5, // Soft bounces in-window before escalating to a hard bounce
resubscribeOnEmailChange: true // Clear the invalid flag when the email changes
}
}

אינטגרציה עם Webhook​

Joryio מעבדת אוטומטית Webhooks של החזרות מ:

  • Amazon SES: התראות SNS
  • SendGrid: Webhooks של אירועים
  • Mailgun: Webhooks

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

ניקוי החזרות ידני​

מנהלים יכולים לנקות מצב החזרה דרך הממשק או ה־API:

await subscriptionsApi.clearBounceStatus(userId, 'Email confirmed valid by user');
החזרות קשות ותלונות ספאם

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

כתובות ממסר של Sign in with Apple

אם דואר לכתובות @privaterelay.appleid.com או @private.icloud.com הוחזר כי דומיין השליחה שלכם לא נרשם אצל Apple, ייתכן שהכתובות האלה סומנו כלא תקינות. תקנו קודם את הרישום, ואז נקו את ההחזרות. ראו Apple Private Email Relay.


משתני תבניות Liquid​

משתנים זמינים​

ניתן להשתמש בהם בתבניות האימייל:

משתנהתיאור
{{ unsubscribe_url }}URL גלובלי לביטול הרשמה
{{ unsubscribe_url_list }}URL לביטול הרשמה ספציפי לרשימה
{{ preferences_url }}URL למרכז ההעדפות
{{ resubscribe_url }}URL להרשמה מחדש (לקמפיינים של win-back)

דוגמת שימוש​

<p>Don't want to receive these emails?</p>
<p>
<a href="{{ unsubscribe_url_list }}">Unsubscribe from this list</a>
or
<a href="{{ preferences_url }}">Manage your preferences</a>
</p>

מסנני סגמנטים​

סוגי מסננים​

קיימים שלושה סוגי מסננים חדשים לפילוח:

מסנן הרשמה לערוץ​

התמקדו במשתמשים לפי מצב ההרשמה לערוץ:

{
type: 'channel_subscription',
operator: 'subscribed_to_channel', // or 'not_subscribed_to_channel'
channel: 'email',
subscriptionStatus: 'opted_in' // optional: specific status
}

מסנן חברות ברשימה​

התמקדו במשתמשים לפי חברות ברשימה:

{
type: 'list_membership',
operator: 'member_of_list', // or 'not_member_of_list'
listId: 'list-uuid',
channel: 'email' // optional: specific channel
}

מסנן סטטוס החזרה​

התמקדו במשתמשים לפי תקינות כתובת האימייל:

{
type: 'bounce_status',
operator: 'email_valid' // 'email_valid', 'email_bounced',
// 'email_hard_bounced', 'email_soft_bounced'
}

מקרי שימוש​

  1. שליחה רק למשתמשים שעשו opt-in:

    { type: 'channel_subscription', operator: 'subscribed_to_channel',
    channel: 'email', subscriptionStatus: 'opted_in' }
  2. החרגת אימיילים שחזרו:

    { type: 'bounce_status', operator: 'email_valid' }
  3. התמקדות במנויי הניוזלטר:

    { type: 'list_membership', operator: 'member_of_list',
    listId: 'newsletter-list-id' }

הפניית API​

ההפניה המלאה ל־REST API לניהול הסכמה לערוצים, רשימות הרשמה וחברות ברשימות - כולל כל נקודת קצה, דוגמאות לבקשה ולתגובה וההרשאות הנדרשות - נמצאת בדף Subscriptions API.

שני דברים שכדאי לדעת לפני שקוראים ל-API:

  • אפשר להירשם באותה קריאה שיוצרת את איש הקשר. כל איבר של attributes ב־POST /users/track מקבל subscriptions - ראו מנויים לרשימות. נקודות הקצה הייעודיות שבהמשך נשארות הדרך לשנות הסכמה מאוחר יותר. opt-out קיים לעולם אינו מבוטל על ידי הקריאה הזו או על ידי ייבוא: הוא נשמר ומדווח, ורישום מחדש של איש קשר שביטל את ההרשמה מחייב תמיד קריאה מפורשת לנקודת הקצה להרשמה.
  • :userId בנתיבים האלה הוא ה־id הפנימי של איש הקשר ב־Joryio (כפי שמוחזר מ־Users API), ולא מזהה המשתמש החיצוני שלכם.

הרשמה טיפוסית - צירוף איש קשר לרשימה בערוץ האימייל:

curl -X POST https://api-eu1.joryio.com/api/subscriptions/contacts/665f1c2ab3d4e5f6a7b8c9d0/lists/3f6c1a2e-9d4b-4f0a-8c7e-1b2d3e4f5a6b \
-H "Authorization: Bearer jry_live_your_api_key" \
-H "Content-Type: application/json" \
-d '{ "channel": "email", "source": "api", "consentText": "Weekly newsletter signup" }'

נקודות קצה ציבוריות (ללא אימות)​

// One-click unsubscribe (RFC 8058): the mail app's List-Unsubscribe-Post
POST /u/:token

// The hosted page's Unsubscribe button (a person's click only, see #automatic-unsubscribe)
// Body: { reason?: string, view?: 'unsubscribe' | 'preferences' }
POST /u/:token/confirm

// Get preferences
GET /preferences/:token

// Save preferences
POST /preferences/:token
Body: { channels: [...], lists: [...], reason?: string, undo?: boolean }

נקודות קצה ל-SDK (אימות באמצעות SDK Key)​

נקודות קצה אלו משמשות את ה-Web SDK ומאומתות באמצעות הכותרת X-SDK-Key.

// Update channel subscription
POST /v1/subscriptions/channel
Headers: { 'X-SDK-Key': 'jry_sdk_web_...' }
Body: {
channel: 'email' | 'sms' | 'whatsapp' | 'push' | 'viber',
status: 'optedIn' | 'subscribed' | 'unsubscribed',
userId?: string, // Use if user is identified
anonymousId?: string // Use if user is anonymous
}

// Update subscription group (list) membership
POST /v1/subscriptions/group
Headers: { 'X-SDK-Key': 'jry_sdk_web_...' }
Body: {
groupId: string, // List ID
channel: 'email' | 'sms' | 'whatsapp' | 'push' | 'viber',
action: 'subscribe' | 'unsubscribe',
userId?: string,
anonymousId?: string
}

אם עדיין אין פרופיל עבור ה-userId או ה-anonymousId, השרת יוצר אותו - לפי userId כשהוא נשלח, ואחרת כפרופיל אנונימי - בדיוק כמו /v1/alias/add, כך ששינוי הסכמה שנעשה לפני שהאירוע הראשון נשמר לא הולך לאיבוד. שרתים ישנים ענו במקום זה 404. קודי הסטטוס של הנתיבים האלה מפורטים בתשובות לשאר נתיבי הכתיבה.


תצורה​

הגדרות סביבת עבודה​

הגדירו את הגדרות ההרשמה תחת Settings → Subscriptions:

interface SubscriptionSettings {
listUnsubscribe?: {
enabled: boolean;
includeMailto: boolean;
scope: 'global' | 'list';
};
bounceHandling?: {
softBounceRetryHours: number; // Window for counting soft bounces
softBounceMaxRetries?: number; // Soft bounces in-window before escalating to hard
resubscribeOnEmailChange: boolean; // Clear the invalid flag when the email changes
};
doubleOptIn?: {
defaultEnabled: boolean;
confirmationEmailTemplateId?: string;
};
bccEmail?: string; // For compliance archiving
}

תאימות​

רשת ביטחון לכותרת תחתונה של ביטול הרשמה​

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

  • רכיב כותרת תחתונה לתאימות - רכיב התוכן compliance_footer (שנוצר אוטומטית עם ברירת מחדל סבירה בפעם הראשונה שמפעילים הוספה אוטומטית) מכיל את הכתובת שלכם וקישורים לביטול הרשמה ולניהול העדפות. תוכלו להפנות אליו בכל מקום באמצעות {{ blocks.compliance_footer }}, או לערוך אותו תחת Content Blocks.
  • מתג הוספה אוטומטית - Settings → Subscriptions → "Auto-append an unsubscribe footer when missing". כשהוא מופעל, תהליך שליחת האימייל מוסיף את הכותרת התחתונה לכל אימייל שיווקי (אימייל שנושא כותרת List-Unsubscribe) שאין בגופו קישור לביטול הרשמה או לניהול העדפות. הכשל פתוח: המנגנון לעולם אינו חוסם שליחה.
  • אזהרה בעורך - עורך האימייל בקמפיין מציג אזהרה כאשר אין בגוף האימייל קישור לביטול הרשמה, כדי שתבחינו בכך לפני השליחה (הגנה גלויה, לא חסימה קשיחה). האזהרה מציעה שני קיצורי דרך בתוך השורה - Add a link (פותח את העורך כדי להוסיף קישור) ו־enable auto-append footer (עובר לדף Subscriptions הזה) - ואפשר לסגור אותה למשך הסשן. כשהוספה אוטומטית כבר מופעלת, האזהרה הופכת להודעת מידע מתונה יותר, משום שהכותרת התחתונה תתווסף עבורכם.

אפשר לבחור רשימות הרשמה גם בצומתי SMS, WhatsApp ו־Viber במסע (ולא רק באימייל), כך ששער השליחה של כל צומת מדלג על אנשי קשר שביטלו את הרשמתם לרשימה באותו ערוץ.

GDPR (אירופה)​

  • להשתמש ב-double opt-in עבור משתמשי האיחוד האירופי
  • לשמור טקסט הסכמה וחותמת זמן
  • לספק גישה נוחה למרכז ההעדפות
  • לכבד בקשות ביטול הרשמה מיד
  • לשמור יומן ביקורת של כל שינויי ההרשמה

CAN-SPAM (ארצות הברית)​

  • לכלול כתובת דואר פיזית באימיילים
  • לכבד בקשות ביטול הרשמה תוך 10 ימי עסקים (Joryio עושה זאת מיד)
  • זיהוי ברור של אימיילים מסחריים
  • לא להשתמש בכותרות נושא מטעות

TCPA (ארצות הברית - SMS)​

  • לקבל הסכמה כתובה מפורשת לפני שליחת SMS
  • לכבד מילות STOP מיד
  • לספק הוראות opt-out בהודעות
  • Joryio מטפלת אוטומטית ב: STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT, REVOKE, OPTOUT, OPT OUT, OPT-OUT (הבסיס האנגלי הקבוע), בנוסף לברירות מחדל מתורגמות (למשל הסר בעברית) ולכל מילת מפתח מותאמת שתוסיפו

טיפול במילות מפתח ב-SMS וב-WhatsApp​

Joryio מעבדת באופן אוטומטי מילות מפתח נכנסות ומתאימה אותן בלי תלות ברישיות ובסבילות להבדלי פיסוק (Stop, STOP!, " stop " נחשבות כולן). STOPALL היא מילת ה־opt-out המובנית היחידה שחלה על הערוץ כולו (בנוסף למילות opt-out מותאמות שתגדירו כחָלות על הערוץ כולו); כל מילת opt-out אחרת מוגבלת לקבוצת ההרשמה לפי מספר או לפי WABA שאליה הגיעה ההודעה, ו־START רושמת מחדש את הקבוצה של אותו מספר או WABA. לרשימה המלאה - הבסיס באנגלית (כולל REVOKE ו־OPTOUT), ברירות המחדל המקומיות והתוספות המותאמות שלכם - ולכלל ההרשמה מחדש, ראו מילות מפתח למעלה.

SMS

מילת מפתחפעולה
STOP, UNSUBSCRIBE, CANCEL, END, QUIT, REVOKE, OPTOUT, OPT OUT, OPT-OUTביטול הרשמה לקבוצה של המספר המקבל
STOPALLביטול הרשמה בכל הערוץ (כל המספרים)
START, YES, UNSTOP, SUBSCRIBE, OPTINהרשמה מחדש לקבוצה של המספר המקבל
HELP, INFOשליחת הודעת עזרה
ברירות מחדל מתורגמות (למשל הסר, PARE, ARRET) + תוספות מותאמותכמו הקטגוריה שלהן לעיל

WhatsApp

מילת מפתחפעולה
STOP, UNSUBSCRIBE, CANCEL, END, QUIT, OPTOUT, OPT-OUTביטול הרשמה לקבוצה של ה-WABA המקבל
STOPALLביטול הרשמה בכל הערוץ (כל חשבונות ה־WABA)
START, UNSTOP, SUBSCRIBE, YES, OPTIN, OPT-INהרשמה מחדש לקבוצה של ה-WABA המקבל

הודעות Webhook נכנסות מאומתות באמצעות חתימה - הודעות STOP או START מזויפות נדחות, וספקים שאינם תומכים באימות חתימה להודעות נכנסות אינם מתקבלים לעיבוד מילות מפתח נכנסות. אם אי אפשר לזהות את הקבוצה לפי מספר או לפי WABA, ביטול ההרשמה חל כברירת מחדל בטוחה על הערוץ כולו.

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


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

  1. השתמשו תמיד בכותרות List-Unsubscribe - משפר את יכולת המסירה ומאפשר ל־Gmail להציג כפתור לביטול הרשמה

  2. הטמיעו double opt-in לשיווק - משפר את איכות הרשימה ואת התאימות

  3. נטרו את שיעורי ההחזרה - שיעורי החזרה גבוהים פוגעים במוניטין השולח

  4. פלחו לפי מצב ההרשמה - שלחו רק למשתמשים שביצעו opt-in

  5. הקלו על ביטול ההרשמה - לחיצה אחת, ללא צורך בהתחברות

  6. שמרו יומני ביקורת - נדרשים לתאימות ומועילים ביישוב מחלוקות

  7. בדקו את מרכז ההעדפות - ודאו שמשתמשים יכולים לנהל את העדפותיהם בקלות

  8. השתמשו בביטול הרשמה לפי רשימה - מאפשר למשתמשים להישאר רשומים לחלק מהתוכן


פתרון תקלות​

בעיות נפוצות​

אימיילים לא נשלחים

  • בדקו אם למשתמש יש מצב unsubscribed בערוץ האימייל
  • בדקו אם כתובת האימייל מסומנת כלא תקינה עקב החזרות
  • אמתו את מצב ההחזרה בפרופיל המשתמש

ביטול הרשמה לא עובד

  • בדקו אם פג תוקף הטוקן (ברירת המחדל היא 90 יום)
  • ודאו שחתימת הטוקן תקינה
  • בדקו אם יש שגיאות ביומן הביקורת

החזרות לא מטופלות

  • ודאו שכתובת ה־Webhook מוגדרת כראוי אצל ספק האימייל
  • בדקו את האימות של ה־Webhook
  • עיינו ביומני השגיאות

ניפוי באגים​

בדיקת סטטוס הרשמה:

# API call
curl -X GET "https://api-eu1.joryio.com/api/subscriptions/contacts/{userId}" \
-H "Authorization: Bearer {token}"

צפייה ביומן הביקורת:

curl -X GET "https://api-eu1.joryio.com/api/subscriptions/contacts/{userId}/history" \
-H "Authorization: Bearer {token}"