رشد محصول بدون داده ممکن نیست؛ چه Eventهایی را از روز اول Track کنیم؟

رشد محصول بدون داده ممکن نیست؛ اما «داده» به‌معنای داشبورد شلوغ نیست. اگر ندانید کاربر به ارزش رسیده، کجا گیر کرده، کدام قابلیت را لمس کرده و چرا برگشته یا نبرگشته، هر کمپین و هر اسپرینت فقط هزینه است. تحلیل رفتار کاربر از event شروع می‌شود: یک نام، یک زمان، یک زمینه، و قانونی که فردا همان نام را عوض نکنید.

این متن فهرست ابزار نیست و نرخ ساختگی از قیف نمونه نمی‌دهد. هدف این است که از روز اول—حتی در نسخهٔ محدود—قرارداد رویداد را ببندید تا بعداً تاریخچه را دور نریزید. Product Analytics وقتی مفید است که رویداد به تصمیم محصول وصل باشد، نه به کنجکاوی لحظه‌ای تیم.

بدون قرارداد نام، هر event یک بدهی است

قبل از فهرست کردن رویدادها، قانون نام را بنویسید. الگوی رایج و قابل نگهداری این است: object_action به زبان انگلیسی پایدار، با زمان گذشته یا حال مشخص، و بدون نسخه در خود نام. invoice_viewed بهتر از ViewInvoiceNew است. checkout_started بهتر از click_btn_3 است. زبان UI عوض می‌شود؛ شیء دامنه باید ثابت بماند.

خصوصیات (properties) را کم و با نوع مشخص نگه دارید: شناسهٔ موجودیت، نقش کاربر، منبع ورود به جریان، و نتیجه. متن آزاد دکمه‌ها را در event نگذارید؛ فردا لیبل فارسی عوض می‌شود و سری زمانی می‌شکند. Enum را مستند کنید. plan_type با مقادیر محدود بهتر از notes آزاد است.

نسخه‌گذاری را روی طرح رویداد بگذارید، نه روی نام. اگر معنی onboarding_completed عوض شد، یا رویداد جدید بسازید یا property definition_version اضافه کنید و در تحلیل فیلتر کنید. عوض کردن بی‌سروصدای معنی، همان کاری است که عدد را در ظاهر رشد می‌دهد و در واقع تعریف را جابه‌جا کرده است.

مالک طرح مشخص کنید. بدون مالک، هر تیم رویداد موازی می‌سازد: مارکتینگ Lead، محصول signup_done، مهندسی user_created. سه نام برای یک اتفاق، تحلیل رفتار کاربر را غیرممکن می‌کند.

Activation: لحظه‌ای که محصول ارزش را نشان داده، نه لحظهٔ ثبت‌نام

ثبت‌نام رویداد حسابداری است؛ activation رویداد محصول است. Activation را با جملهٔ قابل مشاهده تعریف کنید: کاربر به اولین ارزش رسیده است. در ابزار مدیریت کار ممکن است ساخت اولین پروژه باشد. در فروشگاه ممکن است مشاهدهٔ موجودی قابل‌خرید به‌علاوهٔ فهم قیمت باشد—نه لزوماً خرید. در SaaS ساختمانی ممکن است دیدن وضعیت مالی واحد یا ثبت اولین پرداخت باشد.

رویداد پیشنهادی از روز اول: account_created، activation_reached، و رویداد خام همان عمل ارزشی (مثلاً project_created). activation_reached را مشتق نگه دارید تا تعریف در یک جا عوض شود. اگر فقط عمل خام را داشته باشید و تعریف activation بعداً ترکیب دو عمل شود، بازسازی گذشته سخت می‌شود؛ اما داشتن هر دو لایه معمولاً ارزشش را دارد.

زمان تا activation را به‌عنوان توزیع ببینید، نه یک میانگین فریبنده. میانگین، کسانی را که هرگز فعال نمی‌شوند پنهان می‌کند. بهتر است بپرسید چه سهمی در ۲۴ ساعت، در هفت روز، و هرگز به تعریف می‌رسند. عدد را وقتی گزارش کنید که تعریف پایدار است؛ تا آن روز، کیفیت رویداد مهم‌تر از نمودار است.

اگر activation بین نقش‌ها فرق دارد، یک تعریف واحد اجباری نکنید. همان محصول می‌تواند دو دروازه داشته باشد. این را در بخش نقش‌ها با نمونهٔ خانه‌بان باز می‌کنیم. فعلاً این را در طرح رویداد جا بگذارید: role روی activation اجباری است.

آنبوردینگ توالی است، نه یک صفحهٔ تور

آنبوردینگ را به گام‌های قابل رها کردن بشکنید. رویدادهای پایه: onboarding_started، onboarding_step_completed با step_key، onboarding_skipped، onboarding_completed. step_key باید شناسهٔ پایدار باشد (invite_team نه عنوان نمایشی «دعوت همکاران»). اگر تور فقط یک مودال است و skip ندارد، باز هم skip را بگذارید؛ وگرنه رها کردن جلسه از رها کردن تور قابل تفکیک نیست.

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

جزئیات قیف ثبت‌نام تا ارزش را در طراحی قیف آنبوردینگ SaaS عمیق‌تر ببینید. اینجا حداقل طرح رویداد است تا آن قیف بعداً قابل اندازه‌گیری باشد. بدون step_key پایدار، همان مقاله را هم نمی‌توانید به عدد وصل کنید.

Feature usage: تماشای قابلیت، نه شمردن کلیک تزئینی

برای هر قابلیت مهم سه سطح بگذارید: دیده شدن نقطهٔ ورود (feature_viewed یا رویداد مشخص‌تر)، شروع استفاده (feature_started)، و نتیجهٔ موفق (feature_completed). کلیک روی تب را معادل استفاده نگیرید. باز شدن پنل تنظیمات یعنی دیده شدن؛ ذخیرهٔ تنظیم یعنی تکمیل.

از روز اول همهٔ قابلیت‌ها را track نکنید. سه تا پنج قابلیت که به ارزش یا Retention وصل‌اند کافی است. بقیه را وقتی به تصمیم نزدیک شدند اضافه کنید. طرح شلوغ، کیفیت را پایین می‌آورد و تیم را به نادیده‌گرفتن داشبورد عادت می‌دهد.

برای قابلیت‌های چندمرحله‌ای، شناسهٔ جریان (flow_id) را روی رویدادها حمل کنید تا همان جلسه از جلسات دیگر جدا شود. بدون این، نمی‌فهمید کاربر سه بار تلاش کرده یا سه کاربر جداگانه یک بار آمده‌اند.

رویداد feature_used کلی را به‌تنهایی رها نکنید. اگر مجبورید یک رویداد عمومی داشته باشید، feature_key اجباری باشد. تحلیل بدون کلید، یعنی همهٔ قابلیت‌ها در یک سطل.

Conversion: تعریف پولی یا تعریفی که به پول نزدیک است

تبدیل را مثل activation صریح بنویسید. در SaaS ممکن است trial_started، plan_selected، checkout_started، payment_succeeded باشد. در تجارت، مسیر خرید را با رویدادهای جدا ننویسید که بعداً با قیف فروشگاه یکی نشود. حداقل: مشاهدهٔ موجودیت قابل‌فروش، افزودن، شروع تسویه، پرداخت موفق.

وضعیت شکست را هم ثبت کنید: payment_failed با دلیل دسته‌بندی‌شده، نه متن خام درگاه. checkout_abandoned را اگر می‌توانید در سرور از روی نشست ناقص بسازید؛ فقط به ترک صفحه در کلاینت تکیه نکنید. بستن تب با قطع شبکه فرق دارد و هر دو در کلاینت شبیه به نظر می‌رسند.

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

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

خطا و اصطکاک: جایی که رشد قبل از مارکتینگ می‌میرد

رویداد خطا را از لاگ مهندسی جدا کنید اما به آن وصل کنید. flow_error با flow_key، error_code پایدار و اینکه کاربر توانست ادامه دهد یا نه. نمایش toast را معادل خطا نگیرید اگر کاربر همان لحظه موفق شده. خطای مسدودکننده با خطای هشدار در یک سطل، اولویت را خراب می‌کند.

نمونه‌های روز اول: شکست ورود، شکست پرداخت، شکست بارگذاری فهرست اصلی، شکست تحویل یا صدور. اگر محصول فایل یا پیامک یا درگاه خارجی دارد، شکست همان اتصال را با نام سرویس ثبت کنید. این‌ها ورودی صف محصول‌اند، نه فقط آلارم DevOps.

نرخ خطا را روی همان جریان activation و conversion بگذارید. اگر پرداخت موفق کم است و payment_failed بالا نیست، مشکل ممکن است نرسیدن به درگاه باشد نه خود درگاه. بدون رویداد شروع و شکست، این تفکیک را حدس می‌زنید.

Retention: برگشتن به ارزش، نه باز شدن اپ

Retention را با رویداد ارزشی بسنجید نه با session_started تنها. جلسه لازم است، اما بازگشت بدون عمل ارزشی، عادت ضعیف است. رویداد value_action_performed یا همان عمل activation تکراری را در روزهای بعد دنبال کنید. تعریف «کاربر فعال هفتگی» باید به همان عمل وصل باشد.

از روز اول session_started و شناسهٔ نشست را داشته باشید تا فاصلهٔ بین ارزش‌ها قابل محاسبه باشد. نیازی به مدل پیچیدهٔ کوهورت در هفتهٔ اول نیست؛ نیاز به این است که بعداً بتوانید کوهورت بسازید چون شناسهٔ کاربر و زمان عمل را درست ذخیره کرده‌اید.

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

نقش‌های متفاوت، رویدادهای متفاوت: نمونهٔ خانه‌بان

محصول چندنقشی را با یک قیف واحد نشکنید. خانه‌بان نرم‌افزار مدیریت شارژ و هزینه‌های ساختمان است؛ مدیر ساختمان و ساکن هر دو کاربرند اما ارزش اولیه‌شان یکی نیست. این بخش محتوای حقوقی یا آموزش مدیریت آپارتمان نیست. بحث این است که event باید نقش را حمل کند.

برای مدیر، activation ممکن است دیدن تصویر بدهی‌ها یا ثبت یک هزینه/شارژ باشد. رویدادهای نقش‌محور مثل charge_cycle_viewed، expense_recorded، resident_invited به تصمیم مدیر وصل‌اند. برای ساکن، activation ممکن است دیدن قبض واحد یا تکمیل پرداخت باشد: invoice_viewed، payment_succeeded با role=resident. اگر هر دو را در یک task_done بدون نقش بریزید، رشد یک نقش، افت نقش دیگر را می‌پوشاند.

آنبوردینگ هم جدا می‌شود. دعوت ساکن توسط مدیر یک جریان است؛ ورود ساکن از لینک دعوت جریان دیگر. رویداد invite_sent و invite_accepted را با نقش گیرنده ثبت کنید. بدون این، نمی‌فهمید مشکل رشد از نپیوستن ساکن است یا از استفاده‌نکردن مدیر از ابزار دعوت.

رویدادهای تجاری از جست‌وجو تا تأیید تحویل: نمونهٔ هایپراکانت

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

حداقل مجموعه: search_performed با تعداد نتایج (نه متن کامل جست‌وجو اگر حساس است)، product_viewed، add_to_cart، checkout_started، payment_succeeded، delivery_confirmed. تأیید تحویل در کالای دیجیتال معادل رسیدن وضعیت «قابل استفاده» است، نه اسکن انبار. اگر تحویل شکست بخورد، delivery_failed با کد دلیل برای صف پشتیبانی و محصول حیاتی است.

جست‌وجوی صفر نتیجه را جدا ببینید. این رویداد کشف کاتالوگ است نه شکست مهندسی. افزودن به سبد بدون product_viewed در همان نشست ممکن است از لیست باشد؛ منبع را در property بگذارید. جزئیات مدل دادهٔ فروشگاه را در تحلیل دادهٔ فروشگاه اینترنتی از رویداد تا قیف ادامه دهید تا این طرح با گزارش مالی یکی شود اما در جدول event قاطی نشود.

حریم خصوصی: حداقل داده، حداکثر تصمیم

از روز اول چیزی را track نکنید که برای تصمیم محصول لازم نیست. متن پیام، محتوای جست‌جوی حساس، شناسهٔ ملی، و داده‌های پرداخت خام در لایهٔ analytics نباید بروند. شناسهٔ سفارش و وضعیت کافی است. IP و شناسه‌های تبلیغاتی را فقط اگر هدف مشخص و مبنای قانونی دارید جمع کنید؛ پیش‌فرض این مقاله حداقل‌گرایی است.

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

Retention داده هم سیاست می‌خواهد. رویداد خام برای همیشه لازم نیست. برای رشد محصول، سری زمانی تجمیعی و نمونهٔ محدود جلسه معمولاً کافی است. انبار ابدی کلیک، ریسک است نه بلوغ داده.

شناسهٔ کاربر را پایدار و قابل حذف طراحی کنید. وقتی حساب پاک می‌شود، مسیر حذف یا بی‌نام‌سازی event را از قبل داشته باشید. این جزئیات را هفتهٔ بیستم اختراع نکنید؛ در روز اول ارزان‌تر است.

رویداد محصول را با سیگنال جست‌وجو عوضی نگیرید. عنوان و canonical صفحه در Metadata API برای خزنده است؛ Product در Schema.org برای فهم موجودیت در نتایج است؛ ایندکس و خزش در Search Central می‌گوید گوگل صفحه را چطور پیدا می‌کند. هیچ‌کدام جایگزین activation_reached یا payment_succeeded نیستند. اگر JSON-LD شناسهٔ کاربر یا ایمیل بگذارد، هم حریم خصوصی را می‌شکنید هم لایهٔ رشد را با لایهٔ سئو قاطی کرده‌اید.

پرسش‌های متداول

از روز اول چند event کافی است؟

کمتر از آن‌که به نظر می‌رسد. پوشش دهید: ساخت حساب، activation، چند گام آنبوردینگ، یک تا سه قابلیت، شروع و موفقیت تبدیل، خطاهای مسدودکننده، و یک عمل ارزشی تکراری برای retention. بیست رویداد مبهم بدتر از هشت رویداد با تعریف است.

نام فارسی برای event بهتر نیست؟

برای نمایش در داشبورد بله؛ برای کلید فنی خیر. کلید پایدار انگلیسی یا لاتین با مستند فارسی، تحلیل و کد را از تغییر لیبل UI جدا می‌کند. ترجمه را در لایهٔ گزارش بگذارید.

آیا کلیک همهٔ دکمه‌ها را ثبت کنیم؟

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

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