Metabase

مطالعه بیشتر

پس می‌خواهید داده را در مقابل مشتریان خود قرار دهید... اما با چه هزینه‌ای؟

پنج مرحله غم جاسازی

پس می‌خواهید داده را در مقابل مشتریان خود قرار دهید... اما با چه هزینه‌ای؟

وقتی درباره قرار دادن داده در مقابل مشتریان خود فکر می‌کنید، ممکن است نمودارهای سفارشی، معیارهای کدگذاری شده رنگی، و فراوانی فضای سفید را تصور کنید.

اگرچه داشبوردها قادر به ارائه تحلیل خودخدمت به مشتریان شما هستند، به ندرت بهترین ابزار برای کار هستند.

این مقاله به شما نشان می‌دهد چرا شروع با داشبوردهای جاسازی شده (یا هر view از پیش تعریف شده از داده شما) تمایل به ایجاد مشکلات با قابلیت نگهداری و مقیاس‌پذیری دارد.

اگر از قبل متقاعد شده‌اید، رویکرد جاسازی که می‌توانید بگیرید را برای اجتناب از دادن غم به خود بررسی کنید.

مورد استفاده نمونه

بگویید یک پلتفرم e-commerce اجرا می‌کنید. تحلیلگران شما یک داشبورد ساخته‌اند جایی که تیم شما می‌تواند موفقیت هر تاجر را بر اساس داده‌هایی مثل بازدیدها به ازای مشتری، حجم تراکنش در طول زمان، و رتبه متوسط مشتری بررسی کند.

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

مرحله 1: انکار

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

پس از خواندن استراتژی‌های ارائه تحلیل مشتری، تصمیم می‌گیرید single sign-on (SSO)، امنیت ردیف و ستون، و white labeling را ترکیب کنید تا داشبورد موجود خود را مستقیماً در اپلیکیشن رو به تاجر جاسازی کنید.

مرحله 2: خشم

چند هفته پس از rollout تکرار اول، می‌بینید که تاجران شما عاشق استفاده از داشبورد هستند، آنقدر که انبار داده شما کاملاً برای برآورده کردن اشتیاق آن‌ها مقیاس نمی‌کند.

تاجران شما شروع به ناامیدی از مدت زمان بارگذاری داشبورد می‌کنند. تصمیم می‌گیرید منابع داده داشبورد خود را به یک انبار داده سریع‌تر کپی کنید، و تعداد instanceها را برای اندازه خوب تنظیم می‌کنید.

مرحله 3: چانه‌زنی

درخواست‌های ویژگی شروع به roll in برای داشبورد شما می‌کنند — به نظر می‌رسد هرچه تاجران شما بیشتر با داده کار می‌کنند، سؤال‌های بیشتری درباره فیلترها، pivotها، و محاسبات سفارشی دارند.

برخی از تاجران شما می‌خواهند از محاسبات خود برای درآمد استفاده کنند. دیگران به شدت درباره نمودارهای خطی در مقابل نمودارهای میله‌ای نظر دارند. و یک جناح کوچک (اما پرحرف) حتی اصلاً به نمودارها اهمیت نمی‌دهند — همه آن‌ها می‌خواهند راهی برای دریافت داده مشتری de-anonymized برای اجرای کمپین‌های شخصی‌سازی شده است.

مرحله 4: افسردگی

متوجه می‌شوید که جداول در پایگاه داده شما نیاز به جادوی SQL جدی برای پشتیبانی از افزودنی‌های آخر داشبورد که تاجران شما درخواست کرده‌اند دارند.

تیم شما زمان برای refactor کردن schemaها ندارد (آن‌ها مشغول نگهداری viewهای موجود هستند)، پس شروع به نوشتن اسکریپت‌های SQL سفارشی برای برآورده کردن نیازهای مهم‌ترین تاجران خود می‌کنید. انبار داده شما با جداول دلخواه شلوغ می‌شود.

حتی اگر تیم محصول شما بهترین تلاش خود را برای پیگیری درخواست‌ها برای داده بیشتر و راه‌های بیشتر برای نگاه به آن داده انجام می‌دهد، داشبورد داخلی یک بار موفق شما به نظر می‌رسد به یک abomination صد tile جهش یافته است.

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

مرحله 5: پذیرش

خوشحال می‌شوید که به یاد می‌آورید این سناریوی کامل فرضی است. همانطور که روی تروما شبیه‌سازی شده خود تأمل می‌کنید، می‌فهمید که:

  • مشتریان با نگاه به داده به روش‌های مختلف به پاسخ می‌رسند.
  • درخواست‌های داشبورد (آیا می‌توانم یک view خاص از داده را دریافت کنم؟) در واقع درخواست‌های داده خودخدمت (آیا می‌توانم به اندازه نیاز برای پاسخ به سؤال خود view دریافت کنم؟) هستند.
  • نباید مجبور به ایجاد یا به‌روزرسانی جداول خود در پاسخ به درخواست‌های داشبورد باشید.

تغییر ذهنیت: از داشبوردهای جاسازی شده به مدل‌های داده جاسازی شده

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

اگر مدل‌های داده شما برای غیرمهندسان آسان برای پیدا کردن، درک، تغییر، و اعتبارسنجی باشند، اعتماد به نفس و استقلال برای استفاده از داده به روشی که برای آن‌ها بیشتر منطقی است (و زمان خود را از چراندن درخواست‌های داشبورد ad-hoc پس بگیرید) به آن‌ها می‌دهید.

البته، هنوز می‌خواهید از ایجاد یک دسته کاملاً جدید از درخواست‌های مدل داده ad-hoc اجتناب کنید. ارزش وقت شما را دارد (حالا که مقداری پس گرفته‌اید) مدل‌های داده‌ای بسازید که نه فقط از دیدگاه مهندسی بهینه شده‌اند، بلکه از یک طراحی محصول نیز.

مطالعه بیشتر

بیشتر درباره استراتژی، طراحی، و پیاده‌سازی مدل‌سازی داده یاد بگیرید:

اشتباهات رایج در تحلیل

push و pull