نسخه هالووین: داستانهای ترسناک داده در استارتاپها
تیم متابیس
در ۲۰ اکتبر ۲۰۲۲، ما با Amogh Sarda، همبنیانگذار Eesel، و Ali Baghshomali، متخصص داده از Mentat Analytics، برای بحث در مورد برخی داستانهای ترسناک داده در استارتاپها و اینکه چه کاری میتوان برای جلوگیری از آنها انجام داد نشستیم. ما از طریق داستانهای واقعی که میتوانست برای یک شرکت جوان اتفاق بیفتد صحبت کردیم، انگیزهها و پیامدهای بالقوه آنها را توضیح دادیم.
در زیر یک گزیده کوتاه از گفتگو و همچنین یک ضبط کامل از آن آمده است.
شرکتکنندگان:
- Amogh Sarda، همبنیانگذار Eesel، ابزاری که همه اسناد کاری شما را مستقیماً به تب جدید شما میآورد. او در استرالیا مستقر است و قبلاً یک مدیر محصول برای Atlassian و Intercom بود. او عاشق کمدی بداهه است و فکر میکند زندگی استارتاپ ممکن است یک نمایش بداهه باشد.
- Ali Baghshomali خالق Product Analytics Academy، یک مدرسه آنلاین که دورههای تحلیل محصول با کیفیت بالا ارائه میدهد است. او همچنین بنیانگذار Mentat Analytics، یک آژانس مشاوره تحلیل با بالاترین امتیاز است. او قبلاً در تیمهای داده در Bird و Buzzfeed کار میکرد.
- Cynthia Balusek، میزبان ما و معاون مهندسی موفقیت در متابیس.
چه چیزی میتواند در مدیریت رویدادها در یک استارتاپ اشتباه شود
Amogh: داستانی که میخواهم به اشتراک بگذارم در مورد نحوه سیمکشی رویدادها برای Eesel است، و به طور خاص، برخورد با ردیابی رویدادها وقتی در مرحله اولیه هستید.
Eesel یک افزونه مرورگر است که تاریخچه جستجوی شما را فیلتر میکند و فقط لینکهای مرتبط با کار شما را مستقیماً در تب جدید نشان میدهد. این با تمایل ما برای ساخت یک ویژگی جدید برای همکاریهای تیمی شروع شد. برای ردیابی نحوه عملکرد آن، ما ردیابی رویدادهایی مانند projectCreated، projectOpened را راهاندازی کردیم... به نظر آسان و مستقیم میرسید، درست است؟
اما در واقع، در سه ماه از راهاندازی ویژگی، ما «Projects» را به «Folders» تغییر نام دادیم، که نام رویداد را از projectCreated به folderCreated و غیره تغییر داد. خوب، این نیز قابل مدیریت است؛ ما رویدادهای سفارشی ایجاد کردیم و نوعی این نامها را بهروزرسانی کردیم.
اما سپس فهمیدیم که همچنین به برخی رویدادهای ظریفتر نیاز داریم، مانند settingOpened یا linkClicked. در حالی که این را ردیابی میکردیم، همچنین اتفاق افتاد که محصول خود را بهروزرسانی کنیم، و مکانهای جدیدی از جایی که این پوشهها میتوانستند باز شوند ظاهر شد. بنابراین ما به رویدادهای جدید برای آنها نیز نیاز داشتیم.
سوالی که در برخی موارد با آن مواجه شدیم این بود: آیا باید داده را از دست بدهیم، یا زمان و انرژی زیادی را برای نگه داشتن چیزها بهروز از دست بدهیم؟
ما این react hook را کشف کردیم، به عبارت دیگر یک «کلیک جهانی»، که اساساً به همه کلیکها (دکمهها، لینکها، انتخابها) گوش میدهد و ابرداده مرتبط با هر چیزی که کلیک شد را منتقل میکند. نیازی نیست که ما با همه این نامهای مختلف رویداد بیاییم، و نیازی به QA رویدادها نیست. این راهحل مستقل از پلتفرم است و میتواند با تقریباً هر ابزاری استفاده شود. این واقعاً زندگی ما را در Eesel آسانتر کرد.
Ali: Amogh، شما به چیزی اشاره کردید که بسیاری از تیمها با آن دست و پنجه نرم میکنند، که کار مورد نیاز برای ردیابی همه این داده رویداد است.
روشی که میتوانیم به ردیابی جهانی فکر کنیم نوعی معامله بین انجام همه چیز خودتان، یا اجازه دادن به ردیابی خودکار برای انجام کار برای شما است. مزایای انجام ردیابی خودکار این است که داده زیادی را ضبط میکنید، زمان توسعه را در بازگشت و ویرایش تنظیمات رویداد خود صرفهجویی میکنید.
معایب، از سوی دیگر، این است که داده در نهایت خیلی آشفتهتر میشود. از آنجایی که همه چیز را ردیابی میکنید، داده رویداد زیادی جریان مییابد، و قطعاً دادهای وجود خواهد داشت که ممکن است مفید نباشد. به عنوان مثال، اگر تغییراتی در ساختار محصول خود ایجاد کنید، نام رویداد در نهایت تغییر میکند. این کار را در سمت حاکمیت داده اضافه میکند جایی که باید بروید و به صورت دستی نام رویدادها را برای سازگار بودن داده بهروزرسانی کنید.
عیب دیگر این است که اطلاعات زیادی از ویژگیهای رویداد را که ممکن است خاص به مواردی که ردیابی میکنید باشد از دست خواهید داد.
داده رویداد به اقدامات یا رویدادهای خاص در برنامه اشاره دارد. بیایید یک مثال ساده از خرید چیزی آنلاین بگیریم. شما برای یک محصول جستجو میکنید، جزئیات یک مورد را مشاهده میکنید، آن را به سبد خرید اضافه میکنید، و آن را خریداری میکنید. هر یک از آن رویدادها یک محرک رویداد خواهد داشت که یک نقطه داده است که میگوید: «کسی جستجو کرد» یا «کسی یک مورد را به سبد خرید اضافه کرد». رویدادها دارای برچسب زمانی هستند تا بتوانید بدانید کدام یک چه زمانی نسبت به یکدیگر رخ داد.
رویدادها اطلاعات بافتی همراه با آنها به نام ویژگیها دارند. کافی نیست که بدانید کسی برای چیزی جستجو کرده است، همچنین میخواهید بدانید که آن چیز چه بود. به عنوان مثال، برای رویداد «مورد جستجو شد»، ویژگی «اصطلاح جستجو»، «دستهبندی جستجو» و غیره خواهد بود. یا برای رویداد «مورد خریداری شد»، ویژگی «قیمت مورد»، «مقدار خریداری شده» و غیره خواهد بود. وقتی ردیابی خودکار انجام میدهید دیگر ویژگیهای سفارشی تنظیم شده ندارید.
توصیه اینجا این است که یک مدیریت رویداد ترکیبی انجام دهید که این است که برخی ردیابی خودکار را برای ضبط مجموعهای از چیزها قرار دهید تا شکافهایی در داده خود نداشته باشید، اما همچنین مطمئن شوید که ردیابی رویداد دستی انجام میدهید زیرا در غیر این صورت احتمالاً اطلاعات زیادی را از دست خواهید داد.
همچنین توصیه میکنم که بخش تحلیل را به عنوان بخشی از چرخه توسعه محصول در نظر بگیرید. بنابراین برای هر ویژگی که میسازید، باید لیستی از سوالاتی که میخواهید در مورد آن ویژگی پاسخ دهید، یا متریکهایی که میخواهید از قبل ردیابی کنید داشته باشید. به این ترتیب میتوانید مجموعه رویدادها و ویژگیها را از قبل بیاورید که به شما کمک میکند تا در آینده به آن سوالات پاسخ دهید. به این ترتیب هر بار که چیزی جدید ارسال میشود، اطلاعات ردیابی رویداد همراه با آن ارسال میشود. من این را با جزئیات بیشتر در دورههای تحلیل محصول خود پوشش میدهم.
مدیریت داده برای استارتاپها: چه زمانی ابزار درست را انتخاب کنیم
Amogh: داستان دیگری که میخواستم به اشتراک بگذارم در مورد اولین پشته داده ما است. ما چند هزار کاربر بدون هیچ پایگاه داده در ابتدا داشتیم، و از ترکیبی از Intercom و Google sheets استفاده میکردیم. همه تحلیل رویداد از Intercom میآمد، و به طور خاص ما از ویژگیهای کاربر آماده به کار که Intercom میدهد استفاده میکردیم. برای هر کاربر خاص، ما چیزهایی مانند Signed up، Last seen، Browser، OS، و همچنین برخی ویژگیهای سفارشی مانند «Appversion»، «مقدار فضایی که Eesel استفاده میکند» و غیره دریافت میکردیم.
در آن زمان Intercom گزارشهای تجسم داده زیادی در دسترس نداشت. همچنین راهی برای تجسم یک روند در طول زمان وجود نداشت. بنابراین من به صورت دستی داده را به Google Sheets صادر میکردم و تجسمهایی از آن ایجاد میکردم. ما با زمان سطح خود را بالا بردیم و شروع به استفاده از Metabase، Mixpanel و Segment کردیم.
Ali: شروع با Google Sheets برای استارتاپها بسیار رایج است، و در واقع یک ابزار بسیار قدرتمند است. بخشی از مبارزه این است که باید به صادر کردن، تمیز کردن و بهروزرسانی داده به صورت دستی ادامه دهید. همیشه این سوال برای یک استارتاپ مرحله اولیه وجود دارد: «کدام ابزار باید استفاده کنیم، و زمان برای هر کدام چه زمانی است؟» این یکی از رایجترین سوالاتی است که هنگام کار با مشتریانم دریافت میکنم. حتی اگر همه شرکتها متفاوت هستند، و هیچ چارچوب تحلیلی واحدی وجود ندارد که برای همه آنها کار کند، هنوز یک قانون تقریبی وجود دارد که میتواند به شما کمک کند ابزار درست را در مرحله درست انتخاب کنید.
۱. قبل از راهاندازی/ آلفای بسته: وقتی در مرحله بسیار اولیه هستید (~۱۰ کاربر) میخواهید روی سمت کیفی چیزها تمرکز کنید و عمیقتر به گفتگوها با کاربران خود بروید. 
۲. راهاندازی/بتای باز: وقتی راهاندازی میکنید و حدود ۱۰۰ کاربر دارید، و هنوز تخصص SQL در تیم ندارید - بینش محصول اولویت شما میشود. همیشه توصیه میشود که این را قبل از راهاندازی تنظیم کنید تا همه چیز بعداً در جای خود باشد. 
۳. رشد/مقیاسپذیری: در حالی که راهاندازی قبلی برای بینش محصول عالی کار میکند، در واقع تحلیل کسبوکار را پوشش نمیدهد، که این همان چیزی است که ابزاری مانند Metabase برای آن است. در ۱۰۰۰+ کاربر میتوانید شروع به پیادهسازی یک پشته داده مدرن کنید. یک چیز که پیشنهاد میکنم قبل از شروع راهاندازی MDS داشته باشید این است که کسی در تیم که در SQL تجربه دارد داشته باشید. حتی اگر ابزارهایی مانند Metabase لزوماً نیاز به دانستن SQL ندارند، هنوز SQL راه اصلی برای به دست آوردن بیشتر از داده شما است. بنابراین اگر میخواهید با ایجاد یک پشته داده مدرن پیش بروید، صبر کنید تا یک فرد داده در تیم شما ظاهر شود و بتواند مالکیت این را داشته باشد. 
یک داشبورد فروش بسازید که تیم شما واقعاً استفاده کند. ۱۰ متریک کلیدی، نکات و یک مثال زنده در متابیس را ببینید.
تحلیلهای جاسازیشده به معنای دادن دسترسی به کاربران شما به نمودارها، متریکها و گزارشها مستقیماً در داخل محصول شما است، تا بتوانند دادههای خود را کاوش کنند و بر اساس آن عمل کنند بدون اینکه نیاز به ترک برنامه شما داشته باشند یا برای پاسخ به شخص دیگری تکیه کنند.