אינטגרציית WooCommerce

חברו את חנות ה-WooCommerce שלכם באמצעות תוסף WordPress קל, Joryio (שנקרא "Joryio for WooCommerce" לפני גרסה 1.6.2 ו-"Joryio for WordPress" לפני גרסה 1.6.25). כפתור Download Plugin בלוח הבקרה תמיד מוריד את הגרסה העדכנית. סנכרנו מוצרים, הזמנות ולקוחות והפעילו מעקב אחר עגלות נטושות.

אין לכם חנות? אותו תוסף מחבר כל אתר WordPress למעקב עמודים, טפסים באתר, הודעות in-app ו-Web Push - ראו אתר WordPress (בלי חנות).

יכולות

• תוסף WordPress - התקנה קלה באמצעות העלאת תוסף; לוח הבקרה תמיד מגיש את הגרסה העדכנית
• טפסים באתר - שליחות של Contact Form 7 ו-Elementor Pro יוצרות או מעדכנות את איש הקשר ורושמות Form Submitted; כל טופס קובע אם הוא גם רושם לרשימה. עובד גם בלי WooCommerce (ראו טפסים: Elementor ו-Contact Form 7)
• סנכרון בזמן אמת - מוצרים, הזמנות, לקוחות ועגלות מסתנכרנים בזמן אמת דרך התוסף
• מעקב ושחזור עגלות נטושות - מעקב אחר עגלות נטושות, שחזורן באמצעות קישורי שחזור ותיעוד עגלות ששוחזרו
• מעקב בחנות - מעקב אחר צפיות בדפים, במוצרים ובקטגוריות, הוספה לעגלה (כל הוספה, כולל WooCommerce Blocks) והתחלת checkout (קלאסי ו-Checkout block)
• לכידת אימייל - זיהוי אוטומטי של לקוחות ב-checkout ובטפסים
• תיבת סימון להסכמה לדיוור - איסוף הסכמה לקבלת אימייל (ואופציונלית SMS) ב-checkout ובהרשמה, עם תיעוד ההסכמה בכל הזמנה (ראו תיבת סימון להסכמה לדיוור)
• כתובות URL לשחזור עגלה - יצירת קישורים לשחזור עגלות נטושות
• תמיכה בכמה חנויות - חיבור כמה חנויות WooCommerce ופילוח האירועים לפי חנות
• ה-checkout לעולם לא נחסם - אירועי הזמנה נשלחים ברקע, כך ש-Joryio אינה יכולה להאט או לעכב את ה-checkout של הקונה

שלבי הגדרה

שלב 1: קבלת מפתח ה-API

1. עברו אל הגדרות → אינטגרציות ב-Joryio
2. בקטע WooCommerce, לחצו על קבל מפתח API
3. העתיקו את מפתח ה-API שנוצר (מתחיל ב-jry_wc_)

שלב 2: התקנת התוסף

1. הורידו את תוסף Joryio ל-WordPress דרך הגדרות → אינטגרציות בלוח הבקרה של Joryio (כפתור הורד תוסף)
2. בממשק הניהול של WordPress, עברו אל תוספים → הוסף חדש → העלה תוסף
3. העלו את קובץ ה-ZIP ולחצו על התקן עכשיו
4. לחצו על הפעל

שלב 3: חיבור התוסף

1. בממשק הניהול של WordPress, עברו אל WooCommerce ← Joryio
2. הדביקו את מפתח ה-API משלב 1
3. בדקו את Server URL: זו צריכה להיות כתובת ה-API של האזור שלכם, https://api-eu1.joryio.com
4. לחצו על Connect

לאחר מכן העמוד מציג Connected to Joryio עם שם החנות, כתובת החנות ו-Workspace ID.

מגרסת תוסף 1.6.32 לדף ההגדרות יש לשוניות. עד שהחנות מחוברת מוצגת רק Connection; אחרי החיבור:

לשונית	מה יש בה
Connection	החנות, הכתובת שלה ו-Workspace ID, Test connection, Disconnect ומצב הסנכרון
Tracking & identity	Inject Tracking Script וזיהוי מבקרים לפי האימייל שהם מקלידים
Store	Cart Abandonment Time, Recovery Link Reuses Its Cart For ו-Track Guest Carts
Consent	תיבת הסימון להסכמה לדיוור
In-app & web push	הודעות in-app ו-Web Push
Forms	Contact Form 7 ו-Elementor

כל לשונית שומרת רק את ההגדרות שלה, ואחרי שמירה הדף מציג Settings saved.. באתר בלי WooCommerce אין לשוניות Store ו-Consent. גרסאות קודמות מציגות את אותן הגדרות בדף אחד.

שלב 4: אין צורך בהגדרה נוספת

אין צורך ליצור בעצמכם מפתחות WooCommerce REST API: בלחיצה על Connect התוסף יוצר מפתח קריאה/כתיבה בשם Joryio Integration (תחת WooCommerce ← הגדרות ← מתקדם ← REST API) ומעביר אותו ל-Joryio, שמייבאת את המוצרים, הלקוחות וההזמנות שלכם. אל תמחקו את המפתח הזה - בלעדיו הסנכרון ל-Joryio נעצר; אם מחקתם אותו, לחצו שוב על Connect כדי ליצור מפתח חדש.

הגדרות סנכרון

הגדירו את אפשרויות הסנכרון דרך הגדרות → אינטגרציות → WooCommerce → לשונית הגדרות:

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

מעקב בחנות

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

אירוע	נשמר בשם	מתי הוא נשלח
Page View	Page Viewed	כל ביקור בדף
Product Viewed	Product Viewed	דף מוצר. כולל את מצב המלאי: in_stock (true או false) ו-stock_status (in_stock, out_of_stock או backorder)
Category Viewed	Product List Viewed	דף קטגוריית מוצרים, עם category_id, category_name וכתובת הדף (תוסף v1.3.1 ומעלה)
Add to Cart	Product Added	כל הוספה, בכל דרך: כפתור ה-AJAX בדפי החנות והקטגוריות, הטופס בדף המוצר, והכפתורים וה-mini-cart של WooCommerce Blocks (תוסף v1.3.1 ומעלה; גרסאות קודמות ראו רק את כפתור ה-AJAX)
Checkout Started	Checkout Started	דף ה-checkout - קלאסי או Checkout block - פעם אחת לכל עגלה. רענון של דף ה-checkout אינו התחלה שנייה
Identify	$identify	לכידת אימייל מטפסים

לקוחות מחוברים (תוסף 1.6.6 ואילך). כשלקוח מחובר לחנות, התוסף חותם על מספר הלקוח של WooCommerce בשרת של החנות, ואירוע ה-identify נושא את ההוכחה הזו. Joryio בודק אותה ומצרף את הגלישה של המבקר לאיש הקשר שכבר מחזיק במספר הלקוח הזה - לעולם לא לאיש קשר שנמצא לפי אימייל, כי כמה אנשי קשר יכולים לחלוק אותו אימייל. אימייל שאורח מקליד מטופל לפי ההגדרה זיהוי מבקרים לפי האימייל שהם מקלידים של החנות. גרסאות קודמות זיהו לקוח מחובר לפי אימייל בלבד, ולכן יכול היה להיווצר איש קשר שני עם האימייל בלבד לצד איש הקשר של הלקוח; אחרי העדכון, איש הקשר השני הזה מצורף לאיש הקשר של הלקוח בפעם הבאה שהלקוח מתחבר באותו דפדפן. מגרסה 1.6.21 של התוסף, כשאי אפשר לחתום על ההוכחה (לא שמור מפתח API, או ש-Joryio לא זמין), הדפדפן לא שולח דבר עבור לקוח מחובר ומנסה שוב בעמוד הבא - הוא לעולם לא חוזר לזיהוי לפי אימייל בלבד. גם לקוח שנוצר ב-wp-admin (Users → Add New), דרך ה-REST API של WooCommerce או בייבוא מגיע ל-Joryio עם מספר הלקוח שלו, ולקוח ש-Joryio עדיין לא קיבל נשלח לפני ההוכחה הראשונה שלו.

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

אירועי מוצר כוללים product_id, variant_id (לווריאציה), quantity, price, currency ואת מצב המלאי.

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

לכידת אימייל

כתובות אימייל נלכדות אוטומטית מהמקורות הבאים:

• שדה אימייל חיוב ב-checkout
• טפסי הרשמה לניוזלטר
• כל שדה להזנת אימייל

זיהוי מבקרים לפי האימייל שהם מקלידים

מגרסת תוסף 1.6.22, בדף ההגדרות של התוסף (WooCommerce → Joryio → Tracking & identity) יש את Recognise visitors by the email they type. ההגדרה מופעלת כברירת מחדל, ותוסף ישן יותר מתנהג כאילו היא מופעלת.

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

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

העגלה עוברת לפי המייל שהוקלד, וגם מייל מתוקן. העגלה של אורח עוברת לאיש הקשר שהמייל שהקליד בקופה מציין ברגע שהוא מקליד אותו, ולא רק כשהעגלה הנטושה מדווחת. מתוסף 1.6.30 העגלה גם נשמרת עם הדפדפן של האורח עצמו מהמוצר הראשון שנוסף, כך שדפדפן אורח אחד הוא איש קשר אחד. כשמבקר מתקן מייל שהוקלד עם שגיאה, הכתובת השגויה מוסרת שוב והכתובת המתוקנת מותאמת כמו כל כתובת אחרת, כך שהמבקר והעגלה עוברים לאיש הקשר הנכון ואף איש קשר לא נשאר עם השגיאה. כתובת שהוקלדה מוסרת רק כל עוד שום דבר אחר באיש הקשר לא מזהה אדם: הזמנה, מספר טלפון, בחירת הסכמה, חשבון בחנות, או כתובת שהוקלדה לפני יותר מיום - שומרים אותה. רק כתובת שהוקלדה בשדה המייל של הקופה מתוקנת כך: כתובת שהוקלדה בטופס באתר (Contact Form 7, Elementor, תיבת ניוזלטר) לעולם לא מוסרת. מתוסף 1.6.33 התוסף מדווח ל-Joryio מאיזה סוג שדה הגיע כל מייל שהוקלד.

כשכמה אנשי קשר חולקים אימייל

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

הודעות in-app ו-Web Push

מגרסה v1.5.0 של התוסף, סקריפט המעקב טוען בחנות גם את ה-SDK של Joryio לווב, מהכתובת https://sdk.joryio.com/web/1/joryio.min.js (הגרסה העדכנית ביותר של 1.x). קריאות הנתונים שלו נשלחות לשרת Joryio של החנות, כמו סקריפט המעקב. ההגדרות נמצאות ב-WordPress תחת WooCommerce → Joryio → In-app & web push:

הגדרה	ברירת מחדל	מה היא עושה
In-app messages	מופעל	מציג בחנות את הודעות ה-in-app שלכם מ-Joryio
Allow HTML in-app messages	מופעל	מציג גם הודעות שנבנו בעורך ה-HTML. הן מוצגות במסגרת מוגנת בחנות שלכם: סקריפטים שנכתבו בהן לא רצים, וההודעה לא יכולה לגשת לדפי החנות או לשלוח בקשות רשת משלה
Web push	כבוי	מאפשר לקונים להירשם להתראות דפדפן

חנויות שמשדרגות מגרסה ישנה של התוסף מקבלות את אותן ברירות מחדל. ה-SDK נטען על ידי סקריפט המעקב, ולכן השאירו את Inject Tracking Script מופעל.

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

Web Push. דפדפן מקבל את ה-service worker של ההתראות רק מהכתובת של החנות עצמה. כש-Web push מופעל, התוסף כותב קובץ joryio-sw.js לתיקיית האתר וגם עונה על https://your-store/joryio-sw.js מתוך WordPress; ה-worker מכסה את כל האתר וטוען את ה-worker המאוחסן של Joryio. הקונים מתבקשים להירשם דרך הודעת in-app של בקשת הרשמה להתראות, לכן השאירו את הודעות ה-in-app מופעלות, והפעילו Web Push לאפליקציה גם ב-Joryio. Web Push דורש שהחנות תהיה בשורש הדומיין (לא בתת-תיקייה כמו /shop/). אם התוסף לא מצליח לכתוב את הקובץ, דף ההגדרות מציג את השורה האחת שצריך להעלות בעצמכם. כיבוי Web Push גורם לאותה כתובת להגיש worker שמסיר את עצמו מהדפדפנים של המבקרים.

הפעילו Web Push גם ב-Joryio. חיבור החנות יצר עבורה אפליקציה ב-Joryio (הגדרות → אפליקציות, בשם החנות). פתחו אותה, לחצו על הפעמון (Push) ועל הפעלת Web Push: כך נוצרים מפתחות ה-Web Push של החנות, שה-SDK בחנות קורא בעצמו - אין מה להעתיק. אחר כך צרו הודעת In-App עם כפתור שמוגדר ל-בקשה להפעלת התראות והציגו אותה באפליקציה הזו; קונים שמאשרים יכולים לקבל את קמפייני ה-Push ושלבי המסע שלכם.

תיבת סימון להסכמה לדיוור

החל מגרסה v1.3.0 של התוסף אפשר לשאול את הקונים אם הם רוצים לקבל דיוור שיווקי, באמצעות תיבת סימון בדפים שתבחרו. מפעילים אותה ב-WordPress תחת WooCommerce → Joryio → Consent.

הגדרה	מה היא עושה	ברירת מחדל
Show the checkbox on (הצגת התיבה ב-)	בחרו אחת או יותר: Checkout (classic shortcode checkout) - ה-checkout הקלאסי, Checkout (block checkout) - ה-checkout מבוסס הבלוקים, My Account registration form - טופס ההרשמה בחשבון שלי	כולן כבויות
Checkbox text (טקסט התיבה)	הטקסט שליד התיבה. השאירו ריק כדי להשתמש בטקסט ברירת המחדל "Yes, I'd like to receive news and offers by email"	טקסט ברירת המחדל
Ticked by default (מסומנת מראש)	מציגה את התיבה כשהיא כבר מסומנת ב-checkout הקלאסי ובטופס ההרשמה	כבוי
SMS consent (הסכמה ל-SMS)	מוסיפה ב-checkout תיבה שנייה להודעות טקסט, עבור מספר הטלפון לחיוב, עם טקסט משלה	כבוי

היכן התיבה מוצגת

• checkout קלאסי - מתחת להערות להזמנה.
• checkout מבוסס בלוקים - באזור ההזמנה, באמצעות ה-API של WooCommerce לשדות checkout נוספים (Additional Checkout Fields). נדרשת WooCommerce 8.9 ומעלה; בגרסאות ישנות יותר דף ההגדרות מציין שהתיבה לא יכולה להופיע שם. ב-checkout מבוסס הבלוקים התיבה תמיד מוצגת לא מסומנת.
• טופס הרשמה - בטופס ההרשמה של החשבון שלי (תיבת אימייל בלבד).

מה סימון עושה ב-Joryio

• מסומנת - איש הקשר נרשם לאימייל (או ל-SMS) ב-Joryio. היסטוריית המינויים שלו מציגה את המקור woocommerce_checkout או woocommerce_registration ואת הטקסט המדויק שהוצג לו.
• קונה חדש - סימון בטופס ההרשמה של My Account, וסימון בקופה שנשלח לפני ההזמנה, נספרים מיד רק עבור קונה מוכר או מי שכבר רשום. כל אחד אחר נשמר בהמתנה עד ההזמנה שלו עם התיבה מסומנת או לחיצה על מייל האישור, אלא אם בחרתם לספור מיד - ראו הסכמות של קונים חדשים. סימון שמגיע עם ההזמנה תמיד נספר. סימון בהרשמה שנשמר בהמתנה נרשם עם הסיבה registration_tick_pending_confirmation (סימון בקופה שנשמר בהמתנה: checkout_tick_without_order).
• לא מסומנת - שום דבר לא משתנה. תיבה לא מסומנת לעולם אינה נחשבת להסרה מרשימת התפוצה, כך שמי שנרשם במקום אחר נשאר רשום. החריג היחיד הוא ההגדרה האופציונלית תיבה לא מסומנת מבטלת הרשמה, שכבויה כברירת מחדל.
• הסיר את עצמו בעבר - סימון לא רושם מחדש מי שהסיר את עצמו, או שהכתובת או המספר שלו חסומים. הוא יכול להירשם מחדש ממרכז ההעדפות. סימון של לקוח מחובר הוא החריג - ראו מה עושים הסכמה או ביטול מחנות.
• כבר רשום - שום דבר לא נכתב מחדש, כך שתאריך ההרשמה והמקור המקוריים נשמרים.
• הוכחה שנרשמת - כל שינוי שתיבה עושה (סימון, סימון שממתין, ביטול מינוי בתיבה לא מסומנת) רושם את הטקסט שהקונה ראה, את השעה, את העמוד (הקופה או עמוד החשבון שלי) והחל מתוסף 1.6.31 גם את כתובת ה-IP של הקונה: כתובת ה-IP של הלקוח בהזמנה עבור הקופה, וכתובת בקשת ההרשמה עבור טופס ההרשמה. כתובת ה-IP מוצגת רק לחברי צוות שמורשים לראות מידע אישי, נכללת כשהאדם מבקש את המידע שלו, ונמחקת כשהמידע שלו נמחק.
• SMS - ההסכמה היא למספר הטלפון לחיוב. אם לאיש הקשר עדיין אין מספר טלפון, המספר הזה נוסף; מספר שכבר קיים באיש הקשר לעולם אינו מוחלף. מספר שהשיב STOP נשאר מוסר.

מתי סימון נחשב

תוסף 1.6.13 ואילך, ב-checkout הקלאסי וב-checkout מבוסס הבלוקים: WooCommerce → Joryio → Consent → When a shopper ticks the checkout opt-in.

אפשרות	מה קורה
Only when the order is placed (ברירת המחדל)	הבחירה מגיעה ל-Joryio עם ההזמנה. קונה שמסמן ונוטש לא נרשם.
Record consent immediately	הסימון מגיע ל-Joryio ברגע שהקונה מסמן, לפני ההזמנה. קונים ומנויים מוכרים נספרים מיד; אורח חדש נספר אחרי ההזמנה שלו או אחרי שאישר במייל (ראו למטה). אם הקונה מבטל את הסימון שוב באותה קופה, הסימון הזה מבוטל - רק הוא: מינוי שנתן בכל מקום אחר נשאר. גם אירוע העגלה הנטושה נושא את התיבה כפי שהקונה השאיר אותה.

מי נספר מיד עם Record consent immediately (1.6.15 ואילך):

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

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

שתי הגנות ב-אינטגרציות → WooCommerce → הגדרות (מנהלים בלבד; כל שינוי נרשם ביומן הביקורת):

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

• סימוני הסכמה לקונה בשעה - ברירת מחדל 3, לפי כתובת IP, לפי קופה ולפי כתובת אימייל. סימונים מעבר למגבלה לא נרשמים, ואירוע העגלה הנטושה של אותה קופה לא נושא הסכמה; ההזמנה עדיין רושמת את הבחירה. לתוסף יש אותה מגבלה (Opt-in ticks per shopper per hour, ברירת מחדל 3), והוא עוצר סימון כזה לפני שהוא נשלח.

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

• כל שינוי נשלח פעם אחת; פתיחה או רענון של הקופה לא שולחים דבר.

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

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

ניסוח ההסכמה וה-GDPR

עם Record consent immediately, סימון הוא הסכמה לשיווק בפני עצמו - הוא לא קשור לרכישה. ודאו שטקסט התיבה אומר מה הקונה מסכים לקבל ובאיזה ערוץ (למשל "Yes, I'd like to receive news and offers by email"), השאירו את התיבה לא מסומנת כברירת מחדל ונפרדת מאישור התנאים שלכם, והזכירו אותה במדיניות הפרטיות. Joryio רושם עם כל סימון את הטקסט שהוצג, את הזמן, את החנות, את הקופה ואת כתובת ה-IP של הקונה. סימון של אורח חדש נשאר בהמתנה עד ההזמנה שלו או האישור שלו, כך שאף אחד לא מקבל שיווק כי מישהו אחר הקליד את הכתובת שלו; מייל האישור נשלח רק אם הפעלתם אותו. תזכורת העגלה הנטושה מגיעה אז לקונה רשום כהודעה שיווקית.

מוצג ב-Joryio, מוגדר בתוסף

אינטגרציות → WooCommerce → הגדרות מציג את הגדרות ההסכמה בקופה של התוסף בכרטיס Store checkout opt-in (set in your store), לקריאה בלבד: אם התיבה מוצגת (בקופה הקלאסית או בקופת הבלוקים), Ticked by default ו-When a shopper ticks the checkout opt-in, עם גרסת התוסף ומתי דיווח עליהן לאחרונה. משנים אותן רק בתוסף, תחת WooCommerce → Joryio → Consent; Joryio אף פעם לא משנה אותן. עם Record consent immediately, הכרטיס מציג גם את הגדרות Joryio שקובעות אז מה סימון עושה: Opt-ins from new shoppers, אימייל האישור והמגבלה לשעה.

תוסף בגרסה 1.6.16 ומעלה מדווח עליהן עם כל בקשה שהוא שולח ל-Joryio - עגלות, עגלות נטושות, הזמנות, לקוחות, מוצרים וכל השאר - ופעם נוספת כששומרים אחת מהן. שינוי, כמו גרסת תוסף חדשה אחרי עדכון, מוצג מהבקשה הבאה; דיווח שלא השתנה נרשם מחדש לכל היותר פעם בשעה, כך שזמן הדיווח האחרון יכול להיות בן עד שעה. עם תוסף ישן יותר הכרטיס מציג Not reported yet - update the plugin.

הסכמות של קונים חדשים

ההגדרה הסכמות של קונים חדשים (שעוד לא קנו) ב-אינטגרציות → WooCommerce → הגדרות (מנהלים בלבד; כל שינוי נרשם ביומן הביקורת) קובעת מה עושה הסכמה של מי שעוד לא קנה:

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

היא חלה על כל הסכמה שמגיעה בלי הזמנה: התיבה בטופס ההרשמה של My Account, ועם Record consent immediately - גם הסימון בקופה. בכל מקרה:

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

זו לא אותה הגדרה כמו When a shopper ticks the checkout opt-in בתוסף: ההגדרה ההיא קובעת מתי סימון בקופה נשלח - עם ההזמנה או ברגע שהוא נעשה; ההגדרה הזו קובעת מה עושה הסכמה מוקדמת של קונה חדש. עם Only when the order is placed, סימון בקופה מגיע עם ההזמנה ותמיד נספר, ולכן ההגדרה הזו חלה רק על הסכמות בהרשמה ובחשבון.

מה עושים הסכמה או ביטול מחנות

מה החנות שולחת	מה Joryio עושה
סימון הסכמה ב-checkout של אורח	רושם איש קשר שעדיין אין לו מינוי בערוץ הזה. אלא אם ההגדרה של החנות שלמטה מופעלת, לעולם לא רושם מחדש מי שביטל את המינוי - ב-checkout כאורח כל אחד יכול להקליד כל כתובת אימייל.
הסכמה של לקוח מחובר (הזמנה שבוצעה כשהלקוח מחובר לחשבון בחנות - תוסף 1.6.1 ומעלה), עם תאריך מאוחר מהביטול האחרון של איש הקשר	רושם מחדש גם איש קשר שביטל את המינוי דרך קישור הסרה או כפתור ההסרה בלחיצה אחת, דף ההעדפות, ה-API, חבר צוות, או ביטול שנעשה באותה חנות.
הסכמה ב-checkout או ברשומת הלקוח, כשההגדרה לאפשר לסימון הסכמה בקופה לרשום מחדש אנשים שהסירו את עצמם מופעלת (כבויה כברירת מחדל)	רושם מחדש איש קשר שביטל את המינוי - גם אחרי checkout כאורח - כשהזמן שהחנות רשמה להסכמה מאוחר מהביטול האחרון שלו. הסיכון: ב-checkout כאורח WooCommerce לא יכולה לומר ל-Joryio מי הקונה, כך שמי שמקליד בקופה את האימייל של אדם אחר יכול לרשום אותו מחדש; תמיד אפשר לבטל שוב בלחיצה אחת. המקרים שלמטה שלעולם לא מתבטלים עדיין חלים.
תיבה לא מסומנת	אין שינוי - זה אף פעם לא ביטול מינוי. אלא אם הפעלתם בחנות את תיבה לא מסומנת מבטלת הרשמה (כבויה כברירת מחדל).
לעולם לא מתבטל בהסכמה מחנות, כשההגדרה מופעלת או כבויה	תלונת ספאם, החזרה קשה (hard bounce), חסימה ברמת הארגון, סביבת עבודה אחרת, ביטול שנרשם באיש קשר אחר עם אותו אימייל או טלפון, ו-STOP ב-SMS.

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

תיבה לא מסומנת מבטלת הרשמה (אופציונלי)

לחנויות עם מדיניות הסכמה מחמירה, בתוסף 1.6.27 ואילך יש הגדרה אופציונלית ב-WooCommerce → Joryio → Consent, ליד When a shopper ticks the checkout opt-in: An unticked opt-in box at checkout or registration unsubscribes the person. היא כבויה כברירת מחדל.

הגדרה	מה תיבה לא מסומנת עושה
כבויה (ברירת מחדל)	כלום. תיבה לא מסומנת לעולם לא משנה סטטוס של אף אחד.
פעילה	תיבה שהוצגה ונשלחה לא מסומנת - עם הזמנה שבוצעה, או בטופס ההרשמה - רושמת ביטול הרשמה לערוץ של אותה תיבה (אימייל או SMS). רק ללקוחות מחוברים, שהחנות אימתה.
פעילה, עם Also for guest checkouts	אותו דבר גם בקופה כאורח ובהרשמה לחשבון חדש. בקופה כאורח כל אחד יכול להקליד אימייל של מישהו אחר - אורח יכול לבטל הרשמה של אדם אחר. הרשמה לחשבון חדש נחשבת כאורח: החנות לא מאמתת את כתובת האימייל.

• ביטול ההרשמה נרשם כמו כל ביטול אחר: בהיסטוריית המינויים של איש הקשר (מקור woocommerce_checkout / woocommerce_registration, סיבה checkout_box_unticked, עם הטקסט שהוצג ליד התיבה) וכאירוע message.unsubscribed.
• גם מי שמעולם לא נרשם: כשההגדרה פעילה, תיבה לא מסומנת מבטלת את ההרשמה של האדם גם אם הוא מעולם לא נרשם (Not Set הופך ל־Unsubscribed). כמו כל ביטול הרשמה, היא חלה על כל איש קשר עם אותו דוא"ל או טלפון בסביבת העבודה, וביטול שלה דורש הסכמה חדשה.
• לעולם לא עבור תיבה שלא הוצגה (תיבת ה-SMS רק היכן שהיא מוצגת), לעולם לא מסנכרון של הזמנות קודמות, ולעולם לא עבור תיבה שהסימון שלה הוסר לפני ביצוע ההזמנה - הסרת סימון במהלך הקופה רק מבטלת את הסימון של אותה קופה. היא לעולם לא רושמת או רושמת מחדש אף אחד, ולעולם לא משנה חסימה בגלל החזרה (bounce) או תלונה.
• Integrations → WooCommerce → Settings מציג את ההגדרה לקריאה בלבד. גרסאות ישנות יותר לא מדווחות עליה, ו-Joryio מתייחס אליה ככבויה.

מה נשמר

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

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

מסך ההזמנה ב-WooCommerce מציג את הבחירה שנשמרה מתחת לכתובת החיוב.

אל תסמנו את התיבה מראש אם אתם מוכרים באירופה

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

טפסים: Elementor ו-Contact Form 7

מגרסה v1.6.0 התוסף שולח ל-Joryio את השליחות של טפסי Contact Form 7 ו-Elementor Pro שלכם. כל שליחה יוצרת את איש הקשר, או מעדכנת את איש הקשר עם אותו אימייל (אותו טלפון, כשאין בטופס אימייל), ורושמת את האירוע Form Submitted. רק השדות שמיפיתם יוצאים מהאתר שלכם.

Contact Form 7

1. ב-WordPress עברו אל WooCommerce → Joryio (באתר בלי WooCommerce: Settings → Joryio). בלשונית Forms מופיעים כל טפסי Contact Form 7
2. סמנו Send this form to Joryio
3. בחרו List (לא חובה - בלי רשימה הטופס שומר רק את איש הקשר ואת האירוע)
4. בחרו את מצב List subscription (ראו בהמשך), ובמצב ההסכמה גם את שדה ה-acceptance של הטופס
5. מפו את השדות: כל שדה ל-Email, Phone, First name, Last name, Custom attribute (הקלידו את מפתח המאפיין) או Do not send. מפו לפחות שדה אימייל או טלפון
6. לחצו Save form settings (מנהלי מערכת בלבד)

השליחה נשלחת אחרי ש-Contact Form 7 קיבל אותה ושלח את המייל שלו.

Elementor Pro

1. ערכו את הטופס ב-Elementor, ותחת Actions After Submit הוסיפו Joryio
2. באזור Joryio בחרו List ואת מצב List subscription. במצב ההסכמה הזינו Consent field ID - המזהה של שדה ה-Acceptance בטופס, מהלשונית Advanced של השדה
3. הזינו את מזהי השדות של Email, Phone, First name ו-Last name, ומאפיינים מותאמים שורה לכל אחד בצורה attribute_key = field_id
4. לחצו Update

מצבי הרשמה לרשימה

לכל טופס מצב משלו:

מצב	איש קשר ואירוע Form Submitted	הרשמה לרשימה
This is a signup form - always subscribe	בכל שליחה	בכל שליחה
Only when a consent field is ticked	בכל שליחה	רק כששדה ההסכמה של הטופס (שדה acceptance של Contact Form 7 או שדה Acceptance של Elementor) מסומן

המאפיין consentGiven של האירוע מראה מה קרה. תיבה לא מסומנת אף פעם לא מסירה מנוי.

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

כשהרשימה של הטופס דורשת אישור כפול, איש הקשר לא נרשם מיד: Joryio שולח את מייל האישור (אותו מייל כמו בטפסי דפי נחיתה - את התבנית בוחרים ב-Settings → Subscriptions → Double opt-in) ורושם אותו כשהוא לוחץ על הקישור. עד אז האירוע מציין את הרשימה ב-listsPending. ברשימות הבחירה רשימות כאלה מסומנות (double opt-in).

מה Joryio שומר

• איש הקשר - טופס של מבקר ממלא אימייל וטלפון רק כשאין לאיש הקשר כאלה: הוא אף פעם לא משנה את האימייל או הטלפון של איש קשר קיים. לקוח מחובר יכול לעדכן את הטלפון שלו (תוסף 1.6.34): כשלקוח שמחובר לאתר שלכם שולח טופס והאימייל בטופס שייך לאיש הקשר שלו עצמו, הטלפון שהוקלד בטופס מחליף את הטלפון של איש הקשר. התוסף מוכיח מי מחובר באמצעות הוכחה חתומה שנוצרת בשרת שלכם, ורק עבור טופס שנשלח באתר שלכם; האימייל אף פעם לא משתנה בדרך הזו. השמות והמאפיינים המותאמים שמיפיתם נכתבים לאיש הקשר. איש קשר שנוצר מטופס מוצג עם נוצר דרך: טופס באתר
• האירוע - Form Submitted, עם source (cf7 או elementor), formId, formName, pageUrl, consentGiven, consentText (הנוסח של תיבת ההסכמה שסומנה, החל מתוסף 1.6.31), listsSubscribed, listsPending, ה-email וה-phone של הטופס עצמו (בפורמט שבו איש הקשר שומר אותם, כך שטלפון אחר שמבקר הקליד לא הולך לאיבוד) ו-phoneUpdated כשהטלפון בטופס שונה מזה של איש הקשר - true כשאיש הקשר מחזיק בו עכשיו, false כשאיש הקשר שמר את שלו. חברי צוות שאינם מורשים לראות מידע אישי לא רואים את ערכי האימייל והטלפון, והם נמחקים יחד עם האדם. אפשר להשתמש בו כטריגר למסע, כטריגר לקמפיין או כתנאי בסגמנט. שאר הערכים שהוזנו בטופס אינם נשמרים באירוע
• רשומת ההסכמה - כשהטופס רושם את איש הקשר לרשימה, היסטוריית המינויים שומרת את הוכחת ההסכמה: הנוסח המדויק של תיבת ההסכמה שהאדם סימן, העמוד שבו נשלח הטופס (pageUrl), השעה וכתובת ה-IP של המבקר (מוצגת רק לחברי צוות שמורשים לראות מידע אישי). ראו הוכחת הסכמה

הוכחת הסכמה

החל מתוסף 1.6.31, כשהאדם מסמן את שדה ההסכמה של הטופס, התוסף שולח גם את מה שהוא הסכים לו:

• הנוסח - הטקסט הגלוי של שדה ההסכמה: הטקסט של תגית acceptance ב-Contact Form 7 ([acceptance your-consent] I agree to receive news by email [/acceptance]), או ה-Acceptance Text של שדה Acceptance ב-Elementor (ואם אין - התווית שלו). קישורים ועיצוב מוסרים; עד 500 תווים. טקסט שכתבתם מחוץ לתגית ה-acceptance בתבנית של Contact Form 7 לא נשלח - כתבו את הנוסח בתוך התגית. ב-Elementor, השדה הוא זה שמופיע ב-Consent field ID (כל מזהה מותאם אישית), והוא חייב להיות שדה Acceptance
• העמוד, השעה וכתובת ה-IP של השליחה של המבקר

תיבה שלא סומנה לעולם לא שולחת את הנוסח שלה, וטופס הרשמה (בלי תיבה) לא שולח נוסח. ההוכחה נכתבת לרשומת הסכמה רק כשהטופס רושם את איש הקשר לרשימה: עם No list אף אחד לא נרשם, ולכן הנוסח נשאר רק באירוע Form Submitted (consentText; כתובת ה-IP לעולם לא נכתבת לאירוע). ברשימה עם אישור כפול ההוכחה נשמרת עם האישור ונרשמת כשהאדם מאשר.

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

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

אתרים בלי WooCommerce

התוסף עובד בכל אתר WordPress. בלי WooCommerce הוא נמצא תחת Settings → Joryio ומתחברים אותו דבר, עם אותו מפתח jry_wc_: מקבלים טפסים באתר, את סקריפט המעקב עם לכידת אימייל, הודעות in-app ו-Web Push. יכולות החנות - מעקב עגלות, סנכרון הזמנות, מוצרים ולקוחות, קישורי קופונים ותיבת ההסכמה בקופה - נדלקות כש-WooCommerce פעיל. אם תוסיפו WooCommerce בהמשך, לחצו Disconnect ואז שוב Connect, כדי ש-Joryio ייצור את מפתח ה-REST שלו ויסנכרן את החנות. המדריך המלא לאתר בלי חנות: אתר WordPress (בלי חנות).

שחזור עגלות נטושות

התוסף עוקב אחר עגלות קניות בזמן אמת:

1. המערכת עוקבת אחר פריטי העגלה וערכה בזמן שהלקוחות קונים
2. לאחר 30 דקות של חוסר פעילות, העגלה מסומנת כנטושה
3. נוצרת כתובת URL שבאמצעותה אפשר לשחזר את העגלה
4. השתמשו במסע כדי לשלוח אימיילים לשחזור הכוללים את קישור השחזור

כתובות URL לשחזור עגלה

כאשר לקוח לוחץ על קישור השחזור:

1. מצב העגלה שלו משוחזר
2. כל פריטי העגלה מתווספים מחדש
3. הלקוח מועבר ל-checkout

מוצרים שכבר אי אפשר להוסיף (אזלו מהמלאי, נמחקו או לא זמינים) מוזכרים בשמם: "No longer available, so not added: ...". כשאי אפשר להוסיף אף אחד, הקונה רואה בדף העגלה "The products in this cart are no longer available." במקום checkout ריק, והעגלה לא נספרת כמשוחזרת (גרסת תוסף 1.6.9 ואילך).

מגרסת תוסף 1.6.10 הקישור עובד כמו בתוסף Magento:

• הוא לעולם לא מרוקן את העגלה הנוכחית של הקונה - המוצרים השמורים מתווספים אליה. כשבעגלה כבר יש מוצרים, או כשקונה מחובר פותח עגלה שמורה של אורח, עמוד שואל קודם: "Add these products from your saved cart to your current cart?"
• עגלה של לקוח רשום שנפתחת על ידי לקוח מחובר אחר נדחית: "This cart belongs to a different account. Sign out to open it as a guest." אף אחד לא מוזכר בשמו.
• כשנפתחת בלי התחברות, המוצרים של לקוח רשום משוחזרים עם "Sign in to use your saved details at checkout."
• פתיחה חוזרת - אותו דפדפן מגיע לעגלה שכבר שוחזרה (שום דבר לא מוכפל), דפדפן או מכשיר אחר מקבלים עגלה חדשה עם המוצרים השמורים (למטה), ואחרי ההזמנה הקישור מציג "You already completed this order."
• כשאתר אחר טוען אותו (כתמונה, מסגרת או fetch) הקישור לא משנה כלום.
• ההזמנה, לא הלחיצה, נספרת כשחזור: ההזמנה מציינת את העגלה השמורה שממנה הגיעה, כך שהעגלה הנטושה נספרת כמשוחזרת על ידי ההזמנה גם כשהקונה משלים עם מייל אחר.

פתיחת הקישור: עמוד שחזור, עגלה אחת לכל קישור

מגרסת תוסף 1.6.17, פתיחת הקישור לבדה לא משנה דבר. תצוגות מקדימות של קישורים באפליקציות צ'אט וסורקי אבטחה של דואר (Outlook Safe Links, Gmail ואחרים) פותחים קישורים לפני הקונה, וכל פתיחה כזו שחזרה בעבר את העגלה פעם נוספת.

• פתיחת הקישור מציגה עמוד קצר, "Restoring your saved cart...", שלעולם לא נשמר במטמון ולא נסרק למנועי חיפוש. הסקריפט שלו משחזר את העגלה וממשיך לקופה; בלי סקריפט הקונה לוחץ Restore my cart. תצוגה מקדימה או סורק שלא מריצים סקריפט לא משחזרים דבר. עמוד האישור ("Add these products from your saved cart to your current cart?") עדיין מחכה ללחיצה של הקונה.
• עגלה אחת לכל קישור, בכל דפדפן - העגלה שהקישור שחזר נשמרת יחד עם הדפדפן שבו היא שוחזרה (WooCommerce שומר עגלה בסשן של הדפדפן). פתיחה חוזרת של אותו קישור באותו דפדפן מחזירה את המוצרים השמורים לאותה עגלה במקום עותק חדש, למשך 7 ימים (WooCommerce → Joryio → Store → Recovery Link Reuses Its Cart For, 1-30 ימים). דפדפן או מכשיר אחר - או סורק שכן הריץ את העמוד - לעולם לא מקבלים את העגלה הזו: הם מקבלים עגלה חדשה עם המוצרים וקוד ההנחה של העגלה השמורה בלבד, כך ששום דבר שמישהו הקליד בקופה בדפדפן אחד לא מופיע בדפדפן אחר. מאותו רגע הקישור זוכר את העגלה של הדפדפן האחרון. שתי העגלות עדיין נחשבות לאותה עגלה שמורה: הזמנה מכל אחת מהן היא שחזור אחד, ונשלחת רק תזכורת אחת על "ננטשה שוב" לכל עגלה מקורית.
• כבר הוזמן - "You already completed this order.", ושום דבר לא משוחזר.
• לכל היותר 10 שחזורים לקישור בשעה - אחר כך, "Too many attempts with this cart link. Please try again later."

ייחוס של הזמנות משוחזרות

החל מתוסף 1.6.11, קישור השחזור שומר את פרמטרי הייחוס שמעקב ההקלקות של Joryio מוסיף (jr_cid, jr_jid, utm_*) כשהוא מעביר את הקונה לעגלה, כך שההזמנה מיוחסת להודעה ששלחה את הקישור. רק הפרמטרים האלה מועברים, וכל אחד נבדק לפי הפורמט שלו - לעולם לא האסימון של הקישור או כל דבר אחר. כשהקונה פותח את הקישור ומשלים את הרכישה עם מייל אחר, Joryio מייחס את ההזמנה להקלקה של איש הקשר שאליו נשלחה ההודעה. ראו עגלות.

עגלה משוחזרת שננטשה שוב

החל מתוסף 1.6.12, עותק משוחזר שהקונה עוזב שוב מדווח פעם נוספת אחרי זמן הנטישה הרגיל, עם reabandonedAfterRecovery: true ו-originalSessionId באירוע Cart Abandoned; עותק נוסף של אותה עגלה מקורית שנשאר ללא פעילות בתוך 30 יום אינו מדווח. עגלה שכבר היו בה מוצרים וקיבלה את המוצרים השמורים היא עגלה רגילה. הזמנה מכל עותק נספרת כשחזור אחד של העגלה המקורית. ראו עגלות.

לעותק משוחזר של אורח אין מייל (הקישור אף פעם לא מעתיק אותו); מ-1.6.17 הוא בכל זאת מדווח, בלי מייל, ו-Joryio שולח את התזכורת האחת לאיש הקשר של העגלה המקורית - ראו עגלות.

מגרסה 1.6.23, כל אירוע עגלה של עותק משוחזר מציין מאיזו עגלה הוא שוחזר (restoredFromSessionId), כך שעותק של אורח מוצג ב־E-Commerce → עגלות כעותק משוחזר של העגלה של איש הקשר המקורי ולא כעגלה ללא איש קשר, ולא נספר כעגלה נטושה נוספת - ראו עגלות.

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

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

Cart Abandonment Time ו-Track Guest Carts נמצאות תחת WooCommerce → Joryio → Store.

מתוסף 1.6.24:

• בדיקת העגלות הנטושות משתמשת באזור הזמן של האתר עצמו. גרסאות קודמות השוו את השינוי האחרון בעגלה, שנשמר באזור הזמן של האתר, לזמן ב־UTC: חנות שנמצאת מזרחית ל־UTC (למשל בישראל או באירופה) דיווחה על העגלות שלה באיחור של שעות, ולכן Joryio סימנה אותן כנטושות בעצמה קודם, עם עמוד התשלום הרגיל במקום קישור השחזור; חנות שנמצאת מערבית ל־UTC יכלה לדווח על עגלה בזמן שהקונה עוד היה בה.
• העגלה הנטושה נשלחת באותה הרצה של WP-Cron שמוצאת אותה. WordPress מריץ את WP-Cron רק כשמישהו מבקר באתר, כך שבחנות שקטה הבדיקה עצמה עדיין יכולה לרוץ באיחור; אז Joryio מסמנת את העגלה בעצמה, עם קישור השחזור, אחרי זמן הנטישה שלכם ועוד 20 דקות - ראו עגלות. לתזמון מדויק, הריצו את WP-Cron מ־cron של השרת.
• Track Guest Carts כבוי: עגלות אורחים לא נשלחות ל־Joryio ואף פעם לא מסומנות כנטושות, לא על ידי התוסף ולא על ידי Joryio. צפיות בדפים, צפיות במוצרים, Product Added ו־Checkout Started עדיין נרשמים לאורחים.

מתוסף 1.6.28:

• שינוי בעגלה נשלח ל־Joryio מתוך הביקור של הקונה עצמו, בסוף הבקשה (אחרי שהדף נשלח, בשרתי PHP-FPM ו־LiteSpeed), ולא ממתין בתור להרצה מאוחרת יותר של WP-Cron. מוצר שנוסף לעגלה ש־Joryio כבר סימנה כנטושה מגיע ל־Joryio מיד: העגלה כבר לא נטושה, מציגה את התוכן החדש, ומדווחת שוב כנטושה כשהיא עומדת ללא שינוי במשך זמן הנטישה שלכם.
• בדיקת העגלות הנטושות רצה גם בסוף ביקור כשהיא לא רצה כבר דקה (בשרתי PHP-FPM ו־LiteSpeed, אחרי שהדף נשלח), כך שעגלות מדווחות בערך כשזמן הנטישה עבר, גם כש־WP-Cron רץ באיחור.
• הרצה של הבדיקה לבדה - ההרצה בסוף ביקור, או Run now ב־WP Crontrol, שמריצה רק את האירוע הזה - שולחת קודם את האירועים של התוסף שעדיין ממתינים לשליחה (הרצה רגילה של WP-Cron שולחת אותם בעצמה), כך של־Joryio יש את השינוי האחרון בעגלה לפני הנטישה שלה.
• כדי להריץ את WP-Cron ידנית, השתמשו ב־wp cron event run --due-now (WP-CLI), או שלחו בקשה ל־https://<your store>/wp-cron.php בלי ערך doing_wp_cron. בקשה שנושאת ערך doing_wp_cron (למשל ?doing_wp_cron=$(date +%s)) לא מריצה כלום, אלא אם הערך זהה בדיוק לנעילה הנוכחית של WordPress עצמה, ועדיין עונה 200. גם בקשה רגילה לא מריצה כלום אם WP-Cron התחיל ב־60 השניות האחרונות.
• הדיווחים של הבדיקה (מזהי שורות העגלה בלבד) וכל שליחה שנכשלה נכתבים ב־WooCommerce → Status → Logs, במקור joryio.

תמיכה בכמה חנויות

בעת חיבור כמה חנויות WooCommerce:

1. כל חנות מקבלת ישות App משלה עם SDK key ייחודי
2. כל האירועים מתויגים עם $app_id של החנות
3. סננו אירועים לפי $platform = 'woocommerce' או לפי $app_id מסוים
4. משתמשים יכולים להיות מקושרים בין חנויות באמצעות אימייל

התאמה מתוזמנת

עדכונים חיים (התוסף וה-webhooks) עלולים ללכת לאיבוד - למשל כשהחנות לא זמינה, או כשמשלוח נכשל יותר מדי פעמים. כל 6 שעות Joryio בודקת בחנות מה השתנה מאז הבדיקה הקודמת ומשלימה את מה שהעדכונים החיים פספסו: הזמנות (כולל החזרים וביטולים), מוצרים ולקוחות שנרשמו לאחרונה. שינויים בפרופיל של לקוח קיים לא נבדקים (ה-API של WooCommerce לא יכול לרשום לקוחות לפי תאריך שינוי), ועגלות מגיעות רק מהתוסף (ל-API של WooCommerce אין רשימת עגלות). גרסת WooCommerce שמתעלמת מהמסנן "modified after" לא נבדקת להזמנות ולמוצרים.

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

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

התוצאה מוצגת ב-הגדרות → אינטגרציות → WooCommerce: התאמה אחרונה: 22/10/2026 12:00 - פריטים שהושלמו: 3. אם הבדיקות ממשיכות למצוא שינויים שלא הגיעו בזמן אמת, Joryio מעלה התראה Live updates from WooCommerce may be failing (פעמון, לוגים וניטור, ומייל למנהלי סביבת העבודה). הנתונים החסרים מושלמים בכל מקרה, אבל כדאי לבדוק את חיבור החנות: מסעות שמגיבים לשינויים האלה מתחילים באיחור.

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

החזרים וביטולים

כל החזר ב-WooCommerce הופך לאירוע Order Refunded אחד (עם הסכום שהוחזר והסיבה), וכל הזמנה שבוטלה לאירוע Order Cancelled אחד, כך שמסע יכול להגיב להם. החזר שמדווח גם מהתוסף וגם מ-webhook הוא עדיין אירוע אחד. ראו אירועי החזר וביטול.

איך נתוני החנות מעדכנים איש קשר

הזמנות, checkouts ועדכוני לקוחות מהחנות שלכם מעדכנים את איש הקשר המתאים ב-Joryio:

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

Webhooks

התוסף שולח אירועים ישירות ל-Joryio (מהר יותר מ-webhooks). נוסף על כך, webhooks של REST API נרשמים כגיבוי:

• הזמנה נוצרה, עודכנה, נמחקה
• מוצר נוצר, עודכן, נמחק
• לקוח נוצר, עודכן

סנכרון נתונים

סנכרון ידני

הפעילו סנכרון ידני דרך הגדרות → אינטגרציות → WooCommerce → לשונית סטטוס סנכרון:

• סנכרן הכל - סנכרון מלא של מוצרים, הזמנות ולקוחות
• סנכרון מוצרים - סנכרון מוצרים בלבד
• סנכרון הזמנות - סנכרון הזמנות בלבד
• סנכרון לקוחות - סנכרון לקוחות בלבד

סנכרון אוטומטי

התוסף שולח אירועים בזמן אמת עבור:

• הזמנות חדשות
• שינויי סטטוס הזמנה
• עדכוני מוצר
• עדכוני לקוח
• שינויי עגלה
• עגלות ששוחזרו

מחיקת לקוח בחנות שלכם לא מוחקת את איש הקשר ב-Joryio. כדי למחוק את הנתונים של אדם, השתמשו במחיקת נתונים באיש הקשר.

נתוני מוצר

כל מוצר נשמר בקטלוג של Joryio עם:

• שם, מחיר, מחיר מבצע, מטבע, מק"ט, תמונות, קישור למוצר, קטגוריות ותגיות
• מצב מלאי וכמות, למוצר ולכל וריאציה
• וריאציות, לכל אחת מחיר, מלאי, מק"ט ואפשרויות משלה (לדוגמה Color: Blue)
• מותג - מ-WooCommerce Brands ‏(WooCommerce 9.6 ומעלה), או מ-Perfect Brands for WooCommerce או YITH WooCommerce Brands
• ברקוד - שדה ה-GTIN, UPC, EAN או ISBN ‏(WooCommerce 9.2 ומעלה), למוצר ולכל וריאציה
• מאפיינים - כל מאפיין עם הערכים שלו (לדוגמה Material: Linen)
• תיאור - כטקסט רגיל, בלי HTML ובלי shortcodes של בוני עמודים, עד 5,000 תווים

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

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

ניתוק וחיבור מחדש

• Test connection בעמוד ההגדרות של התוסף (מוצג כשהחנות מחוברת) בודק ש-Joryio מקבלת את המפתח ושהחנות מחוברת אצלה, ואם לא - מסביר למה.
• ניתוק בעמוד ההגדרות של התוסף מסיים את החיבור. התוסף מוחק את ה-webhooks של Joryio ב-WooCommerce ואת מפתח ה-REST Joryio Integration שלו, ואז מודיע ל-Joryio, שמסמנת את החנות כמנותקת ומפסיקה לסנכרן. מפתח ה-API נשאר בתוקף - לחצו שוב על Connect עם אותו מפתח. אם אין גישה ל-Joryio באותו רגע, האתר מתנתק בכל זאת והעמוד מציין ש-Joryio עשויה עדיין להציג את החנות כמחוברת: נתקו אותה גם ב-Joryio.
• ניתוק ב-Joryio (אינטגרציות → WooCommerce & WordPress) מבטל את מפתח ה-API מיד; העמוד מאשר זאת ומציג את החנות כמנותקת מיד. חיבור עם המפתח הזה מציג אז "This key was revoked when the store was disconnected in Joryio", ועמוד WooCommerce ב-Joryio מסביר למה אין מפתח. צרו מפתח חדש והדביקו אותו בתוסף כדי להתחבר שוב.
• אחרי חיבור מחדש, מחובר מאז מציג את זמן החיבור החדש ומתחיל סנכרון מלא: סנכרון אחרון מציג מסנכרן כעת... עד שהוא מסתיים. הגדרות ההסכמה שלכם בעמוד החנות ב-Joryio נשמרות גם אחרי ניתוק וחיבור מחדש.

הגדרות התוסף נשמרות גם אחרי Save Changes ועדכוני תוסף. לפני גרסה 1.6.19, Save Changes מחק גם את מפתח ה-API: אם עמוד ההגדרות מציין שלא שמור מפתח API, לחצו Disconnect והתחברו שוב עם המפתח. מגרסה 1.6.21, כל עמוד ניהול מציג הודעה כל עוד לא שמור מפתח API.

מטמון עמודים

סקריפט המעקב זהה בכל עמוד ואינו מכיל דבר על המבקר - לא אימייל, לא מזהה סשן ולא מזהה משתמש - כך שמטמון עמודים יכול לשמור אותו. מי מחובר נבדק על ידי הסקריפט עצמו, בבקשה שלעולם לא נשמרת במטמון. עמוד שנשמר במטמון לפני החיבור אינו כולל את סקריפט Joryio: התוסף מרוקן את המטמון של תוספי המטמון הנפוצים (Breeze, WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, SiteGround Optimizer) בחיבור, בניתוק, בשינוי הגדרות המעקב ובעדכון התוסף. עם כל מטמון אחר - מטמון השרת של ספק האחסון, Varnish או CDN - רוקנו אותו בעצמכם אחרי החיבור.

פתרון בעיות

"Cannot redeclare joryio()" בעת ההפעלה

עותק ישן של התוסף עדיין מותקן (לרוב בתיקייה בשם woocommerce-plugin). בתוספים, השביתו ומחקו כל רשומה של Joryio, ואז העלו שוב את התוסף מלוח הבקרה של Joryio. מגרסה 1.2.1 עותק שני מציג הודעה במקום לעצור את WordPress.

החיבור נכשל או מציג "Malformed identifier"

ודאו ש-Server URL הוא https://api-eu1.joryio.com ושמפתח ה-API מתחיל ב-jry_wc_. אם זה עדיין נכשל, פנו לתמיכה של Joryio וציינו את השעה שבה לחצתם על Connect.

החיבור מודיע שהכותרת Authorization מוסרת

Joryio קוראת את החנות באמצעות מפתח ה-REST API שהתוסף יוצר, שנשלח בכותרת Authorization. שרתים מסוימים - לרוב Apache שמריץ PHP כ-CGI או FastCGI - או תוסף אבטחה מסירים את הכותרת הזו לפני ש-WordPress רואה אותה, ו-WooCommerce עונה כאילו לא נשלח מפתח. הוסיפו את השורות הבאות ל-.htaccess בתיקיית השורש של WordPress, מעל בלוק ה-WordPress:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

אחר כך לחצו שוב על Connect. מגרסה 1.6.5 של התוסף, חיבור שנדחה מוחק את מפתח ה-REST API שנוצר עבורו, כך שלא נשאר מפתח שאינו בשימוש ב-WooCommerce → Settings → Advanced → REST API, והתוסף מציג את הסיבה ש-Joryio מוסרת.

התוסף לא מתחבר

• ודאו שמפתח ה-API נכון (מתחיל ב-jry_wc_)
• בדקו של-WordPress יש גישת HTTPS יוצאת
• ודאו שנקודת הקצה של ה-API נגישה

שגיאות WooCommerce API

• ודאו שהמפתח Joryio Integration עדיין קיים תחת WooCommerce ← הגדרות ← מתקדם ← REST API; אם נמחק, לחצו שוב על Connect כדי ליצור מפתח חדש
• בדקו שלמשתמש ה-API יש הרשאות קריאה/כתיבה
• ודאו שלאתר יש SSL (HTTPS)

מעקב עגלה לא עובד

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

מוצרים/הזמנות לא מסתנכרנים

• בדקו שהסנכרון מופעל בלשונית הגדרות
• נסו לבצע סנכרון ידני באמצעות כפתור "סנכרן הכל"
• ודאו ש-WooCommerce REST API מופעל
• webhook ש-WooCommerce השבית אחרי כשלי שליחה מופיע כ-Disabled תחת WooCommerce > Settings > Advanced > Webhooks. מוצרים ממשיכים להגיע דרך התוסף, וגם הזמנות ולקוחות נשלחים מהתוסף. החזירו אותו ל-Active כדי ששתי הדרכים יפעלו

תוספי מטמון ואופטימיזציה

• מטמון דפים אינו משפיע על המעקב: שום דבר על המבקר אינו נשמר בדף השמור. אחרי הוספה התוסף מגדיר עוגייה קטנה בשם joryio_pending והסקריפט אוסף את ההוספה דרך admin-ajax.php, לכן אל תשמרו את admin-ajax.php במטמון (תוספי מטמון משאירים אותו בשקט כברירת מחדל) ואל תסירו את העוגייה הזו
• דף שמור במטמון שומר את כתובת השרת (Server URL) ואת מפתח ה-SDK שהיו כשנשמר. אחרי שינוי כתובת השרת או חיבור מחדש, נקו את מטמון הדפים כדי שהדפדפנים של המבקרים ישלחו לכתובת החדשה. תוסף Content Security Policy יכול להוסיף את ה-nonce שלו לסקריפט המעקב (תוסף 1.6.7 ואילך, WordPress 5.7 ואילך)
• אסור לשמור את דף ה-checkout במטמון (WooCommerce ותוספי המטמון מחריגים אותו כברירת מחדל), אחרת Checkout Started לא יישלח
• אפשרות "Delay JavaScript" או "טעינת JavaScript באינטראקציה" מעכבת את סקריפט המעקב עד שהמבקר גולל או לוחץ, כך שמבקר שעוזב מיד אינו נספר. החריגו מהאפשרות הזו את הסקריפט של Joryio (הוא מכיל joryio)