ممیزی تعریف معیار: بفهمید چرا دو تیم برای یک معیار عدد متفاوت گزارش می‌کنند
چرا این پرامپت اهمیت دارد
Without a canonical definition, every review becomes an argument about whose spreadsheet is correct, and decisions get made on whichever number arrived first. Teams that find a definition gap after a board deck has gone out spend quarters rebuilding trust in the metric.
ما از آن برای چه استفاده می‌کنیم
Your product team reports 48,200 active customers for March and your finance team reports 31,900. The quarterly review is on Thursday, and you need to know which number is wrong, or whether both are right under different definitions, before anyone presents either one.
پرامپت
Act as a senior analytics lead who audits metric definitions before numbers reach executives. Context: I am [YOUR ROLE] at [YOUR COMPANY NAME]. Two or more teams report a metric called [METRIC NAME], and their numbers do not match. Their definitions, queries or dashboard notes are below, followed by the numbers each team reported for the same period: [PASTE DEFINITIONS, QUERIES OR DASHBOARD NOTES HERE] [PASTE THE REPORTED NUMBERS HERE]. Task: (1) Restate each team's definition as an explicit rule covering five dimensions: population (who is counted), event (what counts as an action), time window, deduplication rule, and attribution rule. (2) List every point where the definitions diverge, and estimate how much of the gap between the reported numbers each divergence explains. (3) Recommend one canonical definition that serves [PRIMARY DECISION THIS METRIC DRIVES], and state directionally which team's number will change and why. Constraints: Use only information in my input. Label every estimate as an estimate and state the assumption behind it. Do not favour a team because of seniority or because its number is larger. Write the canonical definition as one sentence a non-analyst could read. If a divergence cannot be resolved from the input, put it under Open Questions instead of guessing. Output Format: (a) a table with columns Team, Population, Event, Window, Deduplication, Attribution; (b) a ranked list of divergences with estimated contribution to the gap; (c) the canonical definition as a single bold sentence; (d) Open Questions as a bullet list.
نتیجه
Metric audit: Active Customers (March) Scenario: Product reports 48,200. Finance reports 31,900. Gap: 16,300.
Definitions | Team | Population | Event | Window | Deduplication | Attribution | |---|---|---|---|---|---| | Product | All registered users | Any login | Last 30 days | Per user | User | | Finance | Accounts with a paid subscription | Active paid status on report date | Point-in-time | Per account | Account |
Divergences, ranked by estimated contribution to the gap 1. Population (about 14,800 of the 16,300 gap). Product counts free-tier users who logged in during the window. Finance excludes them. Estimate assumes most free-tier logins in Product's count belong to non-paying accounts. 2. Deduplication and attribution (about 1,500). Product counts each login from a 12-seat account as a separate user. Finance counts the account once. Estimate assumes roughly 1,500 of the gap comes from multi-seat accounts. 3. Window (not quantified). A 30-day login window captures users who lapsed during the month. A point-in-time status does not. This pushes the two numbers in opposite directions and cannot be sized from the input.
Canonical definition **Active Customers is the number of accounts with an active paid subscription on the last day of the reporting month.**
Effect on each team Product's number falls sharply and should be reported under its own name, such as Monthly Active Users. Finance's number does not change.
Open Questions - Does Finance count trial accounts as paying? The input does not say. - Does Product's login count include internal staff or support logins? - Does the 30-day window end at UTC midnight or at each user's local time?
دو تیم یک معیار را گزارش می‌کنند و به دو عدد متفاوت می‌رسند. این پرامپت تعریف هر تیم را صریح می‌کند، واگرایی‌ای را که شکاف را توضیح می‌دهد پیدا می‌کند، و یک تعریف استاندارد پیشنهاد می‌دهد که بتوانید به جلسه بررسی ببرید.
چه زمانی از آن استفاده کنید
تیم محصول برای مارس ۴۸٬۲۰۰ مشتری فعال گزارش می‌کند و تیم مالی ۳۱٬۹۰۰. بررسی فصلی پنجشنبه است. قبل از ارائه هر کدام از اعداد باید بدانید کدام اشتباه است، یا اینکه آیا هر دو با تعاریف متفاوت درست‌اند.
چرا مهم است
بدون تعریف استاندارد، هر جلسه بررسی به بحث درباره درستی صفحه‌گسترده‌های هر تیم تبدیل می‌شود و تصمیم‌ها بر اساس عددی گرفته می‌شود که زودتر رسیده است. تیم‌هایی که شکاف تعریف را بعد از ارسال گزارش به هیئت مدیره کشف می‌کنند، ماه‌ها وقت صرف بازسازی اعتماد به آن معیار می‌کنند.
چرا پرامپت این‌گونه ساخته شده است
نقش، یک تحلیلگر را تعریف می‌کند که تعریف‌ها را ارزیابی می‌کند نه اینکه از یک تیم دفاع کند. زمینه، تعاریف و اعداد واقعی شما را لازم دارد، بنابراین مدل بر پایه شواهد کار می‌کند نه بر اساس دانش کلی از معنای «فعال». پنج بُعد (جمعیت، رویداد، بازه زمانی، حذف تکرار، انتساب) جایی هستند که تعریف معیارها تقریباً همیشه از هم جدا می‌شود، و نام بردن آن‌ها مانع می‌شود تحلیل به اختلاف نظر مبهم تبدیل شود. بخش محدودیت‌ها از شایع‌ترین خطا در این نوع کار جلوگیری می‌کند، یعنی عددهای مطمئنی که در ورودی وجود نداشته‌اند. بخش پرسش‌های باز به مدل جایی صادقانه می‌دهد تا مواردی را که نمی‌تواند حل کند در آن بگذارد.
چگونه آن را تطبیق دهید
- فیلدهای داخل کروشه را با تعاریف واقعی از داشبورد یا کوئری هر تیم جایگزین کنید، نه خلاصه‌های آن‌ها.
- اعداد گزارش‌شده را برای حداقل دو دوره اضافه کنید. شکافی که ثابت می‌ماند علت متفاوتی از شکافی دارد که تغییر می‌کند.
- بعد از اجرای اول، یک پرسش تکمیلی بپرسید: رتبه‌بندی واگرایی‌ها را با فرض اینکه حساب‌های آزمایشی در شمارش مالی لحاظ شوند دوباره بسنجید. این نشان می‌دهد نتیجه تا چه اندازه به یک فرض وابسته است.
نشانه خوب این است که تعریف استاندارد در یک خط جا شود و تیمی که عددش تغییر می‌کند هم بتواند آن را بپذیرد. اگر جا نشد، احتمالاً تعریف هنوز مبهم است.