شرح Google tag gateway: اللي في التوثيق واللي مش فيه

كل شوية حد يبعتلي يسألني عن Google tag gateway، وغالبا بيكون قرا جملة في مكان بتقول انها بترجع النسبة اللي الـad blockers وحدود المتصفحات بتاكلها. انا قريت توثيق جوجل نفسه، وهقول لك اللي فيه حرفيا، واللي مش فيه، لان اللي مش فيه هو اللي بيضيع فلوس ناس.

اول حاجة لازم تتقال: دي مش اداة قياس جديدة. دي طريقة تحميل. التوثيق بيقول ان الحاجة دي بتخليك تحمل سكربتات جوجل، زي gtm.js، من البنية التحتية بتاعتك انت كطرف اول، بدل ما تتحمل من سيرفرات جوجل.

الفرق بين الجملة دي وبين «بترجع البيانات الضايعة» فرق كبير، وهو موضوع المقال.

اللي التوثيق بيقوله بالظبط

صفحة dependency serving في توثيق Google Tag Manager، واخر تحديث مكتوب عليها 21 مايو 2026، بتحدد الحاجات دي:

الهدف المعلن هو توصيل البيانات في سياق الطرف الاول. وليها طريقتين للتنفيذ: عن طريق tagging server بتاعك، او عن طريق CDN. والتوثيق بيعلم خيار الـCDN انه هو الموصى بيه.

والمتطلبات مكتوبة بوضوح: لازم يكون عندك server container في Tag Manager، و tagging server، و custom server domain متظبط. يعني الحاجة دي مش بديل عن الـserver-side tagging، دي طبقة فوقه.

دي اهم نقطة عملية في الموضوع كله. لو انت بتفكر تستخدم tag gateway عشان تهرب من تعقيد وتكلفة الـserver-side tagging، التوثيق بيقفل الباب ده من اول سطر في المتطلبات. انا كنت فصلت التكلفة الحقيقية للحكاية دي في شرح Server Side Tracking، والارقام دي لسه هي هي.

المسارين، لان الناس بتفتكرهم واحد

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

المسار الاول مسار تجميع، بيوجه الاحداث للـtagging server بتاعك. المسار التاني مسار سكربت، بيوجه طلبات السكربت لسيرفرات جوجل. يعني السكربت لسه جاي من جوجل في الاخر، بس بيعدي من عندك.

والتوثيق حاطط قيدين على اختيار المسار: اختار مسارات غير مستخدمة عشان متأثرش على ترافيك موقعك القايم، والمسار «must not contain /gtm». الناس بتعدي على الجملة التانية دي بسرعة وهي بتوفر ساعة debugging.

اللي التوثيق مش بيقوله، وده الجزء المهم

انا قريت الصفحة كلها. مفيش فيها ولا رقم عن قد ايه الحاجة دي بترجع من البيانات. مفيش نسبة استرجاع، مفيش قياس اثر، مفيش مقارنة قبل وبعد.

وكمان مش بتتكلم عن عمر الكوكيز، ولا عن حدود المتصفحات زي ITP، ولا عن الـad blockers. الحاجة الوحيدة اللي ليها علاقة بالخصوصية في الصفحة هي اشارة ان لو انت مستخدم consent mode، تقدر تظبط سلوك التاج حسب المنطقة.

فلو انت شايف رقم بيتقال في السوق عن نسبة زيادة في التحويلات المقاسة بعد تفعيل tag gateway، الرقم ده مش من صفحة التوثيق دي. دوّر على مصدره قبل ما تبني عليه قرار، ولو مصدره شركة بتبيع لك التنفيذ، عامله على اساس كده.

وفي الحتة دي انا بكرر حاجة بقولها كل شوية: الفرق بين «هقيس اكتر» و«هبيع اكتر» مش بديهي. وفيه كلام كويس عن حدود رؤية رحلة العميل اصلا كتبه خالد بدر في ايه هي رحلة العميل؟ المراحل الحقيقية وحدود قياسها فعليا، وهو من زاوية صاحب البيزنس مش زاوية المنفذ.

فين الفرق بينها وبين server-side tagging

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

في صفحة المقدمة للـserver-side tagging، جوجل بتقول ان الـserver container «runs on a server that you control»، وان «only you have access to the data in the server until you choose to send it elsewhere»، وان عندك «full control over how that data is shaped, and where it is routed from the server». دي حكاية تحكم في البيانات.

اما tag gateway، زي ما التوثيق بيوصفها، فحكايتها تحميل السكربتات من دومينك. الاتنين مش نفس الحاجة، والتانية بتتطلب الاولى.

عمليا: لو معندكش server-side tagging شغال، tag gateway مش خطوتك الجاية. خطوتك الجاية هي الاولى. ولو عندك، فالسؤال هو هل المشكلة عندك في تحميل السكربت اصلا، وده سؤال تقيسه في حسابك مش تفترضه.

التكلفة اللي محدش بيحطها في الحسبة

صفحة المقدمة بتقول ان السيرفر بيشتغل «in your own Google Cloud Platform project» او في بيئة تانية من اختيارك، وبتوصي بشدة بتركيب السيرفر على دومينك كطرف اول قبل الترافيك الحقيقي.

يعني فيه استضافة بتتدفع شهريا، وفيه دومين فرعي بيتظبط، وفيه حد لازم يراقب السيرفر ده. التوثيق مش بيدي ارقام تكلفة، وانا كمان مش هخترع رقم، لان الفاتورة بتختلف بالترافيك وبالاعداد.

بس القرار واضح: ده مشروع بنية تحتية بميزانية شهرية، مش اعداد بتدوس عليه مرة. ولو حسابك صغير، الفلوس دي في الغالب عايدها اعلى في مكان تاني، زي تظبيط Conversions API صح الاول.

الترتيب اللي انا بنصح بيه

واحد: اتأكد ان القياس الاساسي عندك سليم. لو فيه احداث مكررة او ناقصة، tag gateway مش هيصلحها، هي هتنقل المشكلة لدومين تاني.

اتنين: لو عندك CAPI او ما يعادله، راجع جودته قبل اي كلام عن الطبقة دي. فيه تفصيل كامل في شرح Conversions API عن اللي بيرجع واللي بيفضل ضايع.

تلاتة: لو قررت تمشي، ابدا بخيار الـCDN لان التوثيق معلمه انه الموصى بيه، وخد بالك من شرط الـsame origin serving مع الـtagging server.

اربعة: قبل وبعد، قيس حاجة واحدة متفق عليها سلفا. من غير قياس قبلي، انت مش هتعرف ابدا هل الحاجة دي عملت فرق ولا لا، وهتفضل تقول «حسيت انها حسنت» وده مش قياس.

ولو التحويلات عندك نزلت فجأة وانت بتدور على حل، في الغالب ده مش مكانه. فيه ترتيب تشخيص مختلف تماما كتبته في ليه معدل التحويل نزل فجأة.

حدود الكلام ده

انا اتكلمت عن اللي مكتوب في صفحتين من توثيق جوجل قريتهم النهاردة. صفحة dependency serving وصفحة المقدمة للـserver-side tagging. اي حاجة فوق كده مش مني.

والتوثيق ده بيتغير. الصفحة مكتوب عليها اخر تحديث 21 مايو 2026، ومسارات التنفيذ والواجهة بيتغيروا اسرع من الصفحة نفسها. اقرا الصفحة قبل ما تنفذ، متعتمدش على مقال، بما فيهم ده.

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