كل ما قيود التتبع بتزيد، بيرجع نفس الاقتراح: حوّل للتتبع من السيرفر. الاقتراح صح في حالات، وبيتباع في حالات تانية على إنه حل لمشكلة هو أصلاً مش بيحلها.
المقالة دي عن التلات أسئلة اللي بتقرر: هو بيعمل ايه بالظبط، بيكلف كام فعلاً، وايه اللي مش هيتغير مهما ظبطته.
هو ايه بالظبط، من غير تسويق
في التتبع العادي، الكود بيشتغل في متصفح المستخدم وبيبعت البيانات مباشرة للمنصات. في التتبع من السيرفر، المتصفح بيبعت لسيرفر انت بتشغله، والسيرفر ده هو اللي بيبعت للمنصات.
جوجل بتوصف الفكرة في توثيق Server-side tagging بإنها طريقة لقياس نشاط المستخدم في أي مكان بيحصل فيه، وبتذكر تلات مكاسب: تحسين أداء الصفحة، وضوابط خصوصية أدق، وجودة بيانات أعلى.
الترتيب ده مهم. تحسين أداء الصفحة أول واحد لأنه المكسب المضمون: أكواد أقل في المتصفح يعني تحميل أسرع. جودة البيانات آخر واحد لأنها الأكثر اعتماداً على إعدادك انت.
التكلفة الحقيقية، بأرقام جوجل مش بتقديري
ده الجزء اللي بيتقال بسرعة في العروض، وهو الجزء اللي بيقرر هل ده مناسب لحسابك ولا لأ.
جوجل بتدي تلات طرق للتشغيل: Cloud Run، وApp Engine، وإعداد يدوي على منصة من اختيارك. وفي دليل إعداد Cloud Run في أرقام صريحة.
- جوجل بتوصي بتشغيل حد أدنى instance اتنين «عشان تقلل خطر فقدان البيانات لو حصل عطل في السيرفر».
- كل سيرفر بيكلف حوالي ٤٥ دولار في الشهر، وده instance بـvCPU واحد و٠.٥ جيجا رام على نموذج تسعير CPU always allocated.
- التوقع إن ٢ لـ١٠ سيرفرات بالتوسع التلقائي هيستحملوا ٣٥ لـ٣٥٠ طلب في الثانية، والأداء بيختلف حسب عدد الأكواد وايه اللي بتعمله.
اضرب الرقمين الأولانيين: الحد الأدنى اللي جوجل نفسها بتوصي بيه هو حوالي ٩٠ دولار في الشهر، قبل أي دومين فرعي أو شهادة أو وقت تنفيذ أو صيانة. ده رقم صغير لحساب بيصرف عشرات الآلاف، وهو رقم كبير جداً لمتجر بيصرف ألف دولار في الشهر.
والنقطة التانية اللي بتتنسي: ده مصروف شهري مستمر مش تكلفة إعداد. أي مقارنة بتحسب تكلفة التنفيذ وبتسيب الـ٩٠ دولار دي بره الحسبة مقارنة ناقصة. الموضوع ده من ناحية التكلفة التشغيلية عموماً مشروح كويس عند rivl في تكلفة تشغيل تطبيق ويب شهرياً، وهي بالإنجليزي.
الفرق بينه وبين Conversions API
ده أكتر خلط بشوفه، والاتنين مش نفس الحاجة ولا بديل لبعض.
Conversions API هو مسار لإرسال أحداث لمنصة واحدة من السيرفر. التتبع من السيرفر هو بنية تحتية بتستقبل الأحداث وبتوزعها على أكتر من وجهة. تقدر تشغل CAPI من غير سيرفر بتاعك خالص، وتقدر تشغل سيرفر وتبعت منه لـCAPI وجوجل وتيك توك في نفس الوقت.
لو انت محتاج تحسن جودة أحداث منصة واحدة بس، CAPI أرخص وأسرع وكفاية. شرحت الفرق والحدود بالتفصيل في شرح Conversions API: الفرق الحقيقي وحدود التكرار، والمقالة دي بتتكلم عن الطبقة اللي فوقه مش عنه.
| السؤال | Conversions API | Server Side Tracking |
|---|---|---|
| بيخدم كام منصة | منصة واحدة لكل تكامل | أكتر من وجهة من نفس المصدر |
| محتاج سيرفر بتاعك | لأ | أيوه، وده أصل التكلفة |
| التكلفة الشهرية | صفر تقريباً | حوالي ٩٠ دولار حد أدنى بتوصية جوجل |
| بيحسن سرعة الصفحة | مش بشكل مباشر | أيوه، أكواد أقل في المتصفح |
| بيرجع بيانات مرفوضة الموافقة | لأ | لأ |
اللي مش بيحله، وده الجزء المهم
التتبع من السيرفر مش بيتجاوز الموافقة. لو المستخدم رفض التتبع، رفضه بيتطبق على السيرفر زي ما بيتطبق على المتصفح، والعكس ده مش تحايل تقني ده مخالفة.
ومش بيرجع البيانات اللي ضاعت من قيود المنصات نفسها. لو المنصة قررت تقلل التفاصيل المتاحة، القرار ده على مستواها مش على مستوى إزاي البيانات وصلتها.
ومش بيصلح قياس مكسور من الأساس. لو أحداث التحويل عندك متعرفة غلط، أو بتحسب نفس الحدث مرتين، السيرفر هيبعت نفس الغلط بكفاءة أعلى. ده بالظبط اللي بيخلي حسابات تدفع ٩٠ دولار شهرياً عشان تشوف نفس البيانات المغلوطة بشكل أسرع.
واللي بيشتغل فعلاً بعد قيود الخصوصية، من الناحية التكتيكية مش التقنية، كتبته في الريتارجيتنج بعد قيود الخصوصية.
إمتى يستاهل فعلاً
تلات حالات، ولو مفيش واحدة منهم عندك فالأغلب متحتاجوش دلوقتي.
الأولى: بتبعت نفس الأحداث لتلات منصات أو أكتر. هنا السيرفر بيوفر شغل تكامل متكرر، والتكلفة بتتوزع على تلات استخدامات مش واحد.
التانية: سرعة الموقع مشكلة فعلية ومقاسة، والأكواد جزء مؤثر منها. المكسب هنا حقيقي ومباشر ومش معتمد على إعداد معقد.
التالتة: عندك التزام تنظيمي أو تعاقدي يخليك محتاج تحكم في ايه اللي بيخرج من عندك لمين. ده سبب وجيه ومش بيتحقق بأي طريقة تانية.
لو السبب الوحيد هو «عايز بيانات أحسن»، ده سبب مش كفاية لوحده. ابدأ بمراجعة تعريف الأحداث وتوزيع الميزانية على القياس الموجود، والمدخل ده شرحته في توزيع الميزانية بين ميتا وجوجل: القرار الحقيقي هو القياس.
الأخطاء اللي بتخلي الإعداد يطلع أوحش من اللي قبله
في تلات أخطاء بشوفها بتتكرر، وكلهم بيحصلوا بعد ما السيرفر يشتغل وكل حاجة تبان تمام في الاختبار.
الأول: إرسال الحدث من المتصفح ومن السيرفر في نفس الوقت من غير معرّف موحد. النتيجة تحويلات مضاعفة، والحساب بيبان أحسن من الحقيقة، والمزايدة الأوتوماتيكية بتتعلم على رقم غلط. ده أسوأ من إنك متبعتش أصلاً، لأن الغلط بيتحول لقرارات.
التاني: نسيان إن السيرفر ده بقى نقطة فشل. لو وقع، الأحداث مش بتتأخر، بتضيع. وده بالظبط السبب اللي جوجل بتوصي عشانه بأكتر من instance، والتوصية دي بتتقرا كتفصيلة تقنية وهي في الحقيقة بند تكلفة.
التالت: الاعتقاد إن الإعداد بينتهي. الوجهات بتغير مواصفاتها، والحقول بتتغير، والفشل بيبقى صامت مش برسالة خطأ. لازم يبقى في حد مسؤول بيبص على عدد الأحداث أسبوعياً، وده وقت شهري مستمر مش خطوة تنفيذ.
حد أدنى من الصراحة عن الأرقام
أرقام التكلفة فوق مأخوذة من دليل جوجل لإعداد Cloud Run تحديداً، وهي تقديرية بنص جوجل نفسها ومربوطة بتكوين معين. لو شغلت على App Engine أو على منصة تانية، الرقم هيختلف، ولو ترافيكك أعلى من النطاق المذكور هيختلف أكتر.
وأنا مش هقولك رقم لتكلفة التنفيذ لأن ده بيعتمد على مين بينفذ وعدد الوجهات، وأي رقم أقوله هنا هيبقى تخمين. اللي تقدر تعتمد عليه هو الأرقام المنشورة من جوجل، والباقي اسأل عليه عرض سعر.
أسئلة شائعة
التتبع من السيرفر بيرجع البيانات اللي ضاعت؟
لأ. مش بيتجاوز رفض الموافقة ولا بيرجع تفاصيل المنصة قررت تقللها. بيحسن وصول الأحداث اللي انت أصلاً مسموحلك تجمعها، وده حاجة تانية خالص.
بيكلف كام شهرياً؟
حسب دليل جوجل لـCloud Run، كل سيرفر حوالي ٤٥ دولار في الشهر، وجوجل بتوصي بحد أدنى اتنين عشان تقلل خطر فقدان البيانات. يعني حوالي ٩٠ دولار شهرياً كحد أدنى، بدون تكلفة التنفيذ والصيانة.
أشغله ولا أكتفي بـConversions API؟
لو محتاج تحسن منصة واحدة، CAPI كفاية وأرخص بكتير. السيرفر بيبقى منطقي لما تبقى بتبعت لتلات وجهات أو أكتر، أو لما سرعة الموقع مشكلة مقاسة، أو لما يبقى عندك التزام تنظيمي.
كام طلب في الثانية بيستحمل؟
جوجل بتقول إن التوسع التلقائي من ٢ لـ١٠ سيرفرات متوقع يستحمل ٣٥ لـ٣٥٠ طلب في الثانية، والأداء بيختلف حسب عدد الأكواد وايه اللي بتعمله.
المصادر
- Google: Server-side tagging (التتبع من السيرفر طريقة لقياس نشاط المستخدم في أي مكان بيحصل فيه، بمكاسب في أداء الصفحة وضوابط الخصوصية وجودة البيانات، وتلات طرق تشغيل: Cloud Run وApp Engine وإعداد يدوي)
- Google: Cloud Run setup guide for server-side tagging (توصية بحد أدنى instance اتنين لتقليل خطر فقدان البيانات عند العطل، وتكلفة تقديرية حوالي ٤٥ دولار شهرياً لكل سيرفر بـvCPU واحد و٠.٥ جيجا رام على نموذج CPU always allocated، وتوقع إن ٢ لـ١٠ سيرفرات يستحملوا ٣٥ لـ٣٥٠ طلب في الثانية)