Retention

Retention در آلفانا از Sessionهای تکراری یک Visitor ساخته می‌شود و کمک می‌کند ببینید کاربران بعد از اولین تعامل دوباره به محصول برمی‌گردند یا نه.

SDK برای اینکه بتواند بازگشت‌های یک Visitor را در مرورگر تشخیص دهد، مقدار visitorId را در Browser Storage نگه می‌دارد. تا زمانی که این شناسه در همان محیط مرورگر در دسترس باشد، Sessionهای بعدی می‌توانند به همان Visitor نسبت داده شوند.

این داده پایه تحلیل Returning User و Retention را می‌سازد.

نقش visitorId#

visitorId شناسه‌ای است که Tracker برای دنبال کردن Visitor در Sessionهای مختلف استفاده می‌کند.

وقتی کاربر برای اولین بار وارد سایت می‌شود، SDK می‌تواند یک Visitor Identifier برای او ایجاد کند و آن را در Browser Storage نگه دارد.

در بازدیدهای بعدی، اگر همان شناسه همچنان در مرورگر موجود باشد، Session جدید می‌تواند به همان Visitor متصل شود.

برای مثال:

Visitor A
├── Session 1
├── Session 2
└── Session 3

Retention از همین ارتباط بین Visitor و Sessionهای تکراری ساخته می‌شود.

Sessionهای تکراری#

هر Session بخشی از رفتار کاربر در یک بازه مشخص است.

وقتی یک Visitor در زمان‌های مختلف دوباره به محصول برمی‌گردد، Sessionهای جدیدی برای او ثبت می‌شوند. کنار هم قرار گرفتن این Sessionها کمک می‌کند مشخص شود کاربر فقط یک‌بار وارد محصول شده یا در دوره‌های بعد نیز برگشته است.

برای مثال:

روز اول     → Session 1
روز سوم     → Session 2
روز دهم     → Session 3

در این حالت، گزارش Retention می‌تواند بازگشت همان Visitor را در بازه‌های زمانی مختلف بررسی کند.

شناسایی کاربر بعد از Login#

پیش از Login، Tracker می‌تواند Visitor را با visitorId مرورگر دنبال کند. بعد از اینکه هویت کاربر در محصول شما مشخص شد، می‌توانید ویژگی‌های شناخته‌شده او را با identify() به context Visitor اضافه کنید.

برای مثال:

tracker.identify({
  id: user.id,
  email: user.email,
  plan: user.plan,
});

این اطلاعات کمک می‌کنند Sessionها فقط با یک شناسه ناشناس بررسی نشوند و در تحلیل‌های بعدی context بیشتری درباره کاربر وجود داشته باشد.

برای مثال می‌توانید Retention را بین Planهای مختلف یا گروه‌های مشخصی از کاربران مقایسه کنید.

قرارداد identify()#

در نسخه فعلی، identify() فقط propertyهایی با نوع string می‌پذیرد:

Record<string, string>;

بنابراین اگر مقدار موردنظر عددی یا boolean است، باید قبل از ارسال آن را به string تبدیل کنید.

برای مثال:

tracker.identify({
  id: String(user.id),
  plan: user.plan,
  isTrial: String(user.isTrial),
});

ثابت نگه داشتن نام و نوع propertyها کمک می‌کند Segmentها و تحلیل‌های Retention در طول زمان قابل‌تفسیر باقی بمانند.

identify() چه چیزی را تغییر می‌دهد؟#

identify() ویژگی‌های شناخته‌شده را به context Visitor اضافه می‌کند.

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

برای مثال، به‌جای اینکه فقط Retention کل کاربران را ببینید، می‌توانید رفتار گروه‌هایی مثل این را مقایسه کنید:

• کاربران Plan رایگان
• کاربران Plan Pro
• کاربران Enterprise
• کاربران با Role مشخص
• کاربران یک کشور یا Market مشخص

در این حالت، identify() context بیشتری به Visitor اضافه می‌کند، اما رفتار پایه Retention همچنان از Sessionهای تکراری ساخته می‌شود.

Retention و Login#

Login نقطه مناسبی برای اجرای identify() است، چون در این مرحله معمولاً شناسه و ویژگی‌های قابل اعتماد کاربر در دسترس‌اند.

برای مثال:

async function onLoginSuccess(user) {
  tracker.identify({
    id: String(user.id),
    email: user.email,
    plan: user.plan,
  });
}

بهتر است propertyهایی را ارسال کنید که واقعاً در تحلیل یا Segmenting استفاده می‌شوند و از اضافه کردن داده‌های غیرضروری خودداری کنید.

انتخاب Grain گزارش#

Retention را می‌توان در بازه‌های زمانی مختلف بررسی کرد. انتخاب Grain مناسب به cadence واقعی محصول بستگی دارد.

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

اگر محصول شما یک SaaS است که کاربران چند بار در هفته به آن برمی‌گردند، Retention هفتگی معمولاً خواناتر است.

برای محصول‌هایی که رفتار خرید یا استفاده در آن‌ها کم‌تکرار است، بازه ماهانه می‌تواند تصویر واقعی‌تری بدهد.

یک راهنمای ساده:

این موارد قانون ثابت نیستند؛ بازه را بر اساس رفتار واقعی کاربران محصول خودتان انتخاب کنید.

Retention روزانه#

Retention روزانه زمانی مفید است که بازگشت در فاصله کوتاه برای محصول معنا داشته باشد.

برای مثال، یک ابزار کاری روزانه یا محصولی که کاربران مرتب با آن تعامل دارند.

در این حالت می‌توانید سؤال‌هایی مثل این را بررسی کنید:

• چند درصد کاربران روز بعد برگشته‌اند؟
• بازگشت در روز سوم یا هفتم چگونه تغییر کرده است؟
• کدام Segment بازگشت روزانه بیشتری دارد؟

اگر cadence واقعی محصول هفتگی باشد، استفاده از Daily Retention ممکن است رفتار سالم کاربران را اشتباهاً کم‌تعامل نشان دهد.

Retention هفتگی#

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

کاربری که هفته‌ای دو یا سه بار وارد محصول می‌شود ممکن است در گزارش روزانه Retention ضعیفی داشته باشد، اما از نظر استفاده واقعی کاملاً فعال باشد.

در این حالت می‌توانید Cohortهای هفتگی را بررسی کنید و ببینید چه تعداد از کاربران در هفته‌های بعد دوباره بازمی‌گردند.

Retention ماهانه#

برای محصول‌هایی که خرید یا تعامل اصلی در فاصله‌های طولانی‌تری اتفاق می‌افتد، Monthly Retention می‌تواند انتخاب مناسب‌تری باشد.

برای مثال، اگر انتظار ندارید کاربر هر هفته خرید انجام دهد، Retention ماهانه ممکن است بهتر نشان دهد آیا کاربران در چرخه طبیعی محصول دوباره بازمی‌گردند یا نه.

مهم این است که بازه زمانی با رفتار مورد انتظار محصول هماهنگ باشد.

Visitor و دستگاه#

visitorId در Browser Storage نگهداری می‌شود و به همان محیط مرورگر وابسته است.

بنابراین اگر کاربر از Browser یا Device دیگری وارد شود، نباید به‌صورت خودکار فرض کنید همان Visitor Identifier قبلی در دسترس خواهد بود.

identify() می‌تواند context شناخته‌شده کاربر را ثبت کند، اما در قرارداد فعلی نباید از آن نتیجه گرفت که Identity کاربر در تمام Browserها و Deviceها به‌صورت قطعی و خودکار merge می‌شود.

این تفاوت هنگام تحلیل Retention اهمیت دارد؛ چون رفتار Cross-device می‌تواند نسبت به رفتار داخل یک Browser context متفاوتی داشته باشد.

پاک شدن Browser Storage#

از آنجا که visitorId در Browser Storage نگهداری می‌شود، حذف Storage می‌تواند روی ادامه شناسایی همان Visitor اثر بگذارد.

برای مثال، اگر کاربر:

• داده‌های مرورگر را پاک کند
• از Private Browsing استفاده کند
• Browser دیگری باز کند
• Device دیگری استفاده کند

ممکن است SDK نتواند صرفاً بر اساس Visitor Identifier قبلی همان continuity را حفظ کند.

به همین دلیل، Retention را باید در context محدودیت‌های واقعی Client-side Tracking تفسیر کنید.

Retention و Segmentها#

وقتی ویژگی‌های Visitor با identify() ثبت شده باشند، می‌توانید Retention را برای گروه‌های مختلف با context دقیق‌تری بررسی کنید.

برای مثال:

Plan = free
Plan = pro
Plan = enterprise

یا:

Country = IR
Role = admin
Campaign = spring_sale

این نوع مقایسه می‌تواند نشان دهد آیا یک گروه فقط Conversion اولیه بالاتری دارد یا در دوره‌های بعد نیز بیشتر به محصول برمی‌گردد.

گاهی یک Campaign کاربران زیادی جذب می‌کند اما Retention آن‌ها پایین است. در مقابل، یک Source کوچک‌تر ممکن است کاربران کمتری بیاورد اما بازگشت بیشتری ایجاد کند.

این تفاوت یکی از نشانه‌های مهم برای تحلیل کیفیت جذب کاربر است.

مسیر داشبورد#

گزارش Retention در مسیر فعلی زیر در داشبورد آلفانا قرار دارد:

/dashboard/retention

از این بخش می‌توانید بازگشت کاربران را در بازه‌های زمانی مختلف بررسی کنید و در صورت وجود context کافی، تفاوت بین Cohortها یا گروه‌های کاربران را تحلیل کنید.

نکات اجرایی#

برای اینکه داده Retention قابل‌تفسیرتر باشد:

• Tracker را در تمام صفحات موردنیاز به‌صورت پایدار اجرا کنید.
• بعد از Login، propertyهای مفید را با identify() ثبت کنید.
• نام propertyها را ثابت نگه دارید.
• Grain گزارش را با cadence واقعی محصول هماهنگ کنید.
• رفتار Cross-device را بدون داده قطعی به یک Visitor واحد نسبت ندهید.
• پاک شدن Storage یا تغییر Browser را در تفسیر داده Client-side در نظر بگیرید.
• Retention را در کنار Goal، Journey و Source ورود بررسی کنید تا فقط یک درصد بازگشت بدون context نبینید.