أرسل إلى iPaper المنتجات التي تستحق الظهور.

iPaper منصة دنماركية للكتالوجات الرقمية والكتب الورقية التفاعلية (flipbooks)، يستخدمها تجار التجزئة والسوبرماركت وسلاسل أدوات الصيانة المنزلية (DIY) لتحويل بيانات المنتجات وكتيبات PDF إلى كتالوجات إلكترونية تفاعلية ومتوافقة مع الجوال. ويقوم المنتج على مسارَي نشر أساسيين: Flipbooks التي تحوّل كتالوجات PDF الحالية إلى تجارب رقمية بتقليب الصفحات، وHorizon الذي ينشئ صفحات بنمط الكتالوج مباشرة من خلاصة المنتجات دون مرحلة تصميم PDF. وتستخدم علامات تجارية في قطاع التجزئة مثل JYSK وBricomarche وConforama و10-4 منصة iPaper للحفاظ على العروض الموسمية والكتيبات الأسبوعية وكتالوجات الحملات قابلة للتسوق ومحدّثة باستمرار.

في كلا المسارين، تُعدّ بيانات المنتجات ما يحوّل الصفحة الثابتة إلى صفحة قابلة للتسوق: إذ تقرأ Enrichment Automation من iPaper خلاصة المنتجات أو الملف وتضع نقاطًا تفاعلية قابلة للنقر فوق العناصر المطابقة في الكتالوج، بحيث يستطيع المتسوقون عرض الأسعار والخيارات والصور أو إضافة المنتجات مباشرة إلى سلة الشراء.

تشير بيانات الحالات الخاصة بـ iPaper (نقلًا عن تاجر التجزئة الدنماركي لأدوات DIY، 10-4) إلى زيادة بنسبة 72.5% في مدة البقاء في المتجر الإلكتروني بعد زيارة الكتالوج، و87.0% صفحات إضافية مشاهَدة عبر الكتالوجات الرقمية، وقيمة سلة أعلى بنسبة 5.1% لزوار الكتالوج. وتعتمد هذه الأرقام على دقة بيانات المنتجات الأساسية، لأن أي عدم تطابق في السعر أو المخزون أو الصور يُفسد مباشرة تجربة التسوق داخل الـ flipbook.

1. لا تعمل النقاط التفاعلية ونوافذ المنتجات المنبثقة إلا عندما يتطابق Product ID/SKU في الخلاصة مع المعرّف المضمَّن في ملف PDF أو القالب، وتحافظ الخلاصة الحية على هذا التطابق محدَّثًا مع تغيّر الكتالوج.
2. تُنشأ الكتالوجات المعتمدة على الخلاصة بنمط Horizon مباشرة من الخلاصة، لذا فإن البيانات الناقصة أو غير السليمة تحدّ من التخطيطات وبطاقات المنتجات التي تستطيع iPaper بناءها تلقائيًا.
3. حقول السعر والمخزون التي تتغير كثيرًا (العروض الترويجية، نفاد الكمية) يُفضَّل تزويدها عبر خلاصة بدلًا من ملف ثابت لمرة واحدة، لأن iPaper تتعامل مع الخلاصات والملفات الثابتة بوصفها نموذجين مختلفين لحداثة البيانات.
4. يمكن لخلاصة واحدة سليمة البنية أن تخدم محرك النقاط التفاعلية في Enrichment Automation وميزتَي Shop Checkout/Shop Export معًا، مما يغني عن إدخال البيانات يدويًا مرتين.

تُعدّ Enrichment Automation من iPaper الآلية التي تربط خلاصتكم فعليًا بصفحة الكتالوج. فعند معالجة ملف PDF، تستخرج iPaper كل النصوص والروابط التشعبية والبيانات الوصفية وموضع كل كلمة على الصفحة. ثم تبحث عن معرّفات المنتجات (Product IDs) المضمَّنة في الملف، سواء كانت نصًا مرئيًا أو نصًا مخفيًا أو طبقة مخصصة أو تعليقًا في Acrobat، وتطابق كل واحد منها مع حقل Product ID/SKU في ملف البيانات أو الخلاصة لديكم. وعند العثور على تطابق، تنشئ iPaper تلقائيًا الإثراء (رابط متجر، أو رابط خارجي، أو إطار منبثق، أو معرض صور، أو بطاقة Product View) وتضعه في موضع تلك الكلمة.

يتم دعم أسلوبَين للمطابقة: مطابقة المعرّفات المضمَّنة في PDF مع خلاصتكم، أو (عند التكامل عبر JavaScript) استخدام تعبير نمطي (regular expression) لاستخراج المعرّفات مباشرة من نص PDF، مثل مطابقة نمط رقمي من 6 إلى 10 خانات، عندما لا توجد طبقة معرّفات منفصلة. وتوضح iPaper أن معرّفات المنتجات يمكن أن تحتوي على مسافات عند الضرورة، لكن يجب ألا تتضمن فواصل أسطر أبدًا، وألا تتداخل مع نص آخر على الصفحة، لأن أيًّا منهما سيُفسد المطابقة.

تقبل Enrichment Automation من iPaper أربعة أنواع من مصادر البيانات: .xml و.csv و.json وخلاصة Google Merchant. ويمكن تقديم كل منها إما كملف بيانات ثابت (لقطة لمرة واحدة، مناسبة عندما لا تتغير معلومات المنتجات خلال فترة نشاط الكتالوج)، أو كخلاصة ديناميكية (رابط مباشر، يُستخدم عندما تتغير الأسعار أو المخزون أو حقول أخرى خلال عمر الـ flipbook).

1. يجب أن تكون البيانات مسطّحة (flat) لا متداخلة، إذ تنص إرشادات iPaper على أن البنية المسطحة هي ما يتيح لـ Enrichment Automation قراءة الملف بشكل صحيح.
2. افتراضيًا، تبحث الأتمتة عن أسماء الرؤوس/الأعمدة ابتداءً من الصف 1 في ورقة العمل الأولى، ما لم يتم تحديد صف أو ورقة مختلفة صراحةً.
3. يجب أن تبقى أسماء الرؤوس/الأعمدة متسقة بين التحديثات، فقد تتعطل أتمتة كانت تعمل سابقًا إذا تغيّر اسم أحد الرؤوس.
4. يجب أن تستخدم روابط الخلاصة نطاقًا مخصصًا موثَّقًا، وبروتوكول HTTPS، وترميز روابط متوافقًا مع RFC 2396/RFC 1738.
5. ينبغي أن يستخدم كل محتوى الخلاصة أحرف Unicode صالحة.

لا تشترط iPaper بصرامة سوى حقل واحد لإتمام المطابقة، وهو Product ID/SKU فريد وثابت، لكن الخلاصة الأغنى تتيح أنواعًا أكثر من الإثراء (بطاقات Product View، ومعارض الصور، ونوافذ المتجر المنبثقة). وإذا قدّمتم البيانات عبر خيار خلاصة Google Merchant، فإن iPaper تتوقع أسماء سمات Google Merchant Center القياسية الموضحة أدناه؛ أما في خلاصات CSV/XML/JSON المخصصة، فتقبل iPaper أسماء الأعمدة التي تختارونها ما دامت متسقة بين التحديثات.

كما توصي iPaper بالحفاظ على Product ID نفسه للمنتج نفسه في جميع البلدان واللغات، بحيث يمكن إعادة استخدام إعداد أتمتة واحد عبر جميع النسخ المحلية من الكتالوج.

لا تنشر iPaper تطبيقًا مخصصًا لـ Feedance ولا تكاملًا شريكًا بنقرة واحدة، بل تستقبل بيانات المنتجات عبر خاصية رفع الملفات/الخلاصات العامة في Enrichment Automation، التي تقبل ملفًا ثابتًا مرفوعًا أو رابط خلاصة مباشرة. ويتمثل دور Feedance في ضمان أن البيانات الواصلة إلى مرحلة الرفع تلك تطابق مسبقًا ما تتوقعه Enrichment Automation، لكي يسير الإعداد من جهة iPaper بسلاسة.

1. في Feedance، اربطوا بيانات المنتجات المصدرية (من نظام PIM أو منصة التجارة الإلكترونية أو جدول بيانات) ببنية مسطحة وغير متداخلة، دون مصفوفات متداخلة أو كائنات فرعية، وفق متطلب iPaper للبيانات المسطحة.
2. اختاروا صيغة إخراج تقبلها iPaper: CSV أو XML أو JSON، أو خلاصة متوافقة مع Google Merchant Center إذا رغبتم في إعادة استخدام أسماء الحقول القياسية مثل id وtitle وprice.
3. تأكدوا من أن كل صف منتج يحمل Product ID/SKU الفريد نفسه الذي تستخدمونه (أو تخططون لتضمينه) في ملف PDF، وحافظوا على ثبات هذا المعرّف عبر اللغات ونسخ البلدان.
4. انشروا الخلاصة من Feedance كرابط HTTPS ثابت بترميز متوافق مع RFC، ثم الصقوا هذا الرابط في إعداد مصدر بيانات Enrichment Automation في iPaper كخلاصة (وليس كملف ثابت) إذا كانت أسعاركم أو مخزونكم تتغير خلال عمر الكتالوج.
5. شغّلوا أول تمريرة أتمتة على ملف PDF تجريبي أو تخطيط Horizon للتأكد من أن أسماء الرؤوس وعمود Product ID تُقرأ بشكل صحيح قبل الانتقال إلى كتالوج كامل.

تدعم iPaper وتيرتَي تحديث لمصادر بيانات Enrichment Automation:

1. عند الطلب: تُنشأ الخلاصة من جديد في كل مرة يحمّل فيها زائر رابط الكتالوج. ويُبقي ذلك البيانات سريعة التغير مثل السعر والمخزون محدَّثة قدر الإمكان، لكن iPaper تشير إلى أنه قد يؤثر في سرعة تحميل الصفحة.
2. وفق جدول زمني: تُعاد إنشاء الخلاصة على فترات محددة، مثل مرتين يوميًا. ويضحّي ذلك بقدر يسير من الحداثة مقابل سرعة تحميل أعلى للكتالوج.

وتنصح إرشادات iPaper باختيار الوتيرة التي تتوافق مع مدى تغيّر البيانات الأساسية فعليًا: استخدموا خلاصة حية بتحديثات منتظمة للأسعار الترويجية والحملات الحساسة للمخزون، وملفًا ثابتًا لمرة واحدة للكتالوجات التي تبقى بيانات منتجاتها ثابتة طوال فترة الحملة.

هذه نقاط الإخفاق الموثَّقة في دليل استكشاف الأخطاء الخاص بـ iPaper لـ Enrichment Automation، ويعود معظمها إلى الخلاصة لا إلى ملف PDF:

1. «Custom Link Import produced no links»: إشعار الفشل الرئيسي عندما لا تتمكن Enrichment Automation من إنشاء أي إثراء من تشغيلة معالجة.
2. معرّفات منتجات غير متطابقة: إذا لم يطابق المعرّف في PDF تمامًا أحد المعرّفات في الخلاصة، فلن يحصل ذلك المنتج ببساطة على إثراء.
3. أسماء رؤوس غير متسقة: قد تبدأ خلاصة كانت تعمل سابقًا بالفشل إذا أُعيدت تسمية أحد رؤوس الأعمدة بين التحديثات؛ وتوصي iPaper صراحةً بفحص أسماء الرؤوس أولًا عندما تفشل أتمتة كانت تعمل فجأة.
4. صف الرؤوس أو ورقة العمل في المكان الخطأ: افتراضيًا تبحث الأتمتة عن الرؤوس في الصف 1 من ورقة العمل الأولى فقط؛ وتحتاج البيانات الموضوعة في مكان آخر إلى تحديدها في إعدادات الأتمتة.
5. بنى بيانات متداخلة: قد تمنع الخلاصة ذات الحقول المتداخلة بدل البنية المسطحة الأتمتة من قراءتها بشكل صحيح.
6. نص PDF غير قابل للتحديد: إذا كان ملف PDF صورة ممسوحة ضوئيًا لا نصًا أصليًا، فلا تستطيع الأتمتة العثور على معرّفات لمطابقتها مع الخلاصة إطلاقًا، مهما كانت جودة الخلاصة.
7. عدم تطابق اسم طبقة المعرّفات المخفية: عندما تكون معرّفات المنتجات في طبقة PDF مخفية، يجب أن يطابق اسم الطبقة تمامًا ما هو محدد في إعداد الأتمتة.
8. إصدار PDF غير مدعوم: تدعم iPaper إصدار PDF 1.7 وما دونه، ويوصى بالإصدار 1.5 لأفضل توافق.

ممارسات عامة مثلى، ليست مستمدة من وثيقة خاصة بـ iPaper، للحفاظ على سلامة خلاصة موجَّهة إلى iPaper:

1. أبقوا Product ID/SKU متطابقًا في خلاصتكم ووسوم PDF وأي قناة أخرى (المتجر الإلكتروني، الأسواق الإلكترونية)، حتى لا يتعين تسوية أي تغيير في المعرّف عبر الأنظمة.
2. افصلوا الحقول سريعة التغير (السعر، المخزون) عن الحقول الثابتة (الاسم، الوصف، الصور) في منطق التحديث لديكم، وحدّثوا الحقول سريعة التغير على فترة أقصر ضمن مسار الخلاصة.
3. تحقّقوا من خلاصتكم وفق قائمة فحص للبنية المسطحة والترميز قبل كل نشر، فالكائنات المتداخلة والأحرف غير المتوافقة مع Unicode من الأسباب الشائعة لإخفاقات الاستيراد الصامتة.
4. أضيفوا إصدارًا أو ختمًا زمنيًا لتصديرات الخلاصة لتتمكنوا من معرفة سريعة ما إذا كان فشل الإثراء ناتجًا عن بيانات قديمة أم عن عدم تطابق حقيقي.
5. احتفظوا بكتالوج أو ملف PDF تجريبي صغير مرتبط بخلاصتكم، لكي تُكتشف تغييرات أسماء الرؤوس أو البنية قبل وصولها إلى كتالوج حي موجَّه للعملاء.

ما صيغ الملفات التي تقبلها iPaper لبيانات المنتجات؟
XML وCSV وJSON وخلاصة Google Merchant، تُقدَّم إما كملف ثابت لمرة واحدة أو كخلاصة حية محدَّثة بانتظام.

هل يجب أن تستخدم خلاصتي أسماء حقول Google Merchant Center؟
فقط إذا اخترتم خيار صيغة «Google Merchant feed» في iPaper. أما في خلاصات CSV أو XML أو JSON المخصصة، فتقرأ iPaper أي أسماء أعمدة/رؤوس تستخدمونها، ما دامت متسقة بين التحديثات.

ما الحقل الوحيد الذي تحتاج إليه iPaper حتمًا؟
Product ID/SKU فريد يظهر أيضًا في ملف PDF (كنص مرئي أو نص مخفي أو طبقة أو تعليق)، لأن هذا المعرّف هو ما تستخدمه Enrichment Automation لمطابقة صفوف الخلاصة مع صفحات الكتالوج.

هل تستطيع iPaper قراءة JSON أو XML المتداخل؟
لا، فوثائق iPaper تطلب صراحةً بنية بيانات مسطحة وغير متداخلة لكي تتمكن Enrichment Automation من تحليلها.

هل أستخدم ملفًا ثابتًا أم خلاصة حية؟
استخدموا ملفًا ثابتًا عندما لا تتغير بيانات منتجاتكم طوال عمر الكتالوج، واستخدموا خلاصة حية عندما تتغير الأسعار أو المخزون خلال تلك الفترة.

كانت الأتمتة لدي تعمل والآن لا تنتج أي روابط، فما الذي تغيّر؟
يشير دليل استكشاف الأخطاء في iPaper أولًا إلى اتساق أسماء الرؤوس ومطابقة Product ID، ثم إلى ملف PDF نفسه (نص ممسوح ضوئيًا/غير قابل للتحديد، أو اسم طبقة مخفية خاطئ، أو إصدار PDF غير مدعوم أعلى من 1.7).

iPaper منصة تقدّم حلول النشر الرقمي للشركات لإنشاء كتالوجات وكتيبات ومجلات ومنشورات رقمية تفاعلية عبر الإنترنت. وتتيح للشركات تحويل ملفات PDF الحالية بسهولة إلى منشورات رقمية يمكن تحسينها لتناسب مختلف الأجهزة وتضمينها في المواقع الإلكترونية.

تأسست iPaper عام 2006، ما يجعلها لاعبًا راسخًا في قطاع النشر الرقمي. وتهدف إلى مساعدة الشركات على الانتقال من الوسائط المطبوعة التقليدية إلى المنشورات الرقمية، بما يمكّنها من الوصول إلى جمهور أوسع وتحسين تجربة المستخدم.

نشأت منصة iPaper في الدنمارك، فهي ثمرة الابتكار الدنماركي. وتشتهر الدنمارك بتركيزها القوي على التكنولوجيا والتصميم، وتعكس iPaper هذه القيم من خلال منصة سهلة الاستخدام وجذابة بصريًا.

توفر منصة iPaper مجموعة من الميزات لتعزيز تجربة النشر الرقمي. فهي تتيح للمستخدمين تخصيص مظهر منشوراتهم وتخطيطها، بما في ذلك إضافة عناصر تفاعلية مثل مقاطع الفيديو والروابط التشعبية والرسوم المتحركة. وهذا يضمن أن تكون المنشورات جذابة وتفاعلية، وأن تمنح القرّاء تجربة أكثر انغماسًا.

كما توفر iPaper أدوات تحليلات قوية تتيح للشركات فهم سلوك جمهورها وتفاعله مع المنشورات. وتساعد هذه البيانات الشركات على اتخاذ قرارات مدروسة وتحسين منشوراتها الرقمية للحصول على نتائج أفضل.

وقد صُممت المنصة أيضًا لتكون سهلة الاستخدام، إذ لا تتطلب أي برمجة أو مهارات تقنية لإنشاء ونشر منشورات رقمية بمظهر احترافي. وتوفر محررًا يعتمد السحب والإفلات، ما يسهّل تخصيص المحتوى وإنشاءه.

علاوة على ذلك، تضمن iPaper أن تكون المنشورات الرقمية متجاوبة ومتوافقة مع مختلف الأجهزة وأحجام الشاشات. وهذا يتيح للمستخدمين الاطلاع على المنشورات والاستمتاع بها عبر مختلف الهواتف الذكية والأجهزة اللوحية وأجهزة سطح المكتب.

بفضل تصميمها سهل الاستخدام وميزاتها القوية وتركيزها على تقديم تجربة نشر رقمي سلسة، اكتسبت iPaper اعترافًا وشعبية بين الشركات في مختلف القطاعات. وقد أصبحت منصة موثوقة لإنشاء المنشورات الرقمية وتوزيعها في أنحاء العالم.

خلاصة القول، iPaper منصة نشر رقمي ذات أصل دنماركي تأسست عام 2006. وهي توفر للشركات أدوات لتحويل ملفات PDF إلى منشورات رقمية تفاعلية ومتجاوبة، تعزز تجربة المستخدم وتتيح الوصول إلى جمهور أوسع. وبفضل مجموعة ميزاتها وواجهتها سهلة الاستخدام، أصبحت iPaper المنصة المفضلة للشركات الراغبة في الانتقال من الوسائط المطبوعة التقليدية إلى النشر الرقمي.