الفصل 3 / 9
منطق الهوية: من هو "المستخدم"؟
في Amplitude وحدة التحليل هي الشخص لا الجهاز. ولجمع هاتف الشخص نفسه وجهازه اللوحي ومتصفحه في مستخدم واحد، يدمج Amplitude الهويات. بعد Adjust، هذا هو الجزء الأكثر إرباكًا، وهو المكان الذي تُرتكب فيه أغلى الأخطاء.
- ستعرف ما هي device_id و user_id و Amplitude ID ومن يُنشئها.
- ستتابع عملية الدمج (merge) خطوة بخطوة.
- ستتعرّف على أخطاء user_id التي تحوّل آلاف الأشخاص إلى مستخدم واحد.
ثلاث هويات
| الهوية | من يُنشئها | متى توجد | ماذا تمثّل |
|---|---|---|---|
device_id | الـ SDK (لكل جهاز أو متصفح) | منذ أول فتح، حتى بدون تسجيل دخول | جهاز أو متصفح |
user_id | أنت، من نظام العملاء لديك | عندما يسجّل المستخدم الدخول وتعيّنها أنت | حساب عميل |
| Amplitude ID | Amplitude، بمطابقة الاثنين | دائمًا | "الشخص" الذي يُعدّ في التحليل |
في Adjust يمثّل الـ ADID جهازًا واحدًا في تطبيق واحد، ولا يوجد دمج بين الأجهزة: هاتف الشخص نفسه وجهازه اللوحي تثبيتان منفصلان. في Amplitude يبقى الشخص نفسه مستخدمًا واحدًا ما دام يسجّل الدخول بالـ user_id نفسه. لهذا تختلف أعداد المستخدمين في الأداتين اختلافًا بنيويًا.
تابع الدمج خطوة بخطوة
في السيناريو أدناه يستخدم عميل التطبيق أولًا من الهاتف ثم من الجهاز اللوحي. انتقل بين الخطوات لترى أي event ينتمي إلى أي Amplitude ID.
| Event | الجهاز | device_id | user_id | Amplitude ID |
|---|
قواعد الدمج
- من مجهول إلى معروف: الـ events التي وقعت قبل تسجيل الدخول على جهاز ما تُربط بالشخص عند تعيين
user_idعلى الجهاز نفسه. ولهذا يمكن قياس الـ onboarding قبل تسجيل الدخول. - بين الأجهزة: عندما يظهر الـ
user_idنفسه على أجهزة مختلفة، تُدمج هذه الأجهزة في شخص واحد. - معرّفا user_id مختلفان لا يُدمجان: تسجيل الدخول بـ
user_idمختلف على الجهاز نفسه يُعامل كشخص جديد. المشكلة هي إلى من تُكتب الـ events المجهولة بين عمليتي الدخول.
القواعد الدقيقة للدمج (خاصةً ما يحدث عند تغيّر المستخدم على الجهاز نفسه، وكيف يظهر عدّ "new user" قبل الدمج بأثر رجعي، وهل يمكن التراجع عن دمج خاطئ) موضّحة في توثيق الهوية في Amplitude. تحقّق منها هناك قبل إعطاء العميل جملة قاطعة.
أجهزة، أشخاص، تسجيلات دخول: جمهور واحد وثلاثة أرقام
عدّ الأسبوع نفسه من التطبيق بثلاث وحدات مختلفة يعطي ثلاثة أرقام مختلفة. أيّها "الصحيح" يعتمد على السؤال المطروح.
user_id.أخطاء مكلفة
أخطاء الهوية صامتة: تستمر الـ events بالوصول وتمتلئ المخططات، لكن الأرقام تُكتب لأشخاص خطأ. أكثرها شيوعًا:
لا تفعل
- قيم مشتركة مثل
setUserId('guest')و'0'و'null'و'undefined': يُدمج الجميع في شخص واحد - استخدام البريد الإلكتروني كـ
user_id: قد يتغيّر وهو بيانات شخصية - تعيين معرّف مؤقت قبل الدخول ثم الانتقال إلى المعرّف الحقيقي
- عدم إعادة تعيين الهوية عند تسجيل الخروج
- صيغة معرّف مختلفة بين iOS و Android (
88231وcust_88231)
افعل
- استخدم معرّف العميل الثابت والفريد من الـ backend
- لا تعيّن
user_idقبل أن يسجّل المستخدم الدخول فعلًا - استدعِ دالة reset في الـ SDK عند تسجيل الخروج
- الصيغة نفسها للمعرّف في كل المنصات وفي HTTP API
- افحص بعض مستخدمي الاختبار في user lookup قبل الإطلاق
في معظم الحالات لا يمكن إصلاح الدمج بأثر رجعي. تاريخ آلاف الأشخاص المدموجين تحت 'guest' يبقى "مستخدمًا خارقًا" واحدًا، وتصبح أرقام الـ retention والـ funnel وأعداد المستخدمين لتلك الفترة غير موثوقة.
قد يحظر Amplitude بعض قيم المعرّفات غير الصالحة بوضوح، ويطبّق قاعدة حدّ أدنى للطول على user_id / device_id. راجع القائمة والقاعدة الحالية في توثيق HTTP API.
مثال على تسجيل الخروج
import * as amplitude from '@amplitude/analytics-browser';
// On login: link this device to the backend customer ID
amplitude.setUserId('cust_88231');
// On logout: clear user_id and start a fresh device_id,
// so the next person's events are not written to this user
amplitude.reset();"New user" ليس تثبيتًا
في Amplitude، المستخدم الجديد هو لحظة ظهور Amplitude ID لأول مرة. وفي Adjust، التثبيت هو أول جلسة للجهاز. لذلك يتباعد الرقمان في الحالات التالية:
| الحالة | Adjust | Amplitude |
|---|---|---|
| الشخص ثبّت التطبيق على جهاز ثانٍ وسجّل الدخول | تثبيت جديد | يُدمج، الشخص نفسه |
| الشخص استخدم الويب أولًا ثم ثبّت التطبيق (بالـ user_id نفسه) | تثبيت جديد | مستخدم موجود |
| Amplitude SDK يبدأ بعد الموافقة، والمستخدم رفض | حسب قواعد الموافقة الخاصة به | لا يُرى إطلاقًا |
| Amplitude SDK يبدأ بعد الشاشة الأولى، والمستخدم غادر فورًا | تثبيت | لا يُرى إطلاقًا |
يوضّح الفصل 7 كيف تفصّل هذه الفروق في تحليل الـ discrepancy.
في مشروع تجريبي، سجّل الدخول بالـ user_id نفسه من نافذة متصفح عادية ثم من نافذة خاصة. شاهد في user lookup كيف يُدمج الجهازان في مستخدم واحد. ثم سجّل الدخول بحساب تجريبي آخر دون استدعاء reset() عند الخروج، وتحقّق إلى من كُتبت الـ events بينهما.