اكتشفوا أفضل مصادر زيارات WooCommerce بدون GA4

أكثر لحظة مؤلمة في WooCommerce ليست السلة المهجورة. إنها الرسالة من صديق يدير إعلانات مدفوعة يسأل: «لماذا يقول Facebook إن لديّ 15 مبيعة اليوم بينما لوحة Woo تعرض ثلاثاً؟»

تلك الفجوة هي السبب الأكثر شيوعاً الذي يجعل مالك WooCommerce فردياً يثبّت GA4 أصلاً — والسبب الأكثر شيوعاً لإلغاء تثبيته بعد ثلاثة أشهر. كان من المفترض أن يكون GA4 مصدر الحقيقة. ثم توقّف عن رؤية مستخدمي Safari. ثم أكلت لافتة Cookies نصف البيانات. ثم أكل ITP نافذة الـ 7 أيام. ثم كسر iOS 17 معرّفات النقرة.

إن كنتم تبيعون على WooCommerce كملّاك فرديين، فلستم بحاجة لنموذج نسب سادس. أنتم بحاجة لمعرفة أي القنوات ترسل زواراً مؤهلين وأيها تهدر المال. هذا المنشور يمشي عبر تجميع القنوات الثماني، قاعدة صحة القناة، مصفوفة قرار Scale / Fix / Maintain / Cut، والإجابة الصادقة على «لماذا يُظهر Klaviyo 86 ألف دولار فيما لا يرى Woo سوى 24 ألفاً؟»

ماذا يجيب هذا المنشور

• كيف يجمّع Statnive تلقائياً زيارات WooCommerce في 8 قنوات (ولماذا يتفوق ذلك على الـ 24 لـ GA4).
• قاعدة صحة القناة المُثبَتة والتحفظات الثلاثة التي يخطئ فيها كل مالك فردي.
• مصفوفة القرار ذات الإجراءات الأربعة (Scale / Fix / Maintain / Cut) للحملات المدفوعة.
• لماذا يختلف Klaviyo وWooCommerce على إيرادات البريد — وأيهما تثقون به.
• ما يضيفه WooCommerce Revenue Report v1.0.0 إلى حلقة جودة القناة هذه.

القنوات الثماني التي يجمّعها لكم Statnive

تجميع القنوات الافتراضي في GA4 أصبح الآن 24 فئة. تجميع Statnive هو 8، بالتصميم — ثمانية هو العدد الذي يستطيع مالك فردي الاحتفاظ به في الذاكرة العاملة أثناء مسح تقرير أسبوعي.

القناة	ما يقع هنا	المقابل في GA4
Direct	بلا محيل + بلا UTM	Direct
AI Assistants	ChatGPT وClaude وGemini وPerplexity وCopilot وYou.com (15 مضيفاً)	يقسم بين Direct + Organic
Organic Search	Google وBing وDuckDuckGo وYandex وBaidu وBrave (27 مضيفاً)	Organic Search
Social Media	Facebook وInstagram وTikTok وX وLinkedIn وReddit وPinterest، بالإضافة إلى مختصرات الروابط (35 مضيفاً)	Organic Social
Email	UTM medium يحتوي email أو المحيل مضيف بريد ويب	Email
Referral	أي محيل آخر خارج الموقع	Referral
Paid Search	UTM medium يطابق `^(.cp.	ppc
Paid Social	نفس regex والمصدر شبكة اجتماعية	Paid Social

دلو AI Assistants هو الذي لم يبنه أحد آخر في تقرير افتراضي بعد. لا يزال GA4 يوجّه gemini.google.com إلى Organic Search وchatgpt.com إلى Direct. لمتجر Woo، هذا هو الفرق بين معرفة أن بحث الذكاء الاصطناعي قناة حقيقية وافتراض أن زياراتكم انخفضت.

قاعدة صحة القناة (مع ثلاث تحفظات لا يذكرها أحد)

قاعدة القرار، في جملة واحدة: القناة صحية إذا كانت ارتداداتها عند متوسط الموقع أو أقل ومدة جلستها عند متوسط الموقع أو أعلى، مع 50 جلسة على الأقل في نافذة 7 أيام.

هذا صحيح. لكن كل مدونة CRO تتوقف هنا وتورّطكم. التحفظات الثلاثة:

التحفظ 1 — قارنوا مع مجموعة مطابقة في القصد، لا مع متوسط الموقع

منشور مدونة يلبّي استعلام بحث يرتدّ بنسبة 70 إلى 90٪ والزائر يغادر سعيداً. صفحة هبوط مدفوعة ترتدّ بنسبة 60٪ في النار. حسب تحليل Siege Media لـ 1.3 مليار جلسة، النطاق الصحي لـ «زيارات المحتوى الإعلامي» هو 65 إلى 90٪؛ النطاق الصحي لـ «صفحات الهبوط المعاملاتية» هو 25 إلى 45٪. متوسط الموقع هو متوسط هذين التوزيعين وهو بالتالي خاطئ لكليهما.

الإصلاح: طبّقوا القاعدة ضمن مجموعة قصد منفردة. قارنوا ارتداد كل صفحة هبوط مدفوعة بمتوسط صفحات هبوط مدفوعة أخرى — لا بالمدونة. قارنوا ارتداد كل منشور مدونة بمنشورات مدونة أخرى.

التحفظ 2 — اطلبوا ≥50 جلسة في نافذة 7 أيام قبل تطبيق القاعدة

بأقل من 50 جلسة، معدل الارتداد ضجيج إحصائي. حسب إرشادات منهجية اختبار CXL، تريدون عند الحد الأدنى مئات الجلسات قبل استخلاص استنتاجات على مستوى القناة. الخمسون هي الأرضية حيث يمكنكم اكتشاف مشاكل اتجاهية؛ عاملوا أي شيء أدنى كـ «لا توجد إشارة كافية بعد، استمروا في المراقبة».

التحفظ 3 — أُطّروا القاعدة بـ «أول للتشخيص» لا «أول للإيقاف»

الفخ هو إيقاف الحملات لحظة فشلها في القاعدة. القرار الصحيح هو تشخيصها أولاً. القناة التي تفشل في نصفي القاعدة عادةً لديها واحدة من أربع مشاكل قابلة للإصلاح:

1. صفحة هبوط خاطئة. الإعلان يرسل إلى /shop، الرسالة كانت عن منتج محدد.
2. جمهور خاطئ. انجرفت Lookalike Audience. استُنفدت Custom Audience.
3. UTM مكسور. أعاد مدير الحملة بناء الرابط وأسقط utm_medium. الآن في Direct.
4. عدم تطابق منتج-سوق حقيقي. المجموعة فعلاً لا تريد ما وعد به الإعلان.

أوقفوا فقط بعد أن يعود التشخيص نظيفاً لـ نافذتين متتاليتين.

مصفوفة القرار ذات الإجراءات الأربعة: Scale / Fix / Maintain / Cut

خذوا كل من قنواتكم الثماني وأجيبوا عن سؤالين عن كل منها:

• اتجاه الحجم (آخر 28 يوماً): صاعد، مسطح، أم هابط؟
• الجودة (قاعدة صحة القناة أعلاه): ينجح في النصفين، نصف فقط، أم يفشل في النصفين؟

هذا يمنحكم شبكة 3×3. اطووها إلى أربعة إجراءات:

الاتجاه × الجودة	الإجراء
صاعد + ناجح	Scale — زيدوا الميزانية 20 إلى 25٪، أعيدوا الفحص بعد 7 أيام
صاعد + يفشل في نصف	Fix — شخّصوا أي نصف، اختبروا A/B صفحة الهبوط أو الإبداع الإعلاني
مسطح + ناجح	Maintain — اتركوه؛ لا تفرطوا في تحسين قناة عاملة
هابط + فاشل	Cut — أوقفوا بعد تشخيص لنافذتين، أعيدوا تخصيص الميزانية

هذه هي المصفوفة للطباعة والتثبيت على شاشتكم. تطوي لوحة نسب GA4 ذات الـ 30 تبويباً إلى قرار واحد لكل قناة لكل أسبوع.

لماذا يقول Klaviyo 86 ألف دولار وWoo يقول 24 ألفاً

إن كنتم تشغّلون البريد عبر Klaviyo، سترَون هذا. لوحة Klaviyo تدّعي 86 ألف دولار من «الإيرادات المنسوبة إلى Klaviyo» الشهر الماضي. Woo Reports → Orders لديكم تُظهر 24 ألف دولار من إجمالي الإيرادات. ماذا يجري؟

تأثيران متراكمان:

1. Klaviyo يستخدم نافذة نسب بعد النقر مدتها 5 أيام. أي طلب يُوضع خلال 5 أيام من أي نقرة بريد — بما في ذلك نقرة من تدفق الترحيب الأسبوع الماضي — يُنسب إلى أحدث بريد. لوحة Woo لديكم تسجّل نفس الطلب مرة واحدة، مع أي مصدر آخر نقرة كان فعلاً (غالباً بحث Google عن اسم العلامة بعد أن ذكّرهم البريد).
2. Apple Mail Privacy Protection يجلب مسبقاً كل بريد. هذا يُحسب كـ «فتحة» في Klaviyo حتى عندما لا يفتح المستلم رسالتكم. سلسلة «فُتح → نُقر → اشترى» تُضخَّم 2 إلى 4× حين تكون بيانات الفتح مزيفة.

كلا التأثيرين يجعلان Klaviyo يبدو أفضل 2 إلى 4× من مصدر حقيقة Woo — ولا أحد من الجانبين يكذب. Klaviyo يبلّغ صحيحاً عن «هذا الطلب حدث خلال 5 أيام من ملامسة شخص ما لبريد». Woo يبلّغ صحيحاً عن «آخر نقرة لهذا الطلب كانت من بحث العلامة بعد البريد». هما يجيبان عن أسئلة مختلفة.

التصالح الصادق لمالك فردي:

• لـ حقيقة إيراداتكم، استخدموا سجل طلبات Woo. دائماً. هو الرقم الوحيد الذي تقبله السلطات الضريبية.
• لـ عائد استثمار برنامج البريد، استخدموا رقم Klaviyo مع التحفظ: «هذا الحد الأعلى بافتراض أن نافذتنا ذات الـ 5 أيام تلتقط آخر نقرة صحيحة».
• لـ قرارات تخصيص القنوات، استخدموا تقرير Statnive Referrers ذو حبيبية الجلسة — يُظهر لكم أي القنوات ترسل زواراً مؤهلين أصلاً، قبل أي حجة نافذة نسب. بيانات الزيارة غير ملوثة بنافذة Klaviyo أو بفقدان Cookies في GA4.

إجابة المؤسسة هي نشر Conversions API من جانب الخادم وخياطة طبقة BigQuery. إجابة Woo الفردي: توقفوا عن الجدل حول أي منصة «صحيحة» واستخدموا كل واحدة لما هي صادقة بشأنه.

كيف يبدو WooCommerce Order Attribution + Statnive معاً

منذ WooCommerce 8.5 (يناير 2024)، كل طلب Woo يحمل _wc_order_attribution_* post meta — مصدر أول لمسة، مبني على Cookies، مع غطاء نافذة 7 أيام على Safari (حد Apple ITP). إنه عدسة إيرادات أول لمسة مفيدة.

Statnive لا يتداخل مع هذا. Statnive ذو حبيبية الجلسة (كل زيارة، لا الطلبات فقط)، بلا Cookies (بلا غطاء Safari 7 أيام)، وحالياً لا يرى الإيرادات. الاثنان معاً يغطيان الصورة:

• تقرير Statnive Referrers يجيب: من أين تأتي الـ 99٪ من زياراتي التي لم تشترِ هذا الأسبوع؟
• WooCommerce Order Attribution يجيب: من الـ 1٪ التي اشترت، ما مصدر أول لمسة لكل طلب؟

فعّلوا الاثنين. اقرأوهما في أيام مختلفة لقرارات مختلفة. Order Attribution يقود تخصيص الميزانية حين تكون لديكم بيانات إيرادات؛ Statnive يقود قرار جودة القناة لمجمع الزيارات الأكبر بكثير الذي لم يحوّل أبداً.

ما يضيفه Revenue Report v1.0.0

اعتباراً من v1.0.0 (مايو 2026)، Statnive Revenue Report يشحن الأمرين اللذين لم تستطع حلقة جودة القناة وحدها تغطيتهما:

1. الإيرادات لكل قناة داخل Statnive. جدول «Revenue by Channel» في Revenue Report يعرض Orders وRevenue (net) وAOV عبر القنوات الثماني نفسها الموصوفة أعلاه — Direct وAI Assistants وOrganic Search وSocial Media وEmail وReferral وPaid Search وPaid Social. تستطيعون الإجابة عن «Paid Search جلب 4200 دولار الأسبوع الماضي» دون مغادرة Statnive.
2. انخفاض مرحلة السلة. Cart-to-Purchase Funnel يقرأ أربعة أحداث من جانب الخادم من WooCommerce — wc_product_view → wc_add_to_cart → wc_checkout_start → wc_purchase — ويعرض معدل التحويل لكل خطوة. ترَون أين يسقط Paid Social بين السلة والدفع، لا فقط أنهم يخرجون في مكان ما بعد صفحة السلة.

كلاهما شُحن مجاناً، على WordPress.org، في v1.0.0. الطلبات التاريخية تُملأ تلقائياً أول مرة تفتحون فيها Revenue Report — بلا إعداد مطلوب.

حلقة جودة القناة في هذا المنشور لا تزال تقود جانب الزيارات من القرار (أي القنوات تستحق إنفاقاً إعلانياً أكثر)، وتؤلّف الآن مع Revenue Report لـ جانب الشراء (أي القنوات تحوّل فعلاً وبأي AOV). شغّلوا الاثنين جنباً إلى جنب: قناة يمكن أن تفشل في قاعدة الارتداد+المدة لكنها تحوّل جيداً، أو تنجح في القاعدة وتحوّل سيئاً. على أي حال، لديكم الآن البيانات.

ما تفعلونه بعد ذلك

1. ثبّتوا Statnive على WordPress.org إن لم تكونوا قد فعلتم.
2. افتحوا تقرير Referrers. حدّدوا عدد جلسات قنواتكم الثماني لـ 7 أيام.
3. لكل قناة بـ ≥50 جلسة، احسبوا ارتدادها ومدتها مقابل مجموعتها المطابقة في القصد.
4. ضعوا كل قناة على شبكة 3×3 الاتجاه × الجودة؛ اطووا إلى Scale / Fix / Maintain / Cut.
5. شغّلوا التشخيص على مرشحي «Cut» لنافذتين إضافيتين قبل الإيقاف.
6. اقرأوا الركيزة حول التحليلات التي تحترم الخصوصية لـ WooCommerce CRO للحلقة الأسبوعية الكاملة التي يندرج فيها هذا.

هذا هو سير العمل. عشر دقائق أسبوعياً. بلا GA4. بلا Looker. بلا «مكدّس نمو تجارة DTC». فقط متجركم، ثماني قنوات، مصفوفة واحدة، وانضباط التشخيص قبل الإيقاف.