اگر ریزش روز اول (D1) در اپ شما بالاست، معمولاً مشکل با «پوش/اساماس/دیپلینک» حل نمیشود؛ مشکل اصلی در تجربه ورود کاربر و سنجش ناقص آن است. تا وقتی ندانید کاربر دقیقاً در کدام قدم آنبوردینگ گیر میکند، هر بهینهسازی بیشتر شبیه حدسزدن است. این مقاله یک راهنمای عملی برای ساخت mobile app onboarding funnel است: از تعریف تاکسونومی رویدادها و ۱۲ رویداد کلیدی، تا ساخت قیفهای Activation، کوهورتهای D1/D7/D30، داشبورد Retention، و یک چکلیست QA برای جلوگیری از خطاهای اندازهگیری.
هدف: در کمتر از چند روز بتوانید یک سیستم اندازهگیری قابل اتکا بسازید که نشان دهد «کاربر کجا میریزد، چرا میریزد، و کدام تغییر بیشترین اثر را دارد».
این مقاله برای چه تیمهایی است؟
- تیم محصول/گروث که میخواهد ریزش روز اول را کاهش دهد.
- مارکتینگ اپ که بهجای پیامرسانی، روی تجربه ورود تمرکز میکند.
- تحلیلگر داده که باید رویدادها را استاندارد کند و قیف بسازد.
فهرست مطالب
- تعریف دقیق فانل آنبوردینگ
- ذهنیت درست اندازهگیری قبل از ساخت قیف
- تاکسونومی رویدادها: زبان مشترک تیم
- ۱۲ رویداد کلیدی برای فانل آنبوردینگ
- ساخت قیفهای Activation (چندنسخهای)
- کوهورتهای D1/D7/D30 و Retention
- داشبوردهای ضروری برای تصمیمگیری
- قالب پیادهسازی در GA4/Firebase و Mixpanel
- چکلیست QA اندازهگیری
- خطاهای رایج و دامهای اندازهگیری
- سوالات پرتکرار
تعریف دقیق «فانل آنبوردینگ» و مرز آن با فعالسازی
فانل آنبوردینگ مجموعه قدمهایی است که کاربر از لحظه اولین اجرا تا رسیدن به «اولین ارزش واقعی» طی میکند. بسیاری از تیمها آنبوردینگ را با چند اسلاید خوشامدگویی اشتباه میگیرند؛ اما در اندازهگیری، آنبوردینگ یعنی: رویدادهای قابل مشاهده که نشان میدهند کاربر به سمت ارزش حرکت کرده یا متوقف شده است.
برای جلوگیری از بحثهای بیپایان، دو تعریف عملی داشته باشید:
- Onboarding Funnel: قدمهای لازم برای رسیدن به «آماده استفاده» (مثل اجازهها، ساخت حساب، تنظیمات اولیه).
- Activation: اولین اقدام/نتیجهای که ارزش محصول را ثابت میکند (مثلاً اولین سفارش موفق، اولین ذخیره فایل، اولین پیام ارسالشده).
این مقاله mobile app onboarding funnel را بهصورت کامل پوشش میدهد، اما در عمل باید آن را تا رویداد Activation امتداد دهید؛ چون بسیاری از ریزشهای D1 دقیقاً بین «ثبتنام» و «اولین ارزش» رخ میدهد.
قبل از رویدادها: ذهنیت درست اندازهگیری برای کاهش ریزش D1
بهینهسازی وقتی سریع میشود که «فرضیه» قابل آزمون داشته باشید. پس قبل از ساخت رویدادها، این سه سوال را پاسخ دهید:
- کاربر باید در D0 چه چیزی را تجربه کند؟ (تعریف ارزش اولیه)
- کدام اصطکاکها اجتنابناپذیرند؟ (مثل احراز هویت یا پرداخت)
- کدام اصطکاکها انتخابیاند؟ (مثل تکمیل پروفایل، انتخاب علاقهمندی)
قاعده عملی: هر قدم انتخابی که قبل از ارزش اولیه قرار میدهید، باید در فانل جداگانه اندازهگیری شود؛ وگرنه با سقوط نرخ تبدیل، نمیفهمید مشکل از «قدم انتخابی» بوده یا «قدم حیاتی».
نقطه شروع خوب: نقشه تجربه ۱۵ دقیقهای
روی یک کاغذ، مسیر ۱۵ دقیقه اول کاربر را بکشید: نصب → اجرا → … → ارزش. سپس برای هر گام، یک «رویداد» تعریف کنید. هدف این نیست که همهچیز را ترک کنید؛ هدف این است که نقاط تصمیم و نقاط شکست را قابل مشاهده کنید.
تاکسونومی رویدادها: زبان مشترک تیم محصول، مارکتینگ و دیتا
بدون تاکسونومی، گزارشها با هم سازگار نمیشوند: یک تیم میگوید «ثبتنام»، تیم دیگر «لاگین»، تیم سوم «ورود موفق». نتیجه: قیفهای چندگانه با اعداد متناقض.
یک تاکسونومی خوب سه بخش دارد:
- نامگذاری رویداد: فعل+شیء+وضعیت (مثلاً signup_submitted، signup_succeeded، permission_location_granted).
- پارامترها: حداقل دادهای که برای تحلیل لازم است (مثل method، error_code، screen_name).
- قواعد ارسال: چه زمانی ارسال شود، چندبار، و با چه شرطی.
حداکثر ۵–۱۰ اصطلاح فنی که تیم باید دقیق بداند
- Event (رویداد)
- Property/Parameter (پارامتر)
- Funnel (قیف)
- Cohort (کوهورت)
- Retention (ریتِنشن)
- Attribution (اتریبیوشن/انتساب)
- Identity (شناسه کاربر)
نکته: اگر در تاکسونومی، «شناسه کاربر» را شل بگیرید، کل mobile app onboarding funnel شما روی شن ساخته میشود. در بخش QA به آن برمیگردیم.
۱۲ رویداد کلیدی برای فانل آنبوردینگ (با مثال پارامترها)
این ۱۲ رویداد طوری انتخاب شدهاند که برای اکثر اپها (مارکتپلیس، فینتک، خدماتی، محتوا/اشتراک) قابل انطباق باشند. اگر محصول خاصی دارید، ۲–۳ رویداد اختصاصی به انتهای لیست اضافه کنید، اما اسکلت را تغییر ندهید.
- app_first_open: اولین اجرای اپ بعد از نصب
- پارامترهای پیشنهادی: install_source (در حد «organic/paid» بدون نام کمپین در رویداد)
- onboarding_started: شروع تجربه ورود (بعد از اسپلش/لود اولیه)
- onboarding_step_viewed: مشاهده هر قدم آنبوردینگ
- step_id، step_type (intro, permission, profile, tutorial)
- onboarding_step_completed: تکمیل هر قدم
- step_id، completion_method (skip/submit/auto)
- permission_prompt_shown: نمایش درخواست دسترسی (نوتیفیکیشن، لوکیشن، مخاطبین…)
- permission_result: نتیجه دسترسی
- permission_type، result (granted/denied)
- signup_started: ورود به جریان ثبتنام
- signup_succeeded: ثبتنام موفق
- method (otp, email, google, apple)، is_new_user (true/false)
- login_succeeded: ورود موفق (برای بازگشتیها یا بعد از خروج)
- activation_started: کاربر وارد مسیر ارزش (مثلاً شروع ساخت اولین پروژه/سبد)
- activation_completed: تحقق ارزش اولیه (تعریف اختصاصی محصول)
- onboarding_abandon_detected: رویداد کمکی برای تشخیص ریزش (اختیاری اما مفید)
- last_step_id، last_screen، session_duration_bucket
چرا «onboarding_abandon_detected»؟ چون در بسیاری از ابزارها، فهمیدن اینکه کاربر «واقعاً کجا رها کرده» نیاز به تفسیر دارد. این رویداد را میتوانید با منطق سمت کلاینت بسازید (مثلاً اگر ۶۰ ثانیه در یک قدم ماند و اپ بسته شد).
مثال واقعی: اپ خدماتی با OTP
کاربر app_first_open را میزند، onboarding_step_viewed را برای قدم معرفی میگیرد، سپس signup_started → OTP → signup_succeeded. اگر بین signup_started و signup_succeeded ریزش زیاد باشد، باید رویداد خطای OTP (در قالب پارامتر error_code روی signup یا رویداد جدا) را اضافه کنید، نه اینکه صرفاً UI را حدس بزنید.
ساخت قیفهای Activation: سه قیف که باید داشته باشید
یک قیف کافی نیست. برای مدیریت بهتر، سه قیف بسازید که هر کدام یک سوال مشخص را جواب دهند. در همه اینها، mobile app onboarding funnel هسته داده است، اما خروجیها متفاوتاند.
۱) قیف «حداقلی» (Core Funnel)
این قیف باید کوتاه و مقاوم به تغییرات UI باشد:
- app_first_open → onboarding_started → signup_succeeded/login_succeeded → activation_completed
کاربرد: رصد روزانه سلامت ورود کاربران.
۲) قیف «جزئیات» (Diagnostic Funnel)
برای پیدا کردن گلوگاهها:
- app_first_open → onboarding_step_viewed(step=1) → step_completed(step=1) → … → permission_result → signup_succeeded → activation_completed
کاربرد: تصمیمگیری برای حذف/جابجایی قدمها، یا تغییر متن/زمان درخواست دسترسی.
۳) قیف «تفکیکی» (Segmented Funnel)
همان قیف جزئیات، اما با سگمنتهای کلیدی:
- کانال جذب (paid/organic)
- پلتفرم/نسخه اپ
- نوع دستگاه (سطحی: low/mid/high)
- روش ثبتنام (otp/email/social)
کاربرد: فهم اینکه مشکل تجربه ورود «عمومی» است یا فقط برای یک سگمنت.
کوهورتهای D1/D7/D30: چگونه Retention را به آنبوردینگ وصل کنیم
Retention وقتی معنیدار میشود که به «کیفیت ورود» گره بخورد. کاربری که فقط ثبتنام کرده با کاربری که Activation را کامل کرده، ارزش و رفتار متفاوتی دارد.
تعریف کوهورتها
- Cohort A: کاربرانی که app_first_open داشتهاند (همه ورودیها)
- Cohort B: کاربرانی که signup_succeeded/login_succeeded داشتهاند
- Cohort C: کاربرانی که activation_completed داشتهاند
حالا برای هر کوهورت، D1/D7/D30 Retention را بسنجید. اگر Retention Cohort C خوب است اما A و B بد هستند، یعنی مشکل شما بیشتر «ورود به ارزش» است نه خود ارزش محصول.
تعریف رویداد بازگشت (Return Event)
در اپهای مختلف، معیار بازگشت فرق میکند. پیشنهاد عملی:
- برای اکثر اپها: session_start یا app_open (بدون وسواس بیش از حد)
- برای اپهای transaction محور: activation_started یا view_key_screen
نکته کلیدی: معیار بازگشت را ثابت نگه دارید تا قبل/بعد از تغییرات آنبوردینگ قابل مقایسه باشد. اگر امروز Retention را با app_open و فردا با purchase بسنجید، نمودارها زیبا میشوند اما تصمیمها اشتباه.
داشبوردهای ضروری Retention و Drop-off (حداقلهای تصمیمساز)
داشبورد قرار نیست همهچیز را نشان دهد؛ باید «تصمیم» را آسان کند. برای mobile app onboarding funnel سه داشبورد/بخش لازم دارید:
۱) داشبورد سلامت روزانه (Daily Health)
- تعداد app_first_open
- نرخ onboarding_started از app_first_open
- نرخ signup_succeeded
- نرخ activation_completed
- نرخ crash/freezing در مسیر ورود (اگر دارید)
۲) داشبورد ریزش قدمبهقدم (Step Drop-off)
- Drop-off بین step_viewed و step_completed برای هر step_id
- نتیجه permission_result به تفکیک permission_type
- میانگین زمان هر قدم (اگر ابزار اجازه میدهد)
۳) داشبورد کوهورت و نگهداشت (Cohort Retention)
- D1/D7/D30 برای Cohort A/B/C
- Retention به تفکیک کانال جذب و نسخه اپ
یک جدول مقایسهای: GA4/Firebase یا Mixpanel؟
| نیاز | GA4/Firebase | Mixpanel |
|---|---|---|
| راهاندازی پایه و رایج در اپ | سریع و استاندارد، مناسب اغلب تیمها | نیازمند تنظیم دقیقتر، اما تجربه تحلیل محصول قوی |
| تحلیل قیف و سگمنتسازی | قابل انجام، اما در برخی سناریوها محدودتر | قویتر برای قیفهای چندمرحلهای و برشهای پیشرفته |
| کوهورت و Retention | قابل انجام با گزارشها/اکسپلور | مخصوص تحلیل Retention و Cohort با انعطاف بالا |
| کار تیمی (PM/Marketing/Data) | وابستگی بیشتر به تنظیمات و تفسیر | معمولاً برای تیم محصول خواناتر |
اگر هنوز تصمیم نگرفتهاید، شروع با GA4/Firebase برای استانداردسازی و سپس مهاجرت/اتصال Mixpanel برای تحلیل عمیق، سناریوی رایجی است.
قالب آماده پیادهسازی: رویدادها و پارامترها (GA4/Firebase یا Mixpanel)
برای اینکه پیادهسازی در تیم توسعه سریع شود، یک فایل مشخصات رویداد (Event Spec) بسازید که شامل این ستونها باشد:
- event_name
- when_to_fire (دقیق و قابل تست)
- properties/parameters
- example values
- notes (مثل محدودیت تکرار یا نیاز به dedup)
نمونه مشخصات برای یک رویداد
- event_name: permission_result
- when_to_fire: بعد از پاسخ کاربر به سیستمپاپآپ دسترسی
- parameters: permission_type, result, screen_name
- example: permission_type=notifications, result=denied, screen_name=onboarding_permissions
- notes: فقط یکبار برای هر permission_type در هر نصب (یا با versioning)
نکته مهم برای اتصال داده به کانال جذب
در این مقاله تمرکز روی تجربه ورود است، اما برای تحلیل سگمنت کانال، بهتر است از مکانیزمهای درست انتساب استفاده کنید. اگر در حال طراحی یا اصلاح مسیر ورود از لینکها هستید، مطالعه راهنمای کامل دیپلینکینگ در اپ موبایل کمک میکند تا ریزش «بین کلیک تا ورود» را با «ریزش داخل آنبوردینگ» قاطی نکنید.
همچنین اگر قصد دارید بعد از بهبود mobile app onboarding funnel از پوش برای فعالسازی مجدد استفاده کنید، بهتر است طراحی پیامها هم سیستماتیک باشد؛ در این مورد چکلیست طراحی پوش نوتیفیکیشن یک چارچوب اجرایی میدهد.
چکلیست QA: قبل از تحلیل، مطمئن شوید داده درست است
بیشترین شکست پروژههای فانل از «تحلیل ضعیف» نیست؛ از «داده نادرست» است. این چکلیست را قبل از هر تصمیم محصولی اجرا کنید.
چکلیست QA (قابل اجرا در ۳۰–۶۰ دقیقه)
- رویدادهای step_viewed و step_completed برای همه قدمها ارسال میشوند (نه فقط برخی دستگاهها).
- signup_succeeded و login_succeeded هرگز همزمان برای یک اقدام ثبت نمیشوند (دوگانگی).
- شناسه کاربر بعد از ثبتنام ثابت میشود و بین sessionها تغییر نمیکند (Identity).
- رویدادها دوبار ارسال نمیشوند (Dedup در شرایط retry/شبکه ضعیف).
- پارامتر step_id در همه رویدادهای مرتبط یکسان است (مثلاً 1,2,3 یا intro,permission,profile).
- برای permission_result، نتیجه denied/granted مطابق رفتار سیستمعامل ثبت میشود.
- زمان دستگاه مشکل ایجاد نکرده است (برای تحلیلهای روزانه، اختلاف timezone را بررسی کنید).
- نسخه اپ (app_version) بهعنوان پارامتر یا property ثبت میشود.
پیشنهاد: یک «سناریو تست دستی» تعریف کنید (مثلاً ثبتنام با OTP + رد کردن دسترسی نوتیفیکیشن) و مطمئن شوید رشته رویدادها دقیقاً همان چیزی است که در مشخصات نوشتهاید.
خطاهای رایج در ساخت فانل آنبوردینگ (و راه اصلاح)
این اشتباهات باعث میشوند قیفها بهظاهر کار کنند اما تصمیمها گمراهکننده شوند.
۱) یکی گرفتن «ثبتنام» با «فعالسازی»
اگر success را signup_succeeded بگیرید، ممکن است نرخ تبدیل خوب شود اما D1 بد بماند. راه اصلاح: activation_completed را دقیق و قابل سنجش تعریف کنید.
۲) اضافه کردن قدمهای انتخابی قبل از ارزش، بدون اندازهگیری جداگانه
مثل اجبار به تکمیل پروفایل یا انتخاب علاقهمندی. راه اصلاح: این قدمها را یا بعد از Activation منتقل کنید یا یک قیف جدا برایشان بسازید.
۳) رویدادهای «صفحهمحور» بهجای «رفتارمحور»
اگر فقط screen_view داشته باشید، با تغییر UI یا A/B تست، قیف میشکند. راه اصلاح: رویدادهای معنادار مثل step_completed و permission_result تعریف کنید.
۴) عدم تفکیک کاربران جدید و بازگشتی
ورودی روزانه ترکیبی از نصب جدید و کاربران قدیمی است. راه اصلاح: is_new_user را اضافه کنید یا کوهورت را بر اساس app_first_open بسازید.
۵) قیف بدون سگمنت نسخه اپ
گاهی ریزش فقط از یک نسخه باگدار میآید. راه اصلاح: app_version را در همه رویدادهای کلیدی داشته باشید و گزارشها را بر اساس آن بشکنید.
۶) تصمیمگیری بر اساس یک روز داده
تغییرات کوچک در ورودیها (کمپین، فصل، اختلال شبکه) نمودار را تکان میدهد. راه اصلاح: حداقل ۷ روز یا یک چرخه معنادار کسبوکار را مقایسه کنید.
FAQ: سوالات پرتکرار درباره mobile app onboarding funnel
۱) «فانل آنبوردینگ» را از کجا شروع کنم اگر هیچ رویدادی نداریم؟
با ۵ رویداد پایه شروع کنید: app_first_open، onboarding_started، signup_succeeded، activation_started، activation_completed. سپس برای قدمهای آنبوردینگ step_viewed/step_completed را اضافه کنید.
۲) اگر آنبوردینگ ما اسکرینهای زیادی دارد، چطور رویدادها را زیاد نکنیم؟
بهجای رویداد جدا برای هر اسکرین، از یک رویداد عمومی onboarding_step_viewed با پارامتر step_id استفاده کنید؛ همین الگو برای step_completed هم جواب میدهد.
۳) بهترین تعریف Activation برای اپهای محتوا/اشتراک چیست؟
معمولاً «مصرف ارزش» بهتر از «ثبتنام» است: مثلاً view_content_depth رسیدن به یک آستانه، save_to_favorites، یا شروع trial. شرط: رویداد باید با ارزش واقعی و احتمال بازگشت همبستگی داشته باشد.
۴) چرا Retention را برای سه کوهورت A/B/C جدا میسنجیم؟
چون کیفیت ورود متفاوت است. اگر Retention Cohort C بالاتر باشد، یعنی مشکل اصلی شما رساندن کاربر به Activation است، نه نگهداشت بعد از آن.
۵) برای کاهش ریزش روز اول، اول روی permissionها کار کنیم یا ثبتنام؟
با داده تصمیم بگیرید: اگر drop-off در permission_result(denied) بالاست، ترتیب درخواست دسترسی را تغییر دهید (مثلاً بعد از توضیح ارزش). اگر بین signup_started و signup_succeeded سقوط دارید، مشکل بیشتر friction ثبتنام/OTP است.
۶) آیا لازم است کانالها را با UTM به فانل وصل کنیم؟
برای تحلیل سگمنت کانال مفید است، اما اول داده رفتار داخل اپ را درست کنید. سپس اتصال انتساب را انجام دهید تا بفهمید کدام کانال «کاربر باکیفیت» میآورد.
۷) چطور بفهمیم بهبود آنبوردینگ واقعاً اثر داشته یا فقط نوسان ورودی بوده؟
قبل/بعد را با پنجره زمانی یکسان و با تفکیک کانال/نسخه اپ مقایسه کنید، و اگر امکان دارید A/B تست بگذارید. همچنین نرخ activation_completed و D1 Retention را همزمان بررسی کنید.
۸) بعد از ساخت فانل، گام بعدی برای رشد چیست؟
وقتی mobile app onboarding funnel پایدار شد، میتوانید سراغ بهینهسازی پیامرسانی و بازگشت بروید (پوش، ایمیل، دروناپ)؛ اما این کار زمانی بازده دارد که ریزش در ورود کنترل شده باشد.
جمعبندی: با یک تاکسونومی ساده، ۱۲ رویداد کلیدی، سه قیف (Core/Diagnostic/Segmented)، کوهورتهای A/B/C و داشبوردهای Drop-off و Retention، شما یک سیستم عملی برای کاهش ریزش روز اول میسازید؛ سیستمی که بهجای حدس، با داده مسیر ورود را اصلاح میکند.
