زد

في تكامل Zid لا يكفي إرسال كل ما يتاح من بيانات. نحدد أولًا النتائج التجارية المطلوبة، ثم نختار الأحداث الملائمة، مثل: storefront product visit, checkout progress, completed order, and return. هذه أمثلة للمتطلبات التي ينبغي مراجعتها وليست وعدًا بأن كل حدث مدعوم تلقائيًا. نحدد مع العميل مصدر الحدث وصلاحيات استخدامه ونقطة تسجيله الصحيحة قبل بناء أي خريطة إرسال.

الحقول التي نراجع ملاءمتها بحسب طبيعة الحالة تشمل: order reference, item quantity, currency, discount-adjusted value, status and consent flag. لا نجمع هذه الحقول كلها بالضرورة؛ نستخدم الحد الأدنى المسموح به فقط، ونمنع انتقال المعلومات الحساسة إلى منصات غير مناسبة. الأهم هو ثبات المعرّفات وتطابق القيمة والزمن مع السجل الأصلي حتى تكون المقارنة عادلة.

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

نضع قائمة مراجعة للحقول الخاصة بالمصدر: order reference, item quantity, currency, discount-adjusted value, status and consent flag. لكل حقل نحدد النوع المتوقع والقيمة الافتراضية ومصدر الحقيقة وطريقة التأكد من سلامته. إذا تغيّر الاسم أو صيغة القيمة في النظام المصدر، ينبغي أن يظهر فشل واضح في الاختبار بدل إرسال نتائج لا يمكن الوثوق بها.

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

بعد التشغيل، نحدد مسؤولًا عن مراقبة الأرقام وأسباب الأخطاء. تشمل قائمة المراجعة: event retries, pending payments, canceled purchases and differences between order and payment totals. عند ظهور اختلاف، نبدأ برقم الحدث أو السجل الأصلي، ثم نفحص توقيت الإرسال وحالة الاستجابة، ونوثق أي تغيير في خرائط البيانات قبل إعادة الاختبار.