عند دمج حزمة SDK تقليدية لوساطة الإعلانات بنموذج SaaS، يُرسل تدفق الأحداث لديك — كل طلب إعلان، وكل ظهور، وكل معرّف مستخدم — أولًا إلى خوادم المورّد. وهناك تُعالج البيانات وتُثرى، ثم تُرسل أحيانًا نسخة محجوبة البيانات الحساسة إلى مستودع بياناتك. وبحلول الوقت الذي تطّلع فيه على البيانات، تكون قد مرّت عبر نظام لا تتحكم فيه.
أما حزمة SDK المبنية على Firebase فتعمل بالعكس. تُكتب الأحداث أولًا في Firestore وBigQuery ضمن مشروعك. يقرأ المورّد البيانات من مشروعك، وليس العكس. قد يبدو الفرق نظريًا، إلى أن يحين أول تدقيق للامتثال إلى GDPR.
ما الذي يتغير عندما تكون ملكية البيانات داخل مشروعك؟
- تُنفَّذ طلبات الحذف باستعلام واحد في Firestore — بلا تذكرة دعم لدى المورّد ولا انتظار وفق SLA
- تصبح تكاليف BigQuery قابلة للتوقع لأنك تتحكم في مخطط تصدير البيانات
- تُنفَّذ عمليات ترحيل مخطط البيانات وفق جدولك الزمني، لا وفق ملاحظات إصدار المورّد
- تتقلص إفصاحات الجهات الفرعية المعالجة للبيانات، وغالبًا بدرجة كبيرة
المقايضات التي لا يذكرها أحد في مكالمة المبيعات
الاعتماد على Firebase ليس بلا تكلفة. فأنت تدفع إلى Google مقابل التخزين والاستعلامات التي كنت ستتركها للمورّد في النموذج الآخر. لتطبيق لديه 5 ملايين DAU، تتراوح فاتورة BigQuery بين 400 و1,200 دولار شهريًا — مبلغ يُؤخذ في الحسبان، لكنه هامشي مقارنة بإيرادات الإعلانات التي يحميها.
عليك أيضًا مراعاة حصص الاستخدام. فعدد عمليات الكتابة في Firestore في الثانية، وعمليات الإدراج المتدفق في BigQuery، وبدء التشغيل البارد في Cloud Functions، كلها قيود فعلية تتولى حزمة SaaS SDK التعامل معها دون أن تشعر بها. تتضمن Apps Kit SDK طبقة للتحكم في ضغط تدفق البيانات، تجمع عمليات الكتابة في دفعات للبقاء ضمن حصص الفئة المجانية لمعظم التطبيقات التي يقل استخدامها عن مليون DAU.
ما تدفعه فعليًا إلى Google
نموذج التكلفة رتيب، وهذا هو المقصود: يمكنك تتبّع كل بند في لوحة الفوترة الخاصة بك. هذه هي نطاقات التكلفة التي نرصدها في التطبيقات التي تستخدم Apps Kit SDK فعليًا في 2026، بعد تطبيق طبقة التحكم في ضغط تدفق البيانات وسياسة انتهاء صلاحية أقسام BigQuery بعد 90 يومًا، وهما مفعّلتان افتراضيًا.
- مليون DAU: Firestore من 40 إلى 90 دولارًا، وتخزين BigQuery من 20 إلى 50 دولارًا، واستعلامات BigQuery من 30 إلى 80 دولارًا، وCloud Functions من 10 إلى 30 دولارًا — الإجمالي أقل من 250 دولارًا شهريًا
- 5 ملايين DAU: Firestore من 180 إلى 350 دولارًا، وتخزين BigQuery من 100 إلى 220 دولارًا، واستعلامات BigQuery من 120 إلى 400 دولار، وCloud Functions من 40 إلى 110 دولارات — الإجمالي من 400 إلى 1,200 دولار شهريًا
- 25 مليون DAU: Firestore من 700 إلى 1,400 دولار، وتخزين BigQuery من 450 إلى 900 دولار، واستعلامات BigQuery من 500 إلى 1,800 دولار، وCloud Functions من 150 إلى 400 دولار — الإجمالي من 1,800 إلى 4,800 دولار شهريًا
إعدادات التكلفة التي تُحدث فرقًا فعليًا في الفاتورة
يرجع معظم التفاوت في الأرقام السابقة إلى ثلاثة قرارات. أولًا، هل تستخدم الإدراج المتدفق إلى BigQuery أم ترسل البيانات على دفعات عبر GCS؟ الإرسال على دفعات يخفض تكلفة إدخال البيانات بأكثر من 80%، مقابل تأخير التقارير 30 دقيقة. ثانيًا، انتهاء صلاحية الأقسام: مدة 90 يومًا تغطي كل استعلام تشغيلي احتجنا إليه حتى الآن؛ أما البيانات الخام الأقدم فمكانها التخزين البارد. ثالثًا، كفاءة الاستعلامات: لوحة معلومات واحدة تنفّذ استعلام SELECT * بلا قيود على بيانات مرات الظهور لعام كامل قد تكلّف أكثر من جميع البنود الأخرى مجتمعة.
لماذا تزداد أهمية ذلك في 2026؟
غيّر تحوّلان تنظيميّان المعادلة هذا العام. أصبحت متطلبات قابلية نقل البيانات في DMA تنطبق على أي مورّد يعالج بيانات المستخدمين النهائيين في الاتحاد الأوروبي، وانتهت مهلة إنفاذ DPDP الهندي في مارس. يفترض كلا الإطارين قدرتك على توفير تصدير كامل لكل حدث مرتبط بمستخدم، عند الطلب.
إذا كان مورّد SDK هو المصدر المرجعي المعتمد للبيانات، فأنت تعتمد على أدوات التصدير التي يوفرها. أما إذا كان مشروع Firebase لديك هو المصدر المرجعي، فالتصدير ليس سوى استعلام تعرف بالفعل كيف تكتبه.
كيف يجري تدقيق GDPR / DPDP فعليًا؟
عندما تطلب جهة تنظيمية أو عميل من المؤسسات الكبرى إجراء تدقيق، فهي تريد أربعة مستندات وأدلة: قائمة بكل جهة فرعية تعالج بيانات المستخدمين النهائيين، وتصديرًا كاملًا لبيانات مستخدم محدد، وإثباتًا للحذف، ووصفًا لجدول الاحتفاظ بالبيانات. مع حزمة SaaS SDK، تُعدّ الأول بالرجوع إلى إفصاحات المورّد، وتحصل على التاليين بفتح تذاكر دعم، أما الرابع فتعتمد فيه على التخمين.
مع بنية قائمة على Firebase، تصبح العناصر الأربعة كلها استعلامات تتحكم فيها. الجهات الفرعية المعالجة للبيانات: قائمة خدمات GCP في مشروعك. تصدير بيانات المستخدم: استعلام واحد في Firestore وآخر في BigQuery، وكلاهما متاح كقالب ضمن SDK. إثبات الحذف: دالة Cloud Function تُرجع أعداد الصفوف المتأثرة. الاحتفاظ بالبيانات: سياسة انتهاء صلاحية الأقسام لديك، وهي ظاهرة في لوحة التحكم. وهكذا يتحول التدقيق من سباق محموم يستغرق أسبوعين إلى مهمة تُنجز في نصف يوم.
الانتقال من حزمة SaaS SDK دون تعطيل إسناد التحويلات
الانتقال الذي يُقلق الفرق هو ما تتخيل تنفيذه دفعة واحدة في إصدار واحد. نحن لا نعمل بهذه الطريقة. تُنشر حزمة SDK المبنية على Firebase إلى جانب حزمة SaaS SDK الحالية لمدة أسبوعين إلى أربعة أسابيع، وتكتب البيانات في مسار المعالجة الجديد، بينما يستمر المسار القديم في تغذية جميع لوحات المعلومات ومنصات MMP الحالية.
- الأسبوع الأول: دمج حزمة SDK المبنية على Firebase في وضع التشغيل الموازي، دون أي تغيير يراه المستخدم، والتحقق من تطابق الأحداث في BigQuery
- الأسبوع الثاني: تحويل إشعارات الإسناد الراجعة إلى المسار المبني على Firebase، مع إبقاء وساطة الإعلانات على SDK القديمة
- الأسبوع الثالث: نقل وساطة الإعلانات إلى المسار الجديد، مع إبقاء SaaS SDK تُرسل أحداثًا للقراءة فقط لتكون مرجعًا عند اختلاف النتائج
- الأسبوع الرابع: إزالة حزمة SaaS SDK في تحديث التطبيق التالي، لإنهاء أي اعتماد عليها
متى تظل SaaS الخيار الأفضل؟
إذا كان فريقك لا يستخدم Firebase ولا يخطط لاستخدامه، فالأعباء التشغيلية الإضافية لحزمة SDK المبنية على Firebase عامل لا يُستهان به. وساطة الإعلانات بنموذج SaaS هي الخيار المناسب للاستوديوهات التي تريد إطلاق التطبيق دون الانشغال بإدارة هذه البنية، وللنماذج الأولية التي لم تصبح ملكية البيانات فيها أصلًا استراتيجيًا بعد. القرار ليس تقنيًا، بل يتعلق بمن تريد أن يمتلك سجل التدقيق.
امتلاك تدفق الأحداث ليس مجرد موقف بشأن الخصوصية. إنه الفرق بين التفاوض على عقدك التالي مع المورّد من موقع قوة، والتفاوض وأنت لا تملك سوى لقطة شاشة.
ما الذي ينبغي فعله هذا الربع؟
إذا كنت تستخدم Firebase Analytics بالفعل، فقد قطعت 60% من الطريق نحو حزمة SDK للإعلانات مبنية على Firebase، وربما لا تدرك ذلك. خصّص دورة تطوير لتنفيذ الدمج بوضع التشغيل الموازي الموضح أعلاه، واتخذ قرارك بناءً على تقرير تطابق البيانات، لا على العرض التقديمي للمبيعات. معظم الفرق التي تُكمل مرحلة التشغيل الموازي تقرر الانتقال الكامل خلال تسعين يومًا.
