# ادپیکس بازدیدکننده را چطور می‌شناسد

هر رویداد به یک شناسه ناشناس می‌چسبد، آن شناسه به کاربر سایت وصل می‌شود و کاربر سایت به یک کاربر سراسری. این سه لایه، همان چیزی است که سنجه «کاربران» را در هر گزارش می‌سازد.

## سه لایه، نه یکی

گراف هویت ادپیکس همیشه همین شکل است و تغییر نمی‌کند:

**ناشناس ← کاربر سایت ← کاربر سراسری.**

- **ناشناس** یک شناسه تصادفی است که در مرورگر نگه داشته می‌شود (`__sov_did` و `__sov_aid`). هر رویدادی که پیش از ورود کاربر رخ می‌دهد به همین می‌چسبد.
- **کاربر سایت** همان آدم است، اما فقط در محدوده یک دارایی. وقتی نشانه ای واقعی — ورود، ایمیل، شماره، شناسه مشتری در CRM — پیدا شود، ناشناس به کاربر سایت وصل می‌شود.
- **کاربر سراسری** همان آدم است در همه دارایی ها و همه دامنه‌های سازمان شما. این لایه است که به شما اجازه می‌دهد یک نفر را از تبلیغ تا خرید در دامنه‌ای دیگر دنبال کنید — به شرطی که آن دامنه در تنظیمات میان دامنه‌ای همان جریان اضافه شده باشد.

بین این لایه‌ها یال ها (edges) قرار دارند. هر یال یک شاهد است، و هر شاهد یک ضریب اطمینان دارد.

> **مرز کسب‌وکار شما**
>
> کاربر سراسری متعلق به سازمان شماست و از آن بیرون نمی‌رود. ادپیکس یک لایه بالاتر هم دارد که همان آدم را بین کسب‌وکارهای مستقل — فقط بر پایه‌ایمیل مشترک، نه حدس — به هم وصل می‌کند، اما آن لایه فقط برای مدیران پلتفرم ادپیکس قابل خواندن است. هیچ گزارشی در کنسول شما داده کسب‌وکار دیگری را نشان نمی‌دهد.

## نشانه قطعی در برابر نشانه احتمالی

این تنها تمایزی است که باید در خاطر بسپارید، چون همه رفتار سیستم از آن بیرون می‌آید.

| یال | از کجا می‌آید | نوع | اطمینان | ماندگاری |
| --- | --- | --- | --- | --- |
| `explicit_identify` | فراخوانی `ap('identify', …)`، ارسال فرم ورود، یا شناسایی از مسیر سرور به سرور | قطعی | `1.00` | دائمی |
| `email_bridge` | یک ایمیل مشترک بین دو کاربر | قطعی | `1.00` | دائمی |
| `phone_bridge` | یک شماره مشترک بین دو کاربر | قطعی | `1.00` | دائمی |
| `fp_*` | اثر انگشت مرورگر | احتمالی | حداکثر `0.89` | ۳۰ روز |

نشانه قطعی یعنی خود کاربر چیزی را به شما گفته است — چه با ورود در مرورگر، چه با شناسه ای که CRM شما از سمت سرور می‌فرستد. نشانه احتمالی یعنی سیستم از روی اثر انگشت مرورگر حدس زده است.

> **قانونی که هرگز نقض نمی‌شود**
>
> مرز قطعی بودن، اطمینان `0.90` است. یال اثر انگشت هر بار که دوباره دیده شود کمی تقویت می‌شود، ولی سقفش `0.89` است و هیچ وقت از این مرز رد نمی‌شود. یعنی اثر انگشت فقط می‌تواند یک ناشناس را به کاربری که از پیش قطعی شده بچسباند؛ هرگز نمی‌تواند تصمیمی را که با ورود کاربر گرفته شده عوض کند. یال های `fp_*` هم بعد از ۳۰ روز منقضی و پیش از محاسبه شبانه حذف می‌شوند و از آن پس در هیچ اتصالی شرکت نمی‌کنند.

## رویدادهای پیش از ورود چه می‌شوند

این بخشی است که بیشتر از همه سوءتفاهم می‌سازد. رویدادهایی که پیش از شناسایی ثبت شده‌اند **بازنویسی نمی‌شوند**. سطر رویداد در انبار تحلیلی دست نخورده می‌ماند.

به جای آن، در زمان خواندن گزارش یک جدول جایگزینی به رویدادها متصل می‌شود و کاربر سراسری واقعی را برمی‌گرداند. یعنی همان بازدیدی که دیروز ناشناس بود، امروز — بعد از اینکه کاربر وارد شد — زیر نام همان کاربر دیده می‌شود، بدون اینکه حتی یک بایت از داده‌های خام تغییر کرده باشد.

دو نتیجه عملی دارد:

- سفر کاربر از اولین بازدید ناشناس تا خرید، کامل است.
- اتریبیوشن کانال هم درست می‌ماند، چون اولین برخورد پاک نشده است.

## شما چه چیزی را کنترل می‌کنید

شناسایی خودکار روی فرم ها روشن است — وقتی فرمی با فیلد ایمیل یا موبایل پر و ارسال می‌شود، همان مقدار به عنوان نشانه قطعی برداشته می‌شود. فقط همان فیلد خوانده می‌شود؛ رمز عبور و بقیه فیلدها هرگز.

اگر می‌خواهید صریح باشید، خودتان صدا بزنید:

```js
ap('identify', 'user_8421', { email: 'ali@example.com' });
```

```js
ap('identify', 'user_8421', { phone: '09121234567' });
```

شماره پیش از هش شدن به قالب استاندارد بین المللی تبدیل می‌شود و کد کشور پیش‌فرض دارایی را می‌گیرد، پس `09121234567` و `+989121234567` به یک کاربر می‌رسند.

> **یک شناسه بدهید، نه یک ایمیل خام**
>
> اگر شناسه داخلی کاربر را در آرگومان اول بفرستید، حتی وقتی کاربر ایمیلش را عوض کند تاریخچه اش سالم می‌ماند. ایمیل و شماره را در آرگومان دوم بگذارید تا به عنوان پل قطعی به کار بروند.

## هر شب یک بار، همه چیز مرتب می‌شود

یک کار شبانه روی همه یال ها اجزای متصل را دوباره حساب می‌کند و کاربران سراسری تکراری را در هم ادغام می‌کند. قدیمی ترین شناسه برنده است.

هر ادغام در تاریخچه ادغام ثبت می‌شود و برگشت پذیر است — اگر روزی معلوم شود دو نفر اشتباهی یکی شده‌اند، می‌شود جدایشان کرد. نسخه هر هویت هم فقط بالا می‌رود و هیچ وقت کم نمی‌شود، پس مصرف کننده های پایین دست همیشه می‌فهمند چیزی تغییر کرده است.

مدل هویت یک سطح منجمد است؛ تغییرش نیاز به تصمیم معماری مکتوب دارد، نه یک وصله ساده.

## این را کجا در کنسول می‌بینید

هیچ صفحه‌ای «گراف هویت» نام ندارد. اثرش را در جاهای دیگر می‌بینید — تعداد کاربران در صفحه خانه، طول سفر در گزارش مسیر، و نرخ تبدیلی که پس از فعال شدن شناسایی روی سایت شما واقعی تر می‌شود. اگر هنوز تگ را نصب نکرده‌اید، از [نصب تگ اندازه‌گیری](analytics/start/install-the-tag) شروع کنید.

## پرسش‌های پرتکرار

### چرا تعداد کاربران با تعداد جلسه ها جور درنمی آید؟

یک کاربر می‌تواند ده ها جلسه داشته باشد و یک جلسه هرگز به دو کاربر تعلق نمی‌گیرد. اگر نسبت جلسه به کاربر ناگهان بالا رفت، معمولا یعنی کوکی‌ها پاک می‌شوند یا دامنه‌های شما به هم وصل نشده‌اند، نه اینکه ترافیک واقعا بیشتر شده باشد.

### اگر کاربری با دو ایمیل وارد شود چه اتفاقی می‌افتد؟

هر دو ایمیل نشانه قطعی‌اند، پس هر دو کاربر سایت به یک کاربر سراسری می‌رسند و ادغام در تاریخچه ادغام ثبت می‌شود. گزارش‌ها از آن به بعد یک نفر می‌بینند، نه دو نفر.

### پاک شدن کوکی، تاریخچه کاربر را از بین می‌برد؟

خیر. کوکی هویت فقط شناسه ناشناس را نگه می‌دارد و تاریخچه در سمت ادپیکس است. به محض اینکه کاربر دوباره وارد شود یا شناسایی شود، شناسه ناشناس تازه به همان کاربر سراسری قبلی وصل می‌شود و رویدادهای بین این دو هم به او برمی گردند.

### آیا شناسایی بدون رضایت کاربر انجام می‌شود؟

خیر. شناسایی از همان دسته «آماری» پیروی می‌کند که بازدید صفحه و رویدادها از آن پیروی می‌کنند. در حالت انتخاب صریح، تا وقتی کاربر رضایت ندهد نه کوکی ساخته می‌شود نه رویدادی می‌رود.

## مطالب مرتبط

- [نصب تگ اندازه‌گیری](https://docs.adpix.io/fa/analytics/start/install-the-tag/)
- [دسته‌های رضایت](https://docs.adpix.io/fa/concepts/governance/consent-categories/)
- [مرجع دستورهای تراکر](https://docs.adpix.io/fa/analytics/collect/tracker-reference/)

---

[مستندات](https://docs.adpix.io/fa/concepts/foundations/how-adpix-identifies-visitors/) · AdPix