شرح حلّ الهوية: كيف تتتبّع المستخدمين عبر الأجهزة والمتصفحات

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

تشرح هذه التدوينة المقاربتين الرئيسيتين لحلّ الهوية — القائمة على المطالبات والقائمة على الرسم البياني — وكيف ينفّذ Gurulu كليهما، واعتبارات الخصوصية التي عليك أن تضعها في حسبانك. سواء كنت تبني نظام هوية مخصصًا أو تقيّم منصات تحليلات، فإن فهم هذه الأساسيات سيوفّر عليك أشهرًا من العمل.

الهوية القائمة على المطالبات مقابل القائمة على الرسم البياني

يعمل حلّ الهوية القائم على المطالبات بجمع المعرّفات الصريحة — المطالبات — من تفاعلات المستخدم. عندما يسجّل مستخدم الدخول ببريد إلكتروني، يكون ذلك البريد مطالبة. وعندما يتحقّق من رقم هاتف، تكون تلك مطالبة أخرى. تُرفق كل مطالبة بالجلسة التي لوحظت فيها. إذا تشاركت جلستان المطالبة ذاتها (مثلًا، البريد الإلكتروني ذاته)، فإنهما تُدمجان في هوية واحدة. هذه المقاربة حتمية: لا تدمج الجلسات إلا عند وجود رابط قابل للإثبات.

يبني تحديد الهوية القائم على الرسوم البيانية شبكةً من العلاقات بين المُعرّفات. فبدلاً من المطابقة الثنائية البسيطة، يُنشئ رسماً بيانياً تكون فيه العُقد مُعرّفات (عناوين بريد إلكتروني، وأرقام هواتف، ومُعرّفات أجهزة، وملفات تعريف ارتباط) وتمثّل الحواف التواجد المشترك. وتستطيع الأنظمة القائمة على الرسوم البيانية حلّ العلاقات المتعدّية: فإذا تشارَكت الجلسة A بريداً إلكترونياً مع الجلسة B، وتشارَكت الجلسة B رقم هاتف مع الجلسة C، فإن الجلسات الثلاث جميعها تنتمي إلى الشخص نفسه. والمقايضة هنا هي التعقيد؛ إذ يتطلّب حلّ الرسوم البيانية ضبطاً دقيقاً لتجنّب عمليات الدمج الخاطئة التي يُربَط فيها مستخدمون غير مرتبطين عبر أجهزة مشتركة أو مُعرّفات مُعاد استخدامها.

المطابقة الحتمية مقابل المطابقة الاحتمالية

تتطلّب المطابقة الحتمية تطابقاً تامّاً على مُعرّف ثابت — البريد الإلكتروني نفسه، ومُعرّف المستخدم نفسه، ورقم الهاتف نفسه. وهي عالية الدقّة لكنها محدودة التغطية: إذ تعمل فقط عندما يقدّم المستخدمون معلومات تعريفية. أما المطابقة الاحتمالية فتستخدم نماذج إحصائية لاستنتاج الهوية من إشارات أضعف مثل عنوان IP، وبصمة المتصفّح، ودقّة الشاشة، والأنماط السلوكية. وهي تقدّم تغطية أوسع لكنها تُدخِل خطر النتائج الإيجابية الخاطئة. تستخدم Gurulu المطابقة الحتمية بوصفها الاستراتيجية الأساسية لتحديد الهوية، مع استخدام الإشارات الاحتمالية فقط لربط الجلسات ضمن سياق متصفّح واحد — وليس أبداً لعمليات الدمج عبر الأجهزة.

لماذا تتفوّق المطابقة الحتمية في التحليلات. تُفسِد عمليات الدمج الخاطئة في الرسم البياني للهوية كلّ مقياس لاحق. فإذا جرى دمج مستخدمَين غير مرتبطَين، فإن تاريخ جلساتهما المُجمَّع يشوّه مسارات التحويل، ويضخّم مقاييس التفاعل، ويربك نظام إدارة علاقات العملاء (CRM) لديك. وتتجنّب المطابقة الحتمية ذلك تماماً عبر الدمج فقط عندما تكون الأدلّة قاطعة.

متى تكون المطابقة الاحتمالية مقبولة. بالنسبة إلى ربط الجلسات المجهولة ضمن متصفّح واحد — أي إدراك أن المستخدم الذي زار الموقع أمس واليوم هو الشخص نفسه — تكون النماذج الاحتمالية آمنة. فتكلفة النتائج الإيجابية الخاطئة منخفضة (أعداد جلسات غير دقيقة قليلاً)، ومكاسب التغطية كبيرة.

أنواع الادّعاءات الستة في Gurulu

بُني نظام الهوية في Gurulu حول ستة أنواع من الادّعاءات. وكلّ ادّعاء هو دليل يربط جلسةً بهوية مرجعية. وعندما يرى النظام ادّعاءات متداخلة عبر الجلسات، فإنه يدمجها.

• user_id -- المُعرّف الداخلي للمستخدم في تطبيقك. وهو أقوى الادّعاءات لأنه فريد وثابت. يُضبَط عبر gurulu.identify().
• email -- عنوان البريد الإلكتروني، مُطبَّع إلى أحرف صغيرة. يُجمَع عندما يسجّل المستخدمون اشتراكهم، أو يسجّلون دخولهم، أو يرسلون نماذج تحتوي على حقول بريد إلكتروني.
• phone -- رقم الهاتف بصيغة E.164. مفيد للمنتجات التي تركّز على الأجهزة المحمولة ولتدفّقات المصادقة الثنائية.
• oauth_id -- مزوّد OAuth إضافةً إلى مُعرّف خارجي (مثل google:118234567890). يُجمَع تلقائياً عندما يصادق المستخدمون عبر تسجيل الدخول الاجتماعي.
• session_token -- مُعرّف الجلسة من جانب الخادم. يربط التصفّح المجهول بحالة مُصادَق عليها عندما يسجّل المستخدم دخوله في منتصف الجلسة.
• device_fingerprint -- بصمة جهاز آمنة للخصوصية مُشتقّة من إطار العرض واللغة والمنطقة الزمنية. لا تُستخدَم أبداً لعمليات الدمج عبر الأجهزة؛ بل لاستمرارية الجلسة على الجهاز نفسه فقط.

استدعاء identify()

الطريقة الأساسية لتغذية نظام الهوية في Gurulu بالادّعاءات هي استدعاء واجهة برمجة التطبيقات identify(). فعندما يصادق مستخدم في تطبيقك، تستدعي identify() مع مُعرّف المستخدم وأي خصائص إضافية. ويؤدّي ذلك إلى إنشاء ادّعاء user_id، وادّعاءَي البريد الإلكتروني والهاتف اختيارياً، مع ربط الجلسة المجهولة الحالية بهوية معروفة.

// Deterministic identity: link anonymous session to known user
gurulu.identify('user_12345', {
  email: 'jane@example.com',
  phone: '+1-555-0123',
  name: 'Jane Doe',
});

// The SDK sends a claim of type "user_id"
// Server-side, Gurulu merges all sessions with
// matching email, phone, or user_id into one
// canonical identity node.

بمجرّد استدعاء identify()، تُنسَب جميع الأحداث المجهولة السابقة في الجلسة الحالية بأثر رجعي إلى الهوية المُحدَّدة. وإذا كان هذا البريد الإلكتروني أو مُعرّف المستخدم قد شُوهِد من قبل في جلسة مختلفة — على جهاز أو متصفّح مختلف — فإن الجلسات تُدمَج في ملف مرجعي واحد. وهكذا يعمل تحديد الهوية عبر الأجهزة عملياً: يسجّل المستخدم دخوله على هاتفه، وفجأةً يظهر سجلّ تصفّحه على سطح المكتب في الملف نفسه.

مثال على الدمج عبر المتصفّحات

تأمّل هذا السيناريو: يزور مستخدم موقعك من Chrome على حاسوبه المحمول ويتصفّح ثلاث صفحات منتجات. وفي اليوم التالي، يزوره من Safari على هاتفه ويسجّل اشتراكه ببريده الإلكتروني. وفي اليوم الثالث، يعود إلى Chrome على حاسوبه المحمول ويسجّل دخوله. عند هذه النقطة، لدى Gurulu ثلاث جلسات عبر جهازَين ومتصفّحَين. وعندما يسجّل المستخدم دخوله في اليوم الثالث، يُنشئ استدعاء identify() ادّعاء user_id. ويجد النظام أن هذا الـ user_id يطابق البريد الإلكتروني من جلسة الهاتف (لأن التسجيل أنشأ كلا الادّعاءَين). فتُدمَج الجلسات الثلاث جميعها — جلسة Chrome المجهولة، وتسجيل Safari، وتسجيل دخول Chrome — في هوية مرجعية واحدة ذات خطّ زمني كامل عبر الأجهزة.

هذا الدمج فوري وبأثر رجعي. ويُظهِر ملفّ المستخدم في نظام إدارة علاقات العملاء (CRM) لديك الآن الرحلة الكاملة: التصفّح المجهول، والتسجيل، وزيارة العودة. وتعمل مسارات التحويل التي تمتدّ عبر الأجهزة بشكل صحيح، وتستطيع نماذج الإسناد تتبّع التحويل رجوعاً إلى مصدر الزيارة الأصلي الذي جلب المستخدم إلى موقعك في اليوم الأول.

اعتبارات الخصوصية

ينطوي تحديد الهوية بطبيعته على ربط بيانات المستخدم عبر الجلسات والأجهزة، وهو ما يحمل تبعات تتعلّق بالخصوصية. وقد صُمِّم نهج Gurulu ليكون واعياً بالموافقة في كلّ طبقة. فالادّعاءات لا تُجمَع إلا عندما يقدّمها المستخدم بنشاط — بتسجيل الدخول، أو إرسال نموذج، أو المصادقة. ولا تُستخدَم أي بصمات سلبية أو تتبّع عبر المواقع. والرسم البياني للهوية محصور في موقعك؛ فلا توجد مشاركة للبيانات بين عملاء Gurulu. وتُخزَّن جميع الادّعاءات على هيئة تجزئات مُستعارة (pseudonymized hashes)، لا نصوص صريحة، بحيث إن اختراق قاعدة البيانات لن يكشف عن عناوين البريد الإلكتروني أو أرقام هواتف المستخدمين.

بالنسبة إلى المؤسسات العاملة بموجب اللائحة العامة لحماية البيانات (GDPR) أو قانون KVKK أو أطر مماثلة، تدعم Gurulu التحكّم في تحديد الهوية على مستوى الموافقة. إذ يمكنك تكوين النظام بحيث لا يُحدِّد الهوية إلا للمستخدمين الذين منحوا موافقة على مستوى التحليلات، مع الاستمرار في جمع مقاييس إجمالية للمستخدمين الذين لم يمنحوها. وهذا يمنحك أفضل ما في العالَمَين: تحديد هوية دقيق للمستخدمين الموافِقين، وبيانات إجمالية متوافقة للجميع.