Metabase

کنار هم گذاشتن همه

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

فشار و کشش تحلیل

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

بسیاری از شرکت‌هایی که سفر تحلیلی خود را شروع می‌کنند مطمئن نیستند چگونه یک فرهنگ مبتنی بر داده ایجاد و پرورش دهند. چه متابیس را به عنوان بخشی از stack داده خود شامل کنید یا نه، درباره نحوه پرورش فرهنگی که از داده برای اطلاع‌رسانی تصمیمات خود استفاده می‌کند بحث می‌کنیم.

دو راه اصلی برای دریافت داده در دست افرادی که تصمیم می‌گیرند وجود دارد:

  • فشار دادن داده مهم به مشتریان.
  • یا اجازه دادن به مشتریان برای انتخاب اینکه کدام داده (و چه زمانی) را به کشیدن خود انتخاب کنند.

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

کشیدن داده

برای تصمیمات محلی شده به یک تیم، باید به تیم مسئول گرفتن آن تصمیمات اجازه کشیدن اطلاعات مرتبط با آن تصمیمات را بدهیم. این مثال را در نظر بگیرید:

  • زمینه: حساب‌های جدید روی یک محصول SaaS در حال حاضر از طریق یک سری ایمیل‌ها که ویژگی‌های محصول را توصیف می‌کنند onboard می‌شوند. با این حال، نرخ ریزش برای حساب‌های جدید ~15% در ماه اول آن‌ها است.
  • تصمیم: برای کاهش این ریزش، تیم موفقیت مشتری تصمیم می‌گیرد به طور پیش‌فعال 10% از مشتریان جدید را onboard کند به جای دسترسی به آن‌ها وقتی می‌بینند یک حساب یک هفته بعد غیرفعال است.
  • معیارهای موفقیت: کاهش نرخ ریزش پس از یک ماه.

با توجه به این سناریو، ما، شرکت، چه چیزی نیاز به تنظیم داریم تا تیم موفقیت مشتری بتواند این تصمیم را به روش مبتنی بر داده بگیرد و ارزیابی کند؟

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

A list of accounts.

بعد، نیاز به انتخاب نمونه 10% برای استفاده برای آزمایش onboarding با تماس بالا داریم. باید در برابر وسوسه انتخاب 10 اول، یا در غیر این صورت bias کردن نمونه مقاومت کنیم، و باید ممکن (و ترجیحاً بدون اصطکاک) کنیم نمونه‌ای دریافت کنیم که به سمت مکان، اندازه، یا ویژگی کلیدی دیگر حساب‌های جدید ما weighted نیست. اگر در دسترس باشد، برخی کمک از یک تحلیلگر یا فرد با ذهن آماری در اینجا در تولید این فرآیند نمونه‌گیری و پر کردن یک جدول برای استفاده تیم موفقیت مشتری ارزشمند خواهد بود. در این نقطه، باید بتوانیم جدولی که بیشتر شبیه این است را بکشیم:

An enriched table of customers.

حالا فهرستی از مشتریان داریم که می‌توانند onboard شوند. بیایید چند ماه به آینده fast-forward کنیم، و بررسی کنیم تیم موفقیت مشتری چه چیزی نیاز دارد تا بفهمد این تصمیم چگونه بازی کرد.

ابتدا، بیایید ببینیم برنامه کلی چقدر خوب عمل کرد. برای این، نیاز به تعریف اینکه ریزش چیست داریم، سپس ریزش در نمونه‌ای که به طور تهاجمی onboard شد را محاسبه کنیم. برای تعریف ریزش، ساده‌ترین سناریو را فرض می‌کنیم، جایی که یک وضعیت متمایز "لغو اشتراک" برای حساب‌های کاربر داریم. همه آنچه نیاز داریم پرسیدن یک سؤال برای شمارش تعداد حساب‌ها بر اساس وضعیت و نوع onboarding است.

Results of an experiment: Status by Onboarding.

در دنیای ایده‌آل، نرخ ریزش ما به 0% سقوط می‌کرد، اما آزمایش‌ها به ندرت اینطور کار می‌کنند. بیشتر اوقات نتیجه آزمایش‌هایی مثل این چیزی شبیه "خوب… به نوعی کار کرد" خواهد بود. معمولاً، onboarding در برخی موارد واقعاً خوب کار کرده است، اما در دیگران نه (مثلاً، در مثال زیر می‌بینید که onboarding تهاجمی برای حساب‌های از صنعت مالی واقعاً خوب کار کرد، اما اصلاً برای آن‌هایی در آموزش نه). با نگاه به زیر، متوجه می‌شوید که 30% از حساب آموزشی پس از onboarding تهاجمی ریزش کردند، در حالی که فقط 1% از حساب‌های مالی ریزش کردند.

Cancellations by industry.

اما نباید آنجا متوقف شویم. به عنوان یک شرکت SaaS، ریزش خالص یک معیار make-or-break است، و باید تلاش کنیم بفهمیم چه چیزی آن عدد را بالا یا پایین می‌برد. در سازمان کاملاً مبتنی بر داده ما، تیم موفقیت مشتری خود قادر به حفاری عمیق‌تر به تنهایی خواهد بود، pairing درک حساب‌های ما با بینش‌ها از ابزارهای BI ما برای حفاری به dynamic زیربنایی اصلی.

Response to onboarding: Status by Timezone.

با حفاری به حساب‌ها، عضو تیم شجاع ما متوجه می‌شود که مشکل اصلی این است که 90% از حساب‌های آموزشی در ساحل غرب بودند، در حالی که 75% از حساب‌های مالی در نیویورک سیتی بودند (و همان منطقه زمانی شرکت). با تنظیم sessionهای onboarding خیلی زود در صبح (6 صبح–9 صبح PST)، ما مدیران مدرسه بی‌چاره را مجبور می‌کردیم قبل از اینکه قهوه آن‌ها kick in کرده باشد از یک session onboarding بنشینند. آن‌ها به سرعت خرد در خوابیدن و اجرای همه onboarding ساحل غرب در بعدازظهر را دیدند. ریزش کلی سقوط کرد؛ تصمیم (و تجدید نظر پیگیری) روز را نجات داد.

بیایید اینجا یک مکث کنیم و خلاصه کنیم یک affordance خوب برای کشیدن اطلاعات در یک شرکت چگونه به نظر می‌رسد. ابتدا، داده را به فرمتی که اطلاعات معنی‌دار به تیم موفقیت مشتری ما می‌داد massage کردیم. عملاً، این یعنی ساختار زیربنایی اطلاعات را با مورد استفاده تحلیل در نظر طراحی کردیم. ممکن است نیاز به trade off برخی نیازهای تراکنشی برای مناسب کردن این داده برای تحلیل، trade off با نیازهای تراکنشی، یا تبدیل داده عملیاتی خود برای آسان‌تر کردن تحلیل داشته باشیم. در حالی که وسوسه‌انگیز است سعی کنیم هر تیمی را به درک schema زیربنایی یا یادگیری SQL وادار کنیم، اگر داده خود را به گونه‌ای سازماندهی کنیم که در یک صفحه‌گسترده خوب به نظر برسد خیلی بهتر خواهیم بود.

دوم، نکته اجازه دادن برای pullها ایجاد یک فرهنگ تصمیم‌گیری مبتنی بر داده از پایین به بالا است. اگر می‌توانیم آن را تنظیم کنیم به طوری که افرادی که نزدیک‌ترین به یک تصمیم هستند قادر به پرسیدن و پاسخ دادن به سؤال‌های خود در cadence عملیاتی خود باشند، می‌توانیم سازمانی بسازیم که می‌تواند به سرعت به نیازهای کسب‌وکار در حال تغییر پاسخ دهد. نه فقط این سریع‌تر از punt کردن سؤال‌ها به یک pool تحلیلگر اختصاصی است، بلکه ماهیت خودخدمت اجازه می‌دهد داده به همه گوشه و کنارهای کوچک شرکت ما — شامل تعاملات با مشتریان، شرکا، و فروشندگان — نفوذ کند.

فشار دادن داده

بیایید به انتهای دیگر org chart برگردیم و درباره نحوه فشار دادن داده از طریق یک شرکت صحبت کنیم.

هدف فشار دادن داده اطمینان از این است که همه در یک تیم یا شرکت از یک مجموعه اعداد یا نقاط داده اصلی آگاه هستند. در حالی که اینجا از اصطلاح "push" استفاده می‌کنیم، لزوماً به رسانه استفاده شده برای تحویل اطلاعات اشاره نمی‌کنیم. منظورمان این است که شرکت‌ها نیاز به تکمیل سیستم "pull" غیرمتمرکز (جایی که همه می‌توانند هر داده‌ای که می‌خواهند را جستجو کنند) با تعیین یک مجموعه معیارهای اصلی که تعریف می‌کند چگونه کسب‌وکار خود را اندازه می‌گیرند دارند.

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

در بسیاری از شرکت‌ها، این مجموعه اطلاعات تعیین شده به صورت مرکزی شاخص‌های عملکرد کلیدی (KPI)، معیارهای اصلی، یا چیز دیگری که رسمی به نظر می‌رسد نامیده می‌شود. این معیارها نتایجی را که کسب‌وکار باید در برابر آن مدیریت شود نشان می‌دهند. هرچه این معیارها به نتایج کسب‌وکار مطلوب نزدیک‌تر باشند، بهتر است. در حالت ایده‌آل، باید این اعداد را به گونه‌ای فرموله کنیم که قابل مدیریت باشند، یعنی همه کسانی که اعداد را دریافت می‌کنند می‌توانند اقدام (یا kick off اقدام) برای تغییر این اعداد انجام دهند. علاوه بر این، اغلب مجموعه‌ای از معیارها (داخلی یا خارجی) وجود دارد که محیطی که شرکت در آن کار می‌کند را نشان می‌دهند. علیرغم اینکه چیزهایی نیستند که شرکت می‌تواند کنترل کند، رفتار کلی را راهنمایی می‌کنند، و نامزدهای اصلی برای pushها هستند. یک مثال یک شرکت مالی است که هر صبح یک خلاصه سریع از فعالیت شبانه در مناطق زمانی دیگر برای آماده شدن برای روز خود دریافت می‌کند.

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

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

چه زمانی داده را فشار دهیم

مهم است فرکانس فشار دادن یک معیار را با cadence تصمیم‌گیری که آن معیار اطلاع می‌دهد مطابقت دهیم. اگر یک عدد را از طریق اقداماتی که یک هفته برای برنامه‌ریزی و اجرا طول می‌کشد مدیریت می‌کنیم، دریافت یک ping درباره آن هر ساعت احتمالاً ما را منحرف می‌کند، یا باعث می‌شود thrash کنیم، تا اینکه به تصمیم‌گیری مولد کمک کند. همچنین مفید است دوره طبیعی عدد مورد سؤال را در نظر بگیریم.

اگر درباره ریزش حساب‌ها صحبت می‌کنیم، هر اقدامی که تیم موفقیت مشتری انجام می‌دهد نرخ ریزش را برای روزها یا هفته‌ها تحت تأثیر قرار نمی‌دهد. علاوه بر این، ریزش یک تناوب طبیعی دارد: مشتریان عمدتاً در پایان یک دوره آزمایش 30 روزه لغو می‌کنند یا تمدید نمی‌کنند. در این مورد، منطقی است به ریزش به صورت هفتگی یا حتی ماهانه نگاه کنیم. اگر نیاز به اقدام فوری روی حساب‌های خاتمه یافته داریم، به جای فشار دادن یک معیار، باید آن اقدام را در workflow خاتمه بگنجانیم.

نحوه فشار دادن داده

سه راه اصلی برای فشار دادن اطلاعات از طریق یک سازمان وجود دارد. قدیمی‌ترین مدرسه، اما هنوز مفید به دلیل جاذبه‌ای که می‌دهد، در مقابل مشتریان قرار گرفتن و خواندن اعداد از یک deck است. All-hands، kickoffهای فروش، تماس‌های تحلیلگر: همه مناسبت‌هایی هستند که می‌توانیم مجموعه کوچکی از اطلاعات را به روشی با پهنای باند کم اما سنگین تحویل دهیم.

در حالی که به طور دقیق "push" نیستند، داشبوردها مکان دیگری برای جمع‌آوری معیارها هستند. آن‌ها اغلب چیز خوبی برای بررسی هنگام up-to-speed شدن روی آنچه در روز، هفته، یا دوره زمانی دیگر قبلی اتفاق افتاده است هستند. در حالی که داشبوردها می‌توانند مورد سوء استفاده قرار گیرند، و نیاز به مقداری نگهداری دارند، یک مکان کلیدی برای دریافت مجموعه فعلی اعداد ارائه می‌دهند.

Dashboard of Very Important Business.

در نهایت، یک staple فشار دادن به معنای واقعی کلمه آن است: فشار دادن اطلاعات به inboxهای مشتریان، کانال، و غیره. یک ایمیل که همه می‌توانند اولین چیز صبح بررسی کنند، یا فقط یکی در دوشنبه‌ها، فوق‌العاده مفید برای دریافت مهم‌ترین اعداد و در مقابل مشتریان است. و باید مطمئن شویم اعداد مهم هستند: آسان است یک ایمیل ایجاد کنیم که هیچ کس باز نمی‌کند، که کل هدف تمرین را شکست می‌دهد.

Example of a nightly email.

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

کنار هم گذاشتن همه

حالا که آن‌ها را جداگانه بحث کردیم، بیایید درباره نحوه fit شدن دو وسیله دریافت داده در دست هم‌تیمی‌ها صحبت کنیم.

می‌توانیم با فشار دادن داده خیلی مؤثرتر باشیم اگر راهی واقعاً باز و قابل دسترسی برای همه برای کشیدن بقیه اطلاعاتی که نیاز به کار بهتر دارند برقرار کنیم. اگر می‌توانیم ابزاری ارائه دهیم که حفاری و تشریح معیارهایی که در inboxهای آن‌ها می‌رسند را برای مشتریان آسان می‌کند، نیاز به overload کردن ایمیل‌های خود با هر sub-metric ممکن از یک KPI نداریم. به همین ترتیب، برای پروژه‌هایی با شروع و توقف طبیعی، اگر می‌توانیم دریافت اطلاعات مفید را برای یک تیم آسان کنیم—و آن را برای مدت پروژه به خود فشار دهیم—تیم نیاز به کمک خارجی برای نگه داشتن tabs روی نحوه عملکرد تصمیمات خود نخواهد داشت.

[

](embedding-mistakes.html)