الطلبات
تجيب صفحة الطلبات عن السؤال الذي لا تجيب عنه إلا Joryio: أي رسالة أنتجت كل طلب. إنها تشغيلية لا تحليلية: اعثر على طلب، وتحقق من حالته، وانظر إسناده. يعيش تحليل الإيرادات في نظرة عامة على التجارة الإلكترونية؛ وتدير تنفيذ الطلبات (الشحن والمبالغ المستردة) في متجرك.
كل رقم صافي بعد المبالغ المستردة.
الصفحة
- الرأس - العنوان ومنتقي نطاق زمني (الإعدادات المسبقة نفسها المستخدمة عبر التحليلات)، وتصدير CSV.
- علامات تبويب الحالة - كل الطلبات / مدفوع / معلق / مسترد، مع أعداد.
- شريط الأدوات - البحث (رقم الطلب أو اسم العميل أو Email)، والمصدر، والعميل، والإسناد، والفرز.
- الجدول - صف واحد لكل طلب؛ ويفتح الصف لوحة التفاصيل.
- ترقيم الصفحات - من جهة الخادم؛ تُحمّل الصفحة صفحة واحدة في كل مرة.
علامات تبويب الحالة
تستخدم الصفحة عرضًا موجهًا للدفع للحالة: يملك المتجر التنفيذ، لذلك يُقرأ الطلب المشحون أو المُسلّم هنا بوصفه مدفوعًا بمجرد أن يُبلغ المتجر بأنه دُفع (راجع مدفوع أو بانتظار الدفع):
| علامة التبويب | تتضمن |
|---|---|
| مدفوعة | استُلم الدفع (قيد المعالجة أو مشحون أو مُسلّم) |
| معلقة | لم تُدفع بعد: الطلبات المعلقة، والطلبات بانتظار الدفع (قيد المعالجة أو مشحونة أو مُسلّمة، لكن المتجر لم يستلم الدفع - الدفع عند الاستلام مثلًا) |
| مستردة | مستردة كليًا أو جزئيًا |
مدفوع أو بانتظار الدفع
تقول حالة الطلب أين هو (قيد المعالجة، مشحون، مُسلّم)؛ أما هل دُفع فهي معلومة منفصلة تُقرأ مما يسجّله كل متجر. الطلب قيد المعالجة أو المشحون أو المُسلّم الذي لم يستلم المتجر دفعه يظهر بشارة كهرمانية بانتظار الدفع ويُحتسب ضمن معلقة، ولا يُحتسب أبدًا ضمن مدفوعة:
| المتجر | مدفوع عندما |
|---|---|
| WooCommerce | يكون الطلب Completed، أو دُفع عبر بوابة دفع. طلب الدفع عند الاستلام (Cash on delivery)، أو الطلب المُنشأ في لوحة الإدارة دون طريقة دفع، يبقى بانتظار الدفع حتى تجعله Completed - يسجّل WooCommerce تاريخ دفع لكل طلب يصل إلى Processing، لذلك لا يُقرأ هذا التاريخ وحده على أنه دفع. تنتظر طلبات التحويل البنكي والشيك في On hold (معلقة) حتى تنقلها إلى Processing، وهذا ما يجعلها مدفوعة |
| Shopify | حالة دفع الطلب Paid (أو Refunded / Partially refunded). أما Pending وAuthorized وPartially paid وVoided وExpired فليست مدفوعة |
| Magento | دُفعت فواتير الطلب (يبلغ المبلغ المدفوع إجمالي الطلب)، أو الطلب Complete أو Closed. الطلب الذي نقله Magento إلى Processing لأنه شُحن قبل إصدار فاتورته يبقى بانتظار الدفع |
| PrestaShop | الحالة الحالية للطلب مُعلَّم عليها "Set the order as paid" |
| واجهة Orders API | ترسل paymentStatus: unpaid (أو paid). ومن دونه يُحتسب الطلب قيد المعالجة أو المشحون أو المُسلّم مدفوعًا |
لا تتأثر الإيرادات: تحتسب الإيرادات والإسناد كل طلب غير ملغى وغير مسترد، مدفوعًا كان أم لا، كما في السابق.
تعرض الطلبات المستلمة قبل هذا التغيير ما كانت تقوله حالتها حتى يرسل المتجر الطلب مرة أخرى (أي تحديث، أو مطابقة المتجر، أو مزامنة الآن في التكامل). تحمل طلبات Shopify حالة دفعها بالفعل وتعرضها فورًا. يحتاج WooCommerce إلى الإضافة 1.6.20 أو أحدث لكي تحملها الأحداث المباشرة (تحملها مزامنة REST وwebhooks مع أي إصدار)؛ ويحتاج Magento إلى الامتداد 1.4.20 أو أحدث (تحملها مزامنة الطلبات مع أي إصدار).
فلاتر شريط الأدوات
| الفلتر | الخيارات |
|---|---|
| البحث | رقم الطلب أو اسم العميل أو Email |
| منسوب إلى | الكل / الحملات فقط / الرحلات فقط / غير منسوب |
| العميل | الكل / أول مرة / متكرر |
| الإسناد عبر | الكل / رمز قسيمة / النقر المباشر فقط / نقرة مساعدة / فُتح فقط |
| المتجر | كل المتاجر، أو متجر واحد (انظر المتجر وقناة البيع) |
| القناة | كل القنوات / عبر الإنترنت / نقطة بيع / تطبيق / هاتف وطلبات يدوية / سوق إلكتروني / أخرى |
| الفرز | الأحدث / الأعلى قيمة / الأقل قيمة |
أعمدة الجدول
| العمود | الوصف |
|---|---|
| الطلب | رقم طلبك |
| التاريخ | وقت تقديمه |
| العميل | الاسم + شارة أول/متكرر + Email |
| العناصر | أول عنصر + «+N أخرى - N وحدات» |
| الإجمالي | إجمالي الطلب، وتحتها «-$x مسترد» (مشطوب عند الاسترداد الكامل) |
| منسوب إلى | الحملة/الرحلة + القناة + كيفية اكتساب الإسناد |
| المتجر والقناة | المتجر الذي ينتمي إليه الطلب ومكان بيعه |
| الحالة | مدفوع / بانتظار الدفع / معلق / مسترد جزئيًا / مسترد |
الإسناد
تسجل Joryio لكل طلب أي حملة أو رحلة أنتجته وكيف اكتسب الإسناد ومتى:
| الطريقة | المعنى | القوة |
|---|---|---|
| النقر المباشر | نقر العميل رابط هذه الحملة واشترى (حتمي، في الجلسة نفسها) | قوي |
| نقرة مساعدة | نقر العميل رسالة ضمن النافذة قبل الشراء | قوي |
| فُتح فقط | فتح العميل ولم ينقر (يظهر باللون الكهرماني) | ضعيف |
| غير منسوب | لا تفاعل ضمن النافذة؛ ومع ذلك يحتسب ضمن إجمالي الإيرادات | - |
تعرض خانة «منسوب إلى» اسم الحملة/الرحلة وشريحة قناة (email/SMS/push/in-app/WhatsApp) وسطرًا مثل «نقر - قبل 3 ساعات» أو «فُتح فقط - قبل 41 ساعة».
النقر المباشر فقط
تثق بعض الفرق فقط في المشتريات التي نقر فيها العميل رابطًا واشترى (حتمية)، وتريد استبعاد الأثر ضمن النافذة/المساعد. استخدم فلتر الإسناد → النقر المباشر فقط لسرد تلك الطلبات بالضبط. يتوفر العرض نفسه كمفتاح في نظرة عامة على التجارة الإلكترونية وكقيمة مباشر في تحليلات الحملة.
لوحة التفاصيل
يعرض فتح طلب الإسناد أولًا (لماذا حصل على الإسناد أو لم يحصل)، ثم العميل، ثم عناصر السطر مع الإجمالي الفرعي والمبلغ المسترد وصافي الإيرادات. تُدار المبالغ المستردة والتنفيذ في متجرك، وتذكر اللوحة ذلك. يعرض الطلب الملغى صافي إيرادات 0 والرسالة ملغى - لا يُحتسب ضمن الإيرادات، مثل كل أرقام الإيرادات التي تستبعده.
سلة مستعادة
يحمل الطلب المقدَّم من سلة متروكة - من السلة نفسها أو من رابط استعادة لها؛ أما طلب جهة الاتصال من سلة جديدة فليس استعادة (راجع السلال) - وسم سلة مستعادة تحت "مُسند إلى"، وتُفتح لوحته بالسلة التي استعادها: لمن كانت (جهة اتصال أخرى، عندما أتم المشتري الشراء من رابط استعادة ببريد مختلف)، وقيمتها، ومتى تُركت، ورابط عرض السلة إلى السلال.
الاستعادة والإسناد منفصلان. تحدد الاستعادة السلة التي جاء منها الطلب؛ ويحدد "مُسند إلى" الرسالة التي تحصل على الفضل - في الاستعادة، الرسالة التي نُقر رابط الاستعادة فيها، حتى عندما يُتم المشتري الشراء ببريد آخر (راجع السلال). يكون الطلب المستعاد "غير مُسند" فقط عندما لا تُسجَّل أي نقرة على رسالة.
القسائم
تعرض اللوحة كل رمز قسيمة استُخدم في الطلب، مع الخصم الذي منحه كل رمز، وإجمالي خصم الطلب. تُحفظ كل الرموز، وليس الأول فقط:
| المتجر | الرموز | الخصم لكل رمز |
|---|---|---|
| WooCommerce | كل سطر قسيمة | نعم (دون الضريبة). تحمله طلبات الإضافة بدءًا من الإصدار 1.3.1؛ ترسل الإصدارات الأقدم الرموز فقط |
| Shopify | كل رمز خصم | نعم، مع نوعه (مبلغ ثابت، نسبة مئوية، شحن) |
| Magento | رمز قسيمة الطلب | لا - يُبلغ Magento عن خصم واحد لكل قواعد سلة الطلب، لذا تعرض اللوحة "لم يُبلغ المتجر عن المبلغ" وإجمالي خصم الطلب |
| Orders API | كل عنصر في coupons | عند إرسال amount |
تُطابَق الرموز دون تمييز بين الأحرف الكبيرة والصغيرة - SUMMER10 وsummer10 رمز واحد. أنشئ جمهورًا باستخدام فلاتر القسائم، أو ابدأ رحلة عند Order Completed حيث يحتوي coupon_codes على الرمز (راجع رموز القسائم في حدث الشراء).
المتجر وقناة البيع
يعرض كل طلب مكان بيعه - أي قناة البيع - والمتجر الذي ينتمي إليه، ليتمكن نشاط تجاري لديه متجر فعلي وموقع، أو متجران، من التمييز بين طلباتهما. صفِّ القائمة باستخدام المتجر والقناة؛ وتقسّم نظرة عامة على التجارة الإلكترونية الإيرادات بالطريقة نفسها، وتبني فلاتر المتجر والقناة جماهير منها.
| القناة | المعنى |
|---|---|
عبر الإنترنت (online) | موقعك أو الدفع عبر الويب - الافتراضي |
نقطة بيع (pos) | صندوق دفع في متجر فعلي |
تطبيق (app) | تطبيقك للهاتف المحمول |
هاتف وطلبات يدوية (phone) | أدخله الموظفون: هاتف أو بريد إلكتروني أو طلب يدوي أو مسودة |
سوق إلكتروني (marketplace) | سوق إلكتروني تابع لجهة خارجية |
أخرى (other) | أي شيء آخر |
المتجر المتصل هو متجر طلباته، والقناة مأخوذة مما تسجله المنصة: مصدر الطلب في Shopify (pos لـ Shopify POS، والمسودات وطلبات تطبيق الإدارة كهاتف)، وحقل "created via" في WooCommerce (طلبات لوحة الإدارة كهاتف، وإضافة نقطة البيع كنقطة بيع)، والطلبات المنشأة في لوحة إدارة Magento كهاتف. لا تسجل PrestaShop مكان إجراء الطلب، لذا تكون طلباتها عبر الإنترنت. تحمل الطلبات المرسلة عبر API قيم salesChannel وstoreId وstoreName التي ترسلها - انظر المتجر وقناة البيع في API.
تصدير CSV
ينزّل تصدير CSV الطلبات التي تعرضها الصفحة حاليًا - النطاق الزمني وعلامة التبويب والفلاتر والبحث والترتيب نفسها - عبر كل الصفحات، حتى 50,000 طلب (ضيّق النطاق الزمني للمزيد). يتضمن كل صف الطلب والعميل والمبالغ والخصم والإسناد وعمودين للقسائم: coupon_codes (SUMMER10; VIP) وcoupons الذي يضيف خصم كل رمز عند معرفته (SUMMER10 (10.00); VIP). يتطلب التصدير صلاحية التصدير (users:export)، لأن الملف يحتوي على عناوين Email للعملاء. تبيّن الأعمدة store وstore_id وsales_channel المتجر الذي ينتمي إليه الطلب ومكان بيعه (channel هو قناة الإسناد).
نماذج ونوافذ الإسناد
يمكن ضبط كيفية إسناد طلب:
- النموذج - آخر تفاعل (تتفوق النقرة على الفتح) أو آخر نقرة أو أول تفاعل. اضبط الافتراضي لمساحة العمل من الإعدادات → إسناد الإيرادات؛ ويمكن للحملة أو الرحلة تجاوزه في إعدادات التحويل.
- النافذة - مقدار زمن التفاعل السابق الذي يمكن أن يسبق الطلب. تستخدم كل حملة/رحلة نافذة التحويل الخاصة بها (7 أيام افتراضيًا).
- احتساب عمليات الفتح - ما إذا كانت عمليات الفتح (الأضعف والأكثر تشويشًا من النقرات) تمنح إسنادًا أصلًا. على مستوى مساحة العمل ومفعلة افتراضيًا.
يطبق تغيير الإعداد على الطلبات الجديدة فورًا ويعيد إسناد الطلبات الحالية في الخلفية. لمقارنة النماذج جنبًا إلى جنب (مثل آخر نقرة مقابل آخر تفاعل)، افتح التجارة الإلكترونية → نظرة عامة → مقارنة النماذج.
حقول الطلب
| الحقل | الوصف |
|---|---|
externalId | معرّف طلبك من منصة التجارة الإلكترونية |
userId | معرّف مستخدم Joryio للعميل |
status | حالة الطلب |
paymentStatus | paid أو unpaid كما أبلغ المتجر؛ فارغ عندما لم يُبلغ أي متجر (راجع مدفوع أو بانتظار الدفع) |
total | مبلغ الطلب النهائي |
subtotal | المبلغ قبل الخصومات |
totalRefunded | المبلغ المسترد حتى الآن (يخصم من الإيرادات) |
items | مصفوفة عناصر السطر |
coupons | كل رموز القسائم في الطلب: code وamount (الخصم الذي منحه الرمز، عندما يُبلغ عنه المتجر) وtype. لا يزال couponCode يحمل الرمز الأول |
placedAt | طابع الطلب الزمني |
campaignId / canvasId | علامة الإسناد الحتمية (النقر المباشر) |
source, utmSource, utmMedium, utmCampaign | علامات القناة / UTM |
salesChannel, storeId | مكان بيع الطلب (online أو pos أو app أو phone أو marketplace أو other) والمتجر الذي ينتمي إليه - انظر المتجر وقناة البيع |
تحمل عناصر السطر معرّف المنتج واسمه والكمية والسعر وSKU/الصيغة وعنوان URL للصورة.
استخدام الطلبات في الحملات
رسائل Email تأكيد الطلب
<h1>Thank You for Your Order!</h1>
<p>Order #{{ order.id }}</p>
{% for item in order.items %}
<div class="item">
<img src="{{ item.imageUrl }}" />
<p>{{ item.name }} x {{ item.quantity }}</p>
<p>${{ item.price }}</p>
</div>
{% endfor %}
<p>Total: ${{ order.total }}</p>
تدفقات ما بعد الشراء
أنشئ تدفقات Canvas تشغّلها أحداث الطلب: تأكيد الطلب ومتابعة التسليم وطلب المراجعة والتجديد.
أحداث الطلب
| الحدث | المشغّل |
|---|---|
ecommerce.order.created | تقديم طلب جديد |
ecommerce.order.fulfilled | شحن الطلب |
ecommerce.order.cancelled | إلغاء الطلب |
ecommerce.order.refunded | معالجة الاسترداد |
ecommerce.order.status_changed | أي تغير حالة |
خصائص Order Completed
إلى جانب الطلب نفسه (orderId، total، currency، itemCount، coupon_codes، source)، يحمل كل حدث Order Completed السلة التي جاء منها الطلب وطريقة وصول المتسوق، لتستخدمها في فلتر شريحة أو في شرط رحلة:
| الخاصية | النوع | القيمة |
|---|---|---|
cartRef | نص | مرجع المتجر للسلة التي قُدّم منها الطلب (في Magento quote_33، جلسة WooCommerce، معرّف سلة PrestaShop، رمز checkout في Shopify) - هو نفس cartRef الذي حمله Cart Abandoned لتلك السلة. فقط عندما يرسله المتجر. |
recoveredCart | صح / خطأ | true عندما استعاد الطلب سلة متروكة - القرار نفسه الذي تعرضه علامة سلة مستعادة. الطلب من سلة جديدة قيمته false. |
recoveredVia | نص | في الاستعادة فقط. recovery_link: رابط استعادة أعاد تلك السلة. same_cart: أُكمل الدفع للسلة المتروكة نفسها. contact_cart: لم يحمل الطلب مرجع سلة (طلبات Orders API و SDK و webhook في WooCommerce)، فاحتُسبت السلة المتروكة لجهة الاتصال نفسها. reported: الطلب POST /carts/recovered ذكر هذا الطلب. |
utm_source، utm_medium، utm_campaign، utm_term، utm_content | نص | معاملات UTM للزيارة التي جاء منها الطلب، عندما يبلّغ عنها المتجر (يرسل Shopify القيم source و medium و campaign). |
campaign_id، canvas_id | نص | حملة Joryio أو رحلتها التي وصل المتسوق من رابطها، عندما حمل الرابط ذلك. |
sales_channel، store_id | نص | مكان بيع الطلب، ومتجره عندما يكون له متجر (انظر المتجر وقناة البيع). sales_channel موجود دائمًا. |
الخاصية التي لم يرسلها المتجر تُترك خارج الحدث، ولا تُرسل فارغة أبدًا. يُكتب الحدث بعد أن يحدد Joryio السلة التي أغلقها الطلب، لذلك ترى الرحلة التي تبدأ بـ Order Completed هذه القيم مباشرة. لكل طلب حدث Order Completed واحد بالضبط، يُكتب في أول مرة يستلم فيها Joryio الطلب، بوقت إنشاء الطلب: التحديث اللاحق للطلب نفسه (تغيير الحالة أو الإلغاء أو الاسترداد) لا يكتب حدثًا آخر أبدًا ولا يبدأ الرحلة مرة ثانية أبدًا.
مثال: رحلة تبدأ بـ Order Completed مع الشرط recoveredCart يساوي true يمكنها شكر متسوق عاد إلى سلته.
المبالغ المستردة
تتزامن حالة الاسترداد والمبلغ المسترد من Shopify وWooCommerce (ويمكن لتكامل مخصص إرساله عبر totalRefunded في Orders API). كل رقم إيرادات في الصفحة، وفي الإسناد أيضًا، صافي بعد المبالغ المستردة: يقلل الاسترداد الجزئي صافي إيراد الطلب، ولا يضيف الطلب المسترد بالكامل شيئًا إلى إسناد حملته.
أحداث الاسترداد والإلغاء
يحوّل كل متجر متصل وواجهة Orders API كل استرداد جديد أو إلغاء إلى حدث يمكنك أن تبدأ عليه رحلة أو تبني عليه شريحة:
| الحدث | متى | الخصائص الرئيسية |
|---|---|---|
Order Refunded | مرة واحدة لكل استرداد، كامل أو جزئي | order_id، total (المبلغ الذي أعاده هذا الاسترداد، بعملة الطلب)، total_base (بعملتك الأساسية)، currency، refund_type (full أو partial)، refund_amount (مثل total)، refund_id، reason، products (البنود المستردة، عندما يذكرها المتجر)، coupon_codes, sales_channel, store_id |
Order Cancelled | مرة واحدة لكل طلب | order_id، total، currency، reason، cancelled_at، coupon_codes, sales_channel, store_id |
مرة واحدة، أيًا كان طريق وصوله. يُبلغ المتجر عن الاسترداد نفسه أكثر من مرة - إعادة إرسال webhook، أو الإضافة وwebhook معًا، أو مزامنة تُعاد. يقارن Joryio كل تحديث للطلب بالطلب كما كان محفوظًا: لا يُنشئ حدثًا إلا استرداد لم يُحتسب بعد، ويُتجاهل التحديث الأقدم من الطلب المحفوظ. لكل حدث معرّف ثابت (معرّف الاسترداد لدى المتجر حين يوفره)، فتدخل الرحلة مرة واحدة لكل استرداد.
| المصدر | الاسترداد | الإلغاء |
|---|---|---|
| Shopify | كل استرداد، بمعرّفه وتاريخه وملاحظته والبنود المستردة | cancelled_at، مع سبب الإلغاء من Shopify |
| WooCommerce | كل معرّف استرداد في الطلب (بتاريخ آخر تحديث للطلب)؛ وتُحتسب الحالة refunded من الإضافة استردادًا كاملًا | الحالة cancelled (وأيضًا الدفع الفاشل، أو طلب حُذف في WooCommerce) |
| Magento | كل زيادة في المبلغ المسترد للطلب، تلتقطها مزامنة الطلبات؛ وتُحتسب الحالة closed (يرسلها الامتداد فورًا) استردادًا كاملًا | الحالة canceled |
| واجهة Orders API | refunds في الطلب (حدث واحد لكل id)، أو totalRefunded، أو الحالة refunded، أو POST /orders/:id/refund | الحالة cancelled، أو POST /orders/:id/cancel |
الطلبات السابقة. تسجل أول مزامنة للمتجر استردادات الطلبات السابقة وإلغاءاتها في سجل الأحداث بتاريخها الخاص (إذا كان خلال آخر سنتين؛ ويُتخطى الأقدم)، تمامًا كما تسجل Order Completed لها. ومثلها، لا تبدأ أي رحلة أبدًا: التغييرات التي تصل مباشرة فقط هي التي تبدأ الرحلات.
لا يُخفض الإيراد مرتين. تقارير الإيراد والإسناد وRFM تخصم الاستردادات من الطلب نفسه أصلًا، وتستبعد الطلبات الملغاة والمستردة بالكامل. Order Refunded وOrder Cancelled ليسا إيرادًا: لا يطرحهما أي تقرير.
إذا كنت ترسل الطلبات من SDK أيضًا، فلا تستدعِ orderRefunded / orderCancelled في أدوات التتبع لطلبات يرسلها متجر أو واجهة Orders API بالفعل - وإلا سُجل كل استرداد مرتين.