شوبيفاي

في تكامل Shopify لا يكفي إرسال كل ما يتاح من بيانات. نحدد أولًا النتائج التجارية المطلوبة، ثم نختار الأحداث الملائمة، مثل: product view, checkout completion, confirmed purchase, and eligible refunds. هذه أمثلة للمتطلبات التي ينبغي مراجعتها وليست وعدًا بأن كل حدث مدعوم تلقائيًا. نحدد مع العميل مصدر الحدث وصلاحيات استخدامه ونقطة تسجيله الصحيحة قبل بناء أي خريطة إرسال.

الحقول التي نراجع ملاءمتها بحسب طبيعة الحالة تشمل: checkout or order reference, item IDs, final amount, currency, event timestamp and consent context. لا نجمع هذه الحقول كلها بالضرورة؛ نستخدم الحد الأدنى المسموح به فقط، ونمنع انتقال المعلومات الحساسة إلى منصات غير مناسبة. الأهم هو ثبات المعرّفات وتطابق القيمة والزمن مع السجل الأصلي حتى تكون المقارنة عادلة.

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

نضع قائمة مراجعة للحقول الخاصة بالمصدر: checkout or order reference, item IDs, final amount, currency, event timestamp and consent context. لكل حقل نحدد النوع المتوقع والقيمة الافتراضية ومصدر الحقيقة وطريقة التأكد من سلامته. إذا تغيّر الاسم أو صيغة القيمة في النظام المصدر، ينبغي أن يظهر فشل واضح في الاختبار بدل إرسال نتائج لا يمكن الوثوق بها.

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

بعد التشغيل، نحدد مسؤولًا عن مراقبة الأرقام وأسباب الأخطاء. تشمل قائمة المراجعة: checkout versus order event duplication, privacy settings, app permissions and inconsistent refunds. عند ظهور اختلاف، نبدأ برقم الحدث أو السجل الأصلي، ثم نفحص توقيت الإرسال وحالة الاستجابة، ونوثق أي تغيير في خرائط البيانات قبل إعادة الاختبار.