ليش تابي وتمارا يخلون قنواتك المدفوعة تبان ضعيفة

العميل ضغط إعلان سناب، دخل متجرك، طلع لتابي يكمّل الدفع، ورجع. والطلب انكتب «مباشر».

ولو نسبة كبيرة من عملائك يدفعون بالتقسيط، هالنقطة وحدها تخلي كل قناة مدفوعة في حسابك تبان أضعف من واقعها.

وش يصير في اللحظة اللي يطلع فيها العميل

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

النظام يعتبر الجلسة الأولى خلصت، ويبدأ جلسة جديدة. والطلب يلتصق بالجديدة، فينحسب لآخر مصدر ظاهر بدل المصدر الحقيقي.

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

كيف يبان الخلل على لوحتك

• خانة «مباشر» تكبر شهر بعد شهر وأنت ما زدت شي في السيو ولا في البحث باسم متجرك
• القنوات المدفوعة تبان أضعف من واقعها، وأكثر ما يتضرر المنتجات اللي أغلب دفعها تقسيط
• توقف حملة شغالة، وينزل إجمالي المبيعات بعدها بأسبوعين، وما أحد يربط بين الاثنين

والعلامة الفارقة هي الارتباط: كل ما زادت نسبة الدفع بالتقسيط في متجرك، كبرت الفجوة.

وخانة «مباشر» ما هي قناة أصلًا. هي المكان اللي تنحط فيه كل زيارة ما عرف النظام يسميها. وهذا يهم لأنها السطر الوحيد في تقريرك اللي ما تقدر تتصرف عليه. ما تقدر تصرف على «مباشر»، ولا تحسّنها، ولا تعطي الوكالة بريف عنها. فكبرها ما يشوّه الأرقام بس، ينقل ميزانيتك لعمود ما فيه قرار ممكن.

مثال بأرقام افتراضية

متجر عليه 480 طلب في الشهر، و60% منها دفعها تقسيط، يعني 288 طلب تمر ببوابة خارجية.

قبل ما تعامل البوابات كنقطة عبور:

• 288 طلب مصدرها «مباشر» أو اسم البوابة
• زائد 72 طلب مباشر حقيقي
• المجموع 360 طلب بلا مصدر معروف، يعني 75% من الشهر

وبعدها الـ288 يرجعون لمصادرهم. ولنقل إنهم 150 سناب و90 ميتا و48 جوجل.

وش يسوي هذا في قرار ميزانية واحد، بأخذ سناب ومتوسط طلب 200 ر.س:

أرقام افتراضية للتوضيح، الغرض منها تقدير حجم القرار مو وصف متجر حقيقي.

ما تغيّر شي في الحملة. اللي تغيّر هو مكان كتابة الطلب.

تعامل بوابات الدفع كنقطة عبور

والمبدأ يتعدى الدفع: أي وجهة يمر منها العميل ويرجع منها تتعامل كنقطة عبور، مو كمصدر جديد.

ولما تطبّقها صح، نطاقات البوابات تتصنّف كخطوة مرور. الجلسة تفضل منسوبة لمصدرها الأصلي، والعميل يرجع لنفس الرحلة بدل ما يبدأ وحدة جديدة. وفلوفاي يغطي تابي وتمارا وPayPal وStripe وmyshopify كنقاط عبور.

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

كيف تتأكد إنها تصير عندك

1. شوف نسبة «مباشر» عندك في آخر ستة أشهر. هل تكبر؟
2. قارنها بنسبة الدفع بالتقسيط في نفس الفترة.
3. اسأل: هل السيو والبحث باسم المتجر والبريد كبروا فعلًا بما يفسّر الزيادة؟

لو «مباشر» صاعدة، والطلب على علامتك ثابت، والتقسيط يرتفع، فأنت غالبًا تشوف فقد إسناد عند البوابة مو حركة مباشرة حقيقية.

أسئلة تتكرر

تتأثر بطاقات الدفع كمان؟ أي تحويل خارج الموقع ورجوع منه يقدر يكسر الجلسة، وفيها تحقق 3-D Secure. ومزودو التقسيط هم الحالة الأكثر شيوعًا في السوق.

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

بياناتي القديمة تتصحح؟ لا. الإسناد ينطبق مع وصول الطلبات، والطلبات القديمة تبقى بمصدرها. وهذا سبب إضافي تصلحها قبل الموسم مو بعده.

تشتغل نفس الشي على زد؟ نعم. الانكسار في تحويلة الدفع، مو في منصة المتجر.

قبل ما تنقل ميزانية