تلمتری محصول: چه دادهای جمع کنیم و چرا
بعد از راهاندازی، دو حالت ممکن است. یا نمیدانید کاربران با سامانه چه میکنند، یا آنقدر داشبورد دارید که هیچکدام را نگاه نمیکنید.
حالت دوم شایعتر است و کسی به آن اعتراف نمیکند. سامانهای که چهل نمودار دارد و هیچ تصمیمی از آنها بیرون نمیآید، بدتر از سامانهای است که پنج عدد دارد و هر پنجتا هفتهای یک بار خوانده میشوند.
تفاوت در ترتیب کار است: از سؤال شروع کنید، نه از داده.
تفکیکی که همهچیز را ساده میکند
دو نوع داده که ابزارهایشان شبیه است و مصرفکنندههایشان کاملاً متفاوت:
سنجهٔ فنی — سامانه سالم است؟ نرخ خطا، زمان پاسخ، مصرف منابع، صفهای عقب مانده. مخاطبش تیم فنی است و بحثش در پایش و لاگ و SLO آمده.
تلمتری محصول — کاربر چه میکند؟ کدام قابلیت استفاده میشود، کجا رها میکند، چقدر طول میکشد تا کار را تمام کند. مخاطبش کسی است که تصمیم میگیرد چه چیزی بعد ساخته شود.
سازمانها معمولاً اولی را دارند و دومی را ندارند — و بعد بکلاگ را با نظر بلندترین صدای جلسه پر میکنند.
این مقاله دربارهٔ دومی است.
از سؤال شروع کنید
پیش از افزودن هر رویدادی، سه ستون بنویسید: سؤال، رویدادی که جوابش میدهد، تصمیمی که با جواب گرفته میشود.
اگر ستون سوم خالی است، آن رویداد را اضافه نکنید.
| سؤال | رویداد | تصمیم |
|---|---|---|
| کاربران در ثبت سفارش کجا رها میکنند؟ | هر گام قیف با نتیجه | کدام گام بازطراحی شود |
| قابلیت جدید استفاده میشود؟ | اولین و nامین استفاده به تفکیک کاربر | نگه داشتن یا حذف |
| جستوجو جواب میدهد؟ | جستوجو با تعداد نتیجه و کلیک بعدی | بهبود موتور یا کاتالوگ |
| کجا خطا میبینند؟ | خطای نمایشدادهشده با نوع | اولویت رفع |
چهار ردیف. سازمانی که چهار سؤال روشن دارد، از سازمانی که چهل نمودار دارد جلوتر است.
آن ستون سوم، همان چیزی است که مانع از تبدیل شدن تلمتری به انبار داده میشود.
طراحی رویداد: قراردادی که باید ثابت بماند
رویدادها دادهاند و مثل هر دادهای طرحواره لازم دارند. چهار قاعده که از تجربهٔ اصلاح کردن سامانههای بیقاعده آمدهاند:
نامگذاری یکنواخت و پیشبینیپذیر. یک الگو انتخاب کنید — موجودیت.عمل —
و همهجا رعایتش کنید. مخلوطی از ثبت_سفارش، orderCreated و
checkout-complete در یک سامانه، یعنی هیچکس نمیداند دنبال چه بگردد.
رویداد کم، ویژگی زیاد. بهجای سه رویداد جدا برای سه نوع جستوجو، یک رویداد
جستوجو با ویژگی نوع. تحلیل سادهتر میشود و تغییرات کمتر میشکنند.
شناسهای که به سنجهٔ فنی وصل شود. اگر شناسهٔ درخواست را در رویداد محصولی هم داشته باشید، میتوانید بپرسید «آیا کاربرانی که رها کردند، کندی تجربه کردند؟» — سؤالی که بدون این اتصال قابل جواب نیست.
نسخهگذاری. رویدادی که معنایش عوض شود بدون اینکه نامش عوض شود، تاریخچهٔ تحلیل را خراب میکند: نمودار پرش میکند و هیچکس نمیداند چون رفتار کاربر عوض شده یا چون تعریف عوض شده.
و مثل هر تصمیم بادوام دیگری، طرحوارهٔ رویدادها جایی مکتوب میشود که نفر بعدی پیدایش کند — همانجا که تصمیمها ثبت میشوند.
چه چیزی را جمع نکنید
اینجا جایی است که تلمتری از یک ابزار مفید به یک بدهی تبدیل میشود.
دادهٔ شخصیای که سؤالتان به آن نیاز ندارد. برای فهمیدن اینکه کاربران کجا رها میکنند، به نام و شمارهٔ تلفن نیاز ندارید. شناسهٔ مستعار کافی است. مفصلتر در جمعآوری داده و حریم خصوصی.
«همهچیز، شاید بعداً لازم شد». این استدلال، انبار دادهای میسازد که هزینهٔ نگهداری دارد، سطح حمله دارد، و بهندرت استفاده میشود.
دادهای که کسی مالکش نیست. هر داشبورد باید یک صاحب داشته باشد. داشبورد بیصاحب، سه ماه بعد دادهاش غلط است و کسی نمیداند.
سنجههایی که واقعاً تصمیم میسازند
از میان چیزهایی که میشود شمرد، اینها بیشترین ارزش را در سامانههای سازمانی داشتهاند:
نرخ تکمیل هر جریان کاری. چند درصد کسانی که شروع کردند، تمام کردند. اگر یک عدد را انتخاب میکنید، این باشد.
زمان تا اولین ارزش. از ثبتنام تا اولین کاری که واقعاً مفید بوده. این سنجهٔ تجربهٔ اولین اجرا است و در سامانههای B2B با آموزشپذیری مستقیم رابطه دارد.
استفادهٔ واقعی از هر قابلیت. فهرست قابلیتهایی که کمتر از یک درصد کاربران استفاده میکنند، معمولاً کوتاه نیست — و هر ردیفش هزینهٔ نگهداری دارد.
نرخ خطای دیدهشده توسط کاربر. نه خطای سرور — خطایی که کاربر روی صفحه دید. این دو عدد متفاوتاند و دومی مهمتر است.
مسیرهایی که به پشتیبانی ختم میشوند. اگر تیکتها را برچسب بزنید، این فهرست بهترین منبع بکلاگ است که سراغ داریم و تقریباً همیشه نادیده گرفته میشود.
حلقهای که باید بسته شود
تلمتری وقتی ارزش دارد که به تغییر ختم شود. حلقهٔ کامل چهار گام است:
اندازهگیری → تصمیم → تغییر → اندازهگیری دوباره.
آن گام چهارم است که معمولاً انجام نمیشود. تیم صفحهای را بازطراحی میکند چون داده گفته مسئله دارد، و بعد هیچوقت برنمیگردد ببیند بهتر شد یا نه.
رویهای که پیشنهاد میکنیم: هر تغییری که از داده آمده، عدد هدفش را از قبل بنویسد — «نرخ تکمیل از ۶۲٪ به بالای ۷۵٪». بدون این، بعد از تغییر همیشه میشود روایتی ساخت که موفقیت را نشان دهد.
و اگر عدد جابهجا نشد، این خودش یک یافته است. قابلیتی که ساخته شد و چیزی را عوض نکرد، اطلاعاتی دربارهٔ فرضیههای شما میدهد که هیچ جلسهای نمیدهد.
سه رویدادی که ارزش دارند اول ساخته شوند
اگر امروز هیچچیز ندارید، از اینها شروع کنید:
۱. قیف اصلی کسبوکار — سه تا پنج گام، با نتیجهٔ هر گام. ۲. خطاهایی که کاربر میبیند — با نوع و صفحه. ۳. استفاده از قابلیتهای تازهساختهشده — تا بشود دربارهٔ نگهداشتنشان تصمیم گرفت.
سه مورد، چند روز کار. و بیشتر از داشبوردی که هیچکس بازش نمیکند، تصمیم میسازد.