WordPress

في تكامل WordPress لا يكفي إرسال كل ما يتاح من بيانات. نحدد أولًا النتائج التجارية المطلوبة، ثم نختار الأحداث الملائمة، مثل: form submission, qualified contact request, newsletter signup, and meaningful page engagement. هذه أمثلة للمتطلبات التي ينبغي مراجعتها وليست وعدًا بأن كل حدث مدعوم تلقائيًا. نحدد مع العميل مصدر الحدث وصلاحيات استخدامه ونقطة تسجيله الصحيحة قبل بناء أي خريطة إرسال.

الحقول التي نراجع ملاءمتها بحسب طبيعة الحالة تشمل: form ID, landing URL, event timestamp, consent state, and a stable anonymous event ID. لا نجمع هذه الحقول كلها بالضرورة؛ نستخدم الحد الأدنى المسموح به فقط، ونمنع انتقال المعلومات الحساسة إلى منصات غير مناسبة. الأهم هو ثبات المعرّفات وتطابق القيمة والزمن مع السجل الأصلي حتى تكون المقارنة عادلة.

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

نضع قائمة مراجعة للحقول الخاصة بالمصدر: form ID, landing URL, event timestamp, consent state, and a stable anonymous event ID. لكل حقل نحدد النوع المتوقع والقيمة الافتراضية ومصدر الحقيقة وطريقة التأكد من سلامته. إذا تغيّر الاسم أو صيغة القيمة في النظام المصدر، ينبغي أن يظهر فشل واضح في الاختبار بدل إرسال نتائج لا يمكن الوثوق بها.

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

بعد التشغيل، نحدد مسؤولًا عن مراقبة الأرقام وأسباب الأخطاء. تشمل قائمة المراجعة: a cached form resubmitting the same lead, consent not available at submission time, and inconsistent event naming. عند ظهور اختلاف، نبدأ برقم الحدث أو السجل الأصلي، ثم نفحص توقيت الإرسال وحالة الاستجابة، ونوثق أي تغيير في خرائط البيانات قبل إعادة الاختبار.