الإسناد بلا ملفات تعريف الارتباط: خطة بيانات للعيادة
خطة بيانات الطرف الأول التي تبنيها العيادة في ستة أشهر: الموافقة وconsent mode، هوية CRM، الجمع من جهة الخادم، وإعادة كتابة التحويلات خارج الإنترنت.
بقلم Roozbeh Nazari · CEO
تأجلت نهاية ملفات تعريف الارتباط من الطرف الثالث مرات عدة، ثم أعلنت Google في النهاية تخليها عن خطة إزالتها إلزاميًا من Chrome؛ لكن مشكلة الإسناد لدى العيادات لم تكن محصورة في ملف تعريف الارتباط أصلًا. فبسبب القيود التي يطبقها Safari وFirefox منذ سنوات، وطلب إذن التتبع في iOS، وإدارة الموافقة، وحاصرات الإعلانات، لا يصل جزء من تحويلات موقع العيادة إلى طبقة القياس على الإطلاق. لا تتناول هذه المقالة نظرية نقاش "cookieless"، بل تصف خطة بيانات الطرف الأول التي يمكن للعيادة بناؤها خلال ستة أشهر: ماذا تجمع، وبأي إذن، وإلى أين ترسله، وفي أي تقرير تقرؤه.
تناولنا الجانب المفاهيمي من قبل في مقالة الإسناد من دون ملفات تعريف الارتباط؛ وهنا نتناول المشكلة نفسها عبر مثال عيادة، وبترتيب الإعداد. العيادة في المثال تملك موقعًا بأربع لغات، وتدفق عملاء محتملين يعتمد على WhatsApp في الغالب، ونظام CRM؛ وعلى جانب الإعلانات لديها Google Ads وMeta.
الطبقة الأولى: الموافقة والأساس القانوني
تبدأ خطة بيانات الطرف الأول بالقانون لا بالتقنية. كل بيانات تُجمع في موقع العيادة تلامس البيانات الصحية؛ فحين يملأ المريض نموذجًا من صفحة علاج، يكون النموذج نفسه إفصاحًا عن اهتمام صحي. في قانون حماية البيانات التركي KVKK، البيانات الصحية بيانات شخصية ذات طبيعة خاصة؛ ولذلك تحتاج كل خطوة من الجمع والتخزين والنقل إلى منصة إعلانية إلى تقييم قانوني منفصل. هذه المقالة ليست رأيًا قانونيًا؛ فقبل تطبيق الخطة، حدد مع مستشار حماية البيانات لديك نص الإفصاح وآلية الموافقة الصريحة وشروط النقل.
المقابل التقني هو منصة إدارة الموافقة وconsent mode من Google. تذكر وثائق Google أن consent mode لا يملك شريط موافقة خاصًا به، بل ينقل قرار شريط الموافقة الحالي إلى الوسوم؛ في الوضع الأساسي لا يُحمَّل أي وسم حتى تصل الموافقة، وفي الوضع المتقدم تُحمَّل الوسوم وترسل إشارات من دون ملفات تعريف ارتباط عند رفض الموافقة، وتملأ Google الفجوة بالنمذجة. أي الوضعين يناسب العيادة هو نتيجة التقييم القانوني؛ ونحن نكتفي بالإشارة إلى أن نتيجة القياس تختلف بين الوضعين.
الطبقة الثانية: الهوية ونظام CRM
عمود الإسناد من دون ملفات تعريف الارتباط ليس ملف تعريف ارتباط، بل الهوية التي تمنحها أنت. يحصل المريض على سجل في CRM عند أول تواصل؛ وتُكتب في ذلك السجل معلومات المصدر (الحملة، الصفحة، اللغة، معرّف النقرة) لحظة التواصل الأول، وتُضاف كل خطوة لاحقة (الاستشارة، العرض، العربون، العلاج) إلى السجل نفسه. شرحنا تفاصيل هذا الإعداد للتدفق المعتمد على WhatsApp في مقالة قمع WhatsApp Business API.
على جانب GA4 تُحمل هذه الهوية عبر User-ID. تذكر صفحة مساعدة Google أن User-ID يربط معرّفك الخاص بسلوك المستخدم، وأنه لا يجوز أن يتجاوز 256 حرفًا، ولا أن يحتوي على معلومات يستطيع طرف ثالث استخدامها لتحديد هوية الشخص. عمليًا لا يُستخدم رقم المريض في CRM نفسه، بل رمز عشوائي مشتق منه؛ وفي هذه المرحلة أيضًا تختار بين "المدمج" و"الملاحَظ" في إعداد هوية التقارير.
الطبقة الثالثة: الجمع من جهة الخادم
بعض الوسوم التي تعمل في المتصفح لا تعمل أبدًا. يرسل التوسيم من جهة الخادم الحدث أولًا إلى خادم تحت سيطرتك ثم يمرره منه إلى المنصات؛ وقرار أي بيانات تذهب إلى أي منصة يُتخذ على خادمك. تناولنا قرارات الإعداد وبنود التكلفة بالتفصيل في مقالة server-side tagging. المقابل على جانب Meta هو Conversions API؛ وتشرح وثائق Meta أن الأحداث المرسلة من الخادم تُعالج بالطريقة نفسها التي تُعالج بها أحداث Pixel، وأن إزالة التكرار تُطبق حين يصل الحدث نفسه عبر القناتين.
الطبقة الرابعة: إعادة كتابة التحويل
في العيادة لا يحدث التحويل الحقيقي في الموقع؛ بل يحدث العلاج بعد أسابيع، في العيادة. تصف وثائق Google Ads الخاصة باستيراد التحويلات خارج الإنترنت هذا الوضع بالضبط: يُخصص لكل نقرة إعلان معرّف (GCLID)، تحفظه أنت في CRM، وحين يحدث التحويل تعيد إرساله مع المعرّف. وتذكر الوثيقة نفسها أن عمليات الرفع هذه انتقلت إلى Data Manager API اعتبارًا من 15 يونيو 2026؛ والتكاملات التي ما زالت تستخدم مسار Google Ads API القديم تحتاج إلى تحديث.
التحويلات المحسّنة هي مسار إعادة الكتابة الثاني. تشرح وثائق Google أن بيانات الطرف الأول مثل البريد الإلكتروني والهاتف تُطبَّع ثم تُجزَّأ بخوارزمية SHA256 قبل إرسالها، وأن نسخة "التحويلات المحسّنة للعملاء المحتملين" تطابق العميل المحتمل القادم من الويب مع بيع خارج الإنترنت. وهنا تلزم ملاحظة خاصة بالعيادات: نقل بيانات شخصية مجزَّأة إلى منصة إعلانية في سياق البيانات الصحية يدخل في نطاق التقييم القانوني في الطبقة الأولى، وتضيف سياسات المنصات بشأن التخصيص المرتبط بالصحة قيودًا إضافية. كون الأمر ممكنًا تقنيًا لا يعني أنه ينبغي فعله.
ما الذي لا ينبغي جمعه
خطة بيانات الطرف الأول ليست خطة "اجمع كل شيء". المبدأ الأكثر أمانًا للعيادة هو تقليل البيانات إلى أدنى حد: ما يحتاجه الإسناد هو من أي مصدر جاء المريض وإلى أي مرحلة وصل؛ لا عن أي علاج سأل، ولا تاريخه الصحي، ولا الصورة التي رفعها. هذه المجموعة الثانية تبقى في CRM ولا تدخل طبقة القياس أبدًا. في معلمات الأحداث المرسلة إلى GA4، احمل فئة الصفحة بدل اسم العلاج، وحقيقة بدء المحادثة فقط بدل محتوى رسالة WhatsApp. ولكل حقل يذهب إلى منصة، اطرح سؤال "ألا نستطيع الإسناد من دونه؟"؛ والجواب في الغالب "نستطيع".
ترتيب التنفيذ خلال ستة أشهر
- الشهر الأول: جرد البيانات، ونص الإفصاح، ومنصة الموافقة، وقرار consent mode.
- الشهر الثاني: حقول المصدر وحفظ معرّف النقرة في CRM؛ وكتابة المصدر في تدفق WhatsApp والنماذج.
- الشهر الثالث: الحاوية من جهة الخادم، وUser-ID في GA4، وMeta Conversions API، واختبار إزالة التكرار.
- الشهر الرابع: إعادة كتابة التحويلات خارج الإنترنت (Data Manager API) وقرار التحويلات المحسّنة.
- الشهران الخامس والسادس: وضع تقرير المنصة وتقرير CRM جنبًا إلى جنب، وتحليل الانحراف، وقراءة أثر النمذجة.
ماذا تقرأ في التقرير
ناتج هذه الخطة جدول واحد: عدد العملاء المحتملين والاستشارات والعرابين والعلاجات بحسب المصدر، من CRM. توضع تقارير المنصات بجانب هذا الجدول لا فوقه؛ فعدد التحويلات الذي يعرضه Google Ads منمذج، والعدد في CRM ملاحَظ، والفرق بينهما يخبرك أي طبقة من الخطة ناقصة. إذا كان الفرق كبيرًا ولصالح المنصة، فالنمذجة متفائلة أكثر من اللازم أو أن إزالة التكرار لا تعمل؛ وإذا كان لصالح CRM، فمعرّفات النقرات لا تُحفظ أو أن إعادة الكتابة ناقصة. تُجرى هذه القراءة مرة في الشهر وينتهي كل شهر بإصلاح طبقة واحدة. إعداد هذا التقرير هو التسليم الاعتيادي في خدمة التحليلات والبيانات لدينا؛ والفرق بالنسبة إلى العيادات أن قيود البيانات الصحية مدمجة في كل طبقة.
الخلاصة
الإسناد في عالم من دون ملفات تعريف الارتباط ليس البحث عن ملف تعريف ارتباط جديد بدل الضائع؛ بل الاحتفاظ بالهوية والموافقة والتحويل في نظامك أنت وإعادتها إلى المنصات بطريقة مضبوطة. وبالنسبة إلى العيادة لا يتغير الترتيب: القانون أولًا، ثم الهوية، ثم الجمع من جهة الخادم، وإعادة الكتابة أخيرًا. المشاريع التي تقلب هذا الترتيب تنتهي بإعداد يعمل تقنيًا لكن لا يمكن الدفاع عنه قانونيًا.