Write a KPI definition precise enough that two teams calculate it the same way

Write a formal KPI definition spec for the metric below, precise enough that two different analysts working independently would compute the identical number from the same raw data.

METRIC NAME AND ROUGH INTENT
"Monthly Active Users" — meant to capture how many customers are actively using the product in a given month

AVAILABLE DATA TO CALCULATE IT FROM
events table with user_id, event_type, event_timestamp, platform; users table with user_id, plan_tier, is_internal_test_account, signup_date

WHERE THIS METRIC WILL BE USED
The board deck's growth section, alongside revenue metrics, compared month over month

COMPETING DEFINITIONS ALREADY IN USE, IF ANY
Product team's internal dashboard counts anyone with any event including passive page-loads; this new spec is meant to require a meaningful action event instead

Write the exact formula as an equation using the actual field names from events table with user_id, event_type, event_timestamp, platform; users table with user_id, plan_tier, is_internal_test_account, signup_date, not a plain-language description of the concept — "active users" is not a definition; "COUNT(DISTINCT user_id) WHERE last_event_date >= CURRENT_DATE - 30" is. State every inclusion and exclusion rule explicitly: does the metric include internal/test accounts, does it include free-tier users if the business also has paid tiers, does it count a user who churned and came back within the window as one user or a new one. Name the calculation cadence and the point-in-time behavior — is this calculated as of end-of-day, is it a trailing window or a calendar-period snapshot, and what happens to a historical value of this metric when it's recalculated later (does day 45's number for "last 30 days" change retroactively as new data arrives, or is it locked once calculated). If Product team's internal dashboard counts anyone with any event including passive page-loads; this new spec is meant to require a meaningful action event instead shows this metric is already calculated differently somewhere else in the business, name the specific discrepancy between the two definitions and state which one this spec is choosing, with the reasoning, rather than adding a third silent variant to the pile. Flag any input field this formula depends on that could itself be unreliable (a last_event_date field that's known to lag by a day for one platform) as a caveat that affects how much to trust the number.

WHAT NOT TO DO
Do not write the definition as a paragraph of prose with the formula implied — the formula must be a literal expression against named fields. Do not silently resolve a conflict with an existing definition without naming that a conflict existed and what was chosen.

OUTPUT FORMAT
1. Metric name and one-sentence business intent.
2. Exact formula, as an expression against named fields.
3. Inclusion/exclusion rules, as a bullet list.
4. Calculation cadence and point-in-time/recalculation behavior.
5. Any conflict with an existing definition, and which one this spec adopts and why.
6. Known reliability caveats on the underlying data.