ساخت داشبورد: منابع داده، شاخص‌های کلیدی، نمودارها و دسترسی

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

از پرسش‌ها شروع کنید، نه از نمودارها

داشبوردی که می‌خواهد همه‌چیز را نشان دهد، فقط یک بار باز می‌شود. پیش از فکر کردن به نمودار، به این‌ها جواب دهید:

• برای چه کسی است؟ بنیان‌گذار، تیم فروش، عملیات، سرمایه‌گذاران، مشتریان شما؟
• از چه تصمیم‌هایی پشتیبانی می‌کند؟ «آیا باید یک نفر دیگر برای پشتیبانی استخدام کنیم؟» پرسشی است که داشبورد می‌تواند جواب دهد. «داده‌هامان را نشانم بده» نیست.
• چند وقت یک‌بار نگاه می‌کنند؟ داشبوردهای عملیاتی روزانه به داده‌ی تازه و هشدار نیاز دارند؛ نمای ماهانه‌ی هیئت مدیره نه.

سه تا پنج پرسش بنویسید. هر کدام یک یا دو متریک می‌شود.

هر متریک را دقیق تعریف کنید

بیشتر بحث‌های داشبورد در واقع بحث تعریف است. برای هر عدد یک تعریف کوتاه بنویسید:

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

داده از کجا می‌آید

دو اصل همه‌جا کاربرد دارد:

1. کلیدها را روی سرور نگه دارید. کلیدهای API و رمز پایگاه‌داده باید در متغیرهای محیطی اپ باشند، نه در کد مرورگر.
2. تازگی داده را تعیین کنید. کشیدن داده از چند API در هر بار بارگذاری صفحه کند است و ممکن است به محدودیت نرخ بخورد. برای بیشتر داشبوردهای کسب‌وکار، همگام‌سازی هر ساعت یا شبانه به پایگاه‌داده‌ی خودتان، با برچسب «آخرین به‌روزرسانی» روی صفحه، ساده‌تر و قابل‌اطمینان‌تر است.

اگر API برایتان تازه است، API چیست و پایگاه‌داده چیست مبانی را توضیح می‌دهند.

نمودار مناسب را انتخاب کنید

• یک عدد تکی با تغییر («۴۲ هزار دلار، ۸٪ بیشتر از ماه قبل») — کارت KPI. مفیدترین عنصر در بیشتر داشبوردها.
• روند در طول زمان — نمودار خطی. میله‌ها را فقط برای تعداد کمی دوره به کار ببرید.
• مقایسه‌ی دسته‌ها — نمودار میله‌ای افقی، مرتب‌شده بر اساس مقدار.
• بخشی از کل — میله‌ی انباشته. نمودار دایره‌ای فقط با دو یا سه قطعه کار می‌کند.
• جزئیات و استثناها — جدول با مرتب‌سازی، جست‌وجو و فیلتر. اغلب از هر نموداری مفیدتر است.

رنگ‌ها را ثابت نگه دارید: یک رنگ برای «این دوره»، یک رنگ کم‌رنگ برای «مقایسه»، و قرمز فقط برای چیزهایی که به توجه نیاز دارند.

چه کسی چه چیزی را می‌بیند

پیش از ساختن، دسترسی را تعیین کنید:

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

داشبوردی که داده‌ی درآمد یا مشتری را روی یک نشانی عمومی بدون ورود دارد، نشت داده‌ای است که منتظر کشف شدن است.

یک پرامپت اول که جواب می‌دهد

یک داشبورد فروش برای یک شرکت نرم‌افزار B2B با ده نفر بسازید. مخاطب: بنیان‌گذاران و سرپرست فروش، که هر دوشنبه آن را بررسی می‌کنند. صفحه‌ی نمای کلی: کارت‌های KPI برای MRR جدید این ماه، MRR کل، مشتریان جدید این ماه، مشتریان ریزش‌کرده‌ی این ماه و ارزش خط فروش، هر کدام با تغییر نسبت به ماه قبل؛ یک نمودار خطی MRR برای ۱۲ ماه گذشته؛ یک نمودار میله‌ای معامله‌های جدید بر اساس منبع. یک صفحه‌ی معامله‌ها با جدول قابل جست‌وجو و مرتب‌شونده (شرکت، مسئول، ارزش، مرحله، تاریخ بسته‌شدن) و فیلتر بر اساس مسئول و مرحله. تعریف متریک‌ها: MRR جمع مبالغ اشتراک ماهانه‌ی فعال است، با پلن‌های سالانه تقسیم بر ۱۲؛ ریزش مشتریانی را می‌شمارد که اشتراکشان این ماه تمام شده. فعلاً از داده‌ی نمونه‌ی واقع‌گرایانه در پایگاه‌داده استفاده کنید — بعداً Stripe را وصل می‌کنیم. زمان «آخرین به‌روزرسانی» را نشان دهید. ورود الزامی است. چیدمان تمیز با نوار کناری.

مراحل ساخت

1. چیدمان با داده‌ی نمونه. متریک‌ها و نمودارها را وقتی داده ساختگی و ارزان برای تغییر است، توافق کنید.
2. یک منبع واقعی را وصل کنید. هر عدد را دستی با سیستم منبع مقایسه کنید. اگر MRR با آنچه Stripe نشان می‌دهد فرق دارد، پیش از ادامه علتش را پیدا کنید.
3. بقیه‌ی منابع را یکی‌یکی اضافه کنید و هر کدام را بررسی کنید.
4. تازه‌سازی زمان‌بندی‌شده یا پرس‌وجو هنگام بارگذاری، با برچسب «آخرین به‌روزرسانی».
5. فیلترها — اول بازه‌ی تاریخ، بعد یک یا دو فیلتر دیگری که مردم می‌خواهند.
6. ورود و نقش‌ها.
7. حالت‌های خالی و خطا — صفحه وقتی منبعی از کار افتاده یا فیلتری نتیجه‌ای ندارد چه نشان می‌دهد.
8. با مخاطبان به اشتراک بگذارید، سپس هر چیزی را که یک ماه بعد کسی نگاهش نمی‌کند حذف کنید.

سریع‌اش کنید

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

اشتباهات رایج

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

وقتی ابزار BI بهتر است

اگر داده‌تان از قبل در یک پایگاه‌داده یا انبار است و کاربران اصلی تحلیلگرانی هستند که می‌خواهند آن را بررسی کنند، برش بزنند و نمودارهای خودشان را بسازند، یک ابزار BI — Looker Studio، Power BI، Metabase و دیگران — بهتر از ساخت اختصاصی به آن‌ها خدمت می‌کند. بسیاری از ابزارهای SaaS هم گزارش‌های داخلی خوبی دارند؛ پیش از بازسازی آن‌ها را بررسی کنید. داشبورد سفارشی برنده است وقتی برای مشتری یا غیرتحلیلگر است، به منطق یا دسترسی‌ای نیاز دارد که ابزار BI بیان نمی‌کند، داده‌ها را به شیوه‌ای مخصوص کسب‌وکارتان ترکیب می‌کند، یا داخل محصولی قرار می‌گیرد که از قبل دارید.

اگر کار بیشتر تغییر دادن رکوردهاست تا دیدن عددها، به یک پنل مدیریت یا ابزار داخلی نیاز دارید — ساخت ابزار داخلی را ببینید. و اگر اعدادتان امروز در یک صفحه‌گسترده است، تبدیل صفحه‌گسترده به اپ خواندن بعدی خوبی است.

ساخت با Mythex

در Mythex داشبورد را توصیف می‌کنید و عامل صفحات و نمودارها را در پیش‌نمایش زنده می‌سازد، با داده‌ی نمونه‌ی واقع‌گرایانه شروع می‌کند و وقتی اعداد باید ماندگار شوند به یک پایگاه‌داده‌ی Postgres اختصاصی می‌رود. نمونه‌ی کاربرد داشبورد در مستندات یک پرامپت شروع دارد. اگر داده‌تان در ابزاری مثل Google Sheets است، می‌توانید حساب را از طریق اتصال‌دهنده‌ها وصل کنید و از عامل بخواهید آن را بخواند و داشبورد بسازد.

اتصال‌دهنده‌ی آماده‌ی انبار داده برای خود اپ وجود ندارد؛ برای BigQuery، Snowflake، Stripe و مشابه آن‌ها، اپ به API‌هایشان با کلیدهایی که به‌عنوان راز پروژه ذخیره می‌کنید وصل می‌شود. ورود و نقش‌ها برای افرادی که داشبورد را می‌بینند بخشی از اپی است که می‌سازید. برای شروع از یک پرامپت، قالب‌های داشبورد را ببینید، مثل داشبورد متریک‌ها.

پرسش‌ها