ازاي تقيس الاعلانات الاوفلاين: الطريقتين الرسميتين بالحدود

أكتر سؤال بييجي من حسابات بتبيع في فرع أو على التليفون: إحنا بنصرف على إعلانات وبنبيع أوفلاين، فإزاي نعرف الإعلان جاب كام؟ والسؤال ده له إجابة أوضح مما بيتقال، بس الإجابة مش في الـAPI. هي في سجل المبيعات عندك.

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

مسار ميتا: أحداث المتجر عن طريق Conversions API

ميتا بتوصف المسار ده في توثيق Offline Events via Conversions API، والأرقام اللي جواه هي اللي بتقرر هل ده قابل للتطبيق عندك ولا لأ:

• الحدث لازم يكون action_source قيمته physical_store، ودي اللي بتفرق معاملة الفرع عن حدث الويب.
• التوثيق بيقول بالنص إن «event_time يقدر يكون لحد ٧ أيام قبل ما تبعت الحدث لميتا».
• وللأحداث الأوفلاين والمتجر بـphysical_store، «المفروض ترفع المعاملات في خلال ٦٢ يوم من التحويل».
• قيمة الشراء والعملة مطلوبين لأحداث الشراء، مش اختياريين.

ومنع التكرار هنا بيشتغل بمفاتيح مختلفة عن الويب: dataset_id و event_time و event_name و item_number، زائد مفتاح إما order_id أو معاملات بيانات العميل. لو بترفع نفس المعاملة من مصدرين بمعرّفات مختلفة، انت مش بتقيس، انت بتعد مرتين. وأساس منع التكرار وحدوده متغطي في شرح Conversions API.

خد بالك من نافذة الـ٦٢ يوم تحديداً، لأنها بتقرر تصميم عملية الرفع عندك. لو الفرع بيسلّم كشف مبيعات كل شهرين، فأنت على الحد. ولو بيسلّمه كل ربع سنة، فأنت بتفوّت جزء من معاملاتك قبل أي كلام عن دقة.

مسار جوجل: رفع تحويلات على مستوى الكليك

على جوجل، الفكرة إنك بتخزّن معرّف الكليك مع بيانات العميل وقت ما بيسيب رقمه أو بيدخل الفرع، وبعدين بترفع التحويل لما يحصل. التوثيق في صفحة Upload click conversions في Google Ads API، وأهم شرط فيه بيبان بسيط وبيوقع أغلب الناس:

• وقت التحويل لازم يكون معاه منطقة زمنية محددة، بصيغة yyyy-mm-dd HH:mm:ss+|-HH:mm. مش تاريخ بس.
• وفيه أنواع تحويلات لها قيود أضيق بكتير على النافذة. في تحويلات العمولة لإعلانات الفنادق مثلاً، التوثيق بيقول إنك تقدر ترفع تحويلات لكليكات حصلت في نفس الشهر بس، وإن اللي بيترفع بعد الرابعة صباحاً بتوقيت الباسيفيك في أول يوم من الشهر اللي بعده بيتجاهل.

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

السبب اللي بيخلي أغلب المحاولات تفشل قبل الـAPI

في كل حالة شفتها، المشكلة مكانتش في التكامل. كانت في إن سجل المبيعات الأوفلاين مفيهوش الحاجات اللي المطابقة محتاجاها. الأعراض دايماً واحدة:

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

ولو ده هو مكانك حالياً، الجزء التقني منه مشروح بشكل عملي في نوتة عند rivl عن الانتقال من ملفات الإكسل لقاعدة بيانات من غير ما تخسر التاريخ. النوتة بالإنجليزي، وموجهة لحد بيقرر يبني ولا يشتري، مش لميديا باير.

ترتيب التنفيذ اللي بيوصل لنتيجة

لو هتعمله، اعمله بالترتيب ده بالظبط. أي ترتيب تاني بيخلّي المشكلة تظهر متأخر:

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

ولو التتبع الأساسي عندك مش مظبوط من الأساس، فالأوفلاين مش أولوية، لأن الأخطاء بتتراكم. الأخطاء الشائعة في الإعداد الأساسي متغطية في ازاي تظبط Conversions API صح، ولو بتفكر تنقل التتبع للسيرفر فالتكلفة الحقيقية في شرح Server Side Tracking.

والبيع اللي بيحصل على التليفون؟

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

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

• سجّل معرّف المكالمة ووقتها بمنطقة زمنية، زي أي حدث تاني.
• اربط المعرّف ده بالبيعة لما تحصل، حتى لو بعدها بأسبوعين، ما دام جوه النافذة.
• متعتبرش المكالمة نفسها تحويل لو انت بتحسب عائد. المكالمة مؤشر نية، والفلوس بتيجي من البيعة.
• لو معظم مكالماتك مش بتتحول لبيع، فالمشكلة في العرض أو في جودة الجمهور، والقياس هيوريلك ده بوضوح لأول مرة.

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

حدود صريحة: ده بينسب، مش بيثبت

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

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

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

وحد تاني: نسبة المطابقة عندك هتكون أقل من الويب، دايماً. بيانات الفرع أقل نظافة من بيانات الشيك آوت، وده طبيعي مش عيب في إعدادك. فلو استنيت نسبة مطابقة زي الويب، هتفضل تدوّر على غلط مش موجود.

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